OK, thanks for finding that. I fixed it in svn, the way it is written above will not set SO_REUSEADDR because the parameter is false (0). Also it was #ifdeffed out except for IRIX. You should try an autobuild from tomorrow.
I'll definitely try it out but I am not convinced this is the problem as my port timeout adjustments system-side had no effect suggesting that the port was stuck in a different mode than TIME_WAIT. Could it be something wrong with the destructor?
Yes, that's because in tcp broadcast it sends individual packets to each client, which can eat up time. I suggest using udp for data and tcp for control, as udp broadcast will send one packet to everyone on the subnet.
I understand that but we cannot use UDP as that one at times does not go through when there is a lot of traffic (and we do use UDP for non-critical monitoring in addition to TCP). Last thing I want to have happen is someone missing a critical cue due to dropped UDP packet (which in our case happens a lot--before we switched to TCP I had to press button for the same cue 3-4 times before it was actually received by everyone).
Couldn't the broadcast command spawn a separate thread that then services all clients to avoid xruns?
Not sure which version you have, but try it now: http://pure-data.svn.sourceforge.net/viewvc/pure- data/trunk/externals/mrpeach/net/tcpserver.c?view=log
Will do.
Many thanks for your help!
Best wishes,
Ico