[aprssig] RK3KKPK? (CONNECTED Igates?)

[Randy Love]

With an appropriate APRS QSY object to show the availability for the
functionality.

On Mon, Jan 30, 2012 at 7:38 PM, Bob Bruninga <bruninga at usna.edu> wrote:

> Great!... With the proviso, that it should target 145.01 or other locally
> available packet channel and NOT 144.39.  Maybe 145.55 is an alternative if
> a DX cluster is already there somewhere...
>
> Bob, Wb4APR
>
> -----Original Message-----
> From: aprssig-bounces at tapr.org [mailto:aprssig-bounces at tapr.org] On Behalf
> Of Steve Dimse
> Sent: Monday, January 30, 2012 8:06 AM
> To: TAPR APRS Mailing List
> Subject: Re: [aprssig] RK3KKPK? (CONNECTED Igates?)
>
>
> On (the last few days), (various people) wrote (things like):
>
> > And, of course, two sets of routing tables, two sets of addresses, two
> > sets of address resolution/mapping protocols and so on.
> >
> It is easy to fall into a tendency to over-engineer things. People
> sometimes
> talk about redoing the APRS IS for a variety of reasons, but if it were
> complex it never would have gained traction (just as their proposals to
> re-engineer never gain traction). I was actually guilty of this, I had a
> rather complex plan when the idea for the APRS IS formed, but I am
> eternally
> indebted to Keith WU2Z, who convinced me if the importance of simplicity if
> I wanted it to catch on.
>
> Here is a relatively simple way to do what Bob proposes, call the concept
> CGate, for Connected Gateway.
>
> The CGate listens on RF, when it hears the RF beacon of a local station it
> sends a packet to the internet backbone with the RF station's call and the
> CGate's IP number or DNS name. The packet could be either a new APRS packet
> type, a user-defined packet type, or even just a position report with a
> comment like "CGate via cgate.k4hg.net" or "CGate via 64.76.23.1"on a
> regular position packet. The internet backbone could be the APRS IS itself
> or a stand-alone net using javAPRSSrv and/or aprsd.
>
> The CGate listens on the internet and builds its own flat database of all
> the beacons and the CGate that heard them. Call this a routing table if you
> want, but this is quite simple and reasonably scaleable, even low-end
> computers could handle tables with half a million lines easily.
>
> To initiate a connect I would type into the tnc "C WB4APR VIA CGATE". A
> local CGate could hear the connection request, look in its table for
> WB4APR,
> if it finds an entry it connects to the CGate that heard WB4APR, and that
> CGate sends out a connect request that prints like "K4HG>WB4APR,CGATE*".
> From this point the packets are sent end-to-end via the TCP connection
> between the CGates, the only translation needed to flag the CGATE digi as
> used (CGATE*). The TCP connection would probably use the KISS protocol as
> the data format for simplicity, this would require KISS TNCs on each end to
> be able to send out packets with the callsign of the person on the other
> end
> of the connection.
>
> A problem would be multiple CGates in range of a single RF originating
> station. In that case the operator would need to use the call of one of the
> CGates in place of the generic CGATE via. The other end is not a problem
> because the originator's CGate would only connect to a single CGate at the
> destination, though you may want to add in some sort of quality test in the
> routing table so the better of two CGates is the one in the table.
>
> Personally, I am not convinced this is worth the effort, I doubt it would
> attract many users, but if someone wanted to try this is the way I would
> recommend they do it. You only need write one piece of software (the
> CGate),
> the configuration is automatic, it uses existing infrastructure (at least
> during testing) and the RF users need know nothing about the internet
> network, it just looks like a digi.
>
> Steve K4HG
>
>
>
>
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
>
>
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.tapr.org/pipermail/aprssig/attachments/20120130/617de881/attachment.htm>