4 ms·

"Why are my TCP connections not closing? Why am I encountering port exhaustion?" This has nothing to do with Go. You're implying Go has a bug in its TCP implem

by Thaxll 5y ago

"Why are my TCP connections not closing? Why am I encountering port exhaustion?" This has nothing to do with Go. You're implying Go has a bug in its TCP implementation which I assume is false. Networking works just fine in Go and it's actually easy to use. https://pkg.go.dev/net https://pkg.go.dev/net Edit: I'm getting downvoted but please share with TCP issues in Go.

Diggsey 5y ago
> You're implying Go has a bug in its TCP implementation which I assume is false. No, the parent is implying that Go's TCP implementation is easy to use incorrectly. Specifically in ways which cause the aforementioned issues.
- Thaxll 5y ago
  I need examples, I used it for TCP/UDP and HTTP and beside the gotcha that clients have infinite timeout I don't see anything.
  - oxnrtr 5y ago
    Read the article maybe?
busterarm 5y ago
The author of the blog post literally covered it in the article he wrote two years prior that's linked in the first sentence. It's not "TCP issues in Go" it's "Go leaves you to figure these things out for yourself and write bad code that doesn't work if you don't thoroughly understand its gotchas." Also, if you've been following Go over the years, you'll know that there's basically _always_ open issues (https://github.com/golang/go/issues/39063 https://github.com/golang/go/issues/39063) in net & net/http about how Timeouts get mishandled and connections end up not being closed. Cloudflare even had to write a whole (now old and outdated as hell) article explaining how to "do it properly" https://blog.cloudflare.com/the-complete-guide-to-golang-net-http-timeouts/ https://blog.cloudflare.com/the-complete-guide-to-golang-net... so that you don't footgun yourself.
- Thaxll 5y ago
  Hmm not really, the only thing is the default http client that has no time out which is the case in many languages. The only issue I had was about idle connection and DNS resolution. And the ticket you show does not show any issues on the Go side.
- lenkite 5y ago
  They really need to add a deprecation note to the default http server and client. I have seen SO many people trip over this.

by Thaxll 5y ago

Diggsey 5y ago

> You're implying Go has a bug in its TCP implementation which I assume is false. No, the parent is implying that Go's TCP implementation is easy to use incorrectly. Specifically in ways which cause the aforementioned issues.

Thaxll 5y ago
I need examples, I used it for TCP/UDP and HTTP and beside the gotcha that clients have infinite timeout I don't see anything.
- oxnrtr 5y ago
  Read the article maybe?

busterarm 5y ago

The author of the blog post literally covered it in the article he wrote two years prior that's linked in the first sentence. It's not "TCP issues in Go" it's "Go leaves you to figure these things out for yourself and write bad code that doesn't work if you don't thoroughly understand its gotchas." Also, if you've been following Go over the years, you'll know that there's basically _always_ open issues (https://github.com/golang/go/issues/39063 https://github.com/golang/go/issues/39063) in net & net/http about how Timeouts get mishandled and connections end up not being closed. Cloudflare even had to write a whole (now old and outdated as hell) article explaining how to "do it properly" https://blog.cloudflare.com/the-complete-guide-to-golang-net-http-timeouts/ https://blog.cloudflare.com/the-complete-guide-to-golang-net... so that you don't footgun yourself.

Thaxll 5y ago
Hmm not really, the only thing is the default http client that has no time out which is the case in many languages. The only issue I had was about idle connection and DNS resolution. And the ticket you show does not show any issues on the Go side.
lenkite 5y ago
They really need to add a deprecation note to the default http server and client. I have seen SO many people trip over this.