We are doing quite a bit of bookkeeping for relay nodes, which complicates the internal state and requires more careful handling for any changes.
It would be good if relay nodes were stateless; that is, the message alone should be sufficient to determine the next hop.
One major benefit is that it allows for routes to be flexible as peers are added and removed from a node, without having to update the corresponding internal state of those peers (and the rest of the peers down the relay chain). Right now, our SUB routes are essentially static due to the internal bookkeeping required for each peer, which is problematic on a dynamic network of transient p2p hosts.
One challenge: how to detect loops and terminate the relay. Possible solution: Pass around a list of visited nodes along with the message data. Before doing anything to the message, a node can check the list for its own ID. If on the list, the message has been already handled, so stop.
j0sh
commented
6 years ago
We are doing quite a bit of bookkeeping for relay nodes, which complicates the internal state and requires more careful handling for any changes.
It would be good if relay nodes were stateless; that is, the message alone should be sufficient to determine the next hop.
One major benefit is that it allows for routes to be flexible as peers are added and removed from a node, without having to update the corresponding internal state of those peers (and the rest of the peers down the relay chain). Right now, our SUB routes are essentially static due to the internal bookkeeping required for each peer, which is problematic on a dynamic network of transient p2p hosts.
One challenge: how to detect loops and terminate the relay. Possible solution: Pass around a list of visited nodes along with the message data. Before doing anything to the message, a node can check the list for its own ID. If on the list, the message has been already handled, so stop.