Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!ucsd!ucbvax!tut.cis.ohio-state.edu!mailrus!csd4.milw.wisc.edu!leah!rpi!rpi.edu!deven From: deven@rpi.edu (Deven Corzine) Newsgroups: comp.sys.amiga Subject: Re: RE:New Fish Disks Message-ID: Date: 21 May 89 01:41:31 GMT References: <15678@louie.udel.EDU> Sender: usenet@rpi.edu Organization: RPI Public Access Workstation Lab, Troy NY Lines: 72 In-reply-to: jwhitman@st-louis-emh2.army.mil's message of 17 May 89 18:07:23 GMT In article <15678@louie.udel.EDU> jwhitman@st-louis-emh2.army.mil (Jerry Whitman) writes: Seems there was a real-life (real-death?) problem at UIHUB. Lionell Hummel graciously dropped me a note indicating that UIHUB had in fact crashed and lay at the bottom of the bit bucket un-noticed for a period of time. It happens. A machine which is down (or non-existent) will always give a connection timed out. So can network delays. That brings up a new question. I tried twice yesterday to down load ISPell from FF191. Both attempts were aborted, apparently by UIHUB, about two minutes into the transfer. If memory serves me correctly the messages I got were 1). Connection lost, followed by 2). Connection re-established by peer. However I was actually dis-connected. This sounds like a problem caused by network delays - i.e. your machine was waiting for data from uihub, and due to some delay in the network itself, it timed out, deciding that nothing was forthcoming. Then, the expected data finally DID arrive, which could account for the "Connection re-established by peer" message. [I've never run across that message, though I have hit "Connection reset by peer."] Though the data might have arrived, and the connection may not have needed to be closed, the ftp program probably closed the socket when it got the original connection lost, so that the connection was closed when communication between the machines was restored. This is speculation, of course, but it seems a likely explanation... Does UIHUB look for potentially heavy traffic of a low priority type such as an FTP transfer and elect to terminate it if the time is needed for higher priority tasks, or did I just run into a poor connection? Not bloody likely. It probably wasn't a problem with uihub itself, but with the intervening network, as I said. True, interactive (telnet) connections DO have higher priority, and perhaps would have survived where the ftp connection did not, but it was no policy decision; the network tries to deliver the packets (a "best-effort" delivery system) but makes no guarantees. It gives interactive connections higher priority, but does not intentionally kill lower-priority connections due to network load -- timeouts on either end will do that when the network load gets high enough to introduce significant delays. You probably ran into a "poor connection" in the sense that a major link may have been down, overloading some alternate path with less bandwidth. Such situations happen, and reconnecting isn't likely to help you; the "connections" are logical, while the actual network only delivers packets -- the TCP protocol and controlling software at each end handles building packets into a byte stream. It's not like a phone line, where everything goes across certain wires, and you can get a different path of wires by calling again. In a single TCP connection, different packets in the sequence can take completely different routes. It's not a fixed path. Hence, reconnecting will only likely help if it affects how the remote machine will deal with it as a new connection; it won't change the data transfer rate. That's governed by the state of the network, routers, etc. The network at large doesn't know or care how particular packets combine into a byte stream. Nor need it. I am going to try it again today and see what happens. You can always wait a day or three and try again; if it is a major link down, it will get fixed sooner or later. If it's just too much traffic, you can do much, except maybe try it at 5 AM... Deven -- shadow@[128.113.10.2] Deven T. Corzine (518) 272-5847 shadow@[128.113.10.201] 2346 15th St. Pi-Rho America deven@rpitsmts.bitnet Troy, NY 12180-2306 <> "Simple things should be simple and complex things should be possible." - A.K.