Clients may request that their feed from the server be sent via UDP instead of
TCP. This significantly reduces the IP traffic between the client and the
server as there is no acking that occurs. To make use of UDP, the client
must tell the server via the TCP login line which UDP port it is listening on.
If the server supports UDP transmission, the server will send all APRS lines to
the client via UDP while maintaining the TCP connection to ensure the client is
still there. Each APRS line is in its own UDP packet with no carriage
return/line feed sequence.
As an example, let's say I have a client that connects to first.aprs.net port
10152 and request a UDP feed. This is what it looks like:
TCP |
UDP |
From Client |
From Server (port 10152) |
From Client |
From Server (port 10152) |
Connect to first.aprs.net TCP port 10152 |
#javAPRSSrvr xxxxxxx |
|
|
user AE5PL-TS pass -1 vers t1 1.2 UDP 54321 |
#login AE5PL-TS unverified |
|
|
AE5PL-TS>APRS,TCPIP*:my posit packet |
|
|
XYZ>ABC,TCPIP*,qAC,CDE:my packet |
|
#javAPRSSrvr xxxxxxx every 20 seconds |
|
... (all packets send from UDP port 10152 to UDP port 54321) |
Disconnect from server TCP port 10152 |
|
|
|
Note that nothing ever goes from the client to the server via UDP. This is a one-way data flow. If the server does not support UDP on that
client port, it simply ignores the UDP command and sends all packets via TCP as
normal.