patchlwIP - A Lightweight TCP/IP stack - Patches: patch #5049, Add primitive MSG_PEEK support

 
 

You are not allowed to post comments on this tracker with your current authentication level.

patch #5049: Add primitive MSG_PEEK support

Submitted by:  None
Submitted on:  Sun 23 Apr 2006 05:07:43 AM UTC  
 
Category:  None Priority:  3 - Low
Status:  Done Privacy:  Public
Assigned to:  Frédéric Bernon <fbernon> Originator Email:  -email is unavailable-
Open/Closed:  Closed Planned Release:  None

( Jump to the original submission)

Thu 14 May 2015 01:32:37 PM UTC, comment #7: 

I have a user report that suggests the implementation of MSG_PEEK is not quite correct. The data is being returned [as outlined in the second note in comment #4]. But subsequent calls to recv without MSG_PEEK do not return the same data.

The problem has a software work-around, but ideally the MSG_PEEK flag would behave differently than non-MSG_PEEK flag.

The software work-around is to call recv() with flags=MSG_PEEK and length=0. This forces LWIP to return the number of bytes available but not advance beyond them. Then subsequent calls to recv() with flags=0 actually return the data as expected.

Christopher Pow <cpow>
Sat 30 Jun 2007 05:59:11 PM UTC, comment #6: 

> if I understand these documentations, nothing say we have to process all input queue, but just the datas that the next recv/recvfrom call will return without MSG_PEEK...


Exactly. It's more a generic limitation for TCP that the recv call is limited to one netbuf per call.

Simon Goldschmidt <goldsimon>
Project Administrator
Sat 30 Jun 2007 01:30:58 PM UTC, comment #5: 

Ok, I have change the lwip_recvfrom to process all types of connections with MSG_PEEK. To my point of view, it's compliant with documentations described in comment #4. About Nickolai remark, if I understand these documentations, nothing say we have to process all input queue, but just the datas that the next recv/recvfrom call will return without MSG_PEEK...

So, I consider that closed, but reopen it if you're not agree with that...

Frédéric Bernon <fbernon>
Project MemberIn charge of this item.
Sat 30 Jun 2007 10:46:30 AM UTC, comment #4: 

http://www.opengroup.org/onlinepubs/007908799/xns/recvfrom.html
http://www.opengroup.org/onlinepubs/007908799/xns/recv.html

"MSG_PEEK: Peeks at an incoming message. The data is treated as unread and the next recvfrom() or similar function will still return this data." ... "If a message is too long to fit in the supplied buffer, and MSG_PEEK is not set in the flags argument, the excess bytes are discarded."

ms-help://MS.VSCC.2003/MS.MSDNQTR.2006JAN.1033/winsock/winsock/recv_2.htm

"MSG_PEEK: Peeks at the incoming data. The data is copied into the buffer, but is not removed from the input queue. The function subsequently returns the amount of data that can be read in a single call to the recv (or recvfrom) function, which may not be the same as the total amount of data queued on the socket. The amount of data that can actually be read in a single call to the recv (or recvfrom) function is limited to the data size written in the send or sendto function call."

nickolai@cs.stanford.edu:

"patch...for TCP sockets...limited in that it will not peek across netbuf boundaries"

Frédéric Bernon <fbernon>
Project MemberIn charge of this item.
Sat 30 Jun 2007 07:43:44 AM UTC, comment #3: 

I haven't looked at it and don't really know MSG_PEEK, but I think Kieran would object, until implementing it complete...

Simon Goldschmidt <goldsimon>
Project Administrator
Fri 29 Jun 2007 09:35:17 PM UTC, comment #2: 

Since this patch doesn't change the code if MSG_PEEK is not set in flags (just a real little increase of code for socket layer users), I propose to check in "as is", since it provide the most important part of the job. No objects ?

Frédéric Bernon <fbernon>
Project MemberIn charge of this item.
Mon 19 Feb 2007 11:12:47 AM UTC, comment #1: 

This looks like a partial solution, which although undoubtedly useful (and so thank you for sending it), would be better if it did the whole job.

Would anyone be willing to take this on and produce a more complete patch?

Kieran Mansley <kieranm>
Project Member
Sun 23 Apr 2006 05:07:43 AM UTC, original submission:  

The attached patch provides a simple-minded implementation of MSG_PEEK for TCP sockets (limited in that it will not peek across netbuf boundaries).  Nonetheless, it's sufficient to make wget happy, which requires MSG_PEEK to work.

-- kolya

Anonymous

 

Attached Files
file #9824:  lwip.p added by None (1KiB - text/plain)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by cpow (Posted a comment)
  • -email is unavailable- added by goldsimon (Posted a comment)
  • -email is unavailable- added by fbernon (Posted a comment)
  • -email is unavailable- added by kieranm (Posted a comment)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

     

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2007-06-30 fbernon StatusNone => Done
        Assigned toNone => fbernon
        Open/ClosedOpen => Closed
    2007-02-19 kieranm Priority5 - Normal => 3 - Low
    2006-04-23 None Attached File- => Added lwip.p, #9824

    Back to the top


    Powered by Savane 3.5