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

From: Jonathan Wood <[email-masked]>
Date: Thu, 21 Jun 2001 12:54:00 -0700 (PDT)

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

Alternately we could do what UDP-style sockets do for this -
Include the MSG_ABORT flag in the sndrcvinfo ancillary
data flags structure (see section 5.2.2 in the sockets draft).

Brian, you have argued forcefully against changing the semantics
of shutdown() -- how would you feel about the addition of a
flag, vs. using a flag in sendmsg()?

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

---

From: Kacheong Poon <[email-masked]>
Date: Thu, 21 Jun 2001 13:29:57 -0700 (PDT)

> data flags structure (see section 5.2.2 in the sockets draft).

I think this is safer.  It is true that shutdown() has the socket
level semantics defined.  But I don't think it is safe to introduce
a SCTP level semantics to shutdown() as most people are familiar with
the shutdown() semantics of TCP and we cannot make it work in SCTP.

							K. Poon.
							[email-masked]

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 21 Jun 2001 15:33:37 -0500

Jonathan,

I don't want to change the API semantics (because it takes
XPG or POSIX to do that).

I frankly don't give a hoot if rsh can't be ported smoothly
to SCTP.  Aside from idle experiments, it doesn't really make
any sense to me to do so.  What I do believe is that shutdown()
can be used within the existing API to provide a mechanism
outside of close() for performing orderly shutdown of an
association without destroying the socket.  It is an apt and
suitable purpose and is used in this fashion for ISO sockets.

I would like to avoid using connectionless flags (particularly
"new" ones which are not defined in the current XPG/POSIX
specifications) on connection-oriented sockets for such a common
SCTP procedure.

IMHO. ;)

--brian

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

---

From: Kacheong Poon <[email-masked]>
Date: Thu, 21 Jun 2001 15:19:05 -0700 (PDT)

> XPG or POSIX to do that).

So there are 3 choices to do this:

1. Just have a socket level semantics for shutdown().  But it
does not do anything in the SCTP level.

2. In addition to 1, create a SCTP semantics for that.  The natural
one is for shutdown(SHUT_WR) to initiate the close down sequence,
SCTP will eventually send out the SHUTDOWN chunk.  But this is not
compatible with the TCP semantics, which should be noted in the draft.
This also precludes the use of any new flag in sendmsg() in the TCP
style socket to do similar thing.

3. In addition ot 1, use the same flag with sendmsg() as in UDP style 
socket to do the close down sequence.

Note that close() remain to have the same meaning in all choices.

I think Brian voted for 2 already.  What do other people think?  Or
is there other alternative?

							K. Poon.
							[email-masked]

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 21 Jun 2001 18:18:20 -0500

Kacheong,

Yah... I suppose I voted for 2, but I don't mind a flag
provided it can be added to the sockets interface standards.

--Brian