[PD] pd and tcp: what to do against crashes?

Martin Peach martin.peach at sympatico.ca
Mon Mar 2 01:30:48 CET 2009


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






More information about the Pd-list mailing list