[aprssig] EchoLink APRS-IS Ojbects Mothballed

[Tim Cunningham]

----- Original Message ----- 
From: "Lynn W. Deffenbaugh (Mr)"
To: "TAPR APRS Mailing List"
Sent: Thursday, July 23, 2009 11:47 PM
Subject: Re: [aprssig] EchoLink APRS-IS Ojbects Mothballed


> Tim Cunningham wrote:
>> Think of it as an on demand system where the user requests information in 
>> their specific area, the server sends an ACK back to the requester to 
>> stop the redundancy, and also transmits the Echolink Object back through 
>> the path of the requester until the ACK is fulfilled. This allows all in 
>> the area of the requester to see the available Echolink Objects as well. 
>> No more bandwidth is utilized than what is sent on demand. The requester 
>> hopefully gets the data as well as other listeners in the return path of 
>> the requester. This method should not flood the entire network by keeping 
>> the requested data local to the requesters digi path and IGate. The down 
>> side is the requesters local IGate must allow objects to pass back 
>> through the RF path when dealing with filtered ports on the APRS-IS. 
>> Unless the IGate's that use filtered ports modify their filter, these 
>> object packets could be blocked.
>>
> Interesting idea, but it won't work within the current APRS 
> infrastructure.

Why not? A quick scan of the 3 core servers show that a large percentage of 
users that presnet a filter are using either Range Filter (r), Area Filter 
(a), or My Range Filter (m). Therefore, the only IGates who would need to 
make a change are the few that explicity filter objects specifically. 
Actually, a majority of the IGates will not have to make any change to their 
filters to support this concept! Forget the path concept, just post the 
requested object it on the APRS-IS and the IGates will sort where it needs 
to go to support a local path. Conjestion is still limited to individual 
request for information.


> 1) "back through the path of the requester" - the only thing that does 
> this currently is a message directed to a station that an IGate considers 
> to be local
>

If the object contains the coordinates, the local IGate should pass it if I 
what I stated in the previous paragraph is true. One exception is if the 
local IGate specifically does not allow Internet to RF gating. This we 
cannot see by looking at the APRS-IS servers, but we can see what filter 
commands each IGate sends to the server and this is where I looked.


> 2) "hopefully gets the data as well as other listeners" - If we use 
> messages to the requester, yes, hopefully s/he'll get the answer.  Others 
> will certainly hear it, but it's up to their client software to determine 
> if they actually see messages addressed to other calls.
>
> 3) "IGate must allow objects to pass back" - That was one of the major 
> objects to injecting the objects into APRS-IS.  They would only get out to 
> local RF when/if IGate operators configured them to.  Some caring IGate 
> operators may be inspired/persuaded to gate specific objects to RF, but I 
> don't know of any that will configure to gate all objects to RF.
>

Based on what I see looking at the filter commands the majority of the 
IGates using the core servers the only exception for this idea not to work 
would be if the IGate operator specifically rejects all Internet to RF 
transport. In this case sending the object in a message is not going to work 
either. So the choice may then be do you send it as a message to the 
requester or send it as an object for the benefit of all to see. Based on 
the majority of the filters sent by IGates to the core servers, this is not 
a major problem. The major problem is if the IGate does not allow Internet 
to RF transport then it kills either concept.



73's,
Tim - N8DEU
Decatur, Alabama