From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Lars Magne Ingebrigtsen Newsgroups: gmane.emacs.devel Subject: Re: Determining whether a TCP connection is up Date: Mon, 05 Aug 2013 04:12:50 +0200 Message-ID: References: <87txj64vbx.fsf@dex.adm.naquadah.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1375668796 28086 80.91.229.3 (5 Aug 2013 02:13:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 5 Aug 2013 02:13:16 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Aug 05 04:13:18 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1V6AIP-0005hy-2U for ged-emacs-devel@m.gmane.org; Mon, 05 Aug 2013 04:13:17 +0200 Original-Received: from localhost ([::1]:58780 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V6AIO-0002SK-KG for ged-emacs-devel@m.gmane.org; Sun, 04 Aug 2013 22:13:16 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53905) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V6AIH-0002QE-1D for emacs-devel@gnu.org; Sun, 04 Aug 2013 22:13:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V6AIB-0002rR-HU for emacs-devel@gnu.org; Sun, 04 Aug 2013 22:13:08 -0400 Original-Received: from hermes.netfonds.no ([80.91.224.195]:43632) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V6AIB-0002rK-B3 for emacs-devel@gnu.org; Sun, 04 Aug 2013 22:13:03 -0400 Original-Received: from cm-84.215.51.58.getinternet.no ([84.215.51.58] helo=stories.gnus.org) by hermes.netfonds.no with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1V6AHy-00039u-Hk for emacs-devel@gnu.org; Mon, 05 Aug 2013 04:12:50 +0200 Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAFVBMVEUAAAANCQkODAwIBQWI gnwTExMCAgJJYExuAAACQ0lEQVQ4jVWUwXIbIQyG1XaGO2zsO9rQc1jGe24nOOd6bXKmoeH9H6G/ gHXGmvEa65N+SSyYDLNl69KDbdZRCGHy4XB39S9rqIRm3muPNOaW6zYWsFY8fAi73qbZagolVBiS NN/lHBuqw4K/N7AZhpQ4c1U1mO2rK3YCIEVKSdtmT5oXJsqVYMrzsRYzymzBwJUbWH7W/AWOC+Wy UplymaDJ6GeTGXnWlFXOH0vaoOMwH/PByNMSWqrlM76qReY2hp81yNTbXesLlUOaK8ott8k7nhf6 C3CsGQk2CFBPczAcPCk4V6ht87FUmehzLoVfCimqqtTv9uLXuWgA2TtdC0bIqtK3Rdq/pio/iSr9 gKjMuJ5ShF37tPAUobBraeAX7YYaVUh8LQ30hNzCGzjH5z1DWkY4FrKKtxjTWYBa7xlSC/54TvEP tZ1oxatCJ6oJRQAVqrwIzNFerfrXQVfq7T6ATF1I2q1lxVnoUudc0nUV1KVU/bhJW/GtnlJ676ep SZVTjA7gvaTz7a2F+nYSBVwOMa6fmOV1lQQjpz0UA6DTOTzdAMQxQAg3AONDGiAEHuAkwNgDWngA /pIAeDtg839PGjbAcnUXjcN0SND0AtyQkuuhWU9BW3Fr04CX64Q4tnIhd6CnyU+SIPdAdy/Wifp6 QoJl+Cy0DBt2A4gLGdYwBPFhJrsDlpuH/wK5WQIggYCm7Nr5x5oHQIDD3ZY4a7TGmYbYqIH5pF1J n3wHo8ZeSmMOM2rotlvDHQZAu+HBRgC7/2mP4dcnOujLAAAAAElFTkSuQmCC X-Now-Playing: Phranc's _Amazons_: "Amazons" X-Hashcash: 1:23:130805:emacs-devel@gnu.org::ABu4NpkEsP/no2xg:000000000000000000000000000000000000000000yCHq In-Reply-To: <87txj64vbx.fsf@dex.adm.naquadah.org> (Julien Danjou's message of "Sat, 03 Aug 2013 18:01:38 +0200") User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3.50 (gnu/linux) X-MailScanner-ID: 1V6AHy-00039u-Hk MailScanner-NULL-Check: 1376273573.06002@z45vVAEqZuKYFNTMBLFfHA X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.224.195 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:162421 Archived-At: Julien Danjou writes: > I think most IMAP clients uses a pool of several connections in the > background to deliver actions based on some sort of queue, like delete > something or fetch this. Having this would solve partially the problem > since if a connection goes AWOL, you just have to wait for the kernel to > kill the TCP connection it at some point (which might takes time), but > you can continue to create new (working) connections to fulfil the user > requests in the meantime, and then requeue the action that timed-out. Whether you have a pool of connections or kill/reconnect, the problem remains the same: Figuring out when to switch connections/reconnect. And in the case that the IP address changed, all your connections in the pool will hang, so it doesn't really help... -- (domestic pets only, the antidote for overdose, milk.) No Gnus T-Shirt for sale: http://ingebrigtsen.no/no.php and http://lars.ingebrigtsen.no/2013/08/twenty-years-of-september.html