Alternative transports for Akka.Remote

[rogeralsing]

I would love to see some alternative transport layers for Akka.Remote.
Lately there have been a lot of questions regarding different network aspects, security, throughput etc.
And I do think it would be beneficial the more integrations we have.

For example,

• X-Sockets.NET
• Libuv (NodeJS socket layer)

Libuv is known for its high performance, it would be very interesting to see how that would work with our stack even if the lib itself is native.

X-Sockets.NET is pure .NET but comes with a lot of options and integrations.

Even if such effort turns out to not be used by anyone, it still shows the community what can be done with Akka.NET, and there are always some users that have firm opinions on what to use.

The more options the better imo, just to grow the ecosystem around us.

(And I dont mean that the core team should bother with this, but it could be a nice exercise for the community)

[kekekeks]

Not sure if it should be alternative transports rather than network layers. At least in case of libuv we should keep the wire protocol intact.

[rogeralsing]

Its the transports that are pluggable.

 ### Transports and adapters

    # List of the transport drivers that will be loaded by the remoting.
    # A list of fully qualified config paths must be provided where
    # the given configuration path contains a transport-class key
    # pointing to an implementation class of the Transport interface.
    # If multiple transports are provided, the address of the first
    # one will be used as a default address.
    enabled-transports = ["akka.remote.helios.tcp"]

I see no real reason why you would go Libuv node talking to a Helios node. you could just use the same transport on both sides as any transport specific features would be useless in that case.

[beatsm]

This may be a good as part of an alternative

http://mechanical-sympathy.blogspot.co.uk/2014/05/simple-binary-encoding.html?m=1#comment-form

Regards

---

From: Roger Johanssonmailto:[email protected]
Sent: ‎30/‎05/‎2015 15:02
To: akkadotnet/akka.netmailto:[email protected]
Subject: Re: [akka.net] Alternative transports for Akka.Remote (#1017)

Its the transports that are pluggable.

 ### Transports and adapters

    # List of the transport drivers that will be loaded by the remoting.
    # A list of fully qualified config paths must be provided where
    # the given configuration path contains a transport-class key
    # pointing to an implementation class of the Transport interface.
    # If multiple transports are provided, the address of the first
    # one will be used as a default address.
    enabled-transports = ["akka.remote.helios.tcp"]

I see no real reason why you would go Libuv node talking to a Helios node. you could just use the same transport on both sides as any transport specific features would be useless in that case.

---

Reply to this email directly or view it on GitHub:
#1017 (comment)

[Aaronontheweb]

Edit: actually, X-Sockets would be a good idea

I'd like to see something way out there

• Google Quic protocol
• RGP / reliable multicast protocols
• Shared / named pipes (not sure if this is possible since it doesn't use the IP protocol)

[kekekeks]

I see no real reason why you would go Libuv node talking to a Helios node.

Helios for node running on Windows, libuv for node running on *nix.

[rogeralsing]

@kekekeks that's more like a special version of helios, it could still make sense to have different transports if the backing implementation supports features that are missing from Helios

[kekekeks]

I don't see anything that libuv can support and Helios can't. libuv is just an abstracted I/O event queue after all.

May be it would be better to add libuv support directly to Helios.

[rogeralsing]

Without testing, I would guess that Libuv is a lot faster than Helios. that alone is a reason to have a transport based on that.

[kekekeks]

Argh. livuv isn't some magic, its replacement for System.Net.Sockets and is more efficient for *nix systems, but not for windows (because System.Net.Sockets are designed to perform well on top of I/O Completion Ports with dedicated I/O thread pool and libuv uses the concept of main I/O event loop which works well with epoll/kqueue).

1. You will still need to implemented all that logic already implemented in Helios
2. I don't see why we should have incompatible transports one of whose being good for *nix and another one being good for Windows

[rogeralsing]

2. I don't see why we should have incompatible transports one of whose being good for *nix and another one being good for Windows

I dont know where this comes from?
I'm not talking about replacing the default transport.
I'm talking about having more options. nothing that goes into the core project.

[kekekeks]

If one create a libuv-based transport with incompatible protocol we'll have exactly the described situation.

[rogeralsing]

OK, so we don't build that specific one then.

X-Sockets has a huge community and I see no reason why we should not try to bring our and their user base together.

[uffebjorklund]

I am one of the core devs at XSockets.NET and I love the idea presented here.
I will have to do some homework, but I will be happy to contribute in any way I can.

First of all I will get familiar with Akka, then I will get back to you guys

[rogeralsing]

Related to #788 - Akka.IO Transport

[jordansjones]

I'd be curious to see if NetMQ's Request / Response Socket was a feasible transport option.

There is also an FSharp port

[philiplaureano]

How do you write a custom transport for Akka.Remote?

[Horusiath]

@philiplaureano here you have an alternative transport (using Akka.IO instead of Helios).

Regarding transports - it looks like Lightbend guys are going to merge Artery into master. It's something worth thinking of. Ofc we need to first stabilize and optimize akka streams (which is already fast, but not enough) including performance optimiziations that came on the JVM in v2.4.9.

[sean-gilliam]

Moved issue to AkkaNetContrib/Home#26