Sal Ingrilli

Nothing really "wrong", and in the end icmp4j is able to initialize. Icmp4j by default tries to use the JNI implementation, followed by the JNA implementation. Here is what seems to be happening: 1. icmp4j looks for its native library the path identified by java.library.path 2. It does not find it there, so it logs the warning: loadLibraryNoException (). Native.loadLibrary () failed 3. Then, it looks for it via java resources, meaning on the classpath and inside jars 4. It finds it there, and tells...

Assuming you are using the default icmp4j logger, call something like this: import org.icmp4j.logger.PrintStreamLogger; PrintStreamLogger.setLogLevel(PrintStreamLogger.ERROR); You can also completely override the logger with this: import org.icmp4j.logger.Logger; Logger.setLoggerClass(<your class that implements Logger>) This way you could implement an slf4j version, or a log4j version, for example, and route through your own logging system...

yixing1337 - the full native implementation of this is very time consuming and we don't have enough cycles to deal with this now. So we ticketed this internally, and expect to include this with the next set of native changes. If anybody else cares about this, please speak up. Meanwhile, I think that the rttNanos experimental change we pushed with the link above should be a decent starting point. Yes it does include the JNI overhead, but if you are running this on a decently fast machine, the overhead...

If the os does it and uses the right timing function like GetTickCount() and much better, media timers, then it is extremely accurate. I have done enough with this and VOIP apps that need accurate timing that I am confident we can handle ICMP. At the same time, other considerations are how much crap the OS is doing that it shouldn't, OS firewall, AV firewalls, anti-malware interceptions, packet capturing, and fluctuations in the Quartz. But there is nothing we can do about lots of these. Bottom line,...

By interface I mean the "rttNanos", not the accuracy of the field. Plus we need to think about everybody, not just an individual's use-case. Also, let's be fair to the amount of time added by measuring this on the Java side vs the native side: it varies between operating systems and includes a lot of other "stuff" happening in the middle. In Windows, for example, you should expect a JRE - native switch, then a process-to-OS context switch for privilege escalation, which may be queued on top of it,...

So the interface is OK then? We'll work on the native implementation. I'll see when Laurent is available to help with this and give you an ETA.

Try this: https://we.tl/t-Lwhwe0rNNx And call this to get the rtt in nanoseconds: final long rttNanos = response.getRttNanos (); rttNanos is an experimental feature and currently includes the bridge timing overhead. LMK how it works out for you, and we'll work on pushing the time calc to the native side.

Got it. On the native side, the timing is a standard timeval struct with tv_secs + tv_usecs. So while converting the data type to a float/double would somewhat solve the problem, it would break the response interface, so it's a no-go. I would expose time as a long value representing either millis, micros, or nanos. Millis doesn't work because on LANs we can get < 1 msec response. Micros feels like a better match, But this being a Java interface, I would choose millis or nanos in order to be compatible...