Sealand Systems Ltd logo Use this link to get straight to the content if you are using a screen reader. Lancing
West Sussex
Tel: +44 1903 209367
Mobile: +44 7802 651892
Enquiries@sealand.systems

Get Adobe reader

Get LibreOffice

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.

  • Cut down on inflexible and fault-prone serial connections.
  • UDP communication can be point to point, or point to multipoint.
  • UDP communication will not affect the sender if the receiver goes down.
  • UDP is simpler than TCP - there’s less to go wrong.

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. 

UDP addressing

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. 192.168.1.1:5678

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.

  • Do not use a port number below 1025.  This is because the numbers up to 1024 are reserved for various “well known” services and functions that are crucial to making networks work.
  • The highest port number is 65535 (216-1, if you wanted to know).
  • Do not use a port number that is already in use for something else at the same destination.
  • Avoid using port numbers that might clash with any software you are already using.  For example, EIVA Navipac likes to use ports in the 4000 to 4999 range.
  • It is perfectly possible to send different messages to the same numbered port on different machines – for example, port 5678 on one machine is a different destination from port 5678 on another machine.  But if you use the same port numbers in different places, it is easy to get confused.  There are so many ports available that it’s generally not worth the risk.

Choosing the IP address

You have an easy choice of two: 

Unicast

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 (127.0.0.1, meaning “this host”) to send data from one program to another running on the same PC.

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. 

Broadcast

Not 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 practice

Some examples

In the cases below, 10.112.72.255 is the broadcast address of the 10.112.72.0/24 subnet.

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.

Navipac UDP receive dialogue

2: Broadcasting to the network

Any host in the subnet listening on port 21002 will receive the data.

Navipac UDP send dialogue

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.

Moxa UDP receive port

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:

Moxa UDP address range

But for addresses that are not in a contiguous range, they must be entered individually as ranges beginning and ending with the same address:

Moxa UDP individual addresses

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):

Moxa UDP individual addresses

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:

  • Each serial port can send its received data to no more than four destination UDP ports.
  • Each incoming UDP port can be assigned to only one serial output port.

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:

Moxa UDP misconfigured broadcast

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 .1 to .254.  This means that 254 packets will be emitted onto the network every time data are available, instead of a single packet to the broadcast address.  This is unlikely to stress a modern network, but it does put a considerable load on the Moxa, and in an extreme case it can make the Moxa unresponsive.

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 10.112.72.133.

Moxa UDP multiple ports

Sealand is very pleased to be a supporter of the Open Document Foundation, Linux Mint, and the Lancing and Sompting Churches’ Food Bank.

Valid HTML 4.01 Transitional

Copyright © 2006 - 2021, Sealand Systems Ltd.  Terms of use.
This page updated 29 April, 2021.  Please double-check any information before you use it.

Visit our ISP