-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
feat: Detect and recover from TCP Simultaneous open #2950
base: master
Are you sure you want to change the base?
Conversation
Interested in trying this out for my issue, any updates on this ^^ |
@gdsoumya, could you try this branch to see if it solves your problem? |
top := dq.top() | ||
if !top.ForceDelay && dialsInFlight == 0 && !w.connected { |
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.
Instead of this, how about we introduce another queue:
fixedDelayQueue.
- This construct forces us to expose ForceRetry, which external users never need to use.
- Makes the semantics slightly incorrect for dials that are behind in the queue but don't have the forceRetryFlag.
I suggest introducing:
- a separate fixed Delay Queue with its separate fixedDelayTimer
- adding a
now time.Time
argument to NextBatch that'll return elements that have expired by now - Have two blocks for handling dials, 1 for dialQueue and 1 for fixedDelayDialQueue.
I don't feel strongly about the suggestion. Anything that fixes 2 would be great.
Closes #2925
This touches one of the trickiest parts of the codebase, so please review carefully @sukunrt.
Requires multiformats/go-multistream#114 and a new release from that dep.