Subject: [Tsvwg] Re: question regarding the SCTP API - SCTP_INIT cmsg

From: "Daisy Chang" <[email-masked]>
Date: Thu, 24 Jan 2002 10:20:39 -0600

Oops, I mean "my case #2", not case #1. Sorry.

Regards,
Daisy

Daisy Chang
IBM Linux Technology Center
[email-masked]
Tel: (512)-838-4194    T/L: 678-4194
FAX: (512)-838-4663

---------------------- Forwarded by Daisy Chang/Austin/IBM on 01/24/2002
10:17 AM ---------------------------

Daisy Chang
01/24/2002 09:57 AM

To:    Randall Stewart <[email-masked]>
cc:    <[email-masked]>, <[email-masked]>
From:  Daisy Chang/Austin/IBM@IBMUS
Subject:    Re: question regarding the SCTP API - SCTP_INIT cmsg  (Document
       link: Daisy Chang)

Randy,
      Ah, connect()! I've got the impression a while back that a definition
for
"connect() - UDP style" is contemplated. Now that you mentioned it, I
somehow
couldn't find any reference to it in the API draft. Is this something that
we should
consider to add to our UDP-style support?
      I tend to agree that a 0-length send should not do much. I'm not sure
if a EINVAL is necessary though, given that TCP and UDP both seem to take
it without complaining - as far as I can tell on Linux. I could be wrong
though
because I haven't checked the library routines to see if there is any
specific
length verification there.
      Another thing is that, to me, SCTP_INIT seems to have slightly
different
functionality than a straight connect(). For a UDP-style socket, SCTP_INIT
could provide user with finer granularity of control of those init
parameters per
connection. While setsockopt(SCTP_INITMSG) and connect() can provide
the similar results, I'm wondering, rather than requiring SCTP_INIT with
data,
if we should allow my case #1 to work as "a connect() with init parms"?
What
is your insight?

Thanks,
Daisy

Daisy Chang
IBM Linux Technology Center
[email-masked]
Tel: (512)-838-4194    T/L: 678-4194
FAX: (512)-838-4663

Randall Stewart<[email-masked]>@cig.mot.com on 01/24/2002
04:16:34 AM

Please respond to Randall Stewart<[email-masked]>

Sent by:    [email-masked]

To:    Daisy Chang/Austin/IBM@IBMUS
cc:    <[email-masked]>, <[email-masked]>
Subject:    Re: question regarding the SCTP API - SCTP_INIT cmsg

Daisy:

Here is my interpretation/what we did:

1) Any 0 length send that has no msgflg's to process is an
   error and return EINVAL
2) A 0 length send that has msgflgs aka ABORT/TERM get the
   shutdown to happen.
3) To start an association with no data in the UDP model we
   use connect (much like UDP but without the binding
   effect to the peer endpoint ) :>

R

Daisy Chang wrote:
>
> Hi Randy,
>       A question came up when I was implementing the SCTP_INIT cmsg in
> sendmsg() API on Linux (the lksctp project), I hope that I can find a
quick
> answer here.
>       The question is, what is the behavior of a  sendmsg() call with a
> 0-length
> message, i.e., the total length of iov_len of the msg_iov in the struct
> msghdr is 0, or,
> both the msg_iov and msg_iovlen are 0. Now, if the msg_name is specified,
> and an
> existing association is identified with it, I believe that no data should
> be sent out; we
> will process the cmsg and msg_flags if they are specified, and we are
done.
> But, if
> there is no existing association is found for the msg_name, should we go
> ahead
> establishing one?
>       Considering the following cases, is there any differences among
these
> 3 API's in terms of the effects:
> 1. sendmsg() with msg_name and 0-length data, and NULL cmsg?
> 2. sendmsg() with msg_name and 0-length data, and a SCTP_INIT cmsg?
> 3. sendmsg() with msg_name and 0-length data, and a SCTP_SNDRCVINFO cmsg?
>       The <draft-ietf-tsvwg-sctpsocket-02.txt> doesn't seem to address
this
> very
> specifically. Would you consider to add something to the draft to ensure
> the
> consistencies among implementations?
>
> Thanks,
> Daisy
>
> Daisy Chang
> IBM Linux Technology Center
> [email-masked]
> Tel: (512)-838-4194    T/L: 678-4194
> FAX: (512)-838-4663

--
Randall R. Stewart
[email-masked] 815-342-5222 (cell phone)
|
                                     |
|
                                     |
---------------------- Mailing List commands
--------------------------------
Send the following in the body of a message to
[email-masked]
SUBSCRIBE TO LIST    : subscribe list-name   | LIST OF LISTS   : lists
UNSUBSCRIBE TO LIST  : unsubscribe list-name | RETRIEVE HELP   : help
WHO ON ON THE LIST   : who list-name         | GET DESCRIPTION : info
list-name
|
|
Or you can use http://majordomo.cig.mot.com
------------------------------------------------------------------------------

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

---

From: Randall Stewart <[email-masked]>
Date: Thu, 24 Jan 2002 11:19:16 -0600

Daisy:

Ok looking a bit further it appears that the BSD
stack under UDP will go ahead and send out
a packet with no user data... 

On the TCP side it does append the mbuf to
the TCB for output.. not sure how it
handles this down in the stack (I did not want
to dig down that far).

So the bottom line is when you do send a message with
0 length.. in UDP it may go out :>

So one may not want to accept this since the app may
expect a packet to be generated...

R

Daisy Chang wrote:
> |                                                                             |
> |                                                                             |
> ---------------------- Mailing List commands --------------------------------
> Send the following in the body of a message to [email-masked]
> WHO ON ON THE LIST   : who list-name         | GET DESCRIPTION : info list-name
> |                                                                             |

---

From: Lloyd Wood <[email-masked]>
Date: Thu, 24 Jan 2002 21:04:00 +0000 (GMT)

> a packet with no user data...

and we've got a spare length field... UDP acks?

L.

a UDP Lite for the 21st century.

<[email-masked]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>