nemasu / asmttpd

Web server for Linux written in amd64 assembly.
GNU General Public License v2.0
3.02k stars 199 forks source link

Explanation of sendfile issue #57

Closed jan-guenter closed 1 year ago

jan-guenter commented 1 year ago

I was unsure of the actual impact described in the known issues as "Sendfile can hang if GET is cancelled."

Since I knew that GPT-4 was trained on all the public GitHub repos I asked ChatGPT if it knows asmhttpd and sure it did.

So I asked the following follow-up question:

Since you seem to know the code of asmttpd, do you have any idea what cases this known issue documented in it's Readme? "Sendfile can hang if GET is cancelled."

Here is its full reply:

The issue mentioned in the readme of asmttpd is related to the use of the sendfile system call when handling HTTP GET requests for static files. sendfile is an efficient way to send the contents of a file from one file descriptor to another, often used by web servers to transmit a file directly to a socket without the need for additional buffer copying in the user space.

The issue "Sendfile can hang if GET is cancelled" can occur when a client (e.g., a browser) sends an HTTP GET request and then cancels the request before the server has finished sending the file. In this case, the server continues to send the remaining file data using the sendfile system call, but the client is no longer expecting the data. As a result, the server may become stuck in the sendfile system call, causing it to hang and potentially blocking other requests from being handled.

This issue can be particularly problematic in single-threaded or event-driven servers like asmttpd, where a single process is responsible for handling multiple requests concurrently. If the server hangs in the sendfile call, it might not be able to process other incoming requests, significantly degrading the server's performance.

To resolve this issue, a server could implement a timeout mechanism to detect when a client has disconnected or cancelled a request. If the timeout is reached, the server could stop sending the file and free up resources to handle other requests. Alternatively, the server could use non-blocking I/O or multi-threading to handle multiple connections simultaneously, reducing the impact of a hanging sendfile call on overall server performance. However, implementing these solutions may require additional complexity and overhead in the server's code.

I found this reply very helpful and well written so added it to the README.md as a collapsed detail.

nemasu commented 1 year ago

I think a lot of the information in this description is not correct though. For instance:

-I don't think a timeout mechanism can be implemented with HTTP and sendfile. -asmttpd is not single threaded or event driven. -asmttpd is already multi-threaded.

I think the only useful information would be this bit: "the server continues to send the remaining file data using the sendfile system call, but the client is no longer expecting the data. As a result, the server may become stuck in the sendfile system call"

But it doesn't explain why it gets stuck anyways, so there really isn't any new information.

jan-guenter commented 1 year ago

Thanks for the info @nemasu Closing the PR.

I still think adding some info on this issue and its effects would be nice.