Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

bitswap: Don't send CANCEL to peer we got block from #694

Open
Wondertan opened this issue Oct 19, 2024 · 0 comments · May be fixed by #784
Open

bitswap: Don't send CANCEL to peer we got block from #694

Wondertan opened this issue Oct 19, 2024 · 0 comments · May be fixed by #784
Assignees
@gammazero
Labels
need/analysis Needs further analysis before proceeding need/maintainers-input Needs input from the current maintainer(s) need/triage Needs initial labeling and prioritization

Comments

@Wondertan
Copy link
Member

Overview

Currently, we send CANCEL to every peer in a session once we got a block from a peer. However, the serving peer can and cleans the client's wantlint after serving the block. This suggests that sending CANCEL to the serving peer is redundant.

Proposal

Add peer parameter to PeerManager.SendCancels and exclude it when broadcasting cancels.
@Wondertan Wondertan added the need/triage Needs initial labeling and prioritization label Oct 19, 2024
@gammazero gammazero self-assigned this Oct 22, 2024
@lidel lidel added need/analysis Needs further analysis before proceeding need/maintainers-input Needs input from the current maintainer(s) labels Oct 22, 2024
gammazero added a commit that referenced this issue Jan 8, 2025
@gammazero
do not send CANCEL to peer we got block from
3ae79f9 
The serving peer cleans the client's wantlint after serving the block, making sending CANCEL to the serving peer redundant. So, exclude the serving peer when sending cancels after receiving a block.

Closes #694
@gammazero gammazero linked a pull request Jan 8, 2025 that will close this issue
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@gammazero gammazero

Labels
need/analysis Needs further analysis before proceeding need/maintainers-input Needs input from the current maintainer(s) need/triage Needs initial labeling and prioritization
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

do not send cancel message to peer that sent block ipfs/boxo
3 participants
@lidel @gammazero @Wondertan