-
Notifications
You must be signed in to change notification settings - Fork 0
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
refactor(client): explicit timeout during connect #3
base: master
Are you sure you want to change the base?
Conversation
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.
} | ||
}; | ||
// Wait for connection state to be closed | ||
let mut timer = interval(Duration::from_millis(10)); |
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.
Wonder were this magic number comes from. Or is it part of the spec? 🙈
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.
Probably just tried & tested? I'm not that familiar with the code to really say. Just looking at it now, it's even possible that the whole loop here could be removed because all the work happens inside the spawn_looping_tasks
that build upon the read- and write-halfs of the connection and this task doesn't really need to do anything anymore.
debug! {"Sending HELLO"} | ||
; |
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.
debug! {"Sending HELLO"} | |
; | |
debug! {"Sending HELLO"}; |
We observed a scenario where the client was stuck trying to connect. Most likely cause is that packets were
DROP
ed from the network instead of beingREJECT
ed. This adds an experimental explicit timeout to theTcpStream::connect
call.