[aprssig] are write-only APRS-IS clients valid?

[Lee Bengston]

On Tue, Dec 3, 2013 at 3:54 PM, Lynn W. Deffenbaugh (Mr) <
ldeffenb at homeside.to> wrote:

>
> On 12/3/2013 3:00 PM, Lee Bengston wrote:
>
>
>  I don't know if there is a documentation gap or not, but it seems that
> what is not so well understood by "the community" is how the IS servers
> recognize IGates and what is sent to them when no filter is specified by
> the IGate.  I think it is a lot better understood now - at least by the
> readers of this list.
>
>
> I would caution against implying that IS Servers have any "knowledge" or
> "recognition" of an IGate.  What has been discussed here is the behavior of
> the APRS-IS servers on every filtered port regardless of what is connected
> to that port.  Saying that the IS server "knows" what an IGate is leads
> some people to believe that the APRS-IS does some sort of active routing to
> select IGates for message transmissions.  There is no such capability built
> into the APRS-IS.  Every filtered port that has recently delivered a packet
> for a given source will receive back packets of possible interest to an
> IGate for that/those stations for some period of time.  What the connected
> program does with those packets is not a concern of the APRS-IS network.
>
> But what delivers a packet for a "given source" other that itself if it is
not an IGate?  Hmm perhaps sending an object applies there.  The reason I
implied recognizing an IGate is that in my little experiment 2 years ago, I
configured Xastir with no filter and normal beaconing on both RF and IS.  I
got nothing from the IS in terms of APRS packets.  As soon as I enabled
Igating in Xastir, I received the packets we have been discussing, so
effectively the application was "recognized" as an IGate.  Perhaps it is
better to say it is recognized as something that might be an IGate.

Thanks,
Lee - K5DAT
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20131203/f288f260/attachment.html>