Don't forget the original design of DSTAR with the zones and multiple stacks in a zone. Also, don't forget that there are repeaters that aren't attached to a gateway computer and may never be. That's one of the biggest reasons for the G routing in my mind.
Ed WA4YIH From: [email protected] [mailto:[email protected]] On Behalf Of John Hays Sent: Monday, July 27, 2009 5:38 PM To: [email protected] Subject: Re: [DSTAR_DIGITAL] Re: First home-made dstar G2 gateway went live today. Hi David (and Stewart), On Jul 27, 2009, at 1:30 PM, Stewart Bryant wrote: Let me clarify. I could be wrong, but don't think I ever mentioned a relational database in my discussion. I use the term "hashtable" in the generic sense, which on a gateway or application server would probably be a memory resident data structure with no database at all. If you look at the D-STAR air protocol, there is nothing related to IP involved. Even in DD the D-STAR frame encapsulates an Ethernet packet, which may or may not include a IP packet and certainly there is no need for a DV user to need an IP address. IP really only comes into play as an encapsulating transport layer for native D-STAR frames over the Internet. If we keep out design dependencies that violate the protocol layers for expediency, then the transport can be replaced. The gateway really should keep references to map a callsign address to the gateway or application server address that is servicing that callsign at that instant in time. There really isn't even a need for every gateway to know the current callsign to gateway or application server mapping, it really only needs to keep a cache of active references. The equivalent of a trust server would offer the equivalent of a Dynamic DNS service that would allow unknown mappings to be discovered in real time. Think of it this way [ Internet Packet for Gateway to Gateway Routing/Transport | D-STAR Frame with SRC (MY)/DST(UR) Callsigns | DD Payload of Ethernet packet | IP or other network protocol (address space determined by participants; Net 10, Net 44, Net 192.168.0-255, Net 172.16-31, Net 169.254, or any other space, or even use other Ethernet protocols like IPX/SPX, Ethertalk, XNS, whatever) | End of DD | End of D-STAR Frame | End of Internet Packet ] All nicely encapsulated (easier to do with pictures). Then you could switch to ATM encapsulation rather than straight IP, or send it via Frame Relay, X.25 or even AX.25 without dependency on an artificial IP mapping for callsigns that is unnecessary. DV could travel the same path, just substituting the DV Payload for the DD payload. The code for the D-STAR portion isn't that complex, the gateways and application servers don't even need a callsign (the whole G port anomaly is strange to me -- just send everything to the gateway and let it decide if a given frame needs relayed - you, David, probably had to simulate it in your code to look like an Icom controller based solution, but upon reflection I think you would find it unnecessary and superfluous in your repeater). Traditional IP networking can be used to keep the gateways and application servers properly addressed (maybe even within a VPN), but users don't need to know about routing. John Hays Amateur Radio: K7VE [email protected]<mailto:[email protected]>
<<inline: image001.jpg>>
<<inline: image002.jpg>>
