generated from ipfs/ipfs-repository-template
-
Notifications
You must be signed in to change notification settings - Fork 109
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
SessionManager.ReceiveFrom added HAVEs/DONT_HAVEs even if no sessions were intersted in those, so the following could happen: Session requests BLOCK from one peer and HAVE from another. BLOCK is received before HAVE. Session cleans up its interest on BLOCK, but the following HAVE is still added to BlockResponseManager leaving it there forever. The solution is to add a CID to BlockResponseManager only if there a session interested in it.
- Loading branch information
Showing
3 changed files
with
33 additions
and
27 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
1 comment
on commit 70a6503
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Session cleans up its interest on BLOCK,
but the following HAVE is still added to BlockResponseManager leaving it there forever.
Wouldn't the call to s.sim.FilterSessionInterested
in Session.ReceiveFrom
handle this.?
Also, upon receiving a block, the session should not remove its interest in a block, only that it wants a block.. according to the comment in SessionInterestManager
:
// Note that once the block is received the session no longer wants
// the block, but still wants to receive messages from peers who have
// the block as they may have other blocks the session is interested in.
I do not understand what this line does:
So, it assigns an empty slice of CIDs (with non-zero capacity) to each item of
sets
. Yet the outer loop at line 183 is still iteratingsets
?