[aprssig] Digi Deduplication Behavior

[Andrew P.]

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...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20140521/2974351f/attachment.html>