-
Notifications
You must be signed in to change notification settings - Fork 893
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
GODRIVER-1879 Apply connectTimeoutMS to TLS handshake #594
GODRIVER-1879 Apply connectTimeoutMS to TLS handshake #594
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.
LGTM!
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.
Code changes LGTM, I just have a couple clarifying questions. Nicely done!
var dialCancel context.CancelFunc | ||
if c.config.connectTimeout != 0 { | ||
dialCtx, dialCancel = context.WithTimeout(handshakeCtx, c.config.connectTimeout) | ||
defer dialCancel() |
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.
No need to change. But IIUC, since this derived from handshakeCtx
, it is not strictly necessary to cancel the dialCtx
. Cancelling handshakeCtx
would cancel any derived contexts. Is that right?
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 have the same understanding. However, AFAIK it's good practice to defer all context.CancelFunc
variables and this is happening once per connection handshake, so I don't think it's going to be prohibitive to do that here.
This PR modifies the connection code to apply the
connectTimeoutMS
option to both socket establishment and the TLS handshake. Previously, it was only applied to the former. To aid in testing, I also modified the existingtlsConnectionSource
interface to return a newtlsConn
interface rather than directly returning a concretetls.Conn
. This allows us to provide a custom implementation for TLS handshaking in our tests.The alternate approach considered was to use tls.Dialer or tls.DialWithDialer. These aren't flexible enough because they require us to specify a net.Dialer as the dialer for the underlying network socket, but we actually accept a custom interface to dial connections, which defaults to
net.Dialer
but can be something else (e.g. we have seen this option used to dial TLS connections via openssl rather than crytp/tls).