Does Akka.IO Tcp has a bottleneck in bidirectional communication?

[ovsyannikov vladimir]

I've created the same discussion in Akka user group(sorry for a duplicate), but I don't know what's the best place for.

SO Question

http://stackoverflow.com/questions/30075515/does-akka-io-tcp-has-a-bottleneck-in-bidirectional-communication

[Johannes Rudolph]

That's a good observation. At least in theory, you are right, the
TcpConnection actor cannot read from and write to a socket at the same
time. It has, however, a limit on how many bytes it reads or writes at
one time before it allows to process other things from its mailbox. In
the meantime the OS-level read buffer will be used, so that more bytes
may be dispatched with the next read which should dampen the impact
somewhat.

So, what would be the scenario where this would really matter? You
would need to treat the connection as a really bidirectional one where
both sides stream data all the time. Then you would need to ensure
that the complete stack works independently for both directions. I
wonder if that's really the case even on the OS level. E.g. the OS
needs to somehow linearize sending out ACKs for received data with
sending out data itself. So, in practice I wonder if you can really
demonstrate the latency differences. Do you have any information or
benchmarks for these kind scenarios with other technology?

--
Johannes

-----------------------------------------------
Johannes Rudolph
http://virtual-void.net

[ovsyannikov vladimir]

I don't have any kind benchmark and I think it's not so easy to prove a speed reduction(all frameworks add additional overhead so it's not so easy to find a root cause and so on).
But I'm curious why the design decision has been made. For me it's more logical to have one actor to read from a socket and another to write.

[Johannes Rudolph]

On Wed, May 6, 2015 at 5:17 PM, ovsyannikov vladimir
<vladimir.o...@gmail.com> wrote:
> I don't have any kind benchmark and I think it's not so easy to prove a
> speed reduction(all frameworks add additional overhead so it's not so easy
> to find a root cause and so on).
> But I'm curious why the design decision has been made. For me it's more
> logical to have one actor to read from a socket and another to write.

The design decision was mostly for simplicity. Both of the API (Why
should the user-actor send Writes to a different actor than it
receives the data from? Where should the user send the Close message
to?) and of the implementation (each connection would need to consist
of two actors, one handling the reading, one the writing to remove
"the bottleneck" completely, these two actors would need to be
coordinated during closing the connection, etc). This extra complexity
would have to pull its weight. And it's not clear that an alternative
design would really be "faster". It may be true that you could get
lower latencies in the scenarios you envision by treating both
directions separately but e.g. it is not clear if throughput would be
higher as well.

Also the first purpose of Akka IO was Http which is a classic
request/response protocol which wouldn't benefit from such a design.
What kind of protocols do you have in mind?

[ovsyannikov vladimir]

I'm going to rewrite ReactiveMongo from netty to akka.io.
Implementation is fully wire protocol.