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'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.
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.
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de