PyBitmessage does not wait for "verack" and has non specified timeout. #662
Labels
No Label
bug
build
dependencies
developers
documentation
duplicate
enhancement
formatting
invalid
legal
mobile
obsolete
packaging
performance
protocol
question
refactoring
regression
security
test
translation
usability
wontfix
No Milestone
No project
No Assignees
1 Participants
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: Bitmessage/PyBitmessage-2024-12-19#662
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
I found a (small) bug in PyBitmessage Version 0.4.2 (or in the protocol specification)
Bug description:
The protocol specification states:
... No futher communication is possible until both peers have exchanged their version.
But PyBitmessage Version 0.4.2 sends an "addr" or an "inv"
message, without having received my "verack" (I'm sure I've not send it because I've not yet implemented it)
It's not a "showstopper" type of bug. But as PyBitmessage is assumed to be the "reference implementation" we should clearify what's the correct behaviour. Maybe the "verack" message is optional? Than this should be mentioned in the protocol specification.
In addition to that, PyBitmessage closes the connection after 20 seconds. That looks like a type of "timeout". Why? There is none specified (maybe we should specify one).
Trace:
I think that this can fairly be categorized as a bug. I've fixed it. inv and addr messages now won't be shared before the connection is fully established. "connection is fully established" is defined as having sent and received veracks. Incoming inv and addr messages are already ignored if the connection is not fully established.
If the connection is not fully established then the timeout is 20 seconds; this is what I considered to be the maximum reasonable time it might take to connect through Tor. A long timeout here is bad because it slows down bootstrapping. After the connection is fully established then the timeout is raised to 10 minutes.