<br><br><div class="gmail_quote">On Tue, Mar 16, 2010 at 10:52 AM, Kartik Thakore <span dir="ltr"><<a href="mailto:thakore.kartik@gmail.com">thakore.kartik@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div bgcolor="#FFFFFF"><div>Or you can process the output of ping:</div><div><br></div><div><a href="http://inetdaemon.com/tutorials/troubleshooting/tools/ping/index.html" target="_blank">http://inetdaemon.com/tutorials/troubleshooting/tools/ping/index.html</a></div>
</div></blockquote><div><br>The problem with this approach is that it too is independent of the actual<br>transactions that may exhibit the problem.<br><br>Ie. If you ping the device first, that doesn't mean that you won't get<br>
an 'unreachable' moments later during the numerous subsequent<br>transactions. And to perform a ping right in front of each of those<br>transactions is mega-overkill. And then finally, why do an extra ping to <br>
tickle a response, when the actual transaction will generate the response itself!<br>(Its just a matter of being able to retrieve/extract it from the system.<br><br>Its just that doing with the ping approach proabably means that you have<br>
an 'raw' level path open, and you are doing the ICMP protocol (send)<br>stuff all yourself, and that enables you to do the ICMP receive too.<br><br>What I really need is a way that the application still does its high<br>
level stuff, but also 'register a listener' for potential ICMP (low) level<br>messages.<br><br><br><br></div></div><br>