From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Bob Rogers Newsgroups: gmane.emacs.devel Subject: Re: gnus makes emacs lose response Date: Wed, 23 Aug 2006 23:17:09 -0400 Message-ID: <17645.6709.53699.324551@rgrjr.dyndns.org> References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1156389454 14789 80.91.229.2 (24 Aug 2006 03:17:34 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 24 Aug 2006 03:17:34 +0000 (UTC) Cc: emacs-devel@gnu.org, angeli@iwi.uni-sb.de, "Kim F. Storm" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Aug 24 05:17:32 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1GG5ic-0005nk-Q8 for ged-emacs-devel@m.gmane.org; Thu, 24 Aug 2006 05:17:23 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GG5ic-00018K-1u for ged-emacs-devel@m.gmane.org; Wed, 23 Aug 2006 23:17:22 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GG5iR-000180-8z for emacs-devel@gnu.org; Wed, 23 Aug 2006 23:17:11 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GG5iQ-00017b-Hq for emacs-devel@gnu.org; Wed, 23 Aug 2006 23:17:10 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GG5iQ-00017Y-9u for emacs-devel@gnu.org; Wed, 23 Aug 2006 23:17:10 -0400 Original-Received: from [24.128.218.106] (helo=rgrjr.dyndns.org) by monty-python.gnu.org with smtp (Exim 4.52) id 1GG5qO-00032e-9f for emacs-devel@gnu.org; Wed, 23 Aug 2006 23:25:24 -0400 Original-Received: (qmail 25759 invoked by uid 500); 24 Aug 2006 03:17:09 -0000 Original-To: rms@gnu.org In-Reply-To: X-Mailer: VM 7.19 under Emacs 22.0.50.2 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:58786 Archived-At: From: Richard Stallman Date: Wed, 23 Aug 2006 10:45:30 -0400 > That means after reconnecting to the internet under Windows a new > process is started which has no problem communicating to the server > while on GNU/Linux the old one is reused which obviously cannot cope > with the new internet connection. . . . > I am not sure what the right course of action on GNU/Linux would be to > remedy the problem. Should programs like openssl die when the > internet connection is being closed? Or renegotiate a connection? I don't know whether openssl can keep working when a phone connection drops and is reestablished, but I have seen scp connections keep working when I removed and then reinserted a Wifi card. These cases are not the same but they are analogous; if the openssl/phone case does not work now, it ought to work. The problem is fundamental to dialups (and my apologies if this is old hat, and by "it ought to work" you really meant "Gnus" and not "openssl"). For a wireless card or cable modem, the DHCP server remembers your hardware address, which it uses to give you the IP address you had before, so established TCP connections resume working as soon as the interface comes back up. When you redial, the computer attached to the modem bank has no clue who are (and might even be a different computer than before), so you usually get a different IP address, making TCP connections established with the old IP address unusable. Either way, OpenSSL probably isn't even aware of all this commotion in the lower layers of the networking stack. So you might consider this a bug in GNU/Linux that it doesn't close open connections for old addresses. However, it may not be possible to decide that an old address is truly and forevermore gone, and so (I am guessing) they figured that it is more robust to let higher-level connection timeout mechanisms come into play. (It may even be specified that way, but I don't know the relevant RFCs to check.) By that interpretation, the observed difference in behavior is really a Windows bug. (And it wouldn't be the first time MS chose user convenience over robustness, now, would it? ;-) I see similar problems connection to one of the news servers at my ISP. I just interrupt Gnus, and make anoter refresh -- I guess Gnus could just as well do this automatically if there is no response from the server it used last time. I don't entirely understand that proposal . . . If openssl could resume its connection when you reconnect the phone line, would that make this proposal unnecessary? Would that make this proposal undesirable or incorrect? Would it be possible for Gnus to request a timeout when invoking openssl? I'm afraid I don't know enough about either to make a more detailed suggestion, let alone whether this approach could work. (And http://www.openssl.org/docs/apps/s_client.html doesn't show any timeout-related option, which is not hopeful.) If not, then restarting the connection after a suitable timeout is probably the best available technology. -- Bob Rogers [who sometimes pretends to be a network engineer, often with success.] http://rgrjr.dyndns.org/