Thread (5 messages) 5 messages, 3 authors, 2012-11-07

recvfrom a large packet

From: devendra.aaru <hidden>
Date: 2012-11-07 05:09:14

On Tue, Nov 6, 2012 at 5:20 PM, Bernd Petrovitsch
[off-list ref] wrote:
On Die, 2012-11-06 at 16:08 +0200, Victor Buciuc wrote:
quoted
On Tue, Nov 6, 2012 at 1:35 PM, devendra.aaru [off-list ref] wrote:
quoted
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.
quoted
quoted
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.
[....]
quoted
quoted
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 .....
:-)
quoted
quoted
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.

quoted
   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.
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help