You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Feb 1, 2023. It is now read-only.
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.
The text was updated successfully, but these errors were encountered:
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:
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.
The text was updated successfully, but these errors were encountered: