Network cable disconnect
Camilo Alejandro Arboleda
mislistas.correo at gmail.com
Fri Jun 22 16:23:13 UTC 2007
On 6/20/07, gregory.menke at gsfc.nasa.gov <gregory.menke at gsfc.nasa.gov >
> The IP stack is entirely free to accept your packets and discard them
> and not tell you in any particular timeframe.
Relying on an application layer handshake is not a good way to test
> specific physical connectivity because there is always the possibility
> of multiple interfaces and redundancy in the network which can obscure
> the state of a particular link.
> You'll have to be specific about what you want. If you want to ensure
> app-to-app connectivity (this is probably of most use), then the
> application layer handshake makes sense. "make the green thing light up
> when we're in contact" sort of idea.
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.
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.
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).
Algo mas sobre Camilo Alejandro?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the users