By
To TCP, or not TCP, that is the question. Whether ‘tis nobler in the mind to suffer, suffer you shall not. In this recurring series, Sam Smallman will attempt to explain the transport layer and join the dots from forming an OSC packet, to understanding addresses and subnets, to finally sending a message in a variety of different ways.
In my previous article, I referred briefly to the two important communication protocols that are used to transport messages across an IP network. These are the postmen to our postcards and are the backbone to our network society, used to send emails, view and interact with websites, along with sending DMX over a network, most notably via a protocol called streaming ACN (sACN). They are User Datagram Protocol (UDP) and Transmission Control Protocol (TCP).
UDP
The simpler of the two, UDP is a delivery service that works on top of the network layer, meaning it uses an IP address to transfer data from a source to a destination host but adds two features – Port numbers, which we now know from reading The Address, are used to identify specific services; and a checksum, which makes sure that the entire message arrives safely. So, in other words, a decent addressing scheme and simple error checking. That’s it.
Sending data via UDP isn’t as bad as throwing a paper airplane in the wind. You know the destination and you’ve made your best effort to get it there. You just don’t know if the message arrived. UDP is all or nothing, messages either arrive perfectly intact, or not at all.
UDP is typically used in the instances where you generally don’t mind whether or not a message arrived at its location, because you know another message with similar data will arrive shortly behind it. For example, DMX is transmitted roughly at 44Hz. You can easily allow for the loss of a couple of packets of DMX Data before it would be noticeable on stage. Other examples would be an application sending sound to light data or streaming live video from the internet.
UDP gets a lot of grief for being unreliable. Whilst this is true compared with the TCP alternative, there are many applications which take advantage of this. If you are sending time-sensitive data, such as VoIP call or DMX, then you don’t want your transport protocol wasting time retransmitting lost packets since the lost packet would arrive too late to be played anyway.
TCP
Reliable, ordered and error-checked delivery of messages, what more would you want? TCP, like UDP, offers port numbers to identify specific services, but also adds detection of lost, duplicated, or delivered out of order packets, requests re-transmission where necessary and rearranges everything so it all makes sense.
Where UDP could be thought of as sending a postcard via Royal Mail or USPS, TCP would be the equivalent of sending a text message, with “Send Read Receipts” turned on – I can see you’ve read my message Chris, I shouldn’t have to remind you via a blog post to reply!
“The drawbacks?” I hear you ask. TCP is optimized for accurate delivery rather than timely delivery. Re-transmission of lost messages and waiting for messages out-of-order comes at a cost, and that cost is time.
Which one should I use?
Before we make a decision we need to understand a couple more terms:
Unicast – A one-to-one association. Both TCP and UDP are capable of unicast messaging, which essentially means there are two devices/destinations within this type of communication. The sender and the receiver. TCP communication can only do this.
Multicast – A one-to-many association. Used for protocols such as sACN, it works like a subscription service. Each device, such as a Net3 DMX Gateway, subscribes to receive messages from a specific multicast IP address. These are, in fact, administered by IANA and should sit within the range of 224.0.0.0 – 239.255.255.255. The sender, such as one of our lighting desks, sends out sACN data. For universe 1 it would go to 239.255.0.1; any Net3 DMX Gateway set to output universe 1 would subscribe to that IP Address. Think of multicast as one-to-many, who have chosen to listen. Multicast is only available to UDP and works regardless of IP. Imagine, if you will, that you have a lighting desk set to an IP Address of 192.168.92.101 with a subnet mask of 255.255.0.0 outputting sACN data. It won’t matter that your Net3 DMX Gateways are 10.101.50.101 with a subnet mask of 255.255.0.0. They will still receive sACN data!
Broadcast – A one-to-all association. Broadcasting is like shouting at everyone in a room and not caring if they want to hear what you have to say, or like that drunk friend at a party who never knows when to be quiet. There are two broadcast addresses. The first, 255.255.255.255, will broadcast over the whole local network, despite subnet masks. The second broadcast address is worked out by using both an IP address and a subnet mask and will only broadcast to within that subnet. The broadcast address for our default IP addresses would be 10.101.255.255. It’s worth noting that broadcasting is seen as bad practice. It clogs the network and can produce broadcast storms. Because of this, many switches, and other network equipment and software, will limit the amount of broadcast traffic, or block it entirely.
Broadcast is only available to UDP communication.
It’s worth noting that when using these different methods of transmitting a message, multicast and broadcast require certain levels of configuration for messages to transit routers and managed switches.
Conclusion
So, hopefully you won’t be driven to destruction over networking anymore, and I can stop quoting Shakespeare like I know what it means. We’ve discussed that every device on the network needs its own IP Address; that Port numbers identify services on the device; and that there are two main ways for a message to be delivered. Where you want reliable and ordered messages, choose TCP, such as remotes, for our lighting desks. Where you want to send messages to multiple devices and need fast delivery such as DMX or sound to light, use UDP. When possible, use multicasting. If multicasting isn’t available, separate those devices onto a separate subnet and broadcast on that subnet.
In the unlikely instance you have any problems or questions, feel free to email Tech Support USA, not my email address: sam.smallman@etcconnect.com. We’re always happy to help!
