Hi David (and Stewart),
On Jul 27, 2009, at 1:30 PM, Stewart Bryant wrote:
dlake02 wrote:
>
>
> John
>
> Yes, but my thoughts are why use a relational database to do the
job of
> a Routing Protocol ?
>
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
j...@hays.org
