title: Usage of IcmpSendEcho2 with an asynchronous callback
body: <p>I've been reading the <a href="http://msdn.microsoft.com/en-us/library/aa366051.aspx" rel="nofollow">MSDN documentation for IcmpSendEcho2</a> and it raises more questions than it answers.</p>
  
  <p>I'm familiar with asynchronous callbacks from other Win32 APIs such as <code>ReadFileEx</code>... I provide a buffer which I guarantee will be reserved for the driver's use until the operation completes with any result other than <code>IO_PENDING</code>, I get my callback in case of either success or failure (and call <code>GetCompletionStatus</code> to find out which).  Timeouts are my responsibility and I can call <code>CancelIo</code> to abort processing, but the buffer is still reserved until the driver cancels the operation and calls my completion routine with a status of <code>CANCELLED</code>.  And there's an <code>OVERLAPPED</code> structure which uniquely identifies the request through all of this.</p>
  
  <p><code>IcmpSendEcho2</code> doesn't use an <code>OVERLAPPED</code> context structure for asynchronous requests.  And the documentation is <strike>unclear</strike> <em>excessively minimalist</em> about what happens if the ping times out or fails (failure would be lack of a network connection, a missing ARP entry for local peers, ICMP destination unreachable response from an intervening router for remote peers, etc).</p>
  
  <p>Does anyone know whether the callback occurs on timeout and/or failure?  And especially, if no response comes, can I reuse the buffer for another call to <code>IcmpSendEcho2</code> or is it forever reserved in case a reply comes in late?</p>
  
  <p>I'm wanting to use this function from a Win32 service, which means I have to get the error-handling cases right and I can't just leak buffers (or if the API does leak buffers, I have to use a helper process so I have a way to abandon requests).</p>
  
  <p>There's also an ugly incompatibility in the way the callback is made.  It looks like the first parameter is consistent between the two signatures, so I should be able to use the newer <code>PIO_APC_ROUTINE</code> as long as I only use the second parameter if an OS version check returns Vista or newer?  Although MSDN says "don't do a Windows version check", it seems like I need to, because the set of versions with the new argument aren't the same as the set of versions where the function exists in iphlpapi.dll.</p>
  
  <p>Pointers to additional documentation or working code which uses this function and an APC would be much appreciated.</p>
  
  <p>Please also let me know if this is completely the wrong approach -- i.e. if either using raw sockets or some combination of <code>IcmpCreateFile</code>+<code>WriteFileEx</code>+<code>ReadFileEx</code> would be more robust.</p>