lwIP - A Lightweight TCP/IP stack - Bugs: bug #61097, Deadlock due to inability to...
You are not allowed to post comments on this tracker with your current authentication level.
bug #61097: Deadlock due to inability to receive ACKs when all pbufs are full
Submitter: | Christopher Head <hawk777> | ||
Submitted: | Wed 01 Sep 2021 03:33:33 AM UTC | ||
Category: | TCP | Severity: | 3 - Normal |
Item Group: | Faulty Behaviour | Status: | None |
Privacy: | Public | Assigned to: | None |
Open/Closed: | Open | Planned Release: | None |
lwIP version: | Other |
Thu 02 Sep 2021 03:36:29 AM UTC, comment #1: |
Christopher Head <hawk777> |
Wed 01 Sep 2021 03:33:33 AM UTC, original submission:
Consider an application that works in strict command-response mode; that is, it receives a command, executes it, sends a response to the client, and then goes back to receive the next command. Consider a client that sends commands, but doesn’t read responses. Here’s what will happen; let’s say the client sending the commands is running Linux:
|
Christopher Head <hawk777> |
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.
Powered by Savane 3.13-caa5.
Corresponding source code
I realized later on that everything I just said only applies if you do full-stack zero-copy receives, by having the application keep the pbufs it’s given in the tcp_recv callback until it’s ready to process them. If the application instead adds a copying step, where it copies data from those pbufs into a separate buffer, then that separate buffer only needs to be one window-size long, it doesn’t need to be one window-size times the receive chunk size; so, if you’re OK with losing full zero-copy, this isn’t actually a big problem (and saying that each socket needs a window-sized buffer is totally reasonable).