Data may be sent from your instruments to your app by one of two protocols: UDP or TCP. Whilst some apps, and some Wi-Fi gateways, support just one or the other of these, if you have a choice which is the best option? Let's first cover some basics, then look at both in turn over networks in general, and then add in some peculiarities of Wi-Fi, before drawing some conclusions.
To make a connection between two pieces of software over a network, each requires an IP address that identifies the device the app is running on (or, more precisely, its network port), and a port number (the connection within the device). Many data protocols have standard port numbers, e.g. port 80 is used for HTML, which brings web pages into your browser; the registered port number for NMEA data is 10110, though a significant number of apps don't follow this, and use their own port number. These may be seen as being analogous to a street address and a flat number (or apartment number in America) within the building.
Network connections can be unicast, broadcast or multicast. Unicast connections are point to point, so there is a dedicated connection between the applications running at each end - in our case the Wi-Fi gateway server at one end, and the marine app at the other. Broadcast connections are, as you may expect, when an application just squirts out data on a given port regardless, and other apps can decide to receive it or not. For this, a number of publicly known IP addresses are used (e.g. 255.255.255.255). Multicast is similar to broadcast, in as much as it is also one to many, but instead of broadcasting on a public address, a specific address (in the multicast range) is used, and listeners need to subscribe to the service using the specific IP address and port number - but the sender never knows which (if any) devices are listening in. A point to note is that with a unicast connection there can be two way communications, whereas with broadcast or multicast this is not possible (without some deep network jiggery pokery).
TCP is a bi-directional unicast protocol with guaranteed delivery - the recipient of the data sends an acknowledgement, and if this is not received the data is re-sent. There is some network overhead for the acknowledgements, but on a typical marine network this is not significant. This sounds ideal, as for example the app can both receive GPS and other data, and send commands out to the autopilot, plus the data is guaranteed to get there. So why would anyone want to use anything else? There are a couple of drawbacks, for both the app user and the gateway manufacturer.
First, for the gateway manufacturer, to support TCP needs a more powerful processor with more memory - there is a need to support a separate network connection for each app that connects to the gateway, and the code needed to support multiple TCP connections is quite a bit more complex than to just broadcast on UDP, increasing development and hardware costs. Then, from the users' point of view, configuration is a bit more complex, as in addition to having to set the port number for the connection, they also need to work out what the IP address of the gateway device. This, then increases support calls to the gateway manufacturer. So, although technically great, in practice there are some drawbacks.
UDP data is generally broadcast or multicast - although unicast UDP is available, it is not (to my knowledge) currently supported in any marine related apps or NMEA Wi-Fi gateways.This means that it just goes in one direction, so the app cannot send data back into the wired NMEA network via the gateway, so no controlling of your autopilot, or using your phone's GPS as a backup to your boat's.
For the gateway, this makes life simple as it just sends out all incoming NMEA data, with no need to establish a connection for each client app. Also, for the app developer and user, broadcast UDP makes things simple as there is no need to ask for an IP address. And, as NMEA devices typically sends data out once a second, is it significant if we lose one boat speed reading, as the next will come in before the missing one is noticed - so long as we ignore NMEA sentences marking events, such as waypoint arrival or other alarms, and other sentences that are generally sent less often, such as routes and waypoints.
So far, we have just looked at connections over a standard, wired network, without the additional complexities of Wi-Fi - and this is where it get interesting! The first thing to understand is that Wi-Fi networks run at variable speeds, with the speed varying with the strength of connectionl, as slower data rates are generally more reliable - so the more bars on your signal strength display, the faster the network speed. And this is done on each connection between the access point (AP) and an individual client, due to some lower level communications. So, if the network signal is weak, the speed may throttle right down to 1Mbps. This is for all connections between the AP and the client device, shared between all apps using wireless data.
This is interesting, but with the short distances on a boat isn't the signal always strong, so why does this matter? With TCP it doesn't, but with broadcast or multicast UDP it definitely does, as the Wi-Fi Access Point isn't getting any feedback from the clients about the signal strength. So, to try and ensure that all listeners to the multicast or broadcast data receive the data, the Wi-Fi standards insist that the slowest possible data rate is used for broadcast and multicast connections.
Another consideration is that sending data over Wi-Fi is much more error-prone than sending data over copper wires. Sending data over a radio link is in itself unreliable, and furthermore there is much more interference, both between the overlapping Wi-Fi channels and also from other wireless transmitters using the same public frequency band, e.g. Bluetooth, Zigbee, and poorly shielded microwave ovens. To cope with this, the Wi-Fi protocol has its own low-level error correction protocol, but this is carried on normal network traffic, and so doesn't work when used with broadcast or multicast connections as there is no connection back to the AP. This is the real killer, as UDP transmission errors rise from about 1% over a wired network to 15% or more over Wi-Fi.
Whilst UDP has the benefits over lower hardware requirements and easier setup, the killer is that a high proportion of broadcast and multicast messages are corrupted when sent over Wi-Fi, and this is generally unacceptably high. In contrast, TCP is wholly reliable over Wi-Fi as it is a unicast protocol, and also has its own error correction. Furthermore, it has the benefit of being a bi-directional protocol. So, whenever there is a choice, TCP should be used in preference to UDP.