Hello-
Two items/questions regarding Client::Ping;
1) Client::Ping payload option?
Would a patch for Client::Ping be considered that would allow a user to
set their own data pattern?
my $datapattern = delete $params{DataPattern};
$datapattern = 'Use POE!' x 7 unless defined $datapattern
...
$heap->{data} = $datapattern;
I would like to have the opportunity for a small payload.
2) First Client::Ping post 'slow'?
I noticed that some of the ips posted get handled much slower than
subsequent IPs; In this example, I have parallelism set to 4, so I get
4 late replies [if i had set it to 14, i'd get 14]
4.79.64.42 is alive (packet return time: 0.938143014907837)
38.99.202.26 is alive (packet return time: 0.935018062591553)
38.101.160.229 is alive (packet return time: 0.927701950073242)
63.145.159.18 is alive (packet return time: 0.923621892929077)
65.77.115.178 is alive (packet return time: 0.00751113891601562)
65.113.85.6 is alive (packet return time: 0.00957703590393066)
..
>From a tcpdump, the packets are hitting the host, but just taking a
long time to get processed.
13:39:09.030498 205.213.110.242 > 4.79.64.42: icmp: echo request (DF)
13:39:09.034209 4.79.64.42 > 205.213.110.242: icmp: echo reply (DF)
13:39:09.041748 205.213.110.242 > 38.99.202.26: icmp: echo request (DF)
13:39:09.046869 38.99.202.26 > 205.213.110.242: icmp: echo reply (DF)
13:39:09.051587 205.213.110.242 > 38.101.160.229: icmp: echo request(DF)
13:39:09.056710 38.101.160.229 > 205.213.110.242: icmp: echo reply (DF)
13:39:09.057463 205.213.110.242 > 63.145.159.18: icmp: echo request (DF)
13:39:09.061039 63.145.159.18 > 205.213.110.242: icmp: echo reply (DF)
13:39:10.047931 205.213.110.242 > 65.77.115.178: icmp: echo request (DF)
13:39:10.048490 65.77.115.178 > 205.213.110.242: icmp: echo reply (DF)
13:39:10.049015 205.213.110.242 > 65.113.85.6: icmp: echo request (DF)
13:39:10.056119 65.113.85.6 > 205.213.110.242: icmp: echo reply (DF)
The reason I am concerned; I am trying to code a simple app to do ICMP
reachability testing of IPs and put a bounds on the maximum amount of
time a cycle through all addresses will take to complete. If I have
2000 targets and I want a cycle to complete in a maximum of 60 seconds,
I control the upper bounds (roughly) by using the Timeout and
Parallelism variables. Since I am monitoring backbone network equipment
I have set an aggressive timeout of 0.5 seconds, which is far above any
reasonable value would take. Sometimes, that first ping takes more than
0.5s, and while I do wait for multiple concurrent failed pings before
reporting, it still occasionally causes a false alarm in my testing.
Any thoughts? I can hack around this by pinging '$parallelism' ignored
first items but I am curious to what is the source of this problem and
if it is fixable. I currently have a icmp polling model using
Threads::shared that I would like to replace with this much simpler model.
Thanks-
-Michael
