WIP branch (on top on ted/ping; will be merged there). Uses
https://github.com/urbit/urbit/pull/6836 for the %arvo side.
- [x] Send/Receive STUN request/response, handled in %arvo by stopping
the %ping app.
- [x] Check DNS resolution -- currently we send STUNs in fakeship mode
- (check changing hosts.txt)
- [ ] refactor _stun_czar, _ames_czar,
- make a generic _dns_czar(imp_y) that gets called every ~m5 for our
sponsoring galaxy, and every time an %ames packet is sent to another
galaxy
- [x] refactor _ames_czar/stun_gone
- [x] Use XOR-MAPPED-ADDRESS to send the sponsee's IP
- [x] Better STUN (re)sends, regarding timers (e.g. number of tries per
attempt... etc)
- "send requests at times 0 ms, 500 ms, 1500 ms, 3500 ms, 7500
ms, 15500 ms, and 31500 ms. If the client has not received a
response after 39500 ms", stop, inject %fail, (re)resolve DNS, and
restart STUN.
- [x] Callback error handling
- if a response failes, ignore—sender will try again
- if a request fails, resend it
- if the DNS resolution fails, stop everyting and restart
- if the response doesn't arrive in ~s39, inject %fail, stop everything
and restart
- [ ] DNS Error handling
- [x] Failure to resolve DNS (first time) -- have a global ~s25 timer?
- [x] Change in sponsor's IP -- resolve DNS on failure to hear a
response?
- [x] ~~exponentially backoff~~resolve DNS every 5 minutes
- [x] Better STUN response check
- [x] Add sponsee's IP to MAPPED-ADDRESS attribute field
- [x] cache ip address
- [x] (re)enable %ping app after failure to hear STUN response, if we
eventually hear one
- [ ] Test plan: see last point in
https://github.com/urbit/urbit/pull/6836#issue-1956850750
There is a bug in lick where if a port still has a connection and lick
gets a %shut task the port can still send %soaks to arvo. Arvo poops
when this happens. This bug also shows up when the port is disconnected
and a %disconnect %soak is sent. This PR fixes both of these bugs
Currently we assume that the number of fragments in a `meow` has a fixed
size of 4 bytes (which is also how we deserialize meows in in
[lull.hoon](https://github.com/urbit/urbit/blob/develop/pkg/arvo/sys/lull.hoon#L1397);
see `+sift-meow`), but in some cases we will retrieve from the cache a
meow that has less than 4 bytes, which means that we will go over the
actual length of the meow when calculating the size of the response to
be sent.
(To reproduce the problem, [this pdf](https://www.lab6.com/0) will cause
the publisher to crash on the last fragment if anybody requests it using
remote scry)
This PR fixes this by checking how many bytes are actually used in a
word, and then using that information to correctly calculate the size of
the `meow`.
Thanks to @pkova and @joemfb for helping with this.
This PR ports urbit/urbit#6004. It is not urgent.
Benchmarking this against the old implementation would be worthwhile. It
might also be worth inlining/decomposing `u3a_is_mutable()`; this is
(currently) its only call-site, and the road pointer and seniority
predicate cannot change throughout this loop.
This PR effectively reverts urbit/urbit#1753, which simplified cache
promotion when falling back to an outer road, at the expense of
allocation efficiency.
Early testing shows significant positive effects mitigating snapshot
patch size (see urbit/urbit#6805)
