Subject: Re: [Tsvwg] SCTP Sockets Mapping - Closure of TCP-style SCTP sockets

From: Jonathan Wood <[email-masked]>
Date: Wed, 20 Jun 2001 14:32:56 -0700 (PDT)

>
>> It is not the case that TCP apps expect to be able to do
>> send() after recv() returns 0.  recv() retruns 0 when the
>> connection is disconnected, and a TCP app cannot expect
>> to send() and recv() returns 0 in that case.  A TCP app
>> will get EPIPE/SIG_PIPE.  It is not different from the
>> possible SCTP case.
>
>In the context of what we are discussion (use of shutdown(SHUT_WR)
>to do TCP half-close), the app indeed expects to send after recv()
>returns 0.  You can check the code of, say, rsh.  Note that with
>TCP, recv() returning 0 does not necessarily mean that the socket 
>is disconnected.
>
Yes, Kacheong is correct.

With the current protocol rules, I don't believe that
it is possible to get full TCP-compatibility for shutdown().
While it would be nice to have full compatibility, it would
be hard to justify changing SCTP for so little gain -
shutdown() really is seldom used functionality in TCP
sockets. (Of course, if someone could demonstrate how
half-close would be really useful, I might be swayed...)

It is also important to note that we could fairly easily
recode rsh for SCTP and get the same functionality
using streams.

I agree with Mark Bartlett that shutdown() is useful for
retrieving any remaining data and notifications. The
SCTP semantics would be exactly as defined in XPG.

The only difference is on the shutdown receiver side:
After getting an EOF on a socket, all subsequent attempts
to send will always fail with EPIPE.

Jonathan

_______________________________________________
tsvwg mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/tsvwg