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
===========================================================================