[aprssig] Maximum APRS Packet Lengths

[Greg Trasuk]

Hi all:  See comments interspersed…

Cheers,

Greg Trasuk, VA3TSK


> On Nov 29, 2016, at 8:33 AM, Steve Dimse <steve at dimse.com> wrote:
> 
> 
>> On Nov 29, 2016, at 1:12 AM, Kenneth Finnegan <kennethfinnegan2007 at gmail.com> wrote:
>> 
>> 3. Where did all of these different lengths for comment fields come from?!
>> 
> Perhaps there was some actual math involved (like Bob fitting a list into an 80 character screen), but knowing Bob they might just be something like "67 characters seems about right for message length". They date back far enough that most if not all were set by Bob alone when he was the sole developer.
> 
>> 4. Do we want to consider loosening up the maximum packet length for some of these data types? 
>> 
> Before I'd even consider this discussion I'd want to see some proof that there is a need. If APRS has survived for twenty five years with these limits what exactly is the problem? The negative effects of having 255 byte packets floating around on RF are real, I'd want to see a demonstrated need before even considering an expansion.
> 

With modern programming languages and cryptography libraries, it’s now feasible to do authenticated messages.  This would be  very useful for remote control of repeaters and digipeaters.  The digital signature associated would take up around 50 characters in a message.  So a total of 67 starts to be very tight. 

>> 5. Does anyone happen to know the actual length limits on messaging for various devices out in the wild already?
>> 
> You break a lot more than devices. Since every APRS client has at its heart a database whether using an actual database manager or code of its own, each and every piece of APRS is at risk in such a proposal. 
> 
> The decision to store data in fixed or variable length records is something faced by everyone that writes APRS software. Storing messages in an array of say 70 character strings is very efficient in terms of programming time and CPU cycles, you know that the 25th message starts 24*70 bytes into the array and that a new message can easily reuse the slot of an obsolete message. The trade-off is you waste bytes of RAM and/or disk with short messages. If you go to variable length storage then you need to keep an index of the start of every message and you must perform more complicated garbage collection to reuse storage. You save bytes and lose cycles as well as introducing more complexity, hence more programming time and debugging. My guess is most people make the same decision I did, to use fixed length records, so findU breaks if the message length increases. It certainly can be updated, but if I spend that effort I need for there to be a good reason. I've never heard it.

So, are you saying that if someone did unleash a longer-than-the-standard-allows message onto RF, it would break infrastructure?  Crash clients, crash digipeaters, etc?  Because if that’s the case, that sort of needs to be fixed anyway.  Gotta do your bounds checking, etc.


> 
> Steve K4HG
> 
> 
> 
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> http://www.tapr.org/mailman/listinfo/aprssig