How to get a message every time udp connection drops?
Hi all,
I've built a simple two patch system to use on two separate machines that need to play both the same video in synch.
The "master" machine uses a playbar object and transmits position to the second one (via udp) that stays synched.
The problem arises if/when the connection between the two drops, the video in the slave machine just stops.
I've noticed that if the bangs for the qtmovie in the slave machine come from within the slave machine and not from the master, the video keeps going on even if the connection is dropped. As this is not really elegant I'd like to use a switch that basically would switch the source of the bangs for the slave qtmovie: via udp when connection is ok and internal when connection drops. To do so I'd need udpreceive, udpsend or any kind of object to output any kind of message when the connection drops. Are you aware of any object that would output a essage if the connection gets down?
thanks a lot
niccolo
Hi,
a UDP connection can never drop. The reason is, that there's no such thing as a 'UDP connection' ;-)
The whole point behind UDP is that the UDP sender will just send packets to the network without even knowing if there is anybody listening on the other end. Try it out: even if you send UDP messages to non-existing addresses, you'll get no error reports on the sender side.
If you want to make a managed connection to a remote host, you should use TCP. A managed connection means two things: (1) the receiving host will confirm every received packet to the sender and if a package doesn't arrive, then the sender will attempt to send it again and (2) the receiver side will synchronize the incoming packets, that is, even if the packets arrive in wrong order, the receiver will output them in the same order as how they were sent. Obviously, this type of connection will also report you if the connection was broken. However, you should be a bit careful with TCP, as it might generate a much bigger traffic than a simple UDP. My general experience is that for continuous, control-rate messages (where a dropped value here-and-there shouldn't count that much) you should use UDP; for switches, single bangs etc (where it actually matters to get every single message) you should go with TCP.
I have a couple of objects in my library (see https://cycling74.com/forums/announce-the-sadam-library-version-2012-10-08 ) that realize TCP connections for Max. You can also use the MXJ objects [net.tcp.send] and [net.tcp.recv].
HTH,
Ádám
P.S. Technically, it's not completely true that you can't create a UDP connection; if you create a datagram socket in your program and then connect it, then that would, in fact, be a UDP connection. However, as far as I can tell, that would practically be the same as a TCP connection. To tell the truth, I've never seen any software that would have used datagram sockets combined with connection attempts...
It's not that UDP connections drop, it's that packets just sometimes don't get delivered. That is the nature of UDP.
You might want to think about a "flywheel" approach. In other words, use a local clock on your slave machine and have its speed "corrected" by the receipt of packets from the other end. If you occasionally need guaranteed commands to be received (like changing to a different location in the video) you might want to consider a hybrid approach. Ironically, having run into exactly the same problem sending text messages to iOS control surfaces, I wrote up a brief proposal for how to quickly add TCP support for this kind of thing with negligible impact on the code base and allowing UDP to continue to be used for continuous change. This approach should work just as well for your stuff allowing you to use Siska's objects for the guaranteed stuff.
See http://deskew.com/blog/?p=154 for more info.