We'll need at a bit to represent "is this a request?", i.e. not a response. The is-ames bit should also be consolidated into the 2-bit packet-type field to save space, and of course this function should return these new values -- my inclination would be to add the fields to the $packet type.

This is a note as much to myself as to you:

Something to keep in mind with this sort of change to the packet format is that we should ensure packets at this version are discriminable from older packets. In this case it's good enough just to look at the protocol version, but I was hoping each protocol could develop its own version to enable per-protocol updates later. We could probably still do that, though, by looking at both the protocol version bits and the packet-type bits.

What would the request/response bit be used for? My current implementation is request/response agnostic. I'm setting the next lane on every forwarded packet. Is this a bad idea?

It's legitimate, though maybe not useful, for a relay to set the .next field unconditionally. The relay needs to know where to forward the packet, though, which is why I think we need the request/response bit.

In Ames's current asymmetric routing, the relay doesn't care whether a packet is a request or response, so it forwards the packet to some of the destination ship's sponsors list either way. Symmetric routing needs to route responses differently from requests, though.

In symmetric routing, only the requesting ship needs to send a packet to potentially multiple sponsors. All other ships just send to a single lane. A ship in the responder's sponsors list relays a request down to the next ship down the sponsorship chain, which might be the responder ship itself. A ship sends or relays a response on whatever lane it heard the request packet come from, which is either its immediate sponsor's lane or the requester's lane.

You could almost look this up from PKI information, since if a packet's sender is our transitive sponsee and the receiver is not, it's a response, and if the receiver is our transitive sponsee and the sender is not, it's a request. However, if both sender and receiver ships are our transitive sponsees, then we don't know whether it's a request or response, so it's not clear how to maintain the symmetry of the routing.

If we use a request/response bit in the packet instead, there's no ambiguity, and figuring out the destination ship is more straightforward. If it's a request, find the next sponsor in the sponsors list for that ship. If it's a response, send it back on the lane it came from.

Unfortunately, to forward requests, a relay does still need to look up PKI information for the destination ship, to find its sponsors. It's not a huge problem, but it does increase the amount that the forwarding code needs to interact with Arvo to read PKI information -- ideally a relay could have very minimal state. So a future design might improve upon that, but I don't know how just yet, and it might not be possible without tradeoffs (such as giving the requesting ship more control over the route its packet will take through the routing hierarchy, which isn't necessarily a good thing).

This makes sense to me. I can change the logic to treat requests and responses differently, but I'm not sure it's necessary.
My current relay logic works like this:

1. If we have a lane for sndr to rcvr in the pending map, use that.
2. If we are the direct sponsor of the rcvr, send to rcvr. (rcvr is in our sponsees map)
   --> otherwise, +try-next-sponsor up the sponsorship chain in case rcvr is our transitive sponsee
3. If we don't have an entry for the request in the pending map AND the rcvr isn't our direct or transitive sponsee, send to the rcvr's galaxy.

Regardless of request/response, +on-hear-packet stores [[rcvr sndr]] [lane (unit next-lane)] in the pending map. I think this handles the routes correctly and maintains symmetry without needing to treat requests and responses differently.

Example:

request: ~rovnys -> ~syl -> ~sipsyl -> ~ritpub-sipsyl -> ~mister-ritpub-sipsyl

~rovnys has no record of ~mister-ritpub-sipsyl in the pending requests map and is not a sponsor, so it sends the packet to the ~syl galaxy.
As the request is routed, each relay will enter [[~mister-ritpub-sipsyl ~rovnys] [previous-lane previous-previous-lane]] in its pending map. e.g. ~sypsyl will have [[~mister-ritpub-sipsyl ~rovnys] [(~syl's lane) (~rovnys's lane)]].

response: ~rovnys <- ~syl <- ~sipsyl <- ~ritpub-sipsyl <- ~mister-ritpub-sipsyl

On the way back, the relay's all have entries in their pending map for [~mister-ritpub-sipsyl ~rovnys], so they will send the packet to both lane and the next-lane.
As the request is routed, each relay will enter [[~rovnys ~mister-ritpub-sipsyl] [previous-lane previous-previous-lane]] in its pending map. e.g. ~sypsyl will have [[~rovnys ~mister-ritpub-sipsyl] [(~ritpub-sipsyl's lane) (~mister-ritpub-sipsyl's lane)].

Then, on the next request, the relays have entries in their pending map going both ways. Each relay has an entry in the pending map for [~rovnys ~mister-ritpub-sipsyl] and an entry for [~mister-ritpub-sipsyl ~rovnys]. i.e. after the first request, only the pending map is used to route packets. The result is that all of the relays then try to tighten the route in both directions.

As next-lane is a unit, is for redundant?

yes I think so I'll get rid of it

I don't see a caller of on-hear-forward which provides lane- am I be missing something?

on-hear-forward gets called in on-hear-packet, with the same sample as on-hear-packet.

 %.  +<
 ::
 ?.  =(our rcvr.packet)
    on-hear-forward

Got it, thanks

Tracing this back: it seems that +call correctly passes lane when dud is a cell by extracting it from the task lane.task on line 1065. Otherwise is passes lane (line 1071) which I don't see in the sample at that point - is it passing the type $lane and not the value?

It's still getting the lane and blob from the task: [lane blob ~]:task. The dud looks like a stack trace in case of a crash (I think in the arvo kernel).

Should this be {<final-ship>} as ship is no longer an alias of final-ship?

yes I'll change that

Wasn't pending going to have both rcvr and sndr ships in it?

Yeah that was the original design. I noticed that the relays only need to know the destination, so I'm pretty sure it's okay to drop the sender. e.g. if a relay knows the lane of ~zod, it shouldn't matter where the relayed packets are coming from. It just sends them to ~zod's lane.