Recently, I’ve been thinking about building a blockchain system as an exercise to better understand distributed ledger technology. As part of this thought exercise, I’ve been thinking about simplifying and optimizing process of sharing state between many nodes in a network which has led me to playing around with the UDP protocol. This post explores a naïve peer discovery implementation using UDP multicast. With all the modern languages and tools we use, it’s easy to forget how simple yet powerful some low-level protocols are.
UDP is considered part of the transport layer alongside TCP. Unlike TCP, UDP is a unreliable and connectionless protocol that does not guarantee delivery or order of messages. The protocol is, however, much simpler and faster and supports broadcast and multicast. Because of these properties, UDP should be an excellent protocol to use for any system that must emit its state to multiple subscribers. Examples of these systems are online game engines that must share state between clients, distributed systems where components must be discoverable, and a blockchain network.
I will use Node.js as an example of how to connect to and send messages to a UDP multicast group.
Here, choose the port that we will bind the socket to and the multicast address we will use. The multicast group address must be within the appropriate multicast address space. Much of the space is reserved, but you can still find some unassigned ad-hoc space such as 126.96.36.199-188.8.131.52.
1 2 3 4
Then, import some modules we will use and create the socket reference.
We bind the socket to our port specified above.
The socket is an instance of EventEmitter, so we can listen to a couple events:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
The ‘listening’ event is the first event that is fired after binding to the port. We catch this event and add ourselves to the multicast group. Then, we call
sendMessage every 2.5 seconds which sends a message to the multicast group.
1 2 3
Finally, we listen for the
message event and print any messages we see to the console.
Here’s the whole script:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
I can then run this script in 3 separate terminal sessions to see each process bouncing a message off my home router and communicating with one-another.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
Now for the bad news: UDP multicast is not supported by the vast majority of ISPs and cloud hosting providers which means it likely won’t work over the internet. There are workarounds, but given the added complexity, it is unlikely that UDP multicast is the best approach for sending information in a one-to-many and zero configuration scenario. UDP unicast is still a viable option, but unless we are sending massive amounts of data continuously, TCP (or HTTP) may be a better option.
The fact that UDP multicast is not viable on the global internet is quite unfortunate because it is clearly a very powerful tool for sharing state between systems. I’m sure there are bandwidth and security concerns to overcome in allowing this traffic but, if there were a financial incentive, I have no doubt that ISPs and hosting providers could figure out a way to make it work.