Akka.IO and Azure WebApp connectivity issue

[snekbaev]

Hi,

1.3.10 Azure WebApp + VM. Network has Azure's VPN connection in-between.

Original issue: remoting doesn't work properly with Azure WebApps. I've reported that on Gitter. In a nutshell: when target is up and source is connecting it goes through and stays that way until connection is interrupted, for example, if I manually restart the Azure WebApp it tries to connect again, but this time once source -> target connection is established, target for some reason decides to also connect to the source, i.e. target -> source. And this fails, endpoint is gated. This probably works with ASE environments, but for regular mortals it is not an option. Because docs mention for the remoting to work both endpoints have to be reachable. A heart breaking decision, but had to let the remoting go :(

Another take: I wanted to keep Akka and actors. Spend about a week and now have a client-server solution based on Akka.IO. It is one way: several sources and concurrently for each source an .Ask() is invoked.

Problem: aforementioned implementation works great locally and over LAN. Fails when app is published to Azure WebApp. It is known that this PaaS environment has its own specific requirements for remoting. It took a bit of googling and digging the documentation, but solution is there and it is purely config based which is nice. However, because I can't use remoting any longer, I need to be able to configure Akka.IO in the same way, but there doesn't seem to be an easy solution.

Current workaround: well, I suspected I need to disable the IPv6, same as for remoting. Removed the nuget package from projects, downloaded the sources for 1.3.10 and modified the akka.net-1.3.10 src\src\core\Akka\IO\TcpOutgoingConnection.cs file:

 public TcpOutgoingConnection(TcpExt tcp, IActorRef commander, Tcp.Connect connect)
            : base(tcp, new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp) { Blocking = false }, connect.PullMode)
        {

basically added IPv4 as the address family, referenced a local release build of Akka, republished and it worked.

Given that, I'm proposing to make the address family configurable. Not a sockets expert, but it seems there are three configuration options in this case:

IPv6IPv4Dual (default if nothing is specified)
IPv6
IPv4

which basically can be an enum property which can be passed via the Tcp.Connect instance, for example. It would be great to have this for the next version, otherwise, I will have to be running custom Akka builds :)))

Thank you!

[Aaronontheweb]

@snekbaev yeah, this sound right - Azure's PaaS environments have, for reasons that are inexplicable, have been unable to adopt IPv6 for years.

If you want to adjust the API for making the IPFamily configurable, similar to how we do it for Akka.Remote, I'm sure we'd be open to supporting that.

[snekbaev]

3684

That's what I came up with within a day.

• address family configuration is scoped to TCP and outgoing connection only. UDP version seems to be a bit more complicated and has socket creation in more places, skipped that for now. Didn't modify the listening socket because currently it assumes the address family from the endpoint directly. Which means current implementation is different from the dotnetty one, maybe at some point they can be aligned.
• DNS resolver is now configurable

Unlike the dotnetty configuration, this one is a bit different. Family can't be enforced because as mentioned earlier, current listening socket already enforces it, however, client socket by default doesn't.

Also added some comments to clarify that if outgoing socket is forced to IPv4 then DNS needs to be forced to IPv4 as well, otherwise if DnsEndPoint's primary address/fallback address or IPEndPoint's address ends up being IPv6, then exception is thrown during socket creation.

These changes are obviously opt-in.

[Aaronontheweb]

Closed via #3684