From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/83644 Path: news.gmane.org!not-for-mail From: Julien Danjou Newsgroups: gmane.emacs.gnus.general Subject: Re: imap connections never being closed? Date: Sat, 03 Aug 2013 15:13:58 +0200 Message-ID: <87fvuq6hnt.fsf@dex.adm.naquadah.org> References: <87ppvn5oem.fsf@yun.yagibdah.de> <87d2px8k49.fsf@dod.no> <87siyr6i27.fsf@dex.adm.naquadah.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" X-Trace: ger.gmane.org 1375535710 18121 80.91.229.3 (3 Aug 2013 13:15:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 3 Aug 2013 13:15:10 +0000 (UTC) Cc: ding@gnus.org To: Lars Magne Ingebrigtsen Original-X-From: ding-owner+M31900@lists.math.uh.edu Sat Aug 03 15:15:11 2013 Return-path: Envelope-to: ding-account@gmane.org Original-Received: from util0.math.uh.edu ([129.7.128.18]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1V5bfr-0000K9-28 for ding-account@gmane.org; Sat, 03 Aug 2013 15:15:11 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by util0.math.uh.edu with smtp (Exim 4.63) (envelope-from ) id 1V5bf0-00081Q-Fm; Sat, 03 Aug 2013 08:14:18 -0500 Original-Received: from mx1.math.uh.edu ([129.7.128.32]) by util0.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1V5bez-00081C-6x for ding@lists.math.uh.edu; Sat, 03 Aug 2013 08:14:17 -0500 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx1.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1V5bex-0000cZ-PD for ding@lists.math.uh.edu; Sat, 03 Aug 2013 08:14:17 -0500 Original-Received: from prometheus.naquadah.org ([91.121.37.122] helo=mx1.naquadah.org) by quimby.gnus.org with esmtp (Exim 4.72) (envelope-from ) id 1V5bew-0001BO-1a; Sat, 03 Aug 2013 15:14:14 +0200 Original-Received: from dex.adm.naquadah.org (lns-bzn-28-82-250-173-75.adsl.proxad.net [82.250.173.75]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.naquadah.org (Postfix) with ESMTPSA id D8AD7E00DD; Sat, 3 Aug 2013 15:14:05 +0200 (CEST) Mail-Followup-To: Lars Magne Ingebrigtsen , ding@gnus.org In-Reply-To: (Lars Magne Ingebrigtsen's message of "Sat, 03 Aug 2013 13:29:08 +0200") User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3.50 (gnu/linux) X-Spam-Score: -1.9 (-) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:83644 Archived-At: --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sat, Aug 03 2013, Lars Magne Ingebrigtsen wrote: > Is there any general way to determine if a connection is "stuck"? If > we've created a network connection, and we change IP addresses, then the > connection is AWOL and will never get any response to traffic. > > Hm... > > If there's no way to determine the AWOL-ness of a connection (and I > guess there isn't), but we can see that the IP address has changed, then > we should close the connection and start a new one. > > That might help. But how do we determine that the IP address has > changed? > > The IP address of the host itself may also not change, but the router's > address changes, in which case we won't find that out, but it's a start, > perhaps... > > A TCP level solution would be nice... Having a configurable receive timeout may be enough. If you are not receiving any byte in say 10 or 15 seconds, it's probably better to reconnect. If I'm not mistaken, creating socket with a SO_RCVTIMEO option would help to achieve that. =2D-=20 Julien Danjou =2D- Free Software hacker - freelance consultant =2D- http://julien.danjou.info --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) iQIcBAEBAgAGBQJR/QIWAAoJEGEbqVCLeKXCrboQAJwpcTgsq/a0Y1Zit1bUccP1 sjt4xA+ELLZ6VZzQKFnBlfCMWIy5HEeCz72/Bx92O7wU23CsmXiv4S1M4KbMQNiR TazX0ztuel6RMFzDyR22zDTbiBYUyzCde5Bc1IdyDveScaxUD+LHf7IWxD5sdxqU 28kgqjA3Ze+CCvWaSlP8iJUmY1rqzQN2tJSjwXm1ENO4kV20hywTqkap7eZy5mIc 3Lx0CFFD5hxF+ziaF7b9qv9d3q8mN2TYgklyOmJSe67gyvv+RxAjw9jiaYqqKzA+ AzZe8gS3EifGkMtfCFGoScY6lZ/Z99qD0u6mgFQnSRRjJoR7IgYfVqIM8nfjRKeP 6jY7zMBLWLj6XqnXhULUV6cgJ3GDqigEZCIIg9qWQcHRl/uyqBMR9aRjU4JHIf8+ 3QvlscjD3jW0NXB4CpHfHO3tdBRDMz6ngvzvM9r0GkhX8yBz49P6Ee3Nz++TDtOq 469PpWB87OnPQJ7+tQsJPdm4/R9WoeRQndMsBZ6cbcaKzGxyySDGbev8+/sxJJJ6 8ZqxgknEE2V+xdzc8g8JGWQH2pLY0N+svo2o+2iZqAnMnCM9Mq1T0HvF+U7XAUmS BO+yhYMAzMUCOMQOfzd8IdJip+g56YrOO2dhQ3vORNrdRfu90FIiD5XUWy+NOK6l 0iXujIl37NW2J9iMbYHH =vzQs -----END PGP SIGNATURE----- --=-=-=--