<img height="1" width="1" src="https://www.facebook.com/tr?id=1101141206686180&amp;ev=PageView &amp;noscript=1">

Enterprise Networking in LabVIEW 2

In the first installment of this blog series, we learned about how TCP can be used for 1:1 (unicast) communication and how TCP is a routable (can traverse the internet) protocol.  In this blog series, we learn about a focused use case for its counterpart UDP (User Datagram Protocol). The UDP protocol is known as a connection-less, best effort delivery protocol, unlike TCP, it contains no built-in error checking or high level functionality (e.g. connection setup/teardown). Example code included!

Although UDP lacks the connection-oriented functionality of TCP, it can traverse the internet/network often without issue.  Unlike TCP, n:n communication in UDP is significantly easier because of the lack of functionality.  UDP multicast, a method of n:n communication, can be likened to multiple people going in to known room and shouting at each other. The ‘room’ is identified using a multicast address and port. Valid multicast addresses are Class D addresses (224.0.0.0 - 239.255.255.255); we’ll be using the locally (non routable) multicast address of 239.1.1.1 and port 58431.

Unfortunately, due to UDPs lack of high level functionality, there are problems that may need to be resolved depending on your implementation:

  • How to identify the destination of messages broadcasted
  • How to know if a message was received
  • How to reconstruct data from multiple messages
  • How to respond if no response or acknowledgement received in a timely manner

Utilizing UDP, especially UDP multicast, will often require that you re-implement some TCP functionality. The example below shows a specific use case in which UDP multicast can be used on a local network to identify endpoints. Often static IP addresses are used to avoid this, but static IP addresses are not scalable.

 udp_packet_diagram.png

The packet is designed using cues from TCP, the start preamble and stop suffix help identify when a packet begins and end, while the frame data and message id help identify what kind of message and if multiple messages are being received what order the data should be reconstructed in.

VI Snippet showing a conversion of a packet (string) into a cluster.

VI Snippet showing conversion of a cluster into a packet (string).

This VI is used to encode/decode packets and verify the checksum when received.

VI Snippet showing the diagram of a UDP endpoint.

Using 'launch.vi' the example, multiple copies of this VI can be run and configured to demonstrate udp multicast operations on the primary network adapter. Example code can be downloaded here.

This kind of UDP implementation can be used for auto-detection of network endpoints spanning multiple networks where there are no static IP addresses assuming that UDP multicast routing is enabled and all of the endpoints are accessible. In the next installment of this blog series, we will develop a solution for advanced 1:N communication using the Transmission Control Protocol.