Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!caen!ox.com!ox.com!emv From: emv@ox.com (Ed Vielmetti) Newsgroups: comp.unix.questions Subject: Re: Repeat telneting? Message-ID: Date: 18 Mar 91 04:10:40 GMT References: <17575@sdcc6.ucsd.edu> Sender: usenet@ox.com (Usenet News Administrator) Organization: OTA Limited Partnership, Ann Arbor MI. Lines: 53 In-Reply-To: salamon@sdbio2.ucsd.edu's message of 17 Mar 91 04:51:49 GMT In article <17575@sdcc6.ucsd.edu> salamon@sdbio2.ucsd.edu (Andrew Salamon) writes: I would like to have a way of continuously attempting to connect to a machine with telnet. ie if the machine is down, or there are network problems, I would like to have a small program that would continue trying to connect until it succeeded, or I stopped it. In general, this is not an appropriate use of the network (to bombard a host with telnet connection attempts while it's down). You'd be better off to try to figure out why the service you want is unavailable with a minimum of effort, and then to check back every so often until you find it is there. If everyone were to mercilessly wail on downed hosts and networks until they came back up, it would be more than likely that the hosts in question would crash immediately when they came back to life under the weight of all the simultaneous connection attempts. The first thing to try to do is to determine whether the remote host is down or whether there are network problems. There are two easy ways of doing this. First is to identify a host that is "near" the host you are looking for; this could ideally mean to be on the same subnet, but on the same campus (or in the same country) is often close enough. Use the "ping" command to launch a few pings at the neighbor of the host you are connecting to. If the pings come back, it was probably a host problem; if the pings get lost, suspect a network problem. Network problems can often be isolated with the "traceroute" command. Use it to determine where the return packets stop coming back. If you can get off of your campus, or onto the NSFnet backbone, or wherever, it'll show you how far you get. Chances are things will flake out near the end. When you identify where the pings stop coming back, you'll know if it's trouble on your end or far away. The right thing to do then is to contact your network manager, or campus network support staff, and let them know what has gone wrong. This is especially true if the problem looks to be a local one. If the trouble is (e.g.) the line to Canada is saturated, they may or may not be able to find the end result of the problem. Some problems the only solution is to wait until off-peak hours or to throw money at it. Check your ping program and see if it has an option to send out a packet at regular intervals, say once every 5 or 10 minutes. (the one on ftp.cc.berkeley.edu has this option [-i interval]). This will give you some clue as to whether the host and network are responding, and it won't send out much more traffic than necessary. (it would be nice if ping could send say 5 packets each time at this kind of spacing, so that accidental single drops wouldn't count against you.) -- Msen Edward Vielmetti /|--- moderator, comp.archives emv@msen.com