socket programming using MSG_WAITALL for receiving multicast packets

Hi,

I am calling function recvfrom() with flag set to MSG_WAITALL.
I thought the function is supposed only to return when the buffer is
completely filled up, or when there is a signal or error occurs.

However, in my experiment, the function constantly returns with fewer
number of bytes than requested.  The returned size is always the same
as the payload size of one multicast ip packet.  I wonder why?

Is there a way to make the function (or use other function) only
returns when the buffer is completely filled up if there is no signal
or error occurs??  Baically I don't want frequent context switch
between kernel and user space.  What I want is to accumulate certain
amount of the ip multicast packets before the function returns.  I am
working on Linux 2.6.

Thanks in advance!

John

In article
<25d3af5a-ffeb-422c-8e69-e44bf97926df@t54g2000hsg.googlegroups.com>,
jiangxu168@gmail.com wrote:

> On Mar 20, 4:11_pm, David Schwartz <dav...@webmaster.com> wrote: 
>
> I am receiving high bit rate streamming data such as Video data.  I
> think it will be more efficient with less context switch between
> kernel and user space.  So if the kernel can accumulate more packets
> before wake up the function, it should be more CPU efficient, right?

Regardless, there's nothing you can do about this.  With datagram
sockets, there's always a one-to-one correspondence between datagrams
and calls to recv.  How else do you expect to tell where the datagram
boundaries are?

The MSG_WAITALL option is only meaningful for stream sockets, since
there are no datagram boundaries to worry about.

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***

In article
<fff08a99-f817-48d3-acd9-58707f90b390@e6g2000prf.googlegroups.com>,
David Schwartz <davids@webmaster.com> wrote:

> On Mar 20, 4:23 pm, jiangxu...@gmail.com wrote:
> 
>
> Don't worry, the scheduler agrees with you. When efficiency matters,
> there will be less context switching.
> 
>
> Right, and that's exactly what the kernel will do, all by itself.
>
> If you test with no load, you will get lots of context switches. This
> is fine -- you can't save CPU in a jar to use later. As soon as the
> load goes up, the system will spend time doing other things and by the
> time your process gets to run, more packets will be accumulated as if
> by magic.
>
> Don't try to "fix" the scheduler. It's not broken.

What does the scheduler have to do with this?  He's not talking about
process switches, he's talking about context switches between user and
kernel mode when calling recvfrom().

There is overhead when going into and out of the kernel, but in this
case there's nothing you can do about it.  There's no system call for
getting the datagrams that have been buffered all at once.

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***