Richard L. Hamilton wrote:
Think of what it would mean: the "U" in UDP is for "Unreliable". No guarantee
that packets are delivered at all, or that the sender is notified if they
aren't.
No automatic retries. No guarantee that packets are delivered in order, or
aren't duplicated.
So all one would really know is that the recipient got zero or more packets,
not necessarily in order or nonduplicated. Nor would the recipient have any
idea of whether or not what it received was complete.
Further, the point of sendfile() is speed (as well as ease of use, reducing the
number of system calls needed, etc). If it's faster, it's likelier to overrun
the
receiver, causing it to silently drop even more packets.
For UDP, one needs either single packet messages that one doesn't really
care whether they're received or not, or an application level protocol to
build some sort of reliability or at least acknowledgement on top of UDP.
sendfile() for UDP cannot provide those. It is difficult to imagine
a responsible use of sendfile() for UDP.
Last but not least, the man page for sendfile(3ext) says:
The sendfile() function copies data from in_fd to out_fd starting at
offset
off and of length len bytes. The in_fd argument should be a file descriptor to a
regular file opened for reading. See open(2). The out_fd argument should be a
file descriptor to a regular file opened for writing or to a connected AF_INET
or AF_INET6 socket of SOCK_STREAM type. See socket(3SOCKET). The off
argument is a pointer to a variable holding the input file pointer position from
which the data will be read. After sendfile() has completed, the variable will
be set to the offset of the byte following the last byte that was read. The
sendfile() function does not modify the current file pointer of in_fd, but does
modify the file pointer for out_fd if it is a regular file.
The sendfile() function can also be used to send buffers by pointing in_fd
to SFV_FD_SELF.
A UDP socket is not SOCK_STREAM, so according to the man page, it shouldn't
work. (OTOH, I'm disappointed that it doesn't have to work with an
AF_UNIX SOCK_STREAM socket, although my guess is that sendfile() is
mainly meant for HTTP servers, and other uses are secondary.)
That's not a good argument against implementing it (and changing
the documentation to match) purely for orthogonality. It's not
impossible to imagine a UDP service where the data, while small,
is most conveniently held within a file. For example, an I18N
message catalogue.
A better reason for not having done it yet is lack of resource.
- Jeremy Harris
_______________________________________________
networking-discuss mailing list
[email protected]
