Given TCP connection reuse I don't think the os/kernel will be able to tell apart the TCP connections any better than intercepting the net.Conn with a custom listener. Especially if you're using anything encrypted, staying in Go is going to be necessary for you to get the sort of data you need.
You might be able to use your wrapped Listener strategy if you are willing to set "Connection: Close" on your incoming connections. I suspect that will degrade performance though. You might be able to hack together a Listener which is actually able to pool http client connections yet convince the http library to Close them when it is done with each request, but that sounds hard to do well and would likely to tightly coupled to the http package's implementation. Do you need an exact count? You could probably get a pretty good estimation by just serializing the HTTP headers, counting how long that is, and adding in the size of the Body. -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
