I've made some changes to the amprgw routing mechanism.
Replacing the earlier sequential search through the routing table with a binary search has significantly sped up lookups, which can happen up to twice per packet forwarded (once for source address, once for destination address).
Three times an hour, a background process fetches the encap routing table from the portal, and if it has changed, signals the router process to update its routing table. The routing table update seems to take about 3 msec during which packets can't be looked up and so are not forwarded.
This fetch also updates the data source for the rip sender, so you'll receive updates more quickly now. - Brian
On Mon, May 1, 2017 at 9:42 AM, Brian Kantor Brian@ucsd.edu wrote:
Three times an hour, a background process fetches the encap routing table from the portal, and if it has changed, signals the router process to update its routing table. The routing table update seems to take about 3 msec during which packets can't be looked up and so are not forwarded.
When the table is updated, does it reload the whole table or touch only the changed routes?
Why is it limited to three times per hour? This seems arbitrarily long when the process itself only takes 3ms. It would be nice for those of us on dynamic IPs if the update frequency was 1 minute* or less. *1 minute is also an arbitrary number--the lower the better.
Rather than (or in addition to) polling the encap table from the portal on a timer, the portal could offer an HTTP longpoll API (or various other push messaging protocols) so that address updates are near instantaneous.
Tom KD7LXL
On Mon, May 01, 2017 at 10:06:56AM -0700, Tom Hayward wrote:
When the table is updated, does it reload the whole table or touch only the changed routes?
It touches only the changed routes. New routes are added in place.
Why is it limited to three times per hour? This seems arbitrarily long when the process itself only takes 3ms. It would be nice for those of us on dynamic IPs if the update frequency was 1 minute* or less. *1 minute is also an arbitrary number--the lower the better.
To avoid loading the portal with FTP sessions. It takes around 10 to 15 seconds elapsed to download the file. - Brian
On Mon, May 1, 2017 at 10:21 AM, Brian Kantor Brian@ucsd.edu wrote:
Why is it limited to three times per hour? This seems arbitrarily long when the process itself only takes 3ms. It would be nice for those of us on dynamic IPs if the update frequency was 1 minute* or less. *1 minute is also an arbitrary number--the lower the better.
To avoid loading the portal with FTP sessions. It takes around 10 to 15 seconds elapsed to download the file.
That's not too bad. Sounds like you could run it in an infinite loop and get four updates per minute while creating a maximum of one FTP session on the portal. Something to consider.
Tom KD7LXL
Hadn't thought of that. Thanks for the idea. - Brian
On Mon, May 01, 2017 at 10:25:24AM -0700, Tom Hayward wrote:
To avoid loading the portal with FTP sessions. It takes around 10 to 15 seconds elapsed to download the file.
That's not too bad. Sounds like you could run it in an infinite loop and get four updates per minute while creating a maximum of one FTP session on the portal. Something to consider.
Sent from my iPhone
On 1 May 2017, at 18:06, Tom Hayward esarfl@gmail.com wrote:
(Please trim inclusions from previous messages) _______________________________________________
On Mon, May 1, 2017 at 9:42 AM, Brian Kantor Brian@ucsd.edu wrote:
Rather than (or in addition to) polling the encap table from the portal on a timer, the portal could offer an HTTP longpoll API (or various other push messaging protocols) so that address updates are near instantaneous.
I think this is a good idea, it wouldn't be difficult to come up with a push process that updates every time a gateway is edited. It would eliminate the quite costly FTP part of the current process. I will have a think about this and have a chat with Brian, see what can be done between the two machines.
Chris
-
Brian Kantor -
Chris -
Tom Hayward