1 May
2017
1 May
'17
11:42 p.m.
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
2 May
2 May
12:06 a.m.
On Mon, May 1, 2017 at 9:42 AM, Brian Kantor <Brian(a)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
12:21 a.m.
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
12:25 a.m.
On Mon, May 1, 2017 at 10:21 AM, Brian Kantor <Brian(a)ucsd.edu> wrote:
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
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.
12:31 a.m.
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. 
5:18 a.m.
Sent from my iPhone
On 1 May 2017, at 18:06, Tom Hayward
<esarfl(a)gmail.com> wrote:
(Please trim inclusions from previous messages)
_______________________________________________
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
On Mon, May 1, 2017 at 9:42 AM, Brian Kantor
<Brian(a)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.
2793
days inactive
2793
days old
5 comments
3 participants
participants (3)
-
Brian Kantor -
Chris -
Tom Hayward