Report Peers that give incorrect (not deserializable) data #1350
Assignees
Comments
|
I guess any error that we receive from the request/response protocol should decrease the reputation of the peer regardless of the reason. |
|
The current implementation ignores the error from the 
We need to handle it and, in the same way, send an error or |
This was referenced Dec 22, 2023
xgreenx
added a commit
that referenced
this issue
Jan 6, 2024
For some reason we had a two layers of serialization for request/response messages. This doesn't seem useful at all, and complicates e.g. error handling. This PR removes the extra layer, substantially simplifying that logic. One major upside of this is that #1345 and #1350 can now be solved in a single follow-up PR. ~~Hopefully this doesn't conflict too much with the ongoing libp2p update PR #1379.~~ --------- Co-authored-by: Green Baneling <XgreenX9999@gmail.com>
Dentosal
added a commit
that referenced
this issue
Feb 5, 2024
Closes #1345. Closes #1346 Closes #1350. This PR stops discarding request errors from libp2p, and instead returns them to the sender of the request. Also penalizes peers for sending invalid responses or for not replying at all. Making penalty configurable should be a follow-up PR, as there are other penalties that should be configurable as well TODO: - [x] Make timeout configutable: Already seems to be case on master branch - [x] Add tests - [x] Fix current tests that for some reason don't terminate --------- Co-authored-by: xgreenx <xgreenx9999@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This will require some error handling and possibly moving away from
anyhowin our binary.The text was updated successfully, but these errors were encountered: