Skip to content
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

Enabling/disabling TCP_NODELAY #383

Closed
cedws opened this issue Mar 15, 2023 · 4 comments
Closed

Enabling/disabling TCP_NODELAY #383

cedws opened this issue Mar 15, 2023 · 4 comments

Comments

@cedws
Copy link

cedws commented Mar 15, 2023

TCP sockets in Go have the TCP_NODELAY socket option set by default. This disables Nagle's algorithm which intends to reduce tinygrams by introducing small delays and aggregating them together into larger TCP packets.

This is appropriate for applications running in datacenters with low latency/low jitter network connections, but for an application connecting to an Internet service from a laptop, it's not so good.

https://withinboredom.info/blog/2022/12/29/golang-is-evil-on-shitty-networks/

You can call SetNoDelay(bool) on net.TCPConn to configure the TCP_NODELAY option. Since this library uses net/http, I'm sure there's a way to call this on the underlying connection, but I couldn't see how from having a brief look. I'll post any findings here.

@nhooyr
Copy link
Owner

nhooyr commented Mar 15, 2023

Write a custom net.Listener.

@nhooyr nhooyr closed this as completed Mar 15, 2023
@cedws
Copy link
Author

cedws commented Mar 16, 2023

Is it desirable to expose a method for this? Lot of consumers probably want Nagle's off.

@lesismal
Copy link

I set it by http.Server.ConnState:
https://github.com/lesismal/go-websocket-benchmark/blob/main/frameworks/nhooyr/server.go#L61

But really think it's not convenient.

@nhooyr
Copy link
Owner

nhooyr commented Sep 28, 2023

Is it desirable to expose a method for this? Lot of consumers probably want Nagle's off.

Right but why should my library expose a method when you can already do this at a deeper level by passing a custom net.Listener to http.Server or ConnState like @lesismal suggested.

Maybe in the future it'll be possible simply as a result of me allowing direct access to the *net.Conn, see #331

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants