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 _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list