Lex Spoon wrote:
> 
> Rob Withers <slosher2 at home.com> wrote:
> > > Thanks for posting this; it's one configuration that works.  Rob Wither's stuff
> > > is more compatible with newer Squeak's, however.  Although, to make
> >
> > I see I had problems with old-style Listen for older images.  We also
> > fixed a few close situations:  I am now using shutdown(SHUT_RDWR), and
> > you can no longer write in OtherEndClosed state.  Does the attached work
> > better?
> >
> 
> Great idea, but let's be careful.  In ThisEndClosed, you should be able
> to read but not write.  In OtherEndClosed, you should be able to write
> but not read.  Right?

[OtherEndClosed]
Right?  Sure, according to the TCP protocol.  Unfortunately I left
Stevens at work, so I don't have all the info at hand.  It is true if
the other end closed the write channel only.  If he closes the read also
(by shutdown(SHUT_RDWR) or close()) and we attempt a write on our end,
then I think we get a SIGPIPE.  I have a handler for this which will
result in an EPIPE error being returned from the write operation.  This
week, I disabled writing in OtherEndClosed in reaction to a flow test. 
It is not possible to read from the os in this state.  I think it
returns an error, but I disallow it anyway.

[ThisEndClosed]
This is still readable, if we go the route of closing the write channel
only, otherwise, it may still be readable if we close without Linger
(although I'm not sure of the timing).  If we shutdown read and write,
it may or may not be readable - I'll peruse Stevens (waiting for a FIN
from the otherSideClosing).

[select fd sets]
NOTE: this also has implications for setting up the FD_SETS for each
descriptor  (based on the underlying socket states):
WaitingForConnection  (rd: 1, wr: 1)
Listen                (rd: 1, wr: 0)
Established           (rd if room in buffer: 1, wr: 1)
OtherEndClosed        (rd: 0, wr: 1 (I was but I stopped))
ThisEndClosed         (rd: 1, wr: 0)
Closed                (err..you had better not do this or risk getting a
bad descriptor error from select)

> Also, #close should only shutdown for *writing*, not for reading.
> #close declares that you aren't sending any more data, but you can still
> read if you want.  Still, I guess shutdown() is better than close() --
> Unix's close() is as potent as Squeak's #destroy, but hopefully
> shutdown() is more forgiving.

I did have it this way, originally, but one of the Flow tests didn't
like it so I changed it to closing both the read and write channels.  As
John mentions, most code checks isConnected.

Squeak State
Unconnected            read data: no   write data: no
WaitingForConnection   read data: no   write data: no
Established            read data: yes   write data: yes
ThisEndClosed          read data: yes   write data: no
OtherEndClosed         read data: no   write data: yes ???

If we have agreement on this, and decide what close means (shutdown
write only?), and determine that a read or write primitive fails
(exception signalled), when attempted in the wrong state, then we will
have just about licked this thing.

> At least, this is all the way I currently understand it.  I actually
> submitted a patch to make Linux's close() weaker (ie, more similar to
> closing a file), but the Linux TCP/IP guys argued that I was
> *introducing* a bug, not removing one.  The RFC's seem to back up those
> guys up, if you interpret close() as ABORT.
> 
> Thanks for sending that updated source file!  I guess I'll wait and see what you
> think about these other small issues, though, before I try playing with
> it myself.

Hehe    it is in some flux of course.  Other than the non-forking accept
behavior, all of the changes over the last 3 weeks have been related to
these close semantics.  

Rob
 
> -Lex

-- 
--------------------------------------------------
Smalltalking by choice.  Isn't it nice to have one!