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