Subject: RE: [Tsvwg] SCTP Sockets Mapping - Closure of TCP-style SCTP sock ets

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Thu, 21 Jun 2018 02:41:16 -0700

Jonathan, 

shutdown() does not just provide protocol behavior it also provides
application layer behavior. I think we agree that few applications use
shutdown() to establish a steady-state half-closed TCP connection (and
therefore we are not trying to preserve this type of functionality), rather
most people use it to help in a graceful shutdown by receiving notifications
that all data has been sent/received and blocking further send/recv calls.

Robert.

-----Original Message-----
From:	Jonathan Wood [mailto:[email-masked]]
Sent:	Wednesday, June 20, 2001 10:33 PM
To:	[email-masked]
Subject:	Re: [Tsvwg] SCTP Sockets Mapping - Closure of TCP-style SCTP
sockets

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

---

From: Jon Berger <[email-masked]>
Date: Thu, 21 Jun 2001 16:37:32 +0100

Absolutely.
 
There are three separate issues here.
 
1) Should SCTP have a half close state?
This is more of a religious than technical point.  I personally think the
answer is no because this hasn't proved to be all that useful in the real
world.
 
2) How does the sockets API for SCTP support receipt of data in a graceful
shutdown scenario.
This is a technical issue with the currently defined API.
Support of the shutdown() primitive would help here as a way of decoupling
association shutdown from socket shutdown.
 
3) How does the sockets API for SCTP support retrieval of unsent/unacked
data in a non-graceful shutdown scenario.
This is another technical issue with the currently defined API.
Again the problem here is that the association and socket shutdown need to
be decoupled.  Support of the shutdown() primitive with another flag
indicating hard closure would also fulfill this requirement.
 
In both cases, applications that don't care about this distinction can just
use close() as currently specified.

Jon 

-----Original Message-----
From: Fairlie-Cuninghame, Robert [mailto:[email-masked]]
Sent: 21 June 2018 10:41
To: 'Jonathan Wood'; [email-masked]
Subject: RE: [Tsvwg] SCTP Sockets Mapping - Closure of TCP-style SCTP sock
ets

Jonathan, 

Robert. 

BM__MailData-----Original Message----- 
From:   Jonathan Wood [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent:   Wednesday, June 20, 2001 10:33 PM 
To:     [email-masked] 
Subject:        Re: [Tsvwg] SCTP Sockets Mapping - Closure of TCP-style SCTP
sockets 

Jonathan 

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