About TCP connections - why sometimes it fails?

This forum is for discussing hardware (electronics) and software design aspects of multiplexers in general.
Post Reply
Luis Sa
Site Admin
Posts: 833
Joined: Thu May 04, 2017 4:12 am

About TCP connections - why sometimes it fails?

Post by Luis Sa » Mon Feb 28, 2022 8:23 pm


There have been some doubts and complaints about TCP connections in all the 3 multiplexers (Nmea2Wifi, Nmea3Wifi and Nmea4Wifi). This is another post about this problem. I will try use a simple (no technical) language.

When 2 devices communicate using TCP, one is the SERVER and the other is the CLIENT. The multiplexers are SERVERS. Before any data is exchanged, a connection needs to be established. Only CLIENTS initiate a connection. CLIENTS can not call (cannot establish a connection to) other CLIENTS. They can only call SERVERS. In our case CLIENTS are the apps (OpenCPN, SeaWi, Navionics, ...) that send/receive data to/from the multiplexer (the SERVER). So the CLIENTS( the apps) need to know the IP of the SERVER (the multiplexer) in addition to a common agreed TCP port. When an app (a CLIENT) calls the multiplexer, the message carries the IP of the destination ( or the IP that the multiplexer receives from an external network) and the IP of the app (the CLIENT). This IP is hidden from the users but the multiplexer will get it in the request from the CLIENT.

Now there can exist different types of CLIENTS. OpenCPN can create TCP connections for sending data, for receiving data or for both. Nmea0183Tester.exe (an Windows app that can be downloaded from this site can also create connections for transmitting and for receiving. Some apps only create connections to receive.

A second important thing to understand is that the multiplexer can only support TCP communication with ONE CLIENT at a time. When we set TCP>X we are telling the multiplexer to read data from the client that has requested a connection and to route it to X. On the other hand, when we set X>TCP we are telling the multiplexer to route to the connected TCP CLIENT any data received from X.

If a CLIENT that got a connection to the multiplexer is ready (is able) to transmit and to receive data, we never have any problem if we set X>TCP or TCP>X or both. The problem only can exist in the following case: a TCP client with transmit capacity only has connected to the multiplexer and we have X>TCP set. In order to explain this I need to be a bit technical. The multiplexer constantly tests the state of a boolean variable that we called IsTcpClient. That variable is true or false. If, for example, the TCP port is 0, that variable is false. If we set a valid TCP port, that variable can be false (if no CLIENT is connected) or true (if there is one CLIENT connected). If IsTcpClient is false, the multiplexer will ignore TCP>X and or X>TCP. Now return to our problematic case. IsTcpClient is true but the CLIENT only has transmitting capacity. As X>TCP is true, the multiplexer sends data to the CLIENT IP that is connected. The multiplexer expects an acknowledge from the CLIENT. But the CLIENT is not prepared to receive data. It will not send the acknowledge. The multiplexer will possible send something like this "Did you receive or not my last message? Do you need it to be sent again?" A lot of data accumulates inside the multiplexer buffers before it is sent to the TCP CLIENT. The multiplexer can crash!

That crash is not immediate. If you are in the described situation and you change the CLIENT to be a receiving CLIENT, the multiplexer will problem say "At least you answer to my request now!".

Finally - if the CLIENT is a receiving client only, and you have TCP>X set, there is no problem about that!

Regards, Luis

Post Reply