Subject: recv() clarification in SCTP sockets API draft

From: "David Lehmann" <[email-masked]>
Date: Thu, 29 Jul 2010 11:47:51 -0400

Hello,

Section 6.1 of http://tools.ietf.org/html/draft-ietf-tsvwg-sctpsocket-23
states:

"SCTP is message based.  The msg buffer above in send() and sendto() is
considered to be a single message."

But then goes on to say:

"recv() and recvfrom() cannot distinguish message boundaries."  

So a user on one end using send() sends two messages and the peer doing
_one_ recv() can pick up both messages?  I would think that the recv()
would pick up a single message in a similar manner that send() sends one
message.

Yet the following statement in the draft states...

"In receiving, if the buffer supplied is not large enough to hold a
complete message, the receive call acts like a stream socket and returns
as much data as will fit in the buffer."

... which implies that recv() will stop reading after it reads the
"complete message" as long as the buffer is big enough, which means
recv() can distinguish message boundaries.

What is the correct interpretation?  Thanks.

-David

---

From: Vlad Yasevich <[email-masked]>
Date: Thu, 29 Jul 2010 15:07:22 -0400

On 07/29/2010 11:47 AM, David Lehmann wrote:
> “SCTP is message based.  The msg buffer above in send() and sendto() is
> considered to be a single message.”
> 
>  
> 
> But then goes on to say:
> 
> “recv() and recvfrom() cannot distinguish message boundaries.” 
> 
>  
> 

Yes, but a recv() can also pick up only a part of the first message if partial
delivery is involved.  The trouble with recv() is that it doesn't tell you anything
about message boundries and that's what the spec attempts to say.

>  
> 
> Yet the following statement in the draft states…
> 
>  
> 
> “In receiving, if the buffer supplied is not large enough to hold a
> as much data as will fit in the buffer.”
> 
>  
> 
> … which implies that recv() will stop reading after it reads the
> “complete message” as long as the buffer is big enough, which means

The interpretation is the recv() call doesn't provide you any information regarding
message boundaries.  In an ideal scenario, it works just fine.  However, if only a
partial buffer is returned, due to insufficient user buffer or partial delivery state in
the kernel, then there is no way to tell the message boundaries,  especially if
message sizes change.

-vlad

---

From: Randy Stewart <[email-masked]>
Date: Fri, 30 Jul 2010 13:03:55 -0400

Exactly Vlad:

David... consider a user sending a 8k message.

sendmsg(..., msg, len=8k);

Now on the receive side you do

recv (... , len=1k);

In UDP the rest of the 7k is truncated and discarded...but SCTP is a  
reliable
protocol.. it can't do that..

So you should not use recv() imo unless of course you know your  
message sizes you
are receiving.. but even then I would prefer to use something where I  
can get the
flags and do a check to see if the MSG_EOR is set..

R

> the kernel, then there is no way to tell the message boundaries,   

-----
Randall Stewart
[email-masked]

---

From: Chris Benson <[email-masked]>
Date: Fri, 30 Jul 2010 11:06:16 -0700 (PDT)

Vlad,

My understanding (I think in agreement with your description)
is that on an SCTP socket, recv() will stop at the first message
boundary or before.  The latter case would be if the receiver's
buffer were not large enough for ONE message.  My further
understanding is that the two cases (one full message, or
one part of one message) cannot be distinguished intrinsically
by the caller of recv().

I am more familiar with a AT&T SysV streams paradigm using
getmsg() (<stropts.h> from IEEE Std 1003.1-2001), which
will also read at most one "message", but can distinguish
between the two cases (returning 0, or MOREDATA respectively,
the returned length is inside a provided parameter structure.
This is a clear advantage for a reader that doesn't understand
higher layer packetization.  Although I am aware that 
sctpsockets is maturing, would it be advantageous to extend
it to provide a call that can indicate full or partial message 
receipt?  Or is there such a mechanism within sctpsockets 
already?  I imagine that the internal [kernel] implementation
remains aware of received message boundaries.

With thanks, from Chris Benson.

On Thu, 29 Jul 2010, Vlad Yasevich wrote:

>>  Date: Thu, 29 Jul 2010 15:07:22 -0400
>>  From: Vlad Yasevich <[email-masked]>
>>  To:  <[email-masked]>
>>  Subject: Re: recv() clarification in SCTP sockets API draft
>>

---

From: Vlad Yasevich <[email-masked]>
Date: Fri, 30 Jul 2010 14:23:51 -0400

> remains aware of received message boundaries.

Hi Chris

The spec already documents an API that provides information about
message boundaries.  It abstract that call into sctp_recvmsg()
that provides all the necessary information.  There are other calls
as well that provide the same information.

The spec simply discourages the use of recv() and other calls that do
not carry message boundary information.

-vlad