Socket Disconnection

[Richard Barrett]

At 00:54 24/06/2002 -0700, Andrae Muys wrote:
>"Colin Brown" <cbrown at metservice.com> wrote in message 
>news:<3d16817e$1 at news.nz.asiaonline.net>...
> > Hi Guyon
> >
> > I assume here that you are talking TCP/IP.
> >
> > If you are waiting on a receive [ data = connection.recv() ] then you will
> > have an empty data string returned when the client disconnects.
> >
> > If you are sending you will get an error telling you the link was shut 
> down.
> >
>
>Also note that the only reliable way to detect a client disconnect is
>the latter.  If you want to demonstrate the failure of the recv()
>approach, just yank out the ethernet cable on the client machine, and
>notice that although the client is now disconnected, the server has no
>idea.

That's because making a physical disconnect doesn't immediately cause a 
disconnection of connection oriented services over the medium. Which is 
probably what one wants to happen.

If you reinsert the ethernet cable then you will often find TCP/IP 
connections being carried over it that haven't attempted to pass traffic 
and failed, and disconnected for that reason, during the period that cable 
was out, are still active. A good demonstration of the robust nature of the 
TCP/IP protocols.

Disconnection in a TCP/IP sense is an exchange of segments that fits the 
protocol specification. TCP/IP supports asynchronous, full duplex 
communication and the forward and backward 'channels' each have to be 
terminated individually. TCP/IP itself is a symmetrical protocol i.e. it 
provides a peer-peer communication, not an inherently client-server 
communication. The client/serverness derives from whatever protocol is 
layered on top of TCP/IP, e.g. HTTP.

Simply because one of the two peers closes their outbound 'channel' doesn't 
mean, in a TCP/IP sense, that their inbound 'channel' will not/cannot 
deliver more data.

In the majority of cases, protocols layered on top of TCP/IP tend to be 
synchronous and often inherently create a client/sever relationship between 
the two TCP/IP  peers. It is common practice for higher level protocols, 
when receiving EOF (indicated, for instance, by receipt of an empty string 
from a recv call on a Python socket object), for the recipient to 
immediately respond by closing their outbound connection; this leading to 
termination of the underlying TCP/IP connection. But it doesn't have to be 
so. The recipient can. as far as TCP/IP is concerned, continue to transmit 
data until it chooses to stop.

If you are going to create your own higher level protocol layered on top of 
TCP/IP (rather than using an existing one such as HTTP) then part of the 
protocol design and specification is to decide on such issues. People often 
forget these issues when rolling their own higher level protocols, and can 
then experience considerable difficulty sorting out the problems that arise.

>Might I suggest taking a look at TCP/IP Illustrated Vol 1, by
>W.Richard Stevens.  Definately a book to read if you are doing any
>TCP/IP network programming.
>
>Andrae Muys
>--
>http://mail.python.org/mailman/listinfo/python-list