Nonexistant blocks clog up bitswap #830
Labels
kind/bug
A bug in existing code (including security flaws)
topic/bandwidth reduction
Topic bandwidth reduction
topic/bitswap
Topic bitswap
Comments
whyrusleeping
added
kind/bug
|
great question. i think this should be done by callers-- i.e. if the gateway fails to find it, and the ctx expires, it should cancel it from bitswap. (not sure what a good way to cancel would be-- maybe binding it to a context?) |
|
alright, ill keep thinking about this. it might be good to have an |
|
|
|
This issue is also partly why our idle bandwidth is so high |
|
I want to bump this issue, mars had an idle bandwidth usage of 300KB/s, and had several keys in its wantlist that (i beleive) it couldnt find. Restarting the daemon lowered the bandwidth usage dramatically |
|
@whyrusleeping it should be a matter of expiring the context, right? maybe the entries in the wantlist should have a list of contexts (or a refcount), and if all are cancelled, it's removed |
|
Yeah, we essentially just need an |
|
couldnt dial mars this morning, ssh'ed in to check on it, seemed to be running fine, except running I think this issue needs some higher priority |
|
oof. agreed. |
|
this is fixed |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
If you request a block that does not exist in the network, bitswap will keep it in its wantlist and expend a significant amount of effort into finding that block. I'm not sure what the best way to solve this is, because what if the requested block is just really far away on a computer with a spotty internet connection? At what point is it acceptable to give up the search?
The text was updated successfully, but these errors were encountered: