-
Notifications
You must be signed in to change notification settings - Fork 23
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
Send AwaitReply
to prevent timeouts.
#432
Conversation
33ff682
to
66c88f7
Compare
I think I need some description of the problem that this PR is trying to solve. |
…ble and disable them in our test
c4448a2
to
ef899cd
Compare
trace "Added to current chain" | ||
trace $ "New tip: " ++ condense newTipPoint | ||
trace $ "New fragment: " ++ condense newFragment |
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 this change intended?
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, that was too noisy and mostly redundant
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.
LGTM
This PR builds on top of #431.
When a ChainSync server is done serving its chain, it now sends an
AwaitReply
message to the client so as to not get disconnected from too fast (typically, clients wait for 10s for a response, or 80-150s for a response afterAwaitReply
).As a hack, servers also now return
AwaitReply
when they fall behind the intersection of the client due to thePointSchedule
's structure. It is not clear to us why this is accepted by a client.