-
Notifications
You must be signed in to change notification settings - Fork 73
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[4.0] P2P: Use magnitude safe time types #1316
Merged
Merged
Changes from all commits
Commits
Show all changes
3 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The issue was here.
current_time
was in nanoseconds.lastest_msg_time
was also in nanoseconds, buthb_timeout
was inmilliseconds
. So when the timer ran thelatest_msg_time
had to be within 10000 nanoseconds (10 microseconds) or it would close the connection.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So the issue was that
hb_timeout
was in milliseconds. It seems incorrect to me, as it is defined asstd::chrono::system_clock::duration::rep
, so I feel we should consistently usesystem_clock
duration in tstamp (on my linux system,system_clock
'sduration
is defined aschrono::nanoseconds
.I assume that by using
std::chrono
types, we will benefit from an automatic conversion inif( current_time > latest_msg_time + hb_timeout )
which will prevent the error. Buttstamp
was already a std::chrono duration, so I wonder if most of the changes, including this one, are really needed.My feeling is that the change at line 610 (
hb_timeout = msec;
) would have been enough for the fix, as the problem was that we usedcount()
which just returned a tick count, so we didn't benefit from the conversion from milliseconds to nanoseconds.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could be. Either way, this is much cleaner/safer code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see how this makes the code cleaner or safer. I think if you changed line 610 to
hb_timeout = msec.count()
the issue would come back exactly as before.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm confused at what you are suggesting should be done.
time_point
,milliseconds
,nanoseconds
types are well defined and arithmetic operations are handled correctly.tstamp
(std::chrono::system_clock::duration::rep
) on the other hand is defined asrep
-signed arithmetic type representing the number of ticks in the clock's duration
which is system dependent.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is nanoseconds too sensitive in P2P?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, nanoseconds is kind of ridiculous to use. However, that is what we were already using for
time_message
andtime
ofhandshake_message
. Internally now with this change we just use whateverstd::chrono::system_clock::now()
returns.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think
tstamp
should be either defined as:std::chrono::nanoseconds
(in which case we would benefit from safe type checking and conversions),int64_t
(in which case it would be clear it is simply a number and up to the programmer to ensure we always store nanoseconds into it).As far as I can see, the bug was that we are in case #2 (although it is somewhat obfuscated and unreliable because we use a std::chrono internal type) and that we stored milliseconds in a
tstamp
(line #611).Your change fixes the bug at line 611, and in addition replaces the use of
tstamp
withstd::chrono::system_clock::time_point
. I think it makes the code less readable.My preference would be to implement #1 above, i.e. redefine
tstamp
asstd::chrono::nanoseconds
, which I think would provide the additional safety in a cleaner way.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Completely removed
tstamp
type and backported the bettertime_message
handling frommain
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks Kevin for the change. I'm not quite sure is the initialization with
std::chrono::system_clock::time_point::min()
has a specific benefit, I kinda feel that0
is more appropriate than a negative value. And I also thing that definingtstamp
asstd::chrono::nanoseconds
and using it for ourconnection
time tracking members would be better. But maybe we can talk about this further for 5.0.