[aprssig] APRS message numbers

[Lynn W. Deffenbaugh (Mr)]

Andrew Rich wrote:
> Can someone please explain to me what is the relationship between APRS 
> message numbers and payload ?
>  
> What can the APRS message number go up to ?
>  
> Is it two digits 0 padded ?
>  
> Can you send "TEST{34" and "TEST{45"
>  

Pull a copy of APRS101.PDF and read chapter 14.  Once you understand the 
"message number" or "ack" from there, check out 
http://www.aprs.org/aprs11/replyacks.txt to confuse yourself even more.


> What does the system / mobiles do with it ?
>  

First, there is no "system" to APRS, just a bunch of stations and 
computers that happen to speak a shared protocol.  There is no "central 
server" either.  APRS-IS is simply a pipe that carries APRS-formatted 
traffic further than RF can.

Basically a message can end in an open curly { followed by from 1 to 5 
alphanumeric characters.  The receiver is expected to take the 
characters after the { and send them back to the sender in another 
message whose only text is ackXXXXX where XXXXX are the characters after 
the { in the original message.

> What happens if I send "TEST TWO{34" is that considered a new message ?
>  

Every message is considered a "new" message.  Receiving stations 
(according to the spec) are expected to send back an ack for EVERY 
message received, even duplicates.

> Does the system rely on the fact that the message will either get 
> delievered or die off before the same message number is re-used ?
>  

The sending station doesn't rely on anything in particular.  Many 
stations will keep retransmitting a message until a corresponding ack is 
received or a retry counter expires.  The actual value of the characters 
following the { are up to the sending station.  If the sending station 
wants to re-use them, it can.  No station outside of the sending and 
receiving station is supposed to care.

If you are generating new message traffic, you become the sending 
station and should put your own ack code on it (if you want an ack).  If 
you are spoofing that the message came from some other station 
(considered bad practice on APRS), then you should NOT include an ack 
code as it will go back to that station that won't have any clue what to 
do with it.

Given this, you might begin to see why my design called for the message 
buffering server (not any existing thing within APRS RF or -IS) to do 
its own messaging to/from the sender and receiver and not just blindly 
and automatically buffer the message and deliver it later without 
permission.

Consider station A sending a message to station B suggesting that they 
meet for lunch.  Station B isn't on the air and doesn't get the message, 
so station A lunches alone.  Three days later, station B goes on the air 
and is "discovered" so the buffered message is delivered just before 
lunch.  Station B thinks it is new and goes to the suggested watering 
hole only to wait hours and finally leave disgruntled that Station A 
stood him/her up.  Not a good thing.

IMHO, any message buffer/re-delivery service needs to get the sender's 
permission before buffering a message and also needs to inform the 
eventual recipient that this message has been delayed.  And you can't 
muck within the message body as it may already be at the maximum allowed 
length.

Complicated, isn't it?

Lynn (D) - KJ4ERJ