Repeat telneting?

[Ed Vielmetti]

In article <17575 at sdcc6.ucsd.edu> salamon at 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 at msen.com