Re: Trouble with Net::Ping

On Dec 10, 5:46 pm, "Peter J. Holzer" <hjp-usen...@xxxxxx> wrote:
On 2008-12-09 06:14, Ted Byers <r.ted.by...@xxxxxxxxx> wrote:

On Dec 8, 7:29 pm, Big and Blue <N...@xxxxxxxxxxxxx> wrote:
Ted Byers wrote:
Here is a little script assembled fromt he documentation for
Net::Ping.

That same documentation will show that Net::Ping, by default, tries to
open a TCP socket to the destination.

Yes, I noticed that.  I also noticed that the documentation said it
was the slowest because it is a higher level protocol than the others,
doing checks the others don't.  My recollection is a bit fuzzy, but
IIRC TCP lives on top of UDP (and thus it makes sense that UDP would
be faster)

No. UDP and TCP are at the same level - both are layered on IP. Same for
ICMP although it is more tightly coupled to IP.


OK.
and http lives on top of TCP.  Since I would expect a web
client like a browser based on LWP would be using http exchanges,

Maybe I'm mixing up threads, but didn't you have problems with FTP?
That's a different protocol then HTTP. Both use TCP, but you can't debug
either of them properly by trying to connect to TCP port 7 (which is
what Net::Ping does).


Actually, I am having trouble with both. One script uses Net::FTP to
transfer archives from one of our servers to another across the
country, and the other uses LWP to retrieve a data feed from one of
our suppliers. Both work flawlessly when the amount of data is small
(up to a few hundred k) and both time out when the amount of data is
large (a few MB). Might it be that the client merely thinks the
connection has timed out but that the requested data is still being
transferred? I know that the script that pushes our large archives to
our other server does complete the transfer of the larger files (we
can open them and see they're intact), but then dies believing the
connection is broken and so never makes an attempt to send the next
file in thelist. We managed to work around this by opening the
connection to the ftp server just before trying to transfer a file and
closing it immediately after sending the file (something my colleague
- our system administrator - set up). It seems stupid to have to
close and reopen the ftp connection between large files, especially
when that is unnecessary with smal ones. Is there a better way?

WRT LWP, when the transfer fails, we work around it by recursively
partitioning the period for which we're requesting data into smaller
and smaller sub-intervvals until we get all the data. This is only
necessary when there is several MB worth of data to be retrieved.
Again, is there a better way?




it makes sense that if there is trouble with a given http exchange,
one should check the foundation it is built on, from the top down.

       You may choose one of six different protocols to use for the ping. The
       "tcp" protocol is the default. Note that a live remote host may still
       fail to be pingable by one or more of these protocols.. For example,
       www.microsoft.comisgenerally alive but not "icmp" pingable.

The ping command uses ICMP.

These are different Internet Protocols.

Yes, I know they're different protocols.  But, as you note and I had
already observed, the documentation says tcp is the default protocol,
and thatwww.microsoft.comis generally alive but not icmp pingable.
That is why I tried the default TCP first.

But there is a problem, here, with what you've written.  You say the
ping command uses ICMP, but you saywww.microsoft.comis not ICMP
pingable.  I used the ping command provided by MS with WXP.  Why would
that use ICMP ifwww.microsoft.comis not ICMP pingable.

MS ping uses ICMP because that's its job. "ping" is the command which
checks if a host replies to ICMP echo requests. For some reason
Microsoft doesn't want its web servers to reply to ICMP echo requests.
Maybe they think you should use a browser to look at a webserver, not
ping ;-).

OK. But that makes them unfriendly when one needs to check
connectivity.

Is there something in configuring Net::Ping that can make it useful
for automating checking connectivity (in the context of handling
situations where, say, and LWP agent fails to retieve data as expected
- did we get no data because there was no data or because the
connection was lost or some other reason)?

LWP itself will tell you that.  As noted, the "ping" command itself uses
ICMP - a protocol which would be of little use for data transfer, and
certainly not used by LWP.

I don't understand why you're on about ICMP when the documentation
says it is only one of three protocols, and the default protocol is
TCP.

Probably to explain why it is possible that the ping command shows a
host as alive (that is it replies to ICMP echo requests) but Net::Ping
doesn't (because a connection request to TCP port 7 (echo) times out),
or vice versa. They are just completely different protocols and a
firewall may block one but not the other. (Incidentally, if a firewall
does block requests with a port-unreachable message, Net::Ping thinks
the host is alive, although it may be down).


OK. That makes sense.
In any event, LWP gives only a mention that a given transfer timed out
(and it happens only when trying to transfer a multimegabyte file),
but not why.  I DID use the LWP::DebugFile package for this, but the
data doesn't seem very detailed.

I was, in fact, advised in this forum to check connectivity between
the machines in the transaction using ping and traceroute.

Yes. The commands "ping" and "traceroute". They already exist and are
almost certainly installed on your linux server. No need to write a
replacement in Perl.

OK. But the server running my script is Windows. There traceroute is
tracert (unless Windows Server uses a different name than the other
versions of Windows). And for the purpose of automating checking of
connectivity one would need a little extra code to invoke these OS
commands and parse the output to check for success or failure
(something I'd assumed was what Net::Ping and Net::Traceroute were
made for, but it appears that was wrong).

Thanks

Ted
.

Relevant Pages

  • Re: Trouble with Net::Ping
    ... That same documentation will show that Net::Ping, by default, tries to ... was the slowest because it is a higher level protocol than the others, ... IIRC TCP lives on top of UDP (and thus it makes sense that UDP would ... The ping command uses ICMP. ...
    (comp.lang.perl.misc)
  • Re: Trouble with Net::Ping
    ... IIRC TCP lives on top of UDP (and thus it makes sense that UDP would ... ICMP although it is more tightly coupled to IP. ... That's a different protocol then HTTP. ... The ping command uses ICMP. ...
    (comp.lang.perl.misc)
  • Re: Whats the difference between UDP and TCP packets?
    ... TCP is a connection oriented protocol. ... The host that wants to send data sends a SYN ...
    (comp.security.firewalls)
  • Re: The Minutiae of a TCP Client
    ... bind associates an existing socket with a specific protocol address. ... the preferred way to specify a preference for TCP rather than UDP? ... there is little reason to do ... protocol providing such a connection. ...
    (comp.unix.programmer)
  • Re: Need Good Source re Daylight Savings Time Modification
    ... Rdate uses TCP to retrieve the current time of another ... machine using using the protocol described in RFC 868. ... Listen on port 37. ... U: Close the connection. ...
    (linux.redhat)