This repository has been archived by the owner on Feb 1, 2023. It is now read-only.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Refactor SessionInterestManager #384
Refactor SessionInterestManager #384
Changes from all commits
7087c2d
ca25b01
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
Something here is very strange. I think the meaning of "session interest" has changed over time. In the past, I believe it included everything the session wanted, but hadn't necessarily asked for.
I prefer the new interpretation "things the session is interested in hearing about", but I think we've made a mistake: we're canceling blocks when we become uninterested in them.
Shouldn't we be canceling blocks when they become unwanted?
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.
It's true it's a little convoluted. We actually want to do both:
Note that the session is still interested in the block (but doesn't want the block), because the session wants to add peers who had the block to the session, so as to query them for other blocks that the session wants
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.
My point is that this function returns CIDs (for cancellation) that no sessions are interested in. However, we really want to return CIDs that no session wants.
I think we're technically fine because:
But it's still a bit strange.
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.
I see what you're saying, it's a little strange that we don't just cancel something that no one wants.
When we receive a block we send a cancel to the peer, and mark it as unwanted in the SessionInterestManager. We don't remove it entirely from the SessionInterestManager because if other peers subsequently respond with a HAVE or a block, we want to be able to tell the Session so that it can expand its pool of peers who may have blocks its interested in (this is particularly important in the discovery phase).
On the other hand if the request is cancelled, then the Session is not interested at all in hearing about subsequent blocks or HAVEs for the CIDs in the request, so in that case we remove the CIDs entirely from the SessionInterestManager.
Maybe the naming could be a clearer, I'm not sure that wanted / interested fully captures the concepts.
This file was deleted.