lwIP - 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
Submitter: | None | ||
Submitted: | Sun 23 Apr 2006 05:07:43 AM UTC | ||
Category: | None | Priority: | 3 - Low |
Status: | Done | Privacy: | Public |
Assigned to: | 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: |
Christopher Pow <cpow> |
Sat 30 Jun 2007 05:59:11 PM UTC, comment #6:
|
Simon Goldschmidt <goldsimon> |
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...
|
Frédéric Bernon <fbernon> |
Sat 30 Jun 2007 10:46:30 AM UTC, comment #4: http://www.opengroup.org/onlinepubs/007908799/xns/recvfrom.html
|
Frédéric Bernon <fbernon> |
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> |
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> |
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.
|
Kieran Mansley <kieranm> |
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.
|
Anonymous |
Depends on the following items: None found
Items that depend on this one: None found
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Follow 5 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2007-06-30 | fbernon | Status | None | Done | |
Assigned to | None | fbernon | |||
Open/Closed | Open | Closed | |||
2007-02-19 | kieranm | Priority | 5 - Normal | 3 - Low | |
2006-04-23 | None | Attached File | - | Added lwip.p, #9824 |
Powered by Savane 3.13-d3ae.
Corresponding source code
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.