Skip to content
This repository has been archived by the owner on Feb 1, 2023. It is now read-only.

Prune peers from Session if they stop sending blocks #257

Closed
dirkmc opened this issue Feb 14, 2020 · 0 comments · Fixed by #261
Closed

Prune peers from Session if they stop sending blocks #257

dirkmc opened this issue Feb 14, 2020 · 0 comments · Fixed by #261

Comments

@dirkmc
Copy link
Contributor

dirkmc commented Feb 14, 2020

Typically blocks in a file are organized into a DAG. It is expected that all peers with some part of the file will have the root and the upper branches of the DAG, but some peers may not have large subsections of the DAG.

The Session discovers peers by broadcasting a request for the root and upper branches to all connected peers (and querying the DHT if no connected peer responds). So at the beginning the Session will discover many peers, including those that don't have the full file. Once these upper branches have been fetched, the peers without the rest of the file are no longer needed.

For each block CID, the Session sends an optimistic want-block to one peer in the session, and want-haves to all other peers. The Session only sends one want-block at a time, so if the optimistic want-block is sent to a peer who doesn't have the block, we need to wait for the response before sending want-block to another peer. So overall the file will be downloaded faster if peers are pruned from the Session when they no longer have blocks useful to the Session.

Proposal:

  • The Session keeps track of how many consecutive DONT_HAVE responses it receives from each peer
  • If the number of DONT_HAVE responses exceeds a cutoff, remove the peer from the session

When the Session gets a DONT_HAVE response for a particular CID from all peers in the Session, it will broadcast the request to all connected peers (including those that have been removed from the Session), so in the worst case a peer that has some blocks the Session needs will be removed, then added back when it responds to a broadcast.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant