diff options
| author | John Newbery <[email protected]> | 2020-06-15 09:28:56 -0400 |
|---|---|---|
| committer | John Newbery <[email protected]> | 2020-07-11 07:06:20 +0100 |
| commit | a49781e56d2bd6a61ec027a09c1db9ee1a4abf2e (patch) | |
| tree | 292214604d5f804e38c0cc17858f06f79d4dff5f /src/script/script_error.cpp | |
| parent | [net processing] Fix bad indentation in SendMessages() (diff) | |
| download | discoin-a49781e56d2bd6a61ec027a09c1db9ee1a4abf2e.tar.xz discoin-a49781e56d2bd6a61ec027a09c1db9ee1a4abf2e.zip | |
[net processing] Only call MaybeDiscourageAndDisconnect from SendMessages
`nMisbehavior` is a tally in `CNodeState` that can be incremented from
anywhere. That almost always happens inside a `ProcessMessages()` call
(because we increment the misbehavior score when receiving a bad
messages from a peer), but not always. See, for example, the call to
`MaybePunishNodeForBlock()` inside `BlockChecked()`, which is an
asynchronous callback from the validation interface, executed on the
scheduler thread.
As long as `MaybeDiscourageAndDisconnect()` is called regularly for the
node, then the misbehavior score exceeding the 100 threshold will
eventually result in the peer being punished. It doesn't really matter
where that `MaybeDiscourageAndDisconnect()` happens, but it makes most
sense in `SendMessages()` which is where we do general peer
housekeeping/maintenance.
Therefore, remove the `MaybeDiscourageAndDisconnect()` call in
`ProcessMessages()` and move the `MaybeDiscourageAndDisconnect()` call
in `SendMessages()` to the top of the function. This moves it out of the
cs_main lock scope, so take that lock directly inside
`MaybeDiscourageAndDisconnect()`.
Historic note: `MaybeDiscourageAndDisconnect()` was previously
`SendRejectsAndCheckIfBanned()`, and before that was just sending
rejects. All of those things required cs_main, which is why
`MaybeDiscourageAndDisconnect()` was called after the ping logic.
Diffstat (limited to 'src/script/script_error.cpp')
0 files changed, 0 insertions, 0 deletions