> 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 _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
