> If a terminal moved into another repeater area of the same zone, the software overwrites the headers in incoming packets to redirect the data to the correct area repeater even though the updated user data are not yet shared in the entire network. (Jim's comment this helps a LOT for those of us who move between UHF and VHF during a commute!)
> When dsgwd software detects a terminal movement (changing zones), it immediately updates the Own Database entry of the terminal position. This enables instant position data update and communication link establishment regardless of the synchronization information sent from the Trust Server. > --------- > Switching from one Gateway to another would still be delayed a bit, though. NU5D and I just tested this a bit, and I've been trying to find a concise way to explain what we saw, unfortunately without much success, but here goes. The setup is: 1) I have pgadmin3 running on a Fedora box. I am logged into the dstar_global databases on K5CTX and W5HAT, and I am watching the sync_mng table entry for NU5D on both machines, each in it's own x- window. I refresh one view, then the other, back and forth every few seconds, so I can see changes within a second or two on each gateway. 2) NU5D is within range of both K5CTX and W5HAT. He always transmits on the B band, and he zone routes to the other machine. When transmitting on W5HAT^^B, he routes to /K5CTX^B. We believe the results below would be the same if he was callsign routing to a user "homed" to the other gateway instead -- just so long as his routing takes his header to the target. 3) Before we start, both sync_mng tables show him homed on K5CTX^^B. 4) He transmits on W5HAT^^B with UR=/K5CTX^B (to force a stream to be sent there). As fast as I can click refresh, sync_mng on W5HAT now shows him homed to W5HAT^^B. My next click updates the window with sync_mng on K5CTX which now shows him homed to W5HAT^^A -- and this is a huge change from G2 before the update which would have continued showing him homed to K5CTB^^B for 8 to 12 minutes based on our prior tests. But why does sync_mng on K5CTX show him homed to W5HAT^^A when he is really on W5HAT^^B? First, although K5CTX knows from the header it just received that he is on W5HAT, the header does not tell K5CTX which module he is on. K5CTX would normally find that from its own sync_mng, aka the routing table -- which won't be up to date for 8 to 12 more minutes. Second, it does not matter if K5CTX routes to the correct module on replies to NU5D via W5HAT because with the new scheme, W5HAT overwrites the return header with the correct band module that NU5D is really on if the header is wrong. 5) Finally, in 3 to 8 minutes, the sync_mng table on K5CTX updates from showing NU5D on W5HAT^^A to W5HAT^^B reflecting a sync from the trust server has occurred. We think this solves half of the homed gateway update problem - the 8 to 12 minute delay we see in the sync_mng table being updated by the trust server after a user changes gateways. The half it solves is that a call originator can always be answered, even if the gateway he/she is really on is different from the gateway listed in the sync_mng table on the gateway he/she is calling to. As above, the sync_mng table on that distant gateway will now be immediately updated as soon as it hears a header from him/her rather than waiting for the trust server to eventually deliver the update. Plus, if you are in QSO and move from one gateway to another, that QSO should follow you with perhaps the loss of one round - just so long as the other participant does not simultaneously move too. However, if you originate a call to some who is not really homed to the gateway your local sync_mng says, you will not be correctly routed until your local sync_mng is updated by the trust server. So I guess okay if you move, but not okay if whom you call moves. Right? 73 -- John
