On Sat, Nov 17, 2012 at 2:48 AM, Phil Sorber
<phil@omniti.com> wrote:
>> > 3) Having an output close to what ping actually does would also be nice,
>> > the
>> > current output like Accepting/Rejecting Connections are not that
>>
>> Could you be more specific? Are you saying you don't want to see
>> accepting/rejecting info output?
>
> OK sorry.
>
> I meant something like that for an accessible server:
> $ pg_ping -c 3 -h
server.com > PING
server.com (192.168.1.3)
> accept from
192.168.1.3: icmp_seq=0 time=0.241 ms
> accept from
192.168.1.3: icmp_seq=0 time=0.240 ms
> accept from
192.168.1.3: icmp_seq=0 time=0.242 ms
>
> Like that for a rejected connection:
> reject from
192.168.1.3: icmp_seq=0 time=0.241 ms
>
> Like that for a timeout:
> timeout from
192.168.1.3: icmp_seq=0
> Then print 1 line for each ping taken to stdout.
How does icmp_seq fit into this? Or was that an oversight?
Yes, sorry it doesn't fit in this model. Please forget about it.
Also, in standard ping if you don't pass -c it will continue to loop
until interrupted. Would you suggest that pg_ping mimic that, or that
we add an additional flag for that behavior?
By targeting pg_ping as a clone of ping, yes it would mean that we target it to loop indefinitely if no c flags is given.
FWIW, I would use 'watch' with the existing output for cases that I
would need something like that.
watch allows you to launch a program given a certain time period. I am not sure this is related with pinging a server.
When pinging a server, what you are looking for is not only the connectivity to it but also the latency you have with it, no?
--
Michael Paquier
http://michael.otacoo.com