From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/5279 Path: main.gmane.org!not-for-mail From: Felix Lee Newsgroups: gmane.emacs.gnus.general Subject: dynamic ip (Re: Gnus Memory usage) Date: Sat, 24 Feb 1996 14:08:46 -0800 Message-ID: <199602242208.OAA13870@desiree.teleport.com> References: NNTP-Posting-Host: coloc-standby.netfonds.no X-Trace: main.gmane.org 1035145906 32343 80.91.224.250 (20 Oct 2002 20:31:46 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2002 20:31:46 +0000 (UTC) Return-Path: ding-request@ifi.uio.no Original-Received: from ifi.uio.no (ifi.uio.no [129.240.64.2]) by deanna.miranova.com (8.7.3/8.6.9) with SMTP id OAA18293 for ; Sat, 24 Feb 1996 14:30:16 -0800 Original-Received: from desiree.teleport.com (desiree.teleport.com [192.108.254.21]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Sat, 24 Feb 1996 23:08:28 +0100 Original-Received: from teleport.com ([204.119.17.62]) by desiree.teleport.com (8.6.12/8.6.9) with ESMTP id OAA13870 for ; Sat, 24 Feb 1996 14:08:23 -0800 Original-To: ding@ifi.uio.no In-reply-to: Your message of 24 Feb 1996 08:44:08 +0100. Xref: main.gmane.org gmane.emacs.gnus.general:5279 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:5279 > Mark Denovich writes: > > Not so. I am forced to use Dynamic-IP PPP. Thus my IP address is > > never the same after disconnect. Sgnus and just about every other app > > handle this very poorly, the exception being Netscape. the main reason netscape handles it is because http needs a new connection for every data transfer. netscape news handles dynamic ip about as well as gnus does (automatic reconnect only on connection shutdown). Lars: > I don't know exactly what I should do about it. Gnus should > definitely figure out that something odd is going on when it sends out > commands and doesn't get any data back. Perhaps the commands should > have a timeout thingie (which would not be enabled by default), and > if a command times out, Gnus should just hang up and reconnect. this would be okay, but to be reliable the timeout would have to be on the order of several minutes (since getting a response to a POST command can take minutes). what I'd like instead is an easy way of doing a manual reconnect, since I know when I need to. --