[ipfs/go-bitswap] Allow configurable prioritization of requests

[synzhu]

Can we allow the user customize the behavior for how we prioritize WANTHAVE or WANTBLOCK requests?

For example:

• we may not want to respond to requests for a certain block even though we have that block
• we may want to implement some sort of prioritization for requests, e.g always finish responding to all requests for block 42 before responding to any requests for block 41

[welcome]

Thank you for submitting your first issue to this repository! A maintainer will be here shortly to triage and review.
In the meantime, please double-check that you have provided all the necessary information to make this process easy! Any information that can help save additional round trips is useful! We currently aim to give initial feedback within two business days. If this does not happen, feel free to leave a comment.
Please keep an eye on how this issue will be labeled, as labels give an overview of priorities, assignments and additional actions requested by the maintainers:

• "Priority" labels will show how urgent this is for the team.
• "Status" labels will show if this is ready to be worked on, blocked, or in progress.
• "Need" labels will indicate if additional input or analysis is required.

Finally, remember to use https://discuss.ipfs.io if you just need general support.

[Stebalien]

• The entry point to this code is https://github.com/ipfs/go-bitswap/tree/master/internal/decision.
• You'll probably need to modify the PeerCompare function to take some form of priority into account when deciding between peers.
• If you want to avoid sending blocks, you'll likely want to filter them out of incoming want requests in Engine.MessageReceived. Just make sure to send "don't haves" if requested.
• You can also filter blocks by wrapping the blockstore passed into bitswap.New, but this will prevent bitswap from ever seeing the blocks, regardless of who's asking.

[aschmahmann]

@smnzhu how much of this issue is remaining given the already merged PRs?

[susarlanikhilesh]

• The entry point to this code is https://github.com/ipfs/go-bitswap/tree/master/internal/decision.
• You'll probably need to modify the PeerCompare function to take some form of priority into account when deciding between peers.
• If you want to avoid sending blocks, you'll likely want to filter them out of incoming want requests in Engine.MessageReceived. Just make sure to send "don't haves" if requested.
• You can also filter blocks by wrapping the blockstore passed into bitswap.New, but this will prevent bitswap from ever seeing the blocks, regardless of who's asking.

I need something similar. Like I don't want to request a node even if it has data. I know it's peer ID, I want to avoid pulling blocks from that peer. Where exactly you think I should looks for. I need to stay swarm connected to that peer. So, want_have sends to all the peers connected. But I want to avoid it for that one single peer
Thank you

[welcome]

Thank you for submitting your first issue to this repository! A maintainer will be here shortly to triage and review.
In the meantime, please double-check that you have provided all the necessary information to make this process easy! Any information that can help save additional round trips is useful! We currently aim to give initial feedback within two business days. If this does not happen, feel free to leave a comment.
Please keep an eye on how this issue will be labeled, as labels give an overview of priorities, assignments and additional actions requested by the maintainers:

• "Priority" labels will show how urgent this is for the team.
• "Status" labels will show if this is ready to be worked on, blocked, or in progress.
• "Need" labels will indicate if additional input or analysis is required.

Finally, remember to use https://discuss.ipfs.io if you just need general support.