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

Roman Haefeli reduzierer at yahoo.de
Wed Mar 4 01:21:04 CET 2009


On Tue, 2009-03-03 at 18:44 +0900, PSPunch wrote:
> > i really wonder, how other projects handle that. i mean, if several
> > people download a big file from apache, then a disappearing client
> > doesn't interfere with the other clients. i guess, in apache it is
> > solved by using threads. when using threads, one single thread doesn't
> > necessarily need to know about the buffer state, because it could be
> > blocked without harm to the other apache children. so it can try to send
> > as much data as possible.
> > is using threads the _only_ solution to deal with that problem? i guess,
> > it would overcomplicate the programming of [tcpserver], but you sure
> > know better...
> 
> >From my understanding, the alternative to using multiple
> threads/processes would be to set the socket to "non-blocking" and
> implement a Pd object that buffers the messages requested to be sent.
> Then attempts to retry sending what the OS once rejected should be made.

actually, there is no need for another external, if you implicitly meant
an external here. even more since [tcpserver] accepts only floats,
respectively lists of floats, the buffering can be done easily in pd.

> This will also involve giving the object a timer to call it a fault and
> close the socket if no bytes seemed to have traveled over a certain
> period of time.
 
when all of this is done in pd, one has much more control over it. i
guess, depending on the circumstances, the time limit might differ much,
depending on the application needed. i think, that also the kind of
action, that needs to be performed when the other side stops listening,
is dependent on the specific application of [tcpserver].


> This probably calls for some decision making in the design of the Pd
> object, such as how frequently to retry sending the bytes to the socket.
> I was thinking a [bang] may be flexible. Whether it be triggered by
> [metro] or [bang~], the one designing the patch would have the most
> control over how to deal with the results of the transfer.

yeah, i actually mean the same.


> I found this article helpful to gain basic understanding on which layer
> of the OS or library is responsible for the actions happening beneath
> the covers.
> 
> http://www.amk.ca/python/howto/sockets/


thanks. this will be my bed reading for tonight.

roman


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





More information about the Pd-list mailing list