Network cable disconnect

[Eric Norum]

On Jun 22, 2007, at 11:23 AM, Camilo Alejandro Arboleda wrote:

>
>
> On 6/20/07, gregory.menke at gsfc.nasa.gov  
> <gregory.menke at gsfc.nasa.gov > wrote:
>
> 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.

TCP uses a sliding acknowledgement window so as far as the write()  
call is concerned the data have been sent.  The write did *not*  
fail.  The packets are just waiting somewhere hoping to get through  
to the far end at some point in the future.
If your application really needs to worry about things like this you  
need to use some other protocol -- perhaps even UDP and handling all  
the acknowledgements, timeouts, retransmission your self.

-- 
Eric Norum <norume at aps.anl.gov>
Advanced Photon Source
Argonne National Laboratory
(630) 252-4793