Subject: [Tsvwg] Clarification of sctp_recvmsg in draft-ietf-tsvwg-sctpsocket

From: Florian Niederbacher <[email-masked]>
Date: Thu, 02 Oct 2008 13:45:05 +0200

Hello,
there was a discussion in lksctp- mailing list about the usage of the 
msg_flags of sctp_recvmsg().

9.8. sctp_recvmsg()
...

msg_flags -  A pointer to a integer to be filled with any message flags (e.g.  MSG_NOTIFICATION).

The draft doesn't define exactly how this msg_flags should be used. It would be useful to determine how to use this not only as return parameter, but as I/O parameter.

ssize_t sctp_recvmsg(int sd,
                        void *msg,
                        size_t len,
                        struct sockaddr *from,
                        socklen_t *fromlen
                        struct sctp_sndrcvinfo *sinfo
                        int *msg_flags)

msg_flags is defined as a call by reference parameter and therefore passing flag parameters, like "MSG_PEEK", would be useful. From the definition in the draft you can't see if it should be supported or not.

Example for the usage: In my case I would need only to take off the received message from the recv-queue if the MSG_NOTIFICATION flag is set and no Data. This can be done with the MSG_PEEK. 
In lksctp I can't set the MSG_PEEK flag, but in BSD you can.

The draft says nothing about the ability for the application to set msg_flags value to something that the API can use internally.
BSD implementation, it will pass the value of msg_flags down to the kernel.
LKSCTP on the other hand, always pass down 0.

I guess a clarification of the usage of the msg_flag should be discussed. What are the suggestions and proposals of the tsvwg members?

Best regards
Florian Niederbacher

---

From: Randy Stewart <[email-masked]>
Date: Thu, 2 Oct 2008 07:57:16 -0400

On Oct 2, 2008, at 7:45 AM, Florian Niederbacher wrote:

> Hello,
> there was a discussion in lksctp- mailing list about the usage of  
> the msg_flags of sctp_recvmsg().
>
> 9.8. sctp_recvmsg()
> ...
>
> The draft doesn't define exactly how this msg_flags should be used.  
> It would be useful to determine how to use this not only as return  
> parameter, but as I/O parameter.
>
> msg_flags is defined as a call by reference parameter and therefore  
> passing flag parameters, like "MSG_PEEK", would be useful. From the  
> definition in the draft you can't see if it should be supported or  
> not.
>
> Example for the usage: In my case I would need only to take off the  
> received message from the recv-queue if the MSG_NOTIFICATION flag is  
> set and no Data. This can be done with the MSG_PEEK. In lksctp I  
> can't set the MSG_PEEK flag, but in BSD you can.

Yes this is a in/out flag and maybe we need some text added to the  
document to clarify this. You
SHOULD be able to put a MSG_PEEK in the msg_flags and get back  
MSG_NOTIFICATION... if the next
message that you peeked at was a notification...

>
>
> The draft says nothing about the ability for the application to set  
> msg_flags value to something that the API can use internally.

Which is not correct...

> I guess a clarification of the usage of the msg_flag should be  
> discussed. What are the suggestions and proposals of the tsvwg  
> members?
>

Yeah, we need to add this to the draft...

R

> Florian Niederbacher

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

---

From: Michael Tüxen <[email-masked]>
Date: Thu, 2 Oct 2008 14:15:32 +0200

Hi Randy,

since I'm currently going through the ID and clean it up
I'll add some text to the description of sctp_recvmsg().

Best regards
Michael

On Oct 2, 2008, at 1:57 PM, Randy Stewart wrote:

>> received message from the recv-queue if the MSG_NOTIFICATION flag  
>> is set and no Data. This can be done with the MSG_PEEK. In lksctp I

---

From: Florian Niederbacher <[email-masked]>
Date: Thu, 02 Oct 2008 14:42:53 +0200

Hi,
another question regarding the msg_flags is, how they are handled after 
return from sctp_recvmsg().

Are the input flags(MSG_PEEK, MSG_DONTWAIT,...) set to zero after return 
or not. It makes also a difference for the examples in the draft:
...

/* Intercept notifications here */
              if (msg->msg_flags & MSG_NOTIFICATION) {
                      handle_event(buf);
                      continue;
              }
...

