I am writing a tiny tcp proxy and I want to peek the connection and
then if certain conditions are met maybe splice the two FDs to
communicate one with the other leaving the kernel handle all the
other levels of the FD.
The benefits that I expect are:
- less userspace data copying
- faster data transfer
Likely, yes. But it's not a huge win either, due to syscall overhead.
Depends on the throughput involved.
One good side-effect with GC languages like Ruby is lower GC overhead.
- less complexity handling the buffers in the userspace
I'm not certain about that. It depends 
I do not know if linux Splice is the right choice for the task but I
am almost sure it is.
If someone have any recommendations I would be happy to read them.
Definitely keep up-to-date with the Linux kernel. There were some
important performance/bug fixes in there from as recently as 2013; so
some older distros may be much slower or buggier; especially TCP
which does true zero-copy (Unix domain sockets do not, currently).
Non-blocking behavior was a bit confusing; but makes sense in the end.
You can resize pipes in newer kernel versions, which can improve
throughput.
haproxy might be a good example if you read C, as it's a TCP proxy.
I wrote dtas-player[1] in Ruby to (optionally) use splice+tee, but
mainly for fun and not performance.
Note: I'm the io_splice gem maintainer, too.
[1] git clone git://80x24.org/dtas - lib/dtas/buffer/splice.c
ยทยทยท
Eliezer Croitoru <eliezer@ngtech.co.il> wrote: