-
Notifications
You must be signed in to change notification settings - Fork 53
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(engine): make netxlite.utlsConn public #1018
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.
Looks good to me! It seems we can also seize the opportunity for choosing which functions to expose and for slightly improving the naming of functions.
internal/netxlite/utls.go
Outdated
// newConnUTLS returns a NewConn function for creating utlsConn instances. | ||
func newConnUTLS(clientHello *utls.ClientHelloID) func(conn net.Conn, config *tls.Config) (TLSConn, error) { | ||
// NewConnUTLS returns a NewConn function for creating UTLSConn instances. | ||
func NewConnUTLS(clientHello *utls.ClientHelloID) func(conn net.Conn, config *tls.Config) (TLSConn, error) { |
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 name of this function was ~fine as long as it was private. Now that it is public, I am wondering why its name seems to imply that it creates a new connection, while instead it returns a function for creating a new connection. I suppose we can probably find a better name. Additionally, or instead of doing that, we could also consider keeping this function private. It seems to me an adapter to allow creating uTLS connections inside netxlite/tls.go
and I think most users want instead to call NewConnUTLSWithHelloID
. Regardless of what we choose to do, perhaps NewConnUTLS
is the right name for NewConnUTLSWithHelloID
?
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.
It seems to me an adapter to allow creating uTLS connections inside netxlite/tls.go and I think most users want instead to call NewConnUTLSWithHelloID.
I have the same understanding.
perhaps NewConnUTLS is the right name for NewConnUTLSWithHelloID?
Makes sense.
And I agree, the adapter should rather be private. I can't think of a better name for it though, but I'll think about it
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.
Maybe
NewConnUTLSWithHelloID
--> NewUTLSConn
,
NewConnUTLS
--> newConnUTLS
(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.
How about:
NewConnUTLSWithHelloID
--> NewUTLSConn
,
newConnUTLS
--> newUTLSConnFactory
Not exactly as before but at least it removes the ambiguity of two function only differing in their first letter capitalization and doing a different business?
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, I think that's good 👍
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.
🐳
d2c47a1
to
cc38abc
Compare
Checklist
Description
This PR exposes the
netxlite.utlsConn
to the experiments by making it public (-->UTLSConn
)echcheck
can usenetxlite.UTLSConn
now so we don't need to re-implement utlsConn there any longer.Note that
NewConnUTLSWithHelloID
returns*UTLSConn
now, instead ofTLSConn
, to make it more convenient for experiment developers.