A bitwise AND is then no more possible, because you have to know also 
the previous used flags, if they will also returned back in msg_flags.
In this case you have to deal with a bit mask. I guess what exactly you 
get as return value should also be defined, in this section.
My opinion is that it would be a clean solution to zero-out all input 
flags inside the sctp_recvmsg() - call on return. What are your 
suggestions?

Regards
Florian

Michael Tüxen schrieb:
>>> definition in the draft you can't see if it should be supported or not.
>>>
>>> discussed. What are the suggestions and proposals of the tsvwg members?
>>>
>>
>>
>>

---

From: Randy Stewart <[email-masked]>
Date: Thu, 2 Oct 2008 09:37:55 -0400

They really should be 0'd and then set to
whatever they need to be set to... IMO

R
On Oct 2, 2008, at 8:42 AM, Florian Niederbacher wrote:

> Hi,
> another question regarding the msg_flags is, how they are handled  
> after return from sctp_recvmsg().
>
> Are the input flags(MSG_PEEK, MSG_DONTWAIT,...) set to zero after  
> return or not. It makes also a difference for the examples in the  
> draft:
> ...
>
> A bitwise AND is then no more possible, because you have to know  
> also the previous used flags, if they will also returned back in  
> msg_flags.
> In this case you have to deal with a bit mask. I guess what exactly  
> you get as return value should also be defined, in this section.
> My opinion is that it would be a clean solution to zero-out all  
> input flags inside the sctp_recvmsg() - call on return. What are  
> your suggestions?
>
> Regards
> Florian
>
> Michael Tüxen schrieb:
>> Hi Randy,
>>
>>>> The draft doesn't define exactly how this msg_flags should be  
>>>> used. It would be useful to determine how to use this not only as  
>>>> return parameter, but as I/O parameter.
>>>>
>>>> msg_flags is defined as a call by reference parameter and  
>>>> therefore passing flag parameters, like "MSG_PEEK", would be  
>>>> useful. From the definition in the draft you can't see if it  
>>>> should be supported or not.
>>>>
>>>> Example for the usage: In my case I would need only to take off  
>>>> the received message from the recv-queue if the MSG_NOTIFICATION  
>>>> flag is set and no Data. This can be done with the MSG_PEEK. In  
>>>> lksctp I can't set the MSG_PEEK flag, but in BSD you can.
>>>
>>>> The draft says nothing about the ability for the application to  
>>>> set msg_flags value to something that the API can use internally.

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

---

From: Michael Tüxen <[email-masked]>
Date: Thu, 2 Oct 2008 15:55:09 +0200

Hi Randy,

the implementation on Mac OS X does:

ssize_t sctp_recvmsg(int s,
    void *dbuf,
    size_t len,
    struct sockaddr *from,
    socklen_t * fromlen,
    struct sctp_sndrcvinfo *sinfo,
    int *msg_flags)
{
	struct sctp_sndrcvinfo *s_info;
	ssize_t sz;
	int sinfo_found = 0;
	struct msghdr msg;
	struct iovec iov[SCTP_SMALL_IOVEC_SIZE];
	char controlVector[SCTP_CONTROL_VEC_SIZE_RCV];
	struct cmsghdr *cmsg;

	msg.msg_flags = 0;
        ....
	sz = recvmsg(s, &msg, *msg_flags);
	*msg_flags = msg.msg_flags;

So, yes, they should be cleared (and are on Mac OS X and most likely
on FreeBSD).

I'll choose the wording to make this clear.

Any objections?

Best regards
Michael

On Oct 2, 2008, at 3:37 PM, Randy Stewart wrote:

>>>>> there was a discussion in lksctp- mailing list about the usage  
>>>>> of the msg_flags of sctp_recvmsg().
>>>>>
>>>>> 9.8. sctp_recvmsg()
>>>>> ...
>>>>>
>>>>> used. It would be useful to determine how to use this not only  
>>>>> as return parameter, but as I/O parameter.
>>>>>
>>>> Yes this is a in/out flag and maybe we need some text added to  
>>>> the document to clarify this. You

---

From: Vlad Yasevich <[email-masked]>
Date: Thu, 02 Oct 2008 14:56:43 -0400

> I'll choose the wording to make this clear.

No objections.  Upon return, msg_flags should only contain the value of
the flags from the recvmsg() call.

-vlad