Are you sure about this? ISTM that in most cases when a server goes away unexpectedly the local host will discover this when it next tries to use the socket. Also I recall reading that keepalives are a very controversial concept (since they may actually break connections unnecessarily if the internet merely has a hiccup).
--Guido On Mon, Apr 12, 2010 at 2:51 PM, Jesus Cea <j...@jcea.es> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Debugging a strange problem today, I got the following result: > > Sockets open by stdlib libraries are open without the "keepalive" > option, so the system default is used. The system default under linux is > "no keepalive". > > So, if you are using a URLlib connection, POP3 connection, IMAP > connection, etc., any stdlib that internally creates a socket, and your > server goes away suddendly (you lose network connectivity, by instance), > the library will wait FOREVER for the server. The client can't detect > that the server is not longer available. > > The "keepalive" option will send a probe packed every X minutes of > inactivity, to check if the other side is still alive, even if the > connection is idle. > > The issue is bad, but the solution is simple enough. Options: > > 1. All "client" libraries should create sockets with the "KEEPALIVE" option. > > 2. Modify the socket C module to create all sockets as "Keepalive" by > default. > > 3. To have a global variable in the socket module to change the default > for future sockets. Something like current "socket.setdefaulttimeout()". > The default should be "keepalive". > > 4. Modify client libraries to accept a new optional socket-like object > as an optional parameter. This would allow things like transparent > compression or encryption, or to replace the socket connection by > anything else (read/write to shared memory or database, for example). > > This is an issue in Linux because by default the sockets are not > "keepalive". In other Unix systems, the default is "keepalive". I don't > know about MS Windows. > > What do you think?. The solution seems trivial, after deciding the right > way to go. > > PS: "socket.setdefaulttimeout()" is not enough, because it could > shutdown a perfectly functional connection, just because it was idle for > too long. > > - -- > Jesus Cea Avion _/_/ _/_/_/ _/_/_/ > j...@jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ > jabber / xmpp:j...@jabber.org _/_/ _/_/ _/_/_/_/_/ > . _/_/ _/_/ _/_/ _/_/ _/_/ > "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ > "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ > "El amor es poner tu felicidad en la felicidad de otro" - Leibniz > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQCVAwUBS8OV2Zlgi5GaxT1NAQIJhwP8CH+gij4KfrJ1oHW5ys4PboH5Ru0pgdly > Wbsza0+uj3p68P1vDnC9jIr7j+fI3ql3DOc8zUoIKGpJoaWVspbv3c4vI4ATLHo+ > J6I18dpkviRT8/sT/69vMvghaGndiO0Sks/S4tDjhNstYH7oGjWxi63cKqtGPY/p > WSTLpwrd4SY= > =vkT4 > -----END PGP SIGNATURE----- > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (python.org/~guido) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
