Tel: +44 1903 209367
Mobile: +44 7802 651892
|Main Information Help Links Maritime Personal Small print|
Basics of UDP communication
Get confident with UDP communication, and you can do away with a lot of those pesky serial connections that plague an on-line survey system.
UDP is often termed Unreliable Datagram Protocol. The “unreliable” part refers not to erratic performance, but to the fact that UDP is “connectionless”, so there is no guarantee that the receiving end can be “relied” upon to do anything with the message (known as a packet) that it receives. The delivery of UDP packets that are properly addressed is a function of the network itself, which is generally highly reliable.
UDP packets can also be sent to the “broadcast” address, meaning that they could be received by any host in that network. Consider how many places you might want to send a ZDA telegram – just send it to the broadcast address and listen to it anywhere.
Why use UDP?
The “fire and forget” nature of UDP is powerful. If the receiving end does not deal correctly with the data, it will have no effect on the sending end. This is the same behaviour that is seen with old-fashioned serial connections, with the advantage that once you are confident using UDP, you no longer have all those extra bits of wire strung between devices. And you can make changes just sitting at your keyboard.
Why not TCP?
A Transmission Control Protocol session opens a connection like a telephone call – a point to point connection that is “answered” by the receiving end. Once a TCP connection is established, the protocol checks that each sent packet has been acknowledged by the far end. This might seem superior to just sending out UDP packets without being certain that they are received, but the downside is that a receiving end that is misbehaving can have a negative effect on the sending end. The sending end has to decide how to respond if the receiving end doesn’t answer, or messages are not properly acknowledged.
A UDP packet is sent to a “port” on the receiving host. To use the packet, the receiver must be “listening on the port”. If the receiver is not listening, packets will still be delivered to its network interface, but they will go no further. If the UDP packet is addressed to the network’s broadcast address, then it will be delivered simultaneously to the network interface of every host in the network, and any host listening on that port can make use of the packet.
A UDP packet contains the address of its sender, so it is possible for a receiver to decide to ignore packets (or to accept them) from any specified address. EIVA Navipac does this, which is why you have to enter the source address when setting up to receive data to a UDP port. Yes, there is a source port too – it’s usually chosen at random, and only a firewall administrator needs to care about it.
Port addresses are simply numbers, and there’s no shortage of them, with a valid choice of more than 64,000 per host. The destination is often expressed using the shorthand, <IP address>:<port number>, e.g.
Choosing the UDP port
With such a large choice, are there limitations? Very few. In fact, the only really necessary thing is to avoid using a port number that is already in use.
Choosing the IP address
You have an easy choice of two:
If you only want to send the UDP telegrams to one destination host, then you must use its address, which is its network address if it is a different PC, or the loopback address (
More than one destination
If you want to send data to every (or nearly every) host on the network, then for efficiency you should use the broadcast address. If you want to send the data to a smaller number of locations, you might configure multiple unicasts with each one going to a single address, but you ought also to consider using the network’s broadcast address, as using broadcast means that the data are only transmitted once.
The equipment or program that is sending the data might have limitations. The examples of Moxa configuration, below, show how these particular devices allow a certain flexibility by letting you configure up to four ranges of addresses as targets. But perhaps you have a device that will only allow you to configure one target address, and in this case your only option for sending to multiple targets on your network would be to use the broadcast address.
BroadcastNot only is using broadcasts less work, but you will cut down on network traffic by sending just a single broadcast for each message rather than several unicasts, one to each address. You can also add receivers at any time without needing to change the sending end, and you can still receive the broadcast on the machine that sends it, just as you would if you sent to the loopback address.
You should know the broadcast address, but if you don’t, then you need to look at what your network mask is, and work it out. If I get around to writing a simple page on subnetting, I’ll add a link here. Until then, Google is your friend.
Caveat: There is a class of devices that always send data over UDP, because a serial connection would be too slow. These are generally devices that send high volumes of pictorial data, like sonar sets or screen senders. It is not inherently wrong to send data from these devices to the broadcast address if you have a good reason. Your network will cope with it, but the down side is that the data will arrive at the interface of every host on your network. Hosts that do not need the data will simply drop it, and most modern PCs will have no difficulty with that. But underpowered devices such as many proprietary network interface devices, might suffer performance problems when hit with large quantities of data that need to be dropped. If you find that you must broadcast data, but you have hosts on the network that cannot cope with the volume of packets being received, then your only option is to use an isolated network for the high-traffic devices.
In the cases below,
1: Receiving into Navipac
Some software only needs the UDP port number, but Navipac also checks the source address, so the figures in the dialogue below are source address and destination port.
2: Broadcasting to the network
Any host in the subnet listening on port 21002 will receive the data.
3: Receiving to a Moxa serial device server
Only a single entry is required. The UDP port number is entered as the “Local Listen port” for the serial port in question.
4: Sending from a Moxa serial device server
The sending configuration of a Moxa makes provision not simply for single destination addresses, but address ranges. To send to just one address therefore requires the “Begin” and “End” addresses to be the same. To send to two addresses (or more) can then be done in two different ways. If the addresses happen to be adjacent numerically, then they can be combined into a range, thus:
But for addresses that are not in a contiguous range, they must be entered individually as ranges beginning and ending with the same address:
5: Broadcast from a Moxa serial device server
It follows that to send a broadcast from a Moxa, the broadcast address must be entered as both the beginning and ending of the range (Note, below, the risk of denial of service if this configuration is not done correctly):
Considerations for Moxa serial device servers
Moxa’s options for sending and receiving UDP telegrams are versatile, but not totally flexible. There are minor limitations which are reasonable for practical purposes:
Risk of Denial Of Service
Because of the option to configure a range of addresses, there is a possibility of a serious misconfiguration which might happen when attempting to set up a broadcast. A naive user might expect to set up a broadcast thus:
This configuration will work, but what it actually does is to instruct the Moxa to send a unicast packet in turn to each of the hosts in the range from
Limit on assigning incoming UDP ports to serial ports
Because of the “one serial port” limitation, it is less straightforward to use a Moxa to output the same data on several ports at once (using it as a splitter, or fan-out). Because each serial port must listen to a different incoming UDP port, the sending end would have to set up multiple outputs, each going to a different UDP port at the Moxa’s address. If the sending end were a Moxa, then the limitation of four destination ports would also apply. As an example, the Moxa below was configured so that the same data could be output from two ports on the destination Moxa at