"C. David Shaffer" <cdshaffer at acm.org> wrote:
> Yes, the sockets API gives me a clear cut way to determine if a 
> connection was closed on the other end.  

I am sure it does but I don't know that it is simple.  read() can also
return 0 if there is simply no more data available and you have the
socket in non-blocking mode.  I think one way is to do select() on the
socket and see that it is read-able, *and* for read() to return 0 bytes.
 That might be a sufficient indication.

This does not indicate,  however, whether the other side is going to
allow you to write data back to it.  I don't know if you can do this
check at all.


>Squeak's interface to it, 
> unfortunately does not.  How can I tell if the "primitive failed" b/c 
> the other end was closed or if it had some kind of internal failure? 

This is a severe failure, by the way.  The other side has rejected data
that you sent to it.  It has closed the connection without waiting to
receive what you sent to it.  It happens to be detected during #flush in
this case, but it is still a big problem.


> That is the case generally but the problem I'm having is that 
> SocketStream>>close sends flush so it is the "user" of the Socket.   The 
> close should succeed even if the data can't be flushed (in my opinion) 
> since it leaves you in a sticky mess if you can't close the socket.  I 
> guess that you could expect the caller to protect the close:
> 

Another difference you should be aware of is #close versus #destroy. 
#destroy means "kill the socket, dump the data on the floor, and clean
up".  You can always successfully call #destroy.  #close means "i am
sending no more data".  If you have run into a fatal error such as the
other end killing the connection, then you should probably just #destroy
the socket and not mess with it any more.



-Lex