Newer
Older
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
\section{FELINET}
\subsection{Introduction}
FELINET is the Internet counterpart of the CATS standard. Internet gates are responsible for sending received packets to FELINET. Packets received over FELINET can be gated back to RF. Although not part of the standard, it is possible for gateways to move packets between FELINET and APRS-IS. Not all CATS packets can be represented in APRS, so it is preferable to use FELINET when possible.
FELINET is composed of one or more servers. Each server has a list zero or more upstream servers, which it forwards received CATS packets to. Downstream servers request packets from the upstream servers over the same link. Internet gates, or IGates, connect to servers in the same fashion. From the perspective of an upstream server, there is no difference between an IGate and a downstream server.
A FELINET server must discard any received packets that are bitwise identical to any packets it has seen in the previous 10 seconds. This prevents unintentional loops from repeating packets indefinitely and bogging down the network.
To prepare raw data for FELINET, it must go through the Whiskers and CRC section of The Pipeline. In other words, CATS packets are gated to the FELINET network before the Whitener section of The Pipeline. A CATS packet in this binary form is referred to as a ``semi-encoded CATS packet''. It is only ``semi-encoded'' because it does not pass through the end stages of The Pipeline.
\subsection{gRPC}
FELINET nodes communicate with each other via gRPC. A FELINET server implements a $PushPackets$ method, for streaming packets to the server, and a $GetPackets$ method, for streaming packets from the server. The Proto file which defines the FELINET interface is as follows:
\lstinputlisting[language=C]{proto/felinet.proto}
\noindent There are a few points of note to clarify.
\begin{itemize}
\item In $PacketIn.raw$ and $PacketOut.raw$, the value is a semi-encoded CATS packet.
\item In $PacketFilter.filter$, a value must be specified.
\item In $PacketFilter.filter.all$, the value given must be ignored. Protobuf does not have a null type, so a uint32 is used. Again, this value does not signify anything, so a compliant FELINET server must ignore it.
\item In $DistanceFilter.distance$, the unit is meters.
\item In $CallsignFilter.ssid$, the valid values are 0-255, like in all other SSIDs. Protobuf does not have a fixed single-byte type, so a uint32 is used instead. If an invalid value is supplied, the server must reject it, and close the stream.
\end{itemize}
\subsection{State}
FELINET servers require some amount of state tracking. This is done by passing a V4 UUID into every request. The client is responsible for generating this UUID.
\subsection{Authentication}
FELINET defines a $Login$ endpoint, which is meant to be used for authentication. The exact usage of this endpoint is up to the server. For example, it may be used to allow any access, it may be used to allow write access, or it may not be used at all. This endpoint is meant to be as flexible as possible.
\subsection{Filtering}
When a FELINET node calls the $GetPackets$ method, it must specify an array of filters, which are used to limit what packets are sent to the node from the server. This is done primarily for bandwidth reasons. As such, the filters are very coarse. It is the node's responsibility to filter more on the client-side if required. There are several types of packet filters. When multiple filters are specified, packets which match any filters will be passed to the node. The filter types are as follows:
\begin{description}
\item [All] No filter. All valid packets the server receives will be forwarded to the node.
\item [Distance] Return only packets containing a GPS whisker within the specified latitude (degrees), longitude (degrees), and distance (meters).
\item [Callsign] Return only packets containing the specified callsign/SSID pair. This pair can appear in an identification whisker, route whisker, or destination whisker.
\item [Heard] Return only packets containing a destination or future hop that has been reported to the FELINET server by us in the last $n$ seconds. The value $n$ is specified in the filter. For example, if we send a packet to FELINET with a destination callsign/SSID pair of (ABCXYZ, 6), and less than $n$ seconds later, FELINET receives a packet with (ABCXYZ, 6) as a destination, that packet will be sent to us.
\end{description}
\subsection{Pings}
When a UUID is not used for a period of time, the FELINET server may choose to deallocate its corresponding state. This can be problematic for services that open a connection to FELINET but only send or receive data sparingly. The solution is the $Ping$ endpoint. This endpoint allows ``refreshing'' a UUID, and should be called every 10 minutes for as long as the UUID is used.