lwIP - A Lightweight TCP/IP stack - Tasks: task #14395, recv of short buffer should...
You are not allowed to post comments on this tracker with your current authentication level.
task #14395: recv of short buffer should eventually time out
Submitter: | Simon Goldschmidt <goldsimon> | ||
Submitted: | Thu 02 Mar 2017 12:55:10 PM UTC | ||
Category: | socket/netconn | Should Start On: | Thu 02 Mar 2017 12:00:00 AM UTC |
Should be Finished on: | Thu 02 Mar 2017 12:00:00 AM UTC | Priority: | 3 - Low |
Status: | Cancelled | Privacy: | Public |
Assigned to: | goldsimon | Percent Complete: | 0% |
Open/Closed: | Closed | Planned Release: | None |
Effort: | 0.00 |
Jump to the original submission
Thu 02 Mar 2017 09:27:49 PM UTC, comment #8: |
Simon Goldschmidt <goldsimon> |
Thu 02 Mar 2017 09:16:25 PM UTC, comment #7:
|
Joel Cunningham <jcunningham> |
Thu 02 Mar 2017 07:02:29 PM UTC, comment #6: I think that ignoring PSH and returning any data instead of waiting is a far better solution than the winsock waiting thing.
|
Simon Goldschmidt <goldsimon> |
Thu 02 Mar 2017 03:44:36 PM UTC, comment #5: I've done some auditing of this behavior in LwIP and wanted to share a couple of things:
|
Joel Cunningham <jcunningham> |
Thu 02 Mar 2017 01:50:38 PM UTC, comment #4: I would not bother with SO_SNDLOWAT/SO_RCVLOWAT by the way. In hindsight they were not worth the trouble for me. I added them just because they're is part of the traditional BSD set of socket options, but semantics differ between platforms and few if any applications actually use them. MSG_WAITALL is nice in theory but not (yet) portable and as such probably not used much either. |
David van Moolenbroek <dcvmoole> |
Thu 02 Mar 2017 01:46:27 PM UTC, comment #3: Oops. Copy&pasting is hard. http://smallvoid.com/article/winnt-tcp-push-flag.html |
David van Moolenbroek <dcvmoole> |
Thu 02 Mar 2017 01:45:24 PM UTC, comment #2:
|
Simon Goldschmidt <goldsimon> |
Thu 02 Mar 2017 01:28:31 PM UTC, comment #1: FWIW! After looking into this I decided to disregard the PSH flag in my implementation altogether, instead always returning only whatever is available when anything is available at all (modulo MSG_WAITALL, SO_RCVLOWAT etc). My PoV is that while not considering the PSH flag may cause performance issues, not returning available data may cause correctness issues. As far as I can tell, the BSDs and Linux also follow the same behavior (ie no timeout), but don't quote me on that! On Windows it appears there's a 0.5sec timeout which, as can be expected, causes problems in some scenarios: http://smallvoid.com/article/winnt-tcp-push-flag.htm |
David van Moolenbroek <dcvmoole> |
Thu 02 Mar 2017 12:55:10 PM UTC, original submission:
When recv(1024) is called but we only have 1022 bytes, we currently wait forever (unless the PSH bit is set or the netconn is nonblocking/has a timeout set).
|
Simon Goldschmidt <goldsimon> |
No files currently attached
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 4 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2017-03-02 | goldsimon | Status | Postponed | Cancelled | |
Open/Closed | Open | Closed | |||
2017-03-02 | goldsimon | Status | None | Postponed | |
Assigned to | None | goldsimon |
Powered by Savane 3.13-3230.
Corresponding source code
Hmm, correct. Thanks for pointing that out :-)
I hate that rcvevnt thing :-/ Sorry for the confusion.