[aprssig] Digi Deduplication Behavior
andrewemt at hotmail.com
Wed May 21 16:59:45 CDT 2014
Note that there is no reason why non-APRS packets couldn't be digipeated (they did it in the old days, just not with the flood-fill aliases we use for APRS). Why such packets would be on the same channel as APRS traffic and using APRS flood-fill digipeat aliases is a different story. If such packets were on the APRS channel but not using APRS digipeat aliases like WIDEn-N, they would just die quietly because no APRS-specific digipeater would relay them (wouldn't match the digipeater's alias).
But there is no reason why other broadcast non-connected protocols, such as OpenTRAC, couldn't use APRS-style flood-fill aliases for digipeating. They just should stay off the APRS channels and use separate digipeater instances.
Andrew Pavlin, KA2DDO
author of YAAC (which supports other protocols along with APRS)
> Date: Wed, 21 May 2014 21:42:38 +0000
> From: wb2osz at comcast.net
> To: aprssig at tapr.org
> Subject: Re: [aprssig] Digi Deduplication Behavior
> Two packets are considered a match if the source, destination, and information parts match. The digipeater fields are ignored for the comparison.
> There is no point in comparing the control and protocol id fields because they are always the same for all APRS frames. Non-APRS frames would presumably be dropped before considering whether they were eligible for digipeating.
> A brute force implementation would need to store and compare up to around 270 characters for each packet. This could be a resource drain on a little 8 bit microprocessor.
> A common implementation trick is to store a CRC value instead to greatly reduce storage requirements and expense of comparisons. Not the original CRC of the frame, rather a new CRC computed from the source, destination, and information parts.
> It is very unlikely that two different packets will have the same CRC value especially so close together in time. Occasionally there could be a false match and a packet gets dropped when it shouldn't. Good enough for our purposes.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the aprssig