Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Akka.IO and Azure WebApp connectivity issue #3679

snekbaev opened this issue Dec 18, 2018 · 3 comments


Copy link

commented Dec 18, 2018


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 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)

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!

@snekbaev snekbaev changed the title Akka.IO and Azure WebApp Akka.IO and Azure WebApp connectivity issue Dec 18, 2018

This comment has been minimized.

Copy link

commented Dec 18, 2018

@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.


This comment has been minimized.

Copy link
Contributor Author

commented Dec 20, 2018

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.

Horusiath added a commit that referenced this issue Apr 13, 2019
#3679 Add ability to disable IPv6 for DNS resolution and outgoing socket connection

This comment has been minimized.

Copy link

commented Apr 30, 2019

Closed via #3684

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
2 participants
You can’t perform that action at this time.