Skip Menu |

This queue is for tickets about the AnyEvent-Ping-TCP CPAN distribution.

Report information
The Basics
Id: 123574
Status: new
Priority: 0/
Queue: AnyEvent-Ping-TCP

Owner: Nobody in particular
Requestors: kl [...]

Bug Information
Severity: Wishlist
Broken in: (no value)
Fixed in: (no value)

Subject: Exposing counter - to track packagedrop?
MIME-Version: 1.0
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: Web
Message-ID: <rt-4.0.18-23307-1510228709-1331.0-0-0 [...]>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 483
Download (untitled) / with headers
text/plain 483b
I was wondering if you could expose the counter.. that tcp_ping_syn maintains.. So f.ex. if I run tcp_ping_syn 100 times against a specific host:port combination.. I would like to get a count of how many ack's was returned (a number less than 100 - would mean a package was dropped)? The best way would probably be to have a seperate function tcp_ping_droprate - where you can get the count of sent and received syn/ack's and percent missed? That wouldn't break existing usage.
MIME-Version: 1.0
In-Reply-To: <rt-4.0.18-23307-1510228709-1331.0-0-0 [...]>
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: API
References: <rt-4.0.18-23307-1510228709-1331.0-0-0 [...]>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.18-1934-1510312284-1193.0-0-0 [...]>
Message-ID: <rt-4.0.18-1934-1510312284-1151.123574-0-0 [...]>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
From: kl [...]
Content-Length: 462
Download (untitled) / with headers
text/plain 462b
Currently I do packagedrop calculations - by sending one ping.. for each endpoint to test.. and then run the corresponding ack (which means I'll wait for $timeout) - and count if I got $latency (otherwise that means the package never got an ack).. that works for calculating packagedrops.. and I have found some targets (when I send 100 tcp_syn's - having a few percentage package drops).. but it also means the test takes 100x$timeout when the port is closed :(

This service is sponsored and maintained by Best Practical Solutions and runs on infrastructure.

Please report any issues with to