John Gibson

I'm working on a laptop orchestra piece that requires a conductor machine to send cues and other data to many clients at once. At first I tried udpsend/receive objects, but occasional lost packets make this a bad solution, since my application can't tolerate any lost or reordered data.

So now I'm working with net.tcp.send/recv. Amazingly, I get terrible results with this: packets going to the wrong machine (verified by prints of data to the Max window), and net.tcp.send not reporting failure to deliver packets that were never received by the destination machine.

I suspect this could be because I'm using a single net.tcp.send object in the conductor and switching destination addresses on the fly (and quickly). Perhaps this object is not designed for on-the-fly address changing? Do I need to create a net.tcp.send object on the conductor machine for each client and keep net.tcp.send's address constant?

Is there any solid Max5-compatible alternative to net.tcp.send -- one that doesn't depend on java and is able to report failures with the failing destination address as well as the data that didn't get received?

tcp-networking

Not knowing any details about your project i thought:

If timing and sync is so important maybe it would be worth to consider good old midi again... not very versatile but very reliable...

Not knowing any details about your project i thought:
If timing and sync is so important maybe it would be worth to consider good old midi again... not very versatile but very reliable... 

Thanks for your reply. It's always good to consider using the low-tech approach where possible!

Unfortunately, in this case I want things to scale to as many as 16 or so machines, and dealing with MIDI hardware for all those people would be an extra hassle.

Via an off-list response to my question, I'm now just about certain that my problems stem from a misunderstanding of how net.tcp.send is supposed to work: it isn't likely to do well when asked to change the destination address frequently and rapidly.

jan74 wrote on Fri, 18 September 2009 11:11

jan74 wrote on Fri, 18 September 2009 11:11Not knowing any details about your project i thought:
If timing and sync is so important maybe it would be worth to consider good old midi again... not very versatile but very reliable... 

Changing the port/ip address very fast is not a really a good idea, using multiple 

Changing the port/ip address very fast is not a really a good idea, using multiple mxj net.tcp.* would much more optimized.


TCP networking