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

[Roman Haefeli]

On Sun, 2009-03-01 at 22:53 -0500, Martin Peach wrote:
> 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.

exactly. if the next message is bigger than the left free space in the
buffer, pd is blocked. i guess, we mean the same thing.

> > 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.

ah, yes.. 

> 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.

can you tell me something about how to use it correctly? i just compiled
the newest version and still could prevent it from blocking pd. before
the blocking happens, i do _not_ get any message from the new outlet
from [tcpserver], such as 'sent 0'. so what happens is still, that i
send messages to it until it blocks. is it different on windows? do you
mind sending me a windows binary, if it is? 
is there anything i can do in terms of testing on linux?

roman






		
___________________________________________________________ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de