Hi Martin, IOhannes et al.
Martin, you asked me when I last tested mrpeach's [tcpserver] when I was mentioning the blocking issue. I did another test today with two computers connected over Ethernet. When plugging out the chord, I can simulate a client disappearing without the server noticing and thus filling the socket buffer on the server side. The behavior of [tcpserver] indeed changed since last time I tried. The test setup consisted of a server and a client on Computer A and a client on computer B. Client A sent messages that were broadcasted to both clients by the server. When plugging out the cable, client A (which is running on the same box as the server) did first still receive the messages. After a while, the server started printing lots of errors:
error: tcpserver_broadcast: couldn't create broadcast thread (11)
From then also client A didn't receive any messages anymore, although
the client was still sending messages to the server. After I plugged client B back in, it received all the messages sent by client A from the moment I unplugged the cable until the server started printing errors. However, all the subsequent messages (the ones, that triggered the errors) got lost.
The advantage of this behaviour is that the clients don't get blocked because the server is blocked. But this also means, that when the server is blocked, data is lost. Really problematic is the fact, that from the patch there is no way to detect such a data loss (or is there?). The old implementation (used still by [maxlib/netserver] and also [netsend]) blocks, but never loses any data. Though I think the new non-blocking behaviour is good, there should be a mechanism to know what got lost, so that a patch can handle such a situation and make sure to resend the data.
iemnet's [tcpserver] is again different, in that it buffers huge amounts of data without ever blocking. In my tests I wasn't able neither to block a client nor the server, nor to lose any data. Even if I let the client A sent a ton of data while client B was unplugged, after plugging client B back in, it received all the data that was sent in the meanwhile without dropping one single message.
@ IOhannes Though I like this 'stable'/reliable behaviour of iemnet's [tcpserver], I wonder what happens, if it keeps sending data to the unreachable client. Will it just go on and buffer everything until the whole RAM of the computer is consumed? If so, wouldn't it be more wise to just disconnect that client at some point in order to avoid the box running out of memory?
Roman