_, err = response.Write([]byte("\n"))
flush()
I'm expecting this http handler code:_, err = response.Write([]byte("\n"))
flush()to cause it to detect that the client is no longer around and close the connection. (roughly based on the advice in this blog post)Is that a reasonable expectation? If not, is there any way to force connections to close where the client has disappeared?
Or to phrase the problem in another way, with lots of mobile clients connecting and abruptly disappearing without closing their connections (not sending FIN packets), the http server ends up with a lot of "zombie" connections and can eventually run out of file descriptors and is no longer able to service new clients trying to connect. How are people avoiding that scenario?
--
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/d/optout.
Are you using a current version of Go? TCP keepalive should be set on the server's connection by default.
On Wednesday, March 18, 2015 at 5:21:08 PM UTC-4, Traun Leyden wroteI'm expecting this http handler code:_, err = response.Write([]byte("\n"))
flush()to cause it to detect that the client is no longer around and close the connection. (roughly based on the advice in this blog post)Is that a reasonable expectation? If not, is there any way to force connections to close where the client has disappeared?Nope. There's no way to quickly detect that a client is gone by writing to a tcp connection. The packets will be sent into a black hole into they timeout.
Or to phrase the problem in another way, with lots of mobile clients connecting and abruptly disappearing without closing their connections (not sending FIN packets), the http server ends up with a lot of "zombie" connections and can eventually run out of file descriptors and is no longer able to service new clients trying to connect. How are people avoiding that scenario?You use http.CloseNotifier, which is implemented by the standard ResponseWriter.
If the client has regular activity, I also like to implement an idle timeout by walking read and write deadlines forward after each action on the underlying connection.
On Wednesday, March 18, 2015 at 4:06:43 PM UTC-7, James Bardin wrote:Are you using a current version of Go? TCP keepalive should be set on the server's connection by default.Yep, I'm using go 1.4
You use http.CloseNotifier, which is implemented by the standard ResponseWriter.I was under the impression that CloseNotifier was only useful for clients that explicitly closed their side of the connection, as opposed to dead peers (as described in section 2.3 of the TCP-Keepalive-HOWTO, which is the same scenario I'm testing)
If the client has regular activity, I also like to implement an idle timeout by walking read and write deadlines forward after each action on the underlying connection.In my case, the client has been unplugged and so has no activity.
Note: you'll probably want to look at what is provided by tcpKeepAliveListener (linked below) as any changes you make to the socket will circumvent the use of this wrapper. This is because you'll need to make the listener first and then pass it to the server via Serve instead of calling ListenAndServe.
--I'm trying to figure out why persistent http connections show up in lsof as established for so long (approximately 90 minutes) after mobile clients have disappeared from the network abruptly.The way I'm testing is to run the following handler on a server:and connect with an android test app to the /longpoll endpoint. After it's connected I'm turning off the wifi on the device which takes it completely offline, since it has no other way to access the network.I'm expecting this http handler code:_, err = response.Write([]byte("\n"))
flush()to cause it to detect that the client is no longer around and close the connection. (roughly based on the advice in this blog post)Is that a reasonable expectation? If not, is there any way to force connections to close where the client has disappeared?Or to phrase the problem in another way, with lots of mobile clients connecting and abruptly disappearing without closing their connections (not sending FIN packets), the http server ends up with a lot of "zombie" connections and can eventually run out of file descriptors and is no longer able to service new clients trying to connect. How are people avoiding that scenario?
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Ah, I forgot that the idle time is set fairly high. TCP Keepalive won't kick in for 2 hours, and take another 10min to close the connection.There's an issue here to make other parameters available https://github.com/golang/go/issues/8328
echo 60 > /proc/sys/net/ipv4/tcp_keepalive_time
echo 6 > /proc/sys/net/ipv4/tcp_keepalive_intvl
echo 5 > /proc/sys/net/ipv4/tcp_keepalive_probes
echo 8 > /proc/sys/net/ipv4/tcp_retries2
Don't use the keepalive library linked in that HOWTO article. It leaks file descriptors, and leaves each connection in blocking mode.
Don't use the keepalive library linked in that HOWTO article. It leaks file descriptors, and leaves each connection in blocking mode.