Subject: [Fwd: Re: [[email-masked]: [Tsvwg] SCTP Sockets API Question]]

From: Jon Grimm <[email-masked]>
Date: Thu, 31 Oct 2002 08:40:35 -0600

Forgot to cc the mailing list too.

Hi again,

Chuck Winters wrote:
 >Jon Grimm wrote:
 >>....if you are porting a UDP application, you wouldn't do an 'accept()',
 >>and if you aren't, you have other alternatives - such as peeloff and
 >>events which are more powerful/flexible.  If you really _do_ want
 >>'accept()' maybe TCP-style is better suited for your application??
 >
 > I'm not really looking for UDP transparency, I'm looking more at a 
connected
 > datagram type of service for new applications.
 >

Ah...   Well, why not just use the TCP-style model (1-1)?   Since SCTP
is message based, both API styles preserve this concept (especially if
you stick to sendmsg/recvmsg).

Best Regards,
Jon Grimm

---

From: Chuck Winters <[email-masked]>
Date: Thu, 31 Oct 2002 11:29:33 -0500

Jon,

> you stick to sendmsg/recvmsg).
I was under the impression that if you used the TCP-style model, when you
read from the socket, you would get as many bytes as you asked for(excluding
EPIPE, etc), and not just the next chunk.  So, for instance if SCTP received
2 chunks of 100 bytes each, and you tried reading 120 bytes from the socket,
you would get 100 bytes of the first chunk, and 20 bytes from the next chunk.
Is that not how the stream api works?

> Jon Grimm

Chuck
-- 
Chuck Winters                            | Email:  [email-masked]
Distributed Processing Laboratory        | Phone:  856-338-3987
Lockheed Martin Advanced Technology Labs |
1 Federal St - A&E-3W                    |
Camden, NJ 08102                         |

---

From: Jon Grimm <[email-masked]>
Date: Thu, 31 Oct 2002 11:03:57 -0600

Hi again,

> Is that not how the stream api works?

Certainly an application must allow for thie behavior with read/recv
(though I hope apps are also written to account for short reads 'cause
it happens). However, I don't see strong requirements on this from the
implementor's standpoint, where I may choose to send up message length
reads - the application should never count on this though.  

The recvmsg wording in the I-D currently only says there are two
differences in the behavior of sendmsg/recvmsg between TCP style and UDP
style.  MSG_EOR is not one of those differences, so my current read on
the I-D says that the message boundaries behavior is preserved.  This is
why I tacked on the sendmsg/recvmsg words to my response above.   IMO,
you need to use sendmsg/recvmsg in either bottle to take advantage of
the SCTP features anyway.  

I'm pretty sure I'll get thumped down if I'm reading this all wrong.. so
its good you ask this so I can get this all straight in my head.  ;-)

Best Regards,
Jon

---

From: Chuck Winters <[email-masked]>
Date: Thu, 31 Oct 2002 13:55:59 -0500

It's me again,

> reads - the application should never count on this though.  
"Should" and "Do" are two totally different things :)
> the SCTP features anyway.  
Correct me if I'm wrong, bug if message boundaries are preserved, the semantics 
should be that a read on the socket should return one message, or part of a 
message(if the buffer it is being read into is too small).  If the message is 
smaller than the buffer, still only 1 message is read into the buffer.  Now,
if message boundaries are preserved, and the previously stated semantics are 
correct, then why is SOCK_STREAM used as a service type?  Wouldn't SOCK_DGRAM
be a better fit?

Chuck

---

From: Jon Grimm <[email-masked]>
Date: Thu, 31 Oct 2002 13:50:43 -0600

> "Should" and "Do" are two totally different things :)

Yep, I tried to word that all _very_ carefully.  

> correct, then why is SOCK_STREAM used as a service type?  
> Wouldn't SOCK_DGRAM be a better fit?
>

Well its a little hard to call it a bug if its not specified. 

I just call'em like I read'em.   The recvmsg behavior needs to be there
for applications that want to bite off a little bit of SCTP knowledge. 
I prefer not to have differing behaviors for read vs recvmsg.   Due to
layering, it may even be quite difficult to force two different
behaviors at the read vs recvmsg interface.  In the linux case,
read/recv/recvfrom all wrapper recvmsg before entry into the transport
specific layer.   

Its a little weird to put SCTP under SOCK_STREAM anyway.  IMO, 1-1
should have been SOCK_SEQPACKET and 1-many something new entirely..
SOCK_SCTP.   I'm guessing the original thoughts on the I-D were a
tradeoff in application porting vs semantics vs getting at all the kewl
bits in SCTP.

For impementation reasons I need it to be specified either as:
a) TCP-style recvmsg MUST preserve message boundaries read/recv MAY
preserve boundaries.
b) TCP-style read/recv MUST preserve stream semantics, recvmsg MAY
preserve message semantics

The current I-D allows (a) (though possibly by oversight), but I could
tolerate (b) too  
The third option, which require differing behaviors, will not always be
possible, so... the app will need to be ready for this situation
anyway.   

Best Regards,
Jon

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Thu, 31 Oct 2002 15:03:05 -0600

Jon:

Some answers to both of you:

1) First and formost.. YOU MUST preserve message boundaries no matter
    which you open UDP or TCP style

2) There will  be no MUST/MUST NOT wording in the current ID.. there 
cannot be since it
    will in the end be an informational RFC.

3) What ties the MUST into number 1 is RFC2960.. since it emphasis 
message boundary
     preservation...

So basically you should either get a FULL message or a part of a 
message.. but NEVER
the end of one message and the beginning of the other... otherwise you 
end up with NO
message boundaries and break the SCTP symantics.

Now as to why we made the choices we did.. I think your (Jon's) guesses 
are about
right on.. and we wanted to avoid defining new types i.e. SOCK_SCTP etc..

R

-- 
Randall R. Stewart
ITD
Cisco Systems Inc.
[email-masked] 815-342-5222(cell) or 815-477-2127(office)