-
Notifications
You must be signed in to change notification settings - Fork 344
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement a per-packet timeout (i.e. -W in UNIX ping) #63
Comments
Sorry I'm not sure I understand, can you explain what you are trying to accomplish? |
func worker(addr string, count int) *ping.Statistics {
pinger, CreateErr := ping.NewPinger(addr)
if CreateErr != nil {
panic(CreateErr)
}
pinger.SetPrivileged(true)
pinger.Count = count
pinger.OnRecv = func(pkt *ping.Packet) {
fmt.Printf("%d bytes from %s: icmp_seq=%d time=%v\n",
pkt.Nbytes, pkt.IPAddr, pkt.Seq, pkt.Rtt)
}
pinger.Run()
return pinger.Statistics()
}
func main() {
s := worker("52.34.112.193",10)
fmt.Println(s)
} This is my code, and when I tested it, I found that when the network was not stable enough to recv a packet or two, the count never met and quit the ping program |
It should exit the ping program after sending 10 packets |
You can use the Timeout parameter on the |
case <-interval.C:
if p.Count > 0 && p.PacketsSent >= p.Count {
// before is continue , that is why can't exit pinger
close(p.done)
wg.Wait()
} Timeout this parameter does not meet my requirements...en |
Fundamentally the pinger "count" option waits for responses after it sends out pings so it can't simply exit immediately after sending 10 pings. This is consistent with the BSD implementation of One option would be to make it consistent with the GNU implementation, although I think the BSD implementation seems more reasonable. Another option would be to implement a per-ping timeout ( Lastly there could simply be a boolean switch to have the |
My requirement is to send a packet, wait for the duration of receiving a packet, increase the timeout count if failure and exit the program after waiting for receiving 10 packets, regardless of whether the 10 packets have timeouts or not. I think the Boolean switch is a great option for exiting ping. |
Do you mean you want to wait for |
Yes, wait for |
First, thank you for this project! Without per-packet timeout, the problem I see is that when sending a set of probes, the earlier probes have more time to have responses. Say you send two probes, one at each t=0 and t=1 seconds. Then either deadline or control-C stops listening for replies at t=2. If the response time was a constant 1500ms, the first probe would receive a reply but the second would count as a loss. Max response time is equally problematic and tends to increase with larger It's incorrect to interpret the packet loss results of any ping tool as "the client never responded" since the tools can't show that the remote won't reply, say, tomorrow. Of course a delay of hours is unlikely but when dealing with troubled, congested and highly buffered networks, tens of seconds is not unheard of. Tools and libraries should permit a clear interpretation of packet loss. If you introduce a per-probe timeout, ignore replies past the timeout and wait the duration after sending the last probe, then packet loss can be interpreted as "probes that did not receive a reply within X time". All response times are then bounded. Side note: What is called 'timeout' in this project is 'deadline' in UNIX ping, and I think the UNIX naming makes sense when both are used. 'Deadline' is when everything has to be done. Is this something the developers would be interested in seeing added? |
Looks like I opened a dup: #209 |
change p.PacketsRecv to p.PacketsSent it work , but it impossible to collect the last package after using p.PacketsSent :(
The text was updated successfully, but these errors were encountered: