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.)
I am curious as to whether anyone has compared the present cat(1) tricks
for speed (like last I looked ages ago, using mmap() on one end sometimes)
to sendfile(3ext) in the case of regular file to regular file copy. Seems to
me that if sendfile() optimizes that case reasonably well, it could be faster
than anything else, having total knowledge of preferred
blocksizes on both ends, the full range of VM and buffering tricks available
to the kernel, the ability to recognize the availability of DIRECTIO on
one end or the other, etc (in which case it might be able to do it with
zero memory-to-memory copy), etc.
This message posted from opensolaris.org
_______________________________________________
networking-discuss mailing list
[email protected]
