> 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 _______________________________________________ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
