On Tue, Nov 6, 2012 at 5:20 PM, Bernd Petrovitsch <bernd@xxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx > LUGA : http://www.luga.at > > > _______________________________________________ > Kernelnewbies mailing list > Kernelnewbies@xxxxxxxxxxxxxxxxx > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
