[aprssig] RK3KKPK? (CONNECTED Igates?)

[Steve Dimse]

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