ZeroMQ

More About UDP

So, we have discovery and presence working over UDP IPv4 broadcasts. It’s not ideal, but it works for the local networks we have today. However, we can’t use UDP for real work, not without additional work to make it reliable. There’s a joke about UDP, but sometimes you’ll get it, and sometimes you won’t.

We’ll stick to TCP for all one-to-one messaging. There is one more use case for UDP after discovery, which is multicast file distribution. I’ll explain why and how, then shelve that for another day. The why is simple: what we call “social networks” are just augmented culture. We create culture by sharing, and this means more and more sharing works that we make or remix—photos, documents, contracts, tweets. The clouds of devices we’re aiming toward do more of this, not less.

Now, there are two principal patterns for sharing content. One is the pub-sub pattern, where one node sends out content to a set of other nodes, all at the same time. The second is the late joiner pattern, where a node arrives somewhat later and wants to catch up to the conversation. We can deal with the late joiner using TCP unicast, but doing TCP unicast to a group of clients at the same time has some disadvantages. First, it can be slower than multicast. Second, it’s unfair since some will get the content before others.

Before you jump off to design a UDP multicast protocol, realize that it’s not a simple calculation. When you send a multicast packet, the WiFi access point ...