xiaoxiang781216 commented on PR #7278: URL: https://github.com/apache/incubator-nuttx/pull/7278#issuecomment-1274803295
> @xiaoxiang781216 The fact that recv _can_ return less bytes than requested, does not mean that it _should_. > > At least in my case, all data have been received by the device, in a single TCP frame, but only part of them is in the read-ahead buffer. The data is smaller than the MTU and the available buffers. > You can read as much as you can, but shouldn't wait in case you have receive some data. > > the change may block the recv indefinitely when caller use INFINITE timeout. > > This is the expected behavior when you use an infinite timeout, and it is unrelated to the contents of the read-ahead buffer. In fact, if data are unavailable, then surely the code will block (even with the old implementation), since the buffers will also be empty! > If so, your change should wait until ir_recvlen == ir_buflen here too: https://github.com/apache/incubator-nuttx/pull/7278/files#diff-37fdf02cbdce5f5eb879d55883afc6d6b96d5292799bc721653b55689ae14bd5R415 And think about again whether this is the behavior you really want. > The proposed change allows the user to fine-tune the socket to their needs, choosing between blocking or non-blocking and selecting a proper timeout. I don't see any problems, or how it can harm existing applications. Quite the contrary, you now have more options. > This change definitely will break many application. Many protocol can't predict the length of packet will receive, so application prefer to read the data with the fixed buffer like this: ``` char buf[4096]; ssize_t len = recv(s, buf, sizeof(buf), 0); ``` With your change, recv can't return before got 4KB. But, the sender may need receive the response from receiver to send more data. This is a typical form of a deadlock. > It also simplifies the user code, as now I have to re-do what the socket does (i.e. loop with `recv()` till all data are received or till timeout). > You have to do this as it required by POSIX standard. Otherwise, if the caller doesn't know the size before receiving, it can only read one by at one time. > Do you see any problems / disadvantages with this PR? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: commits-unsubscr...@nuttx.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
