[aprssig] tactical call identifier packet
Wes Johnston, AI4PX wes at ai4px.comFri Jul 25 00:24:52 UTC 2008
- Previous message: [aprssig] tactical call identifier packet
- Next message: [aprssig] tactical call identifier packet
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Just to be a wet blanket.... (not really). What happens when you have non-interconnected nodes and I wander from one area to the next. Node A heard me 4 hours ago, Node B heard me 2 hours ago.... Node A is unaware that Node B heard me more recently... and both answer a query with different answers. Worse yet, I've (fer instance) wandered back into Node A's range but due to a collision, Node A didn't decode me and still think's my last posit is 4 hours old when I'm actually sitting under the node. This begins to sound like "the army way".... the right way, the wrong way and the Army way. Once, a long time ago, I thought caching positions was a good idea, but I came to see that it wasn't worth the effort. No data is better than bad/old data - unless you flag such data so the end user can take the data with a grain of salt. Now if you want to visibly depreciate a cached postion by marking it grey from the start, that might work... but we need someway to A)let the end user know that this station's info may not be valid, but is a best guess, B)Allow an actual position from the actual station to overwrite a cached postion display. Of course none of what I'm suggesting is to be done on the networkside, it's all for the clients to display properly. Wes On Thu, Jul 24, 2008 at 7:55 PM, Scott Miller <scott at opentrac.org> wrote: > > Anybody every thought about using something like a DNS server? Have one > > system that accepts inquiries about serial numbers and maps them to call > > signs. Since APRS acts a lot like a single broadcast domain clients that > > overhead a request-reply could just cache the entry, minimizing traffic. > > The mappings could be aged out of the cache and/or reverified > > periodically. Then you only have one place to update the mapping. I > > grant you doing this would require a change to all APRS clients but so > > would any major change. > > Yes. For position lookups and such, anyway. I seem to remember I had a > working prototype based on BIND, but I can't remember what I did with > the code. I think it's probably on the old Win2k server in the rack in > the garage... I'll have to see if it still boots. > > Or are you talking about on-air lookups? > > Scott > N1VG > > > _______________________________________________ > aprssig mailing list > aprssig at lists.tapr.org > https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig > -- Wes --- Where there's silence, there is no Hope. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.tapr.org/pipermail/aprssig/attachments/20080724/561a8b3c/attachment.htm
- Previous message: [aprssig] tactical call identifier packet
- Next message: [aprssig] tactical call identifier packet
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the aprssig mailing list
