[aprssig] Gating Objects from Internet to RF (fina?l)

[Lynn W. Deffenbaugh (Mr)]

Hessu,

Thank you for your input to the EchoLink discussion and especially the 
considerations of tactical callsigns.

Rest assured that you won't need to worry about filtering the proposed 
EchoLink objects from aprs.fi.  I sent out two as a test and have placed 
the code into my configuration management archives for now.

I like your suggestion of throttling based on a steady-state rate and 
will continue to ponder that approach for any future projects I/we come 
up with for APRS-IS.

Lynn (D) - KJ4ERJ

Heikki Hannikainen wrote:
> On Wed, 22 Jul 2009, Lynn W. Deffenbaugh (Mr) wrote:
>
>> So, a tactical FromCall with NO visibility as to who actually 
>> injected the packet is ok?
>
> In the US it might be legal, over here in Finland it's a bit 
> uncertain, so we don't do it. But we only have one echolink station 
> here now, so it doesn't really matter now. :)
>
> When using a tactical fromcall, the real callsign needs to be present 
> somewhere, like another beacon packet which has the tactical fromcall, 
> and the real callsign in the comment field. Someone could even use 
> CWID to fulfill the word of the law, although that wouldn't be so nice 
> on the APRS channel.
>
> I agree with Bob Bruninga and Steve Dimse - the source callsign should 
> not be impersonated. Some people will be greatly annoyed by someone 
> else using their callsign, and they will be annoyed at the wrong 
> people (like me, as the aprs.fi operator). I would prefer you using 
> your own callsign, so that we could gate it on the network here, too, 
> maybe, some day.
>
> I might have to filter this out of aprs.fi, because of the map 
> cluttering effects. At least I'll have to provide users a method to 
> filter it out from their view, and preferably without removing all 
> other objects. A consistent source callsign would probably be the 
> cleanest way to do this (unless there is a unique symbol for echolink 
> gateways). Most people really look at the APRS map view of the area 
> they live in. After a few weeks, everyone will know that there are a 
> few echolink gateways in their area, they will have them configured in 
> the memory banks of their radios, and they won't want to see them on 
> the map any more. The're mostly interested in the stuff that is new or 
> moving, unless they're visiting a new area, in which case they want to 
> see the stationary stuff, too.
>
> On the subject of packet rate - may I suggest another approach for the 
> flood control. If we would define, that it's OK for an application 
> like this to send out one packet per second on the APRS-IS (86400 per 
> day, or pick some other number if that's too high or low). You could 
> implement your application so that it sends a single packet, sleeps 
> for a second, and then sends the next packet from the queue. It could 
> walk the list of echolink nodes, and by some algorithm, on every 
> second pick the most important node to be announced. It could be the 
> node that was least recently announced, or maybe something more 
> complicated. You could have a configuration variable 
> "packets_per_second 1.5", and between every packet you'd 
> sleep(1/packets_per_second).
>
> This kind of algorithm keeps the load constant and well distributed 
> over time, and keeps the load from increasing suddenly if the amount 
> of echolink nodes would skyrocket somehow. Please consider that the 
> list of nodes might be accidentally or intentionally flooded, spammed, 
> or otherwise inflated or corrupted some night. Bugs happen, and it's 
> nice if the end results are not too surprising.
>
> That being said, I'm not sure if this is worth doing, Steve's 
> APRS-IS-worthiness classification summed it up very well. I'm sure 
> quite a few people would greatly appreciate it, but... I don't know.
>
>   - Hessu, OH7LZB
>
>
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
>