TCP versus UDP

Discussion and support for the Nmea2Wifi multiplexer - a 2-input Nmea 0183 wifi multiplexer.
Post Reply
Luis Sa
Site Admin
Posts: 140
Joined: Thu May 04, 2017 4:12 am

TCP versus UDP

Post by Luis Sa » Sun Mar 03, 2019 1:45 pm


There are some differences between the TCP and UDP protocols. I am not an expert on Internet but I will try to explain the main differences focusing on the operation of the Nmea2Wifi multiplexer.

TCP is a connection type communication. Before any data is exchanged between 2 devices a connection should be established. It is like a phone call. If a person A wants to communicate with a person B, A makes a call. Therefore A needs to know in advance the phone number of B. If B does not answer, A will eventually give up. When B answers, the conversation takes place. If the line is noisy and some sentences are not understood, either A or B can ask for a repetition. The conversation is normally terminated by A.

This is also referred to as a "Client-Server" model where B is a Server and A is a Client. The Server should be ready to receive calls (connection requests) from clients. In our system, the multiplexer is the Server and the smartphones, the tablets or the PCs are Clients. So, when we configure the Client devices for TCP communication, we need to specify the IP address of the multiplexer (Server). This IP address is like the phone number of B in the above analogy. In phone calls voice messages are exchanged. In the Internet, the messages are datagrams consisting on packets of digital data. These datagrams also contain the IP addresses of the target and of the sending device. Therefore when a Server (the multiplexer in our case) receives a connection request from a Client, it will get the IP address of the calling device and will use it to answer/communicate with the Client. Generally, a Server can handle several Clients simultaneously. But this is not the case with the multiplexer. The multiplexer only handles one Client at a time.

It is also important to refer to port numbers. The Client and the Server must agree on which port number they will communicate. We will correct the previous statement. The Server and Client Applications must agree on which port number they will communicate. Port numbers expand the number of connections that can exist simultaneously. In the multiplexer there is just one single application. But, in a PC there may exist several applications running simultaneously. Different applications can communicate in the Internet at the same time providing that they use different port numbers.

We now explain some particularities of the TCP implementation in the multiplexer. When we set port number equal to 0, the TCP Server is not initialized. There will exist no TCP communication. When a non zero port number is specified, the TCP server is initialized and becomes ready to receive connection requests. In the main loop of the software that runs inside the multiplexer, the multiplexer constantly checks if any Client made a request and sets a logic variable, called Client_Is_Available, which is either true or false and, if true, stores the IP address of the Client that requested the connection. If Client_Is_Available is true, the multiplexer does two things. Firstly, it looks for messages (sentences) received on the opened TCP connection. If or when a TCP message is received, it will be echoed on the P3 port if the "WIFI to P3" check box is set. Secondly, when a message (sentence) is received on P1 or P2 and if "P1 to WIFI" or "P2 to WIFI" check box is set, it will echoed that message through the TCP connection. We will return here, after we summarize the
behavior of UDP communication.

UDP is a connection less communication. It is like to place a letter on the Post Office. The letter is sent and we hope it will be delivered at the destination address. Because error correction is not implemented (no data repetition), the communication is very fast. In sailing boats this is quite acceptable as distances and noise are small. As in the case of TCP, the same port number needs be set both in the Server and in the Client. Also, when the UDP port is 0, the multiplexer will not initiate the UDP Server. There is also a special mode of communication called UDP broadcasting. In this mode, a Server or a Client uses as the target IP address the last IP of its sub-net ( in the present case). By doing so, all the IP addresses on the sub-net will take the message. Contrarily to TCP, this mode is "one to many". However, we must remember that the multiplexer AP can only accept 5 Stations at a time. The multiplexer uses UDP broadcasting. If the Clients also use UDP broadcasting, you only need to specify the port number. If the app you are using on the smartphone or on the PC, also requests an IP address in addition to the port number, you should enter

We now describe a particular situation that uses both TCP and UDP and call your attention for an error that may occur. Assume the following scenario. You use the multiplexer with an AIS receiver connected to the P1 port and with a PC running OpenCPN. You want to see the AIS targets on OpenCPN and you want OPenCPN to send commands to the autopilot connected to the P3 port. You also want that 2 members of the crew can see the AIS targets on their smartphones. With such requirements the multiplexer needs to be bidirectional. You could use UDP only, but not TCP only. The reason is the request for the 2 crew members. With TCP you can have only 1 Client. So we will discuss the use of TCP for the OpenCPN to the multiplexer direction and UDP for the multiplexer to the OpenCPN and crew apps direction.

At the multiplexer end, you set the ports numbers for UDP and TCP, the P1 and P3 baud rates and you check the boxes "P1 to WIFI" and "WIFI to P3". At the crew smartphone apps you set the same UDP port number and, possibly, the IP address if requested. At the OpenCPN end you set 2 connections - one UDP connection for input at the chosen port number and one TCP connection for output at the chosen port number and IP address.

It looks all OK but it is not! The arrangement works for some minutes but then it freezes. This error may occur in similar situations with different applications and so it is important to understand the problem and its cure. The error description follows. As explained above OpenCPN will start a TCP connection to send the autopilot data to the multiplexer. In consequence the multiplexer will see the logic variable Client_Is_Available as true. When a packet from OpenCPN arrives it will be echoed on serial port P3. Then an AIS message arrives at P1. This message will be echoed by WIFI. As both UDP and TCP protocols are active the AIS message is echoed at both ports (*). At the UDP port the message is just broadcast and forgotten. However at the TCP port, the multiplexer expects a confirmation from OpenCPN to be sure that the message was received without errors. But the TCP connection on OpenCPN was set for output only. So no acknowledgement will be sent back to the multiplexer. After a while the multiplexer freezes. The solution is to change the TCP connection on OpenCPN to be an output as well as an input. If it also set as an input, the expected acknowledgment that the multiplexer expects is sent. I hope this article is useful. Also read the post script which is relevant to the Nme4Wifi multiplexer.

Regards, Luis

(*) In the Nmea4Wifi multiplexer, instead of the "P1 to WIFI" check boxes there 2 check boxes: "P1 to UDP" and "P1 to TCP". Therefore in the described scenario we would check "P1 to UDP" and would uncheck "P1 to TCP". In that case the P1 received message would not be sent to the TCP port. If someone reports me of a case that requires such a setting, I would be available to change the Nmea2Wifi firmware to take this into account.

Post Reply