salamon@sdbio2.ucsd.edu (Andrew Salamon) (03/17/91)
Greetings! I am very much a novice at this sort of thing, so please bear with me... 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. I can write a simple 'while' loop that does 'telnet host' but when telnet says 'Network Unreachable' or some such, the shell 'while' loop can't do any- thing to continue with the next attempt. I should say, I don't know of any way to make the shell loop do so. Any help would be greatly appreciated. Please respond by e-mail. -- Andrew "Hiding behind 7-bit ASCII" Salamon | a.k.a Bleydion op Rhys salamon@sdbio2.ucsd.edu <---Internet | a.k.a T'nol Grad_Student@Dept_Biology.UCSD <---:) ;) ^) | a.k.a Etienne De Mer
salamon@sdbio2.ucsd.edu (Andrew Salamon) (03/17/91)
My apologies! I forgot to add that I am using SunOS 4.0.3. -- Andrew "Hiding behind 7-bit ASCII" Salamon | a.k.a Bleydion op Rhys salamon@sdbio2.ucsd.edu <---Internet | a.k.a T'nol Grad_Student@Dept_Biology.UCSD <---:) ;) ^) | a.k.a Etienne De Mer
emv@ox.com (Ed Vielmetti) (03/18/91)
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