My manpage sais
Does the word presently mean "someday it will be changed" or not?
And if it's not, then what does prevent it?

Because it depends on mmap() which doesn't work with sockets.

Well, why isn't possible remove the dependence on mmap(), at least when working with sockets? Have someone tried this and found out that it's slower than, for example, use mmaped area as a buffer for read() on socket (although sendfile(file,socket) is faster than open(file), mmap(file), write(socket,mmaped_ptr))?

So far, noone knows? What a pity...

Maybe one reason is that sendfile name implies it is sending a file, and a socket descriptor is related to anything but a file ...

I'm asking about technical difficulties preventing the implementation of sendfile (socket, file). I don't think naming is a problem - if it could be done with syscall named something like recvfile(), I would be happy.

Nothing forbids you to improve sendfile and propose to the linux kernel maintainers this new feature ...
I think that it would be a bad idea anyway, as it would break compatibility with other O/Ses which implement it as a library function, and have conformed to the Linux semantics (AFAIK sendfile is unknow to POSIX or other Unix standardization groups).

Moreover, sendfile justification was to improve performance by using zero copy I/O operations, which is something efficient while mmap is used for the source, but meaningless when the source is remote and its data is arriving at an unpredictible rate from the network.

So this enhancement would have added too high level features in a system call, with few if any performance gain.

I think my idea is not new. When kernel maintainers decided to make sendfile(file,socket), I think they probably (or even certainly) considered reverse variant, and found it unacceptable (as have been said, "with few if any performance gain").
I wondered if someone can point out this considerations. I'm interested in quantitative values ("how many percent will performance rise or fall with this method") but I think it can be found only if someone has already implemented it and measured.
Another answer on my questions would probably be the explanation why it's obvious that there won't be any performance gain. I'm not sure that it's
because it is be zero-copy I/O too, and might be fast.
For example, when one uses {open(file), mmap(file), write(socket,mmaped_ptr)}, there are 1 syscall more and, if file is large, mmap() can fail because of insufficient memory (and if so, one should remap some portions of file, adding count of syscalls), but AFAIK sendfile() uses only one page at a time.

This is obvious, but sendfile() from a socket tied to a foreign host into a local file would risk filling up your disk

Actually, sendfile() has 4th parameter (count) - the number of bytes you would like to send, so I don't think there are problems with that.

Correct, sendfile is hopefully buffer size bounded.
Just to clarify, do you want a function able to receive from a socket, and in that case limited to write to a local file file descriptor, or do you want the function to be orthogonal and work too when both ends are sockets ?

Just socket->file is ok for me

Ok, so that would be something that receivefile, as you suggested.

Perhaps a reason nobody implemented it, is that sendfile is mainly used by servers where each improvement in performance matters (a server may process a bunch of concurrent requests), while that receivefile would be for clients, which are usually more bounded by network throughput, and processing few simultaneaous requests anyway.