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

[Martin Peach]

Roman Haefeli wrote:
> On Sun, 2009-03-01 at 19:30 -0500, Martin Peach wrote:
>>  I think the blocking happens because the 
>> connection is gone, not because of the buffer overflowing.
> 
> i am not sure, if understand what you mean here. what i experience: when
> i overrun the buffer (by plugging out the ethernet cable to the client),
> the pd process of [tcpserver] is completely blocked after having sent
> $BUFFERSIZE bytes. it stays blocked, until i plug in the cable back
> again. the whole content of the buffer is sent after some seconds and
> the server pd instance responds again. this means, that even if the
> connection is not completely lost, a blocking of pd could occur. 

You can send until the buffer fills up, even if it isn't emptying. I 
think it blocks because it only checks for at least one empty space in 
the buffer but then sends more than that.

> 
> if the connection to the client is permanently lost, then there is no
> way to make pd responding again, after a buffer overrun occured.
> 
>> 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.
> 
> i can't follow here as well. it's not about trying to send an infinite
> amount of data in zero time. it's about not knowing the current
> connection condition, and because of that risking a drop-out. since the
> connection condition changes all the time, you cannot implement a
> self-adapting system in pd without knowing the internal buffer status
> (empty or not). so even if you send data with a fixed rate, it still
> could happen, that you trigger the buffer overrun.
> 
>

Well I guess empty and almost full are the same as long as we stick to 
single bytes.
So I made [tcpserver] send the messages one byte at a time. This latest 
version should not block, since it adds only one element to the buffer 
for each select call that says the buffer is still writeable.

Martin