recvfrom a large packet

[devendra.aaru]

On Tue, Nov 6, 2012 at 5:20 PM, Bernd Petrovitsch
<bernd at 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 at 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.

i am sure that i recieved the bytes i sent,
i put a known bytes at the starting and ending of the buffer i send
from the other side,
i checked these at the receive end.

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

>> > since fragmentation happen in the ip layer and assembled happen in the
>> > ip layer it doesnt matter for the upper layer about the packet size.
> [....]
>> > i wrote a test code and it seems to be working.
>
> You tried one case and then you think it is in all cases the same?
> You are very optimistic .....
>

:-)

>> > is there any problem will come if i turn on firewall.
> [...]
>
> Try it. "Turn on firewall" is also not very precise ....
>

i turned on firewall and its working, but when i do a multicast it
seems to be not recieving
any packets, seems that firewall is dropping the fragments. Figuring
out how to dig this out.


>>    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.

>> 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?

> Kind regards,
>         Bernd
> --
> Bernd Petrovitsch                  Email : bernd at petrovitsch.priv.at
>                      LUGA : http://www.luga.at
>
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies