ames: do not produce stale forward lanes

Stale lanes may cause forwarding loops. Imagine the following:
1) Planet A is live. Galaxy B, its indirect sponsor, learns of its route.
2) A goes offline. Another ship, C, is started in its place, at the same route.
3) B receives a packet for A, forwards it to the known route.
4) C received the packet, forwards it to B.
5) Repeat from 3.

Here, we update the forward lane(s) scry used by the runtime to not produce a
peer's lane if they haven't communicated with us in the last hour. Everyone's
supposed to ping their sponsorship chain every 30 seconds. If those aren't
going through, you shouldn't expect to be reachable anyway.

We may or may not want to update +send-blob to match.
This commit is contained in:
fang 2022-06-01 17:17:37 +02:00 committed by GitHub
parent ac90c2a602
commit 999f0e84e9
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23

View File

@ -1158,9 +1158,11 @@
[%forward-lane ~]
::
:: this duplicates the routing hack from +send-blob:event-core
:: so long as neither the peer nor the peer's sponsoring galaxy is us:
:: so long as neither the peer nor the peer's sponsoring galaxy is us,
:: and the peer has been reached recently:
::
:: - no route to the peer: send to the peer's sponsoring galaxy
:: - no route to the peer, or peer has not been contacted recently:
:: send to the peer's sponsoring galaxy
:: - direct route to the peer: use that
:: - indirect route to the peer: send to both that route and the
:: the peer's sponsoring galaxy
@ -1172,6 +1174,8 @@
==
~
=; zar=(trap (list lane))
?: (lth last-contact.qos.u.peer (sub now ~h1))
$:zar
?~ route.u.peer $:zar
=* rot u.route.u.peer
?:(direct.rot [lane.rot ~] [lane.rot $:zar])