|
|
The "q-construct" is implemented on APRS-IS to add the following
capabilities to the Internet APRS transport mechanism.
- APRS-IS Entry Identification
- Support for a Future Authorization Algorithm
- Support for Loop Detection
- Support for Automatic Loop Protection
- Compatibility with Existing IGate and Client Software
- Only Server Support Needed for Implementation
The currently defined q constructs are:
Server Generated:
- qAC - Packet was received from the client directly via a
verified connection (FROMCALL=login). ; The callSSID following the qAC is
the login of the client.
- qAX - Packet was received from the client directly via a unverified
connection (FROMCALL=login). ; The callSSID following the qAX is the login of the client. ;
This construct is in addition to the TCPIP*/TCPXX* construct currently in
place.
- qAU - Packet was received from the client directly via a UDP
connection. ; The callSSID following the qAU is the login of the server.
- qAo - (letter O) Packet was received via a client-only port, the FROMCALL
does not match the login, and the packet contains either a ,I or qAR construct
where the indicated IGate matches the login.
- qAO - (letter O) Packet was received via a client-only port and the FROMCALL
does not match the login.
- qAS - Packet was received from another server or generated by this
server. ; The latter case would be for a beacon generated by the server. ;
Due to the virtual nature of APRS-IS, use of beacon packets by servers is
strongly discouraged. ; The callSSID following the qAS is the login or IP
address of the
first identifiable server (see algorithm).
- qAr - Packet was received indirectly (via an intermediate server)
from an IGate using the ,I construct. ; The callSSID following the qAr it the callSSID of the IGate.
- qAR - Packet was received directly (via a verified connection) from
an IGate using the ,I construct. ; The callSSID following the qAR it the callSSID of the IGate.
Client Generated:
- qAR - Packet is placed on APRS-IS by an IGate from RF. ; The
callSSID following the qAR it the callSSID of the IGate.
- qAZ - Packet is generated by the server/client/IGate and should not
be propagated. ; The callSSID following the qAZ is the callSSID of the
server/client/IGate. ; This is normally used for connection messages such
as messages to USERLIST.
- qAI - Trace packet. ; This packet tells each server to add
login identification to the packet. ; This packet starts with the callSSID
of the originating station following the qAI. ; See algorithm for more
details.
Client generated q constructs will be verified if a new authorization
algorithm is created.
Servers MUST have unique logins from any other server/IGate/client that
insert data onto APRS-IS. ; This is to prevent packets from being
erroneously detected as looping. ; For instance, if my server's login is
AE5PL and my weather client is AE5PL, my server will see ,qAC,AE5PL and consider
this packet a looped packet. ; As logins can be any combination of 9
alphanumeric characters, this should not pose a problem.
IGates which append IGATECALL,I to the end of packets and which are directly
connected to a server which supports the q construct will have the IGATECALL,I
converted to qAR,IGATECALL, qAr,IGATECALL, or qAo,IGATECALL to support the extended capabilities of the q
construct.
Servers will have the ability to selectively enable tracing on all packets
through server configuration. ; This must be used judiciously and only when
a loop condition is suspected due to the increased bandwidth demands that
tracing creates.
q constructs will only appear on APRS-IS and are not to be used elsewhere due
to bandwidth considerations.
For example, this is what happens to a packet without a q construct which
enters the system via a verified connection:
Original packet:
AE5PL>APRS,TCPIP*:payload
Packet leaving the server if trace is off:
AE5PL>APRS,TCPIP*,qAC,AE5PL:payload
or, if trace is on:
AE5PL>APRS,TCPIP*,qAC,AE5PL,AE5PL-JS:payload
|
