FELINET changes

proto/felinet.proto

@@ -4,7 +4,7 @@ package felinet;
 service Handler {
     rpc Login(LoginRequest) returns (LoginResponse);
     rpc PushPackets(stream PacketIn) returns (PushPacketResponse);
-    rpc GetPackets(PacketFilter) returns (stream PacketOut);
+    rpc GetPackets(PacketRequest) returns (stream PacketOut);
     rpc Ping(PingRequest) returns (PingResponse);
 }
 
@@ -20,17 +20,28 @@ message LoginResponse {
     bytes uuid = 4;
 }
 
-message PushPacketResponse {}
-
 message PacketIn {
     bytes raw = 1;
     bytes uuid = 2;
 }
 
+message PushPacketResponse {}
+
+message PacketRequest {
+    repeated PacketFilter filters = 1;
+    bytes uuid = 2;
+}
+
 message PacketOut {
-	bytes raw = 1;
+    bytes raw = 1;
+}
+
+message PingRequest {
+    bytes uuid = 1;
 }
 
+message PingResponse {}
+
 message PacketFilter {
     oneof filter {
         uint32 all = 1;
@@ -38,7 +49,6 @@ message PacketFilter {
         CallsignFilter dest = 3;
         uint32 heard_seconds = 4;
     }
-    bytes uuid = 10;
 }
 
 message DistanceFilter {
@@ -51,9 +61,3 @@ message CallsignFilter {
     string callsign = 1;
     uint32 ssid = 2;
 }
-
-message PingRequest {
-    bytes uuid = 1;
-}
-
-message PingResponse {}

standard.tex

@@ -712,8 +712,8 @@ FELINET nodes communicate with each other via gRPC. A FELINET server implements
 
 \noindent There are a few points of note to clarify.
 \begin{itemize}
-\item In $Packet.raw$, the value is a semi-encoded CATS packet.
-\item In $Packet.filter$, a value must be specified.
+\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.
@@ -721,11 +721,11 @@ FELINET nodes communicate with each other via gRPC. A FELINET server implements
 
 \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. The $Login$ endpoint returns a UUID, which should be passed in future requests for maintaining state.
+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 even blindly accept all credentials. This endpoint is meant to be as flexible as possible. The $Login$ endpoint returns a UUID, which must be passed into future requests. This UUID is used to track state.
 
 \subsection{Filtering}
 
-When a FELINET node calls the $GetPackets$ method, it must specify a filter, which is 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. These filters cannot be mixed and matched --- only one can be used as a time. However, it is possible to call the $GetPackets$ method multiple times at once, although this is generally not recommended. The filter types are as follows:
+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.