Roman Haefeli wrote:
On Tue, 2009-02-24 at 21:15 +0000, Martin Peach wrote:
Roman Haefeli wrote:
--- Martin Peach martin.peach@sympatico.ca schrieb am Di, 24.2.2009:
Roman Haefeli wrote:
> On Mon, 2009-02-23 at 21:03 +0000, Martin
Peach wrote: Yes, I agree. I think a status outlet on the [tcpserver] could be extended later to have more messages. Some of the stuff that gets printed to the Pd window could go there and then it could be handled by the patch instead of the 'operator'. I don't want to keep adding more outlets, so it would output lists with a selector, like [comport].
i totally agree, that instead of adding more outlets it would be better to provide additional information on the same outlet with appropriate selector.
OK it's done for now, in svn. Each time something is sent, you get a "sent" message from the status outlet that gives the number of bytes that were actually sent and the client number. Also a [client( message with no data lists the connections using a "client" selector. The send function doesn't wait any more. If the number of bytes sent is zero, you have to try again. It all needs to be tested...
thank you for implementing those changes.
i finally had a chance (and time) to have a closer look and it turned out, that the additional information is actually no gain and this still doesn't allow to programm a non-blocking server. it seems, that the 'sent' message is output, when something was _added_ to the 'send' buffer. actually, we would need this message to appear when something was _removed_ from the buffer, which is when a message actually was sent.
Yes, because the actual buffer is hidden from the user. You should get a 'sent 0' message when it would block though, I don't know why you don't.
with the current implementation, the buffer still overruns without having the chance to know this beforehand. whenever i send a message to client, i get _immediately_ a 'sent 1 7' message, which i use to trigger the next message, etc. so buffer keeps filling and filling. when the buffer is full, [tcpserver] blocks pd. so, currently the situation is not different from the one before i have started this thread.
It's not supposed to do that. It should return 'sent 0' when it can't take any more, never block. Are you sending to the same client or many different ones? Can you post a test patch that will reproduce the bug? Something like this should stop when the buffer is full:
[bang][r stop] | | [until] | [send 1 7 7 7 7 7 7 7( | [tcpserver] | | | | | [route sent] | [select 0] | [s stop]
i don't know, how much control you have at c level over what is happening at tcp level. in order to solve the current issues at pd-level, information about either the current buffer size or amount of sent bytes (number of bytes removed from the buffer) would be required. i don't know how and if this is possible at all.
I don't think it's possible (but then I'm often wrong ;(). There might be an ioctl that will return the buffer size so you could know how much is safe to send at once.
i would be interested to read about the c functions providing tcp capabilities. may i ask where you got your knowledge about those?
From all over, but usually from the man pages for tcp, send, ioctl, and the like. For Windows, MSDN has a lot of info about winsock, which is very similar to unix sockets.
Martin