Re: [go-nuts] go http server seems to not close sockets

[Péter Szilágyi]

Imho, this is TCP by design. You'll just have to wait out the timeout period till the TCP stack gives back the port to the OS. Or you can restart the network stack :P

On Tue, Mar 19, 2013 at 7:38 AM, Tobias Weingartner <tobias.we...@gmail.com> wrote:

So, I've got the following snippet:

$ cat testserver.go 
package main
import (
    "net/http"
    "io"
    "strconv"
)
func HelloServer(c http.ResponseWriter, req *http.Request) {
     result := "hello, world!\n"
     c.Header().Set("Content-Type", "text/plain")
     c.Header().Set("Content-Length", strconv.Itoa(len(result)))
     io.WriteString(c, result); 

     req.Body.Close()
}
func main() {
http.Handle("/", http.HandlerFunc(HelloServer))
http.ListenAndServe(":8080", nil)
}
$ go build testserver.go
$ netstat -an | grep TIME | wc -l
0
$ curl -s http://localhost:8080/
hello, world!
$ netstat -an | grep TIME | wc -l
1

However, every time a connection is made, the socket ends up in TIME_WAIT.  It looks like the socket is not closed on the go side.

Am I missing something to have these sockets closed once a request is finished?

Yes, keep-alive, blah blah blah, but once a connection drops, how do I close the socket on the server side?

I see this with go1.0.3 as well as tip (16294:43eb97ed849a).  Thoughts?

-T.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[James Bardin]

On Tuesday, March 19, 2013 8:06:46 AM UTC-4, Péter Szilágyi wrote:

Imho, this is TCP by design. You'll just have to wait out the timeout period till the TCP stack gives back the port to the OS. Or you can restart the network stack :P

It's not your humble opinion, it's the TCP specification ;)

 Tobias, TIME_WAIT is what you should expect to see on the server side, and should never cause you any problems.

If you are actually running out of sockets, on Linux you can set net.ipv4.tcp_tw_reuse to reuse ports in TIME_WAIT as needed.

[Toby]

It is not TCP by design. It is only if the socket is not closed
correctly. It means that one side has closed the connection, but the
other side has not.

-Toby.

[James Bardin]

No, it's the last stop in an active close on a TCP socket. Here's another diagram that groups them a little better (basically the same though) http://en.wikipedia.org/wiki/File:Tcp_state_diagram_new.svg

The socket is held there (per the spec) for twice the Maximum Segment Lifetime to pick up any possible late packets. It's usually far longer than needed, but again, it's rarely noticed.

http://en.wikipedia.org/wiki/Maximum_segment_lifetime

[Tobias Weingartner]

James, I stand corrected.  Thank you.  PEBKAC.

-Toby.