103 lines
4.3 KiB
Markdown
103 lines
4.3 KiB
Markdown
|
|
APRS-IS UDPPEER2 protocol
|
|
----------------------------
|
|
|
|
This is an attempt to document a new UDP based protocol for passing APRS-IS
|
|
packets between hub servers.
|
|
|
|
Work in progress. Not finished.
|
|
|
|
|
|
Background
|
|
-------------
|
|
|
|
Currently APRS-IS packets are transmitted between peers (between aprs2.net
|
|
hubs and aprs.net core servers) in UDP frames, simply by putting each 1-line
|
|
packet inside an UDP frame without any other information. Since there is no
|
|
sequence numbering, there is no statistical information on any possible
|
|
packet loss, or other issues, for peer sessions. There is also no
|
|
authentication, so UDP frames can be injected by spoofing the source IP
|
|
address. The current protocol is not extensible, additional information can
|
|
not be added before or after the packet. Therefore, a new protocol would be
|
|
useful for adding link-layer information and future extensions.
|
|
|
|
The Open Glider Network has started to use aprsc, with packet rates
|
|
exceeding 600 packet/second. Running peering sessions with UDP would cause
|
|
unnecessarily high packet rates, as opposed to TCP which can coalesce
|
|
multiple APRS packets into a single TCP segment and IP packet. On the other
|
|
hand, it would be good to set up the UDP full mesh peering between their
|
|
nodes, so that the core interconnections would be more stable without TCP
|
|
backoff issues.
|
|
|
|
|
|
Proposal
|
|
-----------
|
|
|
|
Packets are transmitted over UDP using Protocol Buffers encoding, but only
|
|
after it has been confirmed that the other peer can process them. A
|
|
handshake protocol for detecting capable peers is documented. So far, only
|
|
the handshake protocol is documented here (work in progress).
|
|
|
|
Before a successful handshake is completed, peers can already transmit
|
|
packets using the old plain UDP format. The handshake is an opportunistic
|
|
upgrade method to the new protocol: if it doesn't happen, old protocol
|
|
is used as before.
|
|
|
|
Once an upgrade to the new protocol is made, a ping-pong polling
|
|
routine is started. Should it fail for more than 5 minutes, the sender
|
|
must revert to the old protocol, in case the peer would be downgraded
|
|
to software which does not understand v2 binary packets.
|
|
|
|
The Protocol Buffers encoding is chosen due to the following features:
|
|
* Small overhead, binary encoding
|
|
* Binary clean, can transport binary byte streams such as raw packets
|
|
and hashes
|
|
* Extensible - fields can be added without breaking existing receivers
|
|
* Has a simple, lean language to document and synchronize the protocol
|
|
structure and compilers to transform the specification to code
|
|
in various languages (C, C++, C#, Java, Python, Go...)
|
|
* Proven to work in large deployments (Google & friends)
|
|
* Fairly good documentation:
|
|
https://developers.google.com/protocol-buffers/docs/overview
|
|
|
|
|
|
Handshake
|
|
----------
|
|
|
|
The handshake packets are comment packets, starting with a '#',
|
|
so that they can be safely ignored by older server versions.
|
|
|
|
1. Peer 1 (SERVER-I1) transmits an UDP comment handshake packet,
|
|
saying it supports "v2" protocol, gives its Server ID, app version,
|
|
and a random token unique to this packet.
|
|
|
|
\# PEER2 v 2 hello SERVER-I1 vers aprsc 1.2.3.4 token hq736t7q63
|
|
|
|
2. Peer 2 (SERVER-I2), upon receiving the packet from a preconfigured
|
|
peer's IP address, replies, saying it also can do the "v2" protocol,
|
|
and returns the random token. If the peer does not understand v2,
|
|
it will not reply.
|
|
|
|
\# PEER2 v 2 ok SERVER-I2 vers aprsc 2.3.4 got hq736t7q63
|
|
|
|
3. Peer 1 (SERVER-I1), upon receiving this packet, with the correct token,
|
|
knows that Peer 2 will understand the v2 protocol, and can start
|
|
sending v2 data packets to it.
|
|
|
|
For compatibility with future versions, if Peer 2 receives a "v 4 hello"
|
|
packet, and does not understand v4 yet, it should respond with a "v 2 ok"
|
|
packet. Any additional keys and values after the token must be ignored, so
|
|
that further versions can add parameters in the hello packet.
|
|
|
|
Peer 2 will individually send it's own 'hello' packet (step 1) to confirm
|
|
that Peer 1 does v2. Receiving a 'hello' packet does not necessarily
|
|
mean that the peer would do v2 - the packet could have been spoofed.
|
|
|
|
A node can transmit an initial "hello" packet immediately after starting up,
|
|
and at regular intervals (once per 10 minutes?) when receiving non-v2
|
|
packets from a peer. This is to ensure that a peering link will bump up to
|
|
v2 protocol eventually, if one node is upgraded, or if the initial handshake
|
|
packets are lost.
|
|
|
|
|