<br><br><div><span class="gmail_quote">On 6/20/07, <b class="gmail_sendername"><a href="mailto:gregory.menke@gsfc.nasa.gov" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">gregory.menke@gsfc.nasa.gov

</a></b> <<a href="mailto:gregory.menke@gsfc.nasa.gov" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">gregory.menke@gsfc.nasa.gov

</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br><br>The IP stack is entirely free to accept your packets and discard them

<br>and not tell you in any particular timeframe.</blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Relying on an application layer handshake is not a good way to test

<br>specific physical connectivity because there is always the possibility<br>of multiple interfaces and redundancy in the network which can obscure

<br>the state of a particular link.<br><br>You'll have to be specific about what you want.  If you want to ensure<br>app-to-app connectivity (this is probably of most use), then the<br>application layer handshake makes sense.  "make the green thing light up

when we're in contact" sort of idea.</blockquote><div> You are right IP doesn't have to do so. But, isn't TCP protocol supposed to do that? If I send a TCP packet, but I don't get any answer (ACK packet) I would expect the write() call to return an error, or anything indacating that write() actually failed.

<br><br>I really don't expect it returning on any specific time frame, but I don't expect either a success status after calling "write()" when it did fail.<br> </div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

If you specifically want to test the link-state of an interface (which is not necessarily the same as compatible IP stack configurations), then you'll have to interrogate the PHY chip on the device.  To do that,

probably your best bet would be to modify the driver to pull out PHY state at suitable points and store it (or put it in a message queue). Greg </blockquote></div> <br clear="all"> --  Algo mas sobre Camilo Alejandro?

<br><a href="http://camiloaa.blogspot.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://camiloaa.blogspot.com</a>