[aprssig] RK3KKPK? (CONNECTED Igates?)

[Bob Bruninga]

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