The sendfile() description across the OSes is not the same. The FreeBSD version https://man.freebsd.org/cgi/man.cgi?sendfile(2) for example has words "The nbytes argument specifies how many bytes of the file should be sent, with 0 having the special meaning of send until the end of file has been reached" while Linux version does not states anything about zero count, so this seems to be "system defined". We can try to experiment with the Linux version to see how zero bytes count is handled.
Best regards, Petro On Sun, Jun 18, 2023, 11:10 PM Fotis Panagiotopoulos <f.j.pa...@gmail.com> wrote: > Hi Alan, > > Thanks for checking this out. > > The resources you linked indicate (correctly) that a TCP segment may have 0 > data size. > But also that usually this is not allowed for the users? I don't know, I > don't intend to use this. > > However, sendfile (not the plain send) would be completely meaningless with > a 0 size, I think. > Currently, NuttX will not send anything on the wire with size set to 0. Not > even an empty TCP segment. > > I don't really want to change the way it works, only improve its behavior. > As it is right now, resources are wasted, and the cryptic EAGAIN makes > troubleshooting harder. > > But what's best? Return zero? Change errno? > > On Sun, Jun 18, 2023 at 10:13 PM Alan C. Assis <acas...@gmail.com> wrote: > > > Suggest, try to run you same application with this issue on Linux. > > > > I'm expecting at least a similar error on Linux. > > > > BR, > > > > Alan > > > > On 6/18/23, Alan C. Assis <acas...@gmail.com> wrote: > > > Hi Fotis, > > > > > > On 6/18/23, Fotis Panagiotopoulos <f.j.pa...@gmail.com> wrote: > > >> Hello, > > >> > > >> Due to a bug in my application, the code tried to use sendfile() with > > >> zero > > >> size. > > >> > > >> As I see, sendfile() will happily proceed, and it will block here: > > >> > https://github.com/apache/nuttx/blob/master/net/tcp/tcp_sendfile.c#L523 > > >> > > >> Obviously, it will never manage to send any data (as the requested > size > > >> is > > >> 0), > > >> and after the timeout expires, it will return EAGAIN. > > >> > > > > > > Good finding! > > > > > > BTW, that is the default timeout value? > > > > > > I think conn->sconn.s_sndtimeo is only defined when people enable the > > > CONFIG_NET_SOCKOPTS. > > > > > >> This seems a bit wrong to me. > > >> Why not return immediately, but instead wait for the (inevitable) > > >> timeout? > > >> Why not return a more meaningful error code, or maybe just 0? > > >> > > > > > > I was going to suggest avoid sending a packet with 0 byte, but it is > > > supported: > > > https://www.quora.com/Can-TCP-send-0-byte-packets > > > https://github.com/golang/go/issues/10940 > > > > > > See, technically it is not an error! :-) > > > > > >> I couldn't find what the standards dictate for this edge case, so > maybe > > >> the > > >> current behavior is correct. > > >> > > >> What do you think? > > >> > > > > > > I think it is correct, but most servers will just ignore it and you > > > will end-up with a timeout. > > > > > > BR, > > > > > > Alan > > > > > >
