BPJ0%LEHIGH.BITNET@ibm1.cc.lehigh.edu (Bin) (05/15/89)
Hi, Does anybody know where I can obtain the new fish disks 189-200 other than uihub.cs.uiuc.edu? Either that node is closed down or there is some other problem, I can't get to it. Desperately seeking fish, Bin
jwhitman@st-louis-emh2.army.mil (Jerry Whitman) (05/15/89)
Bin <BPJ0%LEHIGH.BITNET.IBM1.CC.LEHIGH.EDU> writes that he cannot reach uihub.cs.uiuc.edu for Fred Fish disks 189-200. When I try to access the node all I get is an FTP time-out trying to establish the connection. Seems something is definately wrong here. While I am not glad to hear that someone else is having trouble I am glad to know the problem may not be mine alone. Has anyone been successful reaching the node? Thanks much!!!! Regards; Jerry Whitman
jwilson@s.cs.uiuc.edu (05/17/89)
I couldn't get to uihub.cs.uiuc.edu until today, and it's not very far from here :-) However, it seems to be back up.
C503719@umcvmb.missouri.edu (Baird McIntosh) (05/18/89)
In article (15498@louie.udel.edu), jwhitman@st-louis-emh2.army.mil (Jerry Whitman) writes: >>Bin <BPJ0%LEHIGH.BITNET.IBM1.CC.LEHIGH.EDU> writes that he cannot reac >>uihub.cs.uiuc.edu for Fred Fish disks 189-200. >When I try to access the node all I get is an FTP time-out trying to >establish the connection. Seems something is definately wrong here. >While I am not glad to hear that someone else is having trouble I am glad > to know the problem may not be mine alone. >Has anyone been successful reaching the node? I have had the same time-out troubles in the past, but recently I have gotten lucky. It seems to be a hit-or-miss situation...sometimes you CAN and sometimes you CAN'T get connected. The flakey behavior of uihub has prompted a friend to rename it yo.yo.edu. :-) I CAN say that Fish Disks 189-200, with the exception of 192 (?), were in the archive when I was able to connect. >Thanks much!!!! Best of luck in your connection attempts. >Regards; >Jerry Whitman Baird McIntosh # INTERNET- c503719@umcvmb.missouri.edu <-or-> BITNET- c503719@umcvmb.bitnet # # "Don't tell me truth hurts, little girl, 'cause it hurts like hell." # # -- from UNDERGROUND, by David Bowie. / "USENET is not a network." #
jwhitman@st-louis-emh2.army.mil (Jerry Whitman) (05/18/89)
Thanks to many who responded to my inability to reach UIHUB [128.174.252.27]. 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 appears all is well now. I can successfully reach UIHUB now. 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. 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? I am going to try it again today and see what happens. Regards, Jerry
deven@rpi.edu (Deven Corzine) (05/21/89)
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] <shadow@pawl.rpi.edu> Deven T. Corzine (518) 272-5847
shadow@[128.113.10.201] <shadow@acm.rpi.edu> 2346 15th St. Pi-Rho America
deven@rpitsmts.bitnet <userfxb6@rpitsmts> Troy, NY 12180-2306 <<tionen>>
"Simple things should be simple and complex things should be possible." - A.K.denbeste@bbn.com (Steven Den Beste) (05/21/89)
Several people have complained here about extraordinarily slow FTP response when accessing the Fish disk archives at UIUC. I've been in contact with some of the system gods at UIUC, and it was explained to me this way: This is a side effect of the Arpanet phaseout. The node that UIUC used to connect to was one of the first to be turned off. So they reconnected through a gateway (level 4, that is, an IP gateway) in (I think they said) Michigan. When you FTP to uihub or uxe what you are REALLY doing, as far as the Arpanet is concerned, is calling the IP gateway. It operates at the same network level as IP on your system (so it is a "peer"). It then opens a new connection down to UIUC through some other non-Arpanet medium. When you get any of the "peer" messages, especially "connection reset by peer", what you are being told is that the IP gateway broke the connection for some reason. (I conjecture that it does this in self-defense when it is overloaded, likely preserving connections by its owners and killing others like you and me first.) Now some interesting questions and their answers: 1. Is it going to get better? Probably not. 2. Is it going to get worse? It is likely that as the Arpanet is further phased out, other things like this will happen to other sites, and UIUC might get worse or lose connection entirely. 3. Why is the Arpanet being phased out? Because Defense Advanced Research Projects Agency (who pays for it) doesn't think that the Arpanet is either advanced, or research, or a project anymore and doesn't want to shell out all the money it costs. The NSFnet is supposed to pick up the traffic as the Arpanet phases out, but the NSFnet will be charging its users for their traffic, so don't expect the same kind of free and easy access you have now. (All the UUCP and BITNET users are now entitled to one (1) each snicker.) 4. When I get one of these messages, is there anything I can do to fix the problem? No. 5. If I try it again immediately will I have better success? It is hard to say for sure, but it isn't likely. 6. Is there anything UIUC can do about this? Not really. There isn't really any chance of them getting another direct connection to the Arpanet - that's what the phase-out is about. Any answer for them is going to be extremely expensive. 7. How can I get a clean transfer, then? You might try calling at 4:00 AM on a Sunday when the traffic level is low at the gateway... Sorry to paint such a bleak picture. I now have a question of my own, which I'd sure appreciate an answer to: I seem vaguely to remember that there was some other site which had a duplicate of uxe's Fish disk directory, but I'll be damned if I remember where it was. Am I imagining it, and if not, could someone mail me the name or address of that site? Steven C. Den Beste, BBN Communications Corp., Cambridge MA denbeste@bbn.com(ARPA/CSNET/UUCP) harvard!bbn.com!denbeste(UUCP)
hummel@m.cs.uiuc.edu (05/25/89)
/* Written 11:23 am May 21, 1989 by denbeste@bbn.com in comp.sys.amiga: */ > Now some interesting questions and their answers: OK. Steven Den Beste gave some good and useful information about the woes of the ARPA phaseout, but most of the problems being reported are strictly UIHUB's. It is a black-sheep SV machine in a BSD shop, hence it sees relatively little use, and that's why I was able to usurp disk space for a "staging" area to the UXE archive. Unfortunately, the "administrative gods" here don't give it a high priority when it is having problems, like those it's been having since upgrading it to SV r3.1.1. If I can wing some administrative privledges on UIHUB, I will straighten things out right away. For the time being, though, it will be quite intermittent. > I now have a question of my own, which I'd sure appreciate an answer to: I > seem vaguely to remember that there was some other site which had a duplicate > of uxe's Fish disk directory, but I'll be damned if I remember where it was. The site is: 128.8.10.14 trantor.umd.edu and the directory is info-amiga/uxe/amiga. If the administrator of that archive would get in touch with me, I would be happy to provide the material that everyone's going to UIHUB for, viz: Fish Disks 189-210, CUCUG disks 16-19, and VirusX 3.2. < Lionel ---------- Lionel Hummel 404 W. High St. #6, Urbana, IL 61801 University of Illinois, Urbana-Champaign [H] (217)344-5303 [W] (217)333-7408 hummel@cs.uiuc.edu {pur-ee,uunet}!uiucdcs!hummel BIX: lhummel