recvfrom a large packet

[bernd@petrovitsch.priv.at (Bernd Petrovitsch)]

On Mit, 2012-11-07 at 00:09 -0500, devendra.aaru wrote:
> On Tue, Nov 6, 2012 at 5:20 PM, Bernd Petrovitsch
> <bernd@petrovitsch.priv.at> wrote:
> > On Die, 2012-11-06 at 16:08 +0200, Victor Buciuc wrote:
> >> On Tue, Nov 6, 2012 at 1:35 PM, devendra.aaru <devendra.aaru@gmail.com> wrote:
> >> > if i do a recvfrom (sk, buf, 10000, 0, &addr, &len), shall i recv all the data
> >> > i mean the 10000 bytes?
> >
> > Not necessarily. Consider the case that the other side sends only 9000
> > bytes.
> >
> I tested with 1000 -- 10000 byte ranges in addition of 1000 bytes or 100 bytes.

Ah, you meant you get all the bytes you sent (and not you always want to
get 10000 bytes and return then).

In a LAN, it probably works all the time that you get all the data at
once (and you usually have no packet drops in LANs too).
Over router, firewalls and/or the Internet as such, it may be different
as routers (similar to all other IP hosts) may drop packets and/or
reorder them so it may take some time for a 10k packet to come through.

[...]
> i used MSG_TRUNC to get the correct number of bytes that i recieved.

AFAIK that shouldn't make a difference (in that aspect).

[...]
> >>    I think a signal can interrupt recvfrom. If you already had some
> >> data copied in the buffer then it will return something. You should
> >
> > No, if a signal interrupts the recvfrom(), recvfrom() returns -1 (and
> > errno == EINTR).
> > Thus it cannot report any partially received packet and so there is
> > nothing written to the buffer.
> 
> basically i check for EINTR, when it occur i dont need to do anything
> for the buffer, just returning out.

Yes, the buffer shouldn't change - at least no (sane) user-space program
will expect anything useful in the buffer.

> >> always check what you get in the result returned by recvfrom. If
> >> you're not satisfied with what you got you can always call again. (I
> >> assumed it's UDP we're talking about).
> >
> > That is actually the only robust way:
> > 1) append the read data to a buffer
> > 2) check if enough is there to handle a packet. If not goto 1)
> > 3) handle the first packet and delete it.
> > 4) goto 2)
> 
> you mean to say use the MSG_PEEK flag and move past the buffer you read?

Hmm, I don't understand.
The 4 steps above describe what a userspace application should do
IMHO:-).

I'm not a fan of MSG_PEEK and the like. It leads people to "look what
will come and if we are happy with it, actually get it".

The problem with this approach is, that it implicitly assumes that no
one else is interfering with the filedescriptor/socket/entity.

That may hold for hello-world class programs, school (and university)
exercises, demo application, proof-of-concept prototypes and other small
write-once-and-never-touch-again software.

In real life with large applications, changing developer teams and
maintenance over years, people tend to stumble over all kinds of
implicit assumptions (which are violated over time) - and though someone
writes today in a specification and/or design document (and every
README;-) "we will never use threads and close all fds > 2 immediately
after a fork()", it may be well different in 6 months and the
documentation is changed/updated/fixed and usually no one really checks
the code afterwards.
Add the common copy-and-paste-and-change-a-few-lines-and-never-touch-
old-code programming technique for the next feature and it gets even
worse in the long run.

	Bernd
-- 
Bernd Petrovitsch                  Email : bernd at petrovitsch.priv.at
                     LUGA : http://www.luga.at