Roman Haefeli wrote:
On Sun, 2009-03-01 at 17:01 -0500, Martin Peach wrote:
So I added a [clientbuf( message to [tcpserver] to get/set the size of the send buffer. Apparently the actual buffer will be twice this size.
when i set the buffer to 10, i get a message: tcpserver_buf_size: client 1 set to 2048
when no cable is plugged in, pd blocks after the second 8-byte message, so i guess, that real client buffer is 10 and not 2048.
I think it really is 2048, the smallest the OS will permit, and the send is blocking for another reason. The OS is not required to set the size you ask for, the number [tcpserver] gives you is obtained by asking for the size after setting it to 10.
I'm still looking for a way to know if the buffer is so full that any further data will block.
it seems, that it would be more elegant to know, when it is empty. i think this is more useful, since then you know that you can send a message, which is <= buffersize without blocking pd. otoh, when you know, that it is almost full, then it is more likely to overrun the buffer with a big message.
But if you know how much data you want to send you could set the buffer to at least that size first. I think the blocking happens because the connection is gone, not because of the buffer overflowing. If the connection is present the buffer will be emptying as fast as the network can drain it, so just pacing the writes should work. Trying to write an infinite amount instantly won't.
It seems that even if the select() call returns OK there still may not be enough room for any arbitrary length of data. Probably I need to set the sockets to nonblocking.
what does that mean: setting sockets to non-blocking? will this cause the sockets to simply ommit data, that cannot be sent in time? if so, i think, that would be the worst solution of all.
It's kind of like running each send call in its own thread, so if something gets stuck it won't block everything else in the process. That's better than making a thread for each connection.
Martin