Subject: flags not specified for send.../recv... calls

From: "Jan Newmarch" <[email-masked]>
Date: Fri, 29 Jun 2007 15:12:06 +1000

Hi

The various send.../recv... calls take a flags parameter. Draft 14 of
the spec says things like:
- 3.1.4 sendmsg ...no new flags are defined for STCP at this level...
- 4.1.5 connect ...MSG_EOF should not be set in the flags parameter
when calling
   sendto() or sendmsg() ...
- 6.1 send ...flags -  (described below)...
- 8.10 sctp_send ...flags -  is used in the same format as the sendmsg
call flags (e.g.
      MSG_DONTROUTE)

So the spec doesn't really say what the possible values are except
that they shouldn't be MSG_EOF and might be MSG_DONTROUTE.

Looking at the Linux and BSD code I see MSG_PEEK and MSG_DONTWAIT
supported, plus possibly others (MSG_NOSIGNAL - Linux; MSG_WAITALL??,
MSG_NBIO - BSD). BSD explicitly knocks out MSG_OOB. Neither handle
MSG_DONTROUTE which is given as an example in the spec!

Should the spec be more specific?

Cheers

Jan
--

---

From: Randall Stewart <[email-masked]>
Date: Fri, 29 Jun 2007 06:23:28 -0400

> Should the spec be more specific?

MSG_XXX flags are defined in

man sendmsg

on your system. Not supporting OOB makes sense since this is a
TCP specific thing...

MSG_NBIO or MSG_WAITALL seem to be o/s specific..

I think the thing on MSG_EOF is an old hold over from when
we tried to use the MSG_XXX flags.. but changed over into
using sinfo_flags and SCTP_XXXX... we can probably remove
the MSG_EOF mention all together..

R

-- 
Randall Stewart
NSSTG - Cisco Systems Inc.
803-345-0369 <or> 803-317-4952 (cell)

---

From: "Jan Newmarch" <[email-masked]>
Date: Fri, 29 Jun 2007 23:47:41 +1000

Hi

"man sendmsg" gives me a whole bunch of MSG_XXX flags. Some are O/S
specific (but I'm not sure which), others don't make sense for SCTP
like MSG_OOB (but I'm not sure about all of them) and some others
don't seem to be implemented. But saying "flags are some unspecified
subset of the sendmsg flags listed in the man pages for your O/S that
aren't O/S specific and which make sense for SCTP" isn't really a good
guide to writing portable code.

Wouldn't it be better to have the spec have something like:
--------
send, etc: flags are a bitwise OR of zero or more of MSG_EOR, MSG_DONTWAIT

recv, etc: flags are a bitwise OR of zero or more of  MSG_EOR,
MSG_PEEK, MSG_DONTWAIT

Additional flags may be supported by particular implementations.
-------
Cheers

Jan
--

---

From: Randall Stewart <[email-masked]>
Date: Fri, 29 Jun 2007 10:02:11 -0400

> guide to writing portable code.

IMO the bottom line is don't use them.

We can document the ones we want to support.. but you will always
have cases where the O/S has far more than we list... and thus
you may have to turn to local documentation on the O/S.. aka
man sctp
or some such..

Don't think I documented this in BSD.. probably should hvae ;-)

R

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 29 Jun 2007 11:36:59 -0600

Jan,

> guide to writing portable code.

MSG_XXXX flags and the sockets interface is standardized by POSIX 1003.1
and Single UNIX Specification released by IEEE and The Open Group.  If
you look at the "reference" pages for recvmsg() and sendmsg() in the
Base Specifications you will find the flags described there.  It also
describes which are "protocol-specific" and which are not.  The list of
flags from Issue 6 is:

 MSG_OOB, MSG_EOR, MSG_PEEK, MSG_WAITALL, MSG_TRUNC, MSG_CTRUNC

The only two flags that are protocol-specific (in their protocol effect
but not in their interface semantics) are MSG_OOB and MSG_EOR.

MSG_OOB is used to send and receive out-of-band data.  What constitutes
"out-of-band data" is protocol specific.  For SCTP, unordered data can
clearly be considered out of band (because it can be delivered ahead of
normal ordered data).

MSG_EOR requires the protocol to support the concept of a record.  TCP
does not.  UDP and SCTP do.  As SCTP supports records, the use of
MSG_EOR is clear from the POSIX sepcifications.

Support for the other flags is not optional, and their use is described
in the standard.

A particular OS will normally support more flags than this, however,
almost none of those can be used in a portable fashion.

--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: "Jan Newmarch" <[email-masked]>
Date: Sun, 1 Jul 2007 00:09:24 +1000

Thanks Brian

I wasn't aware of that spec. I'm looking at
http://www.unix.org/single_unix_specification/ "The Open Group Base
Specifications Issue 6, IEEE Std 1003.1, 2004 Edition" now. This makes
things much easier, I think. Note: I'm only talking about the flags
parameter, not the msg_flags field in the message header parameter in
recvmsg.

API spec 14  in section 6.1.  send(), recv(), sendto(), recvfrom() says
"flags -  (described below)" and then doesn't describe them after all.
In the light of your email could I suggest this be changed to:

"
flags - for send, etc, the flags are a bitwise OR of zero or more of MSG_EOR
          - for recv, etc, the flags are a bitwise OR of zero or more
of MSG_PEEK and
            MSG_WAITALL
         - other flags such as MSG_DONTWAIT may be supported by implementations
"

Two issues still:

- MSG_EOR is only worth setting if the sending side is sending partial
messages (by setting SCTP_EXPLICIT_EOR). But this is covered by the
flag SCTP_EOR in the sinfo_flags of sctp_extrcvinfo used by sendmsg.
Should this be allowed in send, etc? it sounds reasonable to me since
it means that calls such as send/sendto/etc can be used for partial
sending.

- I'm not so sure about your suggestion that MSG_OOB for send/etc
should trigger an unordered message. I think I should let others argue
this one... Is it in any implementation you know of?

Thanks

Jan
--