how to handle "aliveness" of a req_id in the case of a requester sending a post request to multiple peers

[cblgh]

writing up this scenario while it's fresh from the debugging caves!

scenario:

a requester sends a single post request a set of hashes to its tree of connected peers. each responder receives the post request and responds with the subset of posts they have in a post response. each responder then sends a concluding post response (posts=[]) back to the requester.

how does the requester know when the post request is finally concluded and the req_id is consequently no longer alive?

one condition: when the requester has received all the posts they've requested.

are there other conditions? what if the requester never receive all posts (example: the only peer which had that post happened to go offline immediately after responding), is that req_id just kept alive until the requester reboots the cable program?

context:

ran into this when i was grinding bugs in cable-core & cable-client this week! i noticed when running 3 simultaneous sessions that the third session was often not appearing in the nicks sidebar, despite having verified data flowing across all connections.

it turned out that the second peer managed to 'conclude' the post request before the third peer managed to send off their response with the sought-after posts. i solved this particular scenario by simply not responding to a post request at all if a peer has none of the requested data (i.e. not sending a concluding post response posts=[]). having run into it, i started to wonder about related scenarios when peers may only collectively have a subset of the data, and thus this topic was born

[hackergrrl]

Since TTL is being dropped for Cable 1.0, can we consider this issue resolved?

[cblgh]

i think so!