Try connecting to a port on a terminal server running at say
9600 baud, send a file, and then close.  If the socket is
aborted, the terminal server obligingly tosses all of the data
in its buffer that hasn't drained out the slow port.

Sounds a little unusual, but most of the terminal server ports
sold today are connected to consoles on server and old legacy
devices without network connections.  There are lots of network
management systems that script through these things.

The last I checked HP/UX still had a problem with aborting
connections that you carefully shutdown().

-david

> -----Original Message-----
> From: John M McIntosh [mailto:johnmci at smalltalkconsulting.com]
> Sent: Wednesday, July 05, 2000 6:25 PM
> To: squeak at cs.uiuc.edu
> Subject: Re: [ENH] Socket Test Suite.
> 
> 
> on 7/5/00 12:00 PM, Lex Spoon at lex at cc.gatech.edu wrote:
> 
> > John M McIntosh <johnmci at smalltalkconsulting.com> wrote:
> >> I have run some tests on Linux, there are some interesting 
> behavior issues
> >> between that implementation and the macintosh 
> implementation, on socket
> >> close for example and difference of opinion on address 
> information for UDP
> >> sockets after setpeer:  My intent in building this suite 
> is to clear up
> >> differences of opinion between platform implementations of 
> the Socket
> >> support code.
> > 
> > 
> > The socket-closing code on Unix is wrong.  The "close" 
> command invokes
> > Unix's close(2), which is incorrect.  Squeak's close 
> command actually
> > mean shutdown for sending, while close(2) is more like Squeak's
> > "destroy".  Squeak's "close" should really invoke Unix's 
> shutdown() with
> > an appropriate argument.
> > 
> > I've fixed this once or twice, but I never got anyone to 
> use it because
> > I never successfully verified a misbehavior from it, and 
> nobody wants to
> > introduce bugs just to do something the Right Way.  In theory, the
> > problem is that some data you have sent might not be successfully
> > received, because you've aborted the connection.
> > 
> > Anyway, the fix is simple, though error prone: modify the 
> SocketClose
> > implementation to call shutdown() instead of close(), add a 
> new state
> > for "thisEndClosed" to the Unix implementation, and then 
> patch up all
> > the other socket routines to be able to handle this new state.  (For
> > example, reading should be allowed when a socket is in state
> > thisEndClosed....)
> > 
> > 
> > -Lex
> > 
> 
> Well we  need someone to mess with Unix version and make it official.
>  Takers? Goodness knows about the windows version.
> 
> Don't be shy, I'd do it (maybe) but I'm kinda busy right at 
> the moment.
> 
> Also Craig and I have be chatting back and forth on this 
> whole close issue,
> since on the macintosh we do this shutdown or half socket 
> close then go into
> waitForDisconnect: waiting for the socket to close, then 
> after the timeout
> we do the actual close if required to disconnect the socket, 
> if in fact the
> otherside hasn't issued a shutdown(2) or close(2).
> 
> I did see a problem if you happen to do socket to socket on 
> the same machine
> within the same image with a higher priority server. The 
> higher priority
> server using the close(2) tends to flush and disconnect the 
> client before
> the client can get around to reading the data. This of course 
> is a unique
> issue, but if you happen to write a client/server application 
> and do testing
> within one image, well you might encounter it. This however 
> is NOT a problem
> with the Socket code on the macintosh, perhaps on Linux or windows?
> 
> PS Does this mean someone has run the Socket test suite?
> 
> --
> ==============================================================
> =============
> John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
> Corporate Smalltalk Consulting Ltd.  
> http://www.smalltalkconsulting.com
> ==============================================================
> =============
> Custom Macintosh programming & various Smalltalk dialects
> PGP Key: DSS/Diff/46FC3BE6
> Fingerprint=B22F 7D67 92B7 5D52 72D7  E94A EE69 2D21 46FC 3BE6
> ==============================================================
> =============
>