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:
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.
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:
Packet leaving the server if trace is off:
or, if trace is on:
APRS is a registered trademark of APRS Software and Bob Bruninga, WB4APR.
copy from 100watts forum..
73 from me