/**
* ShortPasta Foundation
* http://www.shortpasta.org
* Copyright 2009 and beyond, Sal Ingrilli at the ShortPasta Software Foundation
* <p/>
* This is free software; you can redistribute it and/or modify it
* under the terms of the GNU Lesser General Public License version 3
* as published by the Free Software Foundation as long as:
* 1. You credit the original author somewhere within your product or website
* 2. The credit is easily reachable and not burried deep
* 3. Your end-user can easily see it
* 4. You register your name (optional) and company/group/org name (required)
* at http://www.shortpasta.org
* 5. You do all of the above within 4 weeks of integrating this software
* 6. You contribute feedback, fixes, and requests for features
* <p/>
* If/when you derive a commercial gain from using this software
* please donate at http://www.shortpasta.org
* <p/>
* If prefer or require, contact the author specified above to:
* 1. Release you from the above requirements
* 2. Acquire a commercial license
* 3. Purchase a support contract
* 4. Request a different license
* 5. Anything else
* <p/>
* This software is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE, similarly
* to how this is described in the GNU Lesser General Public License.
* <p/>
* User: Sal Ingrilli
* Date: Jan 2, 2010
* Time: 11:36:08 AM
*/
###
### Project details
###
Compilers
Java code built with Sun Java 1.6.0_17-b04
Native code built with MS-VCPP 6
Apache Ant 1.7.1
Binaries
shortpasta-icmp.dll (68 KB)
shortpasta-icmp.jar (35 KB)
sping.exe (52 KB)
Example (simple):
import org.shortpasta.icmp.IcmpUtil;
import org.shortpasta.icmp.IcmpPingResponse;
final IcmpPingResponse icmpPingResponse = IcmpUtil.executeIcmpPingRequest (
ipAddress,
timeout);
Example (advanced):
import org.shortpasta.icmp.IcmpUtil;
import org.shortpasta.icmp.IcmpPingResponse;
final IcmpPingRequest icmpPingRequest = new IcmpPingRequest ();
icmpPingRequest.setIpAddress ("192.168.1.1); // always set the ip address to ping
// icmpPingRequest.setPacketSize (32); // set the packet size if you want a size other than 32
icmpPingRequest.setTimeout (1000); // always set a timeout, or your thread might wait forever!
// icmpPingRequest.setIdentifier (5000); // set identifier/sequenceNumber only if you don't want shortpasta-icmp to do it=
// icmpPingRequest.setSequenceNumber (1); // shortpasta-icmp sets these to the process id and an incremental number that starts with 1
// icmpPingRequest.setThrowExceptionOnTimeoutFlag (true); // set this if you want to receive a TimeoutIcmpException to signal a timeout
// icmpPingRequest.setUseDedicatedSocketFlag (true); // set this if you want this ping to be processed entirely on the native side and with a dedicated socket
final IcmpPingResponse icmpPingResponse = IcmpUtil.executeIcmpPingRequest (icmpPingRequest);
###
### Date: 2010-02-28 8:35:00
### Build: 1004
### Version: 1.0.4
###
- [FEATURE]
All native binaries are now released in "release" mode instead of "debug" mode.
- [FEATURE]
Add "sping.exe", which stands for shortpasta-icmp.exe.
This is a command line tool that executes the identical logic as the dll, but it is statically linked.
This tool works similarly to the Windows ping.exe.
This tool has no external DLL dependencies other than operating system DLLs.
Usage:
C:\sping>sping
Thanks for using sping, the win32 version of shortpasta-ping
ShortPasta Foundation, http://www.shortpasta.org
Copyright 2009 and beyond, Sal Ingrilli at the ShortPasta Software Foundation
Usage: sping [/debug] [/xml] [/h] [/?] [/n count] [/w timeout] target_name
C:\sping>
Execute normal ping, with a delay of 20 msecs, and execute only 10 times:
C:\sping>sping google.com /w 20 /n 10
Pinging 66.102.7.105 with 32 bytes of data:
Request timed out after 20 msecs
Reply from 66.102.7.105: bytes=32 time=16ms TTL=58
Reply from 66.102.7.105: bytes=32 time=18ms TTL=58
Request timed out after 20 msecs
Reply from 66.102.7.105: bytes=32 time=16ms TTL=58
Reply from 66.102.7.105: bytes=32 time=17ms TTL=58
Request timed out after 20 msecs
Reply from 66.102.7.105: bytes=32 time=16ms TTL=58
Reply from 66.102.7.105: bytes=32 time=16ms TTL=58
Request timed out after 20 msecs
C:\sping>
Execute normal ping, with a delay of 20 msecs, execute only 10 times, but output in xml:
C:\sping>sping google.com /xml /w 20 /n 10
Pinging 66.102.7.105 with 32 bytes of data:
<v>1</v><returnAddress>66.102.7.105</returnAddress><packetLength>32</packetLength><delay>16<delay><ttl>58</ttl>
<v>1</v><timedOutFlag>true</timedOutFlag><delay>20</delay>
<v>1</v><returnAddress>66.102.7.105</returnAddress><packetLength>32</packetLength><delay>16<delay><ttl>58</ttl>
<v>1</v><returnAddress>66.102.7.105</returnAddress><packetLength>32</packetLength><delay>16<delay><ttl>58</ttl>
<v>1</v><timedOutFlag>true</timedOutFlag><delay>20</delay>
<v>1</v><timedOutFlag>true</timedOutFlag><delay>20</delay>
<v>1</v><returnAddress>66.102.7.105</returnAddress><packetLength>32</packetLength><delay>17<delay><ttl>58</ttl>
<v>1</v><returnAddress>66.102.7.105</returnAddress><packetLength>32</packetLength><delay>17<delay><ttl>58</ttl>
<v>1</v><timedOutFlag>true</timedOutFlag><delay>20</delay>
<v>1</v><timedOutFlag>true</timedOutFlag><delay>20</delay>
C:\sping>
- [FEATURE]
Add native function Java_org_shortpasta_icmp_platform_windows_WindowsNativeUtil_executePing ()
which executes the full icmp echo request/response/timeout in a single native block.
This method creates its own socket.
This method matches the response by identifier/sequenceNumber.
Here are the results of this test case:
1. Command prompt running: ping google.com /t
2. Command prompt running: sping google.com /t
When sping does not match the response by identifier/sequenceNumber, it confuses the "ping.exe" response
packets with its own, and results in some delay values that are completely off:
Reply from 66.102.7.104: bytes=32 time=25 msecs TTL=58
Reply from 66.102.7.104: bytes=32 time=23 msecs TTL=58
Reply from 66.102.7.104: bytes=32 time=44 msecs TTL=58
Reply from 66.102.7.104: bytes=32 time=38 msecs TTL=58
Reply from 66.102.7.147: bytes=32 time=2593932180 msecs TTL=58
Reply from 66.102.7.104: bytes=32 time=1003 msecs TTL=58
Reply from 66.102.7.147: bytes=32 time=2593934187 msecs TTL=58
Reply from 66.102.7.104: bytes=32 time=2012 msecs TTL=58
Reply from 66.102.7.147: bytes=32 time=2593936195 msecs TTL=58
Reply from 66.102.7.104: bytes=32 time=3009 msecs TTL=58
Reply from 66.102.7.147: bytes=32 time=2593938196 msecs TTL=58
Control-C
When sping does match the response by identifier/sequenceNumber, everything looks as you would expect:
Pinging 66.102.7.104 with 32 bytes of data:
Reply from 66.102.7.104: bytes=32 time=22ms TTL=58
Reply from 66.102.7.104: bytes=32 time=22ms TTL=58
Reply from 66.102.7.104: bytes=32 time=22ms TTL=58
Reply from 66.102.7.104: bytes=32 time=25ms TTL=58
Reply from 66.102.7.104: bytes=32 time=30ms TTL=58
Reply from 66.102.7.104: bytes=32 time=24ms TTL=58
- [FEATURE]
Pimped out IcmpPingRequest to allow the user to:
1. Set the identifier/sequenceNumber pair
2. Specify throwExceptionOnTimeoutFlag on a request-basis
3. Specify to use a dedicated socket for the entire request/response/timeout workflow for this ping requet
Here are the IcmpPingRequest attributes
private String ipAddress;
private Integer packetSize;
private Long timeout;
private Integer identifier;
private Integer sequenceNumber;
private Boolean throwExceptionOnTimeoutFlag;
private Boolean useDedicatedSocketFlag;
- [DOCUMENTATION]
shortpasta-icmp is compiled with this version of Java:
C:\dev\shortpasta\trunk\icmp\build>java -version
java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04)
Java HotSpot(TM) Client VM (build 14.3-b01, mixed mode, sharing)
###
### Date: 2010-02-13 15:00:00
### Build: 1003
### Version: 1.0.3
###
- [BUG FIX]
Add synchronization around sequenceNumber generation.
The previous implementation, under heavy load and in an overflow situation, could cause the
sequenceNumber to be reset by multiple threads.
The symptom would be that some requests timeout because the response seems to be never received.
With this fix, you should never see NativeUtil logging this 2 times in a row:
"generateNextSequenceNumber (): sequenceNumber overflow detected: resetting icmpEchoRequestSequenceNumber"
- [FEATURE]
The native code now processes multiple echo responses at the same time, resulting in more throughpout
because less JNI is taking place.
This method:
WindowsNativeUtil.receiveIcmpEchoResponse (timeout)
Has been changed to:
WindowsNativeUtil.receiveIcmpEchoResponseList (timeout, maxPacketListSize)
The default maxPacketListSize is 1000.
- [FEATURE]
The native code now calculates delay.
This results in more accuracy because JNI is not in the picture.
When WindowsNativeUtil.sendIcmpEchoRequestPacket () sends a packet, it marks the timestamp with this:
echoReq.dwTime = ::GetTickCount ();
When WindowsNativeUtil.receiveIcmpEchoResponseList () receives a packet, it calculates the delay with this:
const DWORD dwDelay = GetTickCount () - echoReply.echoRequest.dwTime;
Note, however, that has a side-effect of this calculation, delay might come
This is presented to the user via this call:
IcmpPingResponse.getDelay ();
The time taken by the Java side to wrap all native calls, from send to receive, is available via this:
IcmpPingResponse.getInvocationDuration ();
- [FEATURE]
The native code now tries to use performance counters for delay calculations.
APIs used: QueryPerformanceFrequency () and QueryPerformanceCounter ()
Performance counters provide the most accurate timing in a Windows environment.
See http://msdn.microsoft.com/en-us/library/ms644900(VS.85).aspx#high_resolution
If there are any failures in trying to use performance counters, the library
automatically fallsback to using ::GetTickCount ().
Note, however, from http://msdn.microsoft.com/en-us/library/ms724408(VS.85).aspx:
"The resolution of the GetTickCount function is limited to the resolution of the system timer,
which is typically in the range of 10 milliseconds to 16 milliseconds."
When the library is initialized, it logs something like showing the details of the performance timer
and whether it is indeed using performance timers or not:
INFO : Java_org_shortpasta_icmp_platform_windows_WindowsNativeUtil_initialize ():
performanceTimerFrequency.QuadPart: 2668050000
performanceTicksPerMillisecond : 2668050
performanceTimerStartTime.QuadPart: 6498594659677264
usePerformanceCountersFlag : 1
You can use org.shortpasta.icmp.platform.windows.WindowsNativeUtil.get/setUsePerformanceCountersFlag ()
to manage this behavior.
Before this change, you might have seen some delay values of 0, when you expected something greater than 0.
For example, when pinging a LAN ip, I would get a delay of 0, just because the ECHO response came back
within the GetTickCount () resolution. With delay calculations based on performance counters, this
behavior has mostly gone away, and I have seen delays calculated as low as 1 millisecond.
- [FEATURE]
The library Logger now delegates a user-specified Logger implementation that can be specified via:
1. System Property "org.shortpasta.icmp.jle.logging.Log4JLogger"
2. IcmpUtil.setLoggerClass (final Class<? extends Logger> loggerClass)
If the user has not specified a Logger via these methods, the icmp library tries to log via log4j, by
attempting to set the logger to org.shortpasta.icmp.jle.logging.Log4JLogger.
If log4 is not on the classpath, this will fail, and the icmp library fallsback to logging via the default logger:
org.shortpasta.icmp.jle.logging.PrintStreamLogger
The user can dynamically change the Logger by calling this method at any time (example for Log4J provided):
IcmpUtil.setLoggerClass (org.shortpasta.icmp.jle.logging.Log4JLogger.class)
All logging is wrapped within "logger.isDebugEnabled ()" or similar blocks.
All logging can be categorized via log4j category blocks like this one:
<category name="org.shortpasta.icmp">
<priority value="info"/>
</category>
- [FEATURE]
If you are using an IcmpUtil method that gives you back a IcmpPingResponse, this will contain the time in
which the echo request was sent, and the time in which the response was received.
###
### Date: 2010-02-10 14:29:28
### Build: 1002
### Version: 1.0.2
###
- [BUG FIX]
Implement sequenceNumber rollover: when sequenceNumber reaches 65536,
it is reset so the sequenceNumber value is maintained within a 2-byte boundary. (Phase 2)
###
### Date: 2010-02-03 09:33:07
### Build: 1001
### Version: 1.0.1
###
- [FEATURE]
Asynchronous ICMP ping support
public static void executeIcmpPingRequest (
final IcmpPingRequest icmpPingRequest,
final IcmpEventHandler icmpEventHandler);
- [BUG FIX]
Implement proper request-response matching via managed identifier/sequenceNumber
The identifier/sequenceNumber fields are now set to the process id and a rolling integer
value that starts with 1. This can be seen in IcmpPingResponse itself because it will be
marked with the correct responseIpAddress.
- [BUG FIX]
Implement proper sequenceNumber rollover: when sequenceNumber reaches 65536,
it is reset so the sequenceNumber value is maintained within a 2-byte boundary. (Phase 1)
- [FEATURE]
ICMP socket optimization: only 1 socket is used for all requests
- [FEATURE]
Implement several unit tests
###
### Date: 2009-10-12 12:00:00
### Build: 1000
### Version: 1.0.0
###
- [FEATURE]
Initial Implementation
- [FEATURE]
Synchronous ICMP ping support
public static IcmpPingResponse executeIcmpPingRequest (
final String ipAddress,
final int packetSize,
final long timeout)
throws InterruptedException;
- [BUG]
Warning: this implements an improper request-response match via identifier/sequenceNumber
always set to 1/1. This means that if many threads are calling executeIcmpPingRequest ()
the echo response will most likely be mismatched. This can be seen in IcmpPingResponse
itself because it will be marked with the wrong responseIpAddress.
So this version is accurate only if you execute 1 ICMP ping at a time.
Download Latest Version
shortpasta-icmp-1006.zip (2.3 MB)
