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

[Roman Haefeli]

On Sun, 2009-03-01 at 19:30 -0500, Martin Peach wrote:

> 
> But if you know how much data you want to send you could set the buffer 
> to at least that size first.

yeah, this works for the very first time you send a chunk of data. the
next time, you don't know, if the buffer is already empty again or if
there is still some data left to be sent. in an environment like netpd
(and many others) you cannot make any assumptions about the internal
buffer state, since it would be just too complex. there are situations,
where there are problably some kilobytes sent in 0 logical time (on a
state dump, for instance), where most of the time there are only
sporadically distributed messages to be sent. 

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

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.


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

sounds exciting. do you think you could implement that?

roman


	
		
___________________________________________________________ 
Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de