If you broadcast messages to multiple peers and receive a response, you might want to send additional messages to the same peer through the same intermediaries, saving bandwidth so that follow-up requests do not need to do a flood-fill up to N hops. This branch adds a circuit_id field to requests and responses:
Peers responding to requests can set a circuit_id so that the requesting peer can reach them by the same route. Peers between a requester and responder can keep a routing table mapping circuit ids to a peer connection to send replies along so that messages with the same id do not need to be broadcast on all connections.
Circuits are not intended to be durable or long-lasting. Once a peer disconnects, all circuits on that interface can be forgotten. Peers keeping a circuit table might remember only a fixed number of circuits for each connection, vacating circuits not recently used for circuits more recently used.
If you broadcast messages to multiple peers and receive a response, you might want to send additional messages to the same peer through the same intermediaries, saving bandwidth so that follow-up requests do not need to do a flood-fill up to N hops. This branch adds a circuit_id field to requests and responses:
https://github.com/cabal-club/cable/tree/circuit_id
Peers responding to requests can set a circuit_id so that the requesting peer can reach them by the same route. Peers between a requester and responder can keep a routing table mapping circuit ids to a peer connection to send replies along so that messages with the same id do not need to be broadcast on all connections.
Circuits are not intended to be durable or long-lasting. Once a peer disconnects, all circuits on that interface can be forgotten. Peers keeping a circuit table might remember only a fixed number of circuits for each connection, vacating circuits not recently used for circuits more recently used.