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

PSPunch shima at pspunch.com
Tue Mar 3 10:44:31 CET 2009


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

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.

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.


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/


I have yet to learn and may be wrong.
Please excuse me if this has already been done.

--
David Shimamoto




More information about the Pd-list mailing list