-
Notifications
You must be signed in to change notification settings - Fork 0
GPSD Server?
As explained in the How does it work? section of this wiki, the GPSD server is an application or a daemon running on a GPS device.
GPSD servers usually provide TCP or UDP connectivity, depending on their design.
The Android application Share GPS provides a GPSD server available in TCP or UDP.
The TCP (Transmission Control Protocol) is a protocol based on handshake establishment. Packets of data are acknowledged, so the packets order is guaranteed. This means that it is reliable but heavy.
The TCP_NODELAY socket option allows to send packets without waiting for a send buffer to be full. It is used by this program. But if the GPSD server does not use it, useless latency is introduced.
The UDP (User Datagram Protocol) is a protocol simply transmits datagrams with no check. There is no actual so-called connection. The packets order is not guaranteed, so the network can change the order of packets. This means that it is light but not so reliable.
In general, a client bounds outgoing connection with a random local UDP port, let's say 53964
(normal UDP).
Let's say that the GPSD server is set to use the default UDP port 2947
.
Here is a small exchange:
- Request: source port
53964
& destination port2947
- Reply: source port
2947
& destination port53964
The GPSD client receives the answer on its bound port. It can treat the answer.
Well, this is not so usual but it is possible. What I call Symmetric UDP is UDP where the server replies with a destination port that is the same as its local port. For instance, Share GPS uses symmetric UDP.
Let's see what happens with a symmetric UDP server, using a normal UDP client:
- Request: source port
53964
& destination port2947
- Reply: source port
2947
& destination port2947
The GPSD client does not receive the answer. The operating system finds no program bound to the local UDP port 2947
when it receives the packet: it gets destroyed.
The GPSD server ignores the source port of the request. We need to force the source port on the client instead of using a random number. That is what I call symmetric UDP.
Let's see how it works now with a symmetric UDP client:
- Request: source port
2947
& destination port2947
- Reply: source port
2947
& destination port2947