Getting Akka.NET to connect to a remote addresses

Question

All the demos I have found showing how to get started with remoting in Akka.NET demonstrate the simplest use case where the two actors are running on the same machine using localhost.

I am trying to get an Akka.NET actor to connect to a remote machine and have run into some difficulty.

The code is extremely simple:

Client Code:

var config = ConfigurationFactory.ParseString(@"
    akka {  
        log-config-on-start = on
        stdout-loglevel = DEBUG
        loglevel = DEBUG
        actor {
            provider = ""Akka.Remote.RemoteActorRefProvider, Akka.Remote""

            debug {  
                receive = on 
                autoreceive = on
                lifecycle = on
                event-stream = on
                unhandled = on
            }

            deployment {
                /remoteactor {
                    router = round-robin-pool
                    nr-of-instances = 5
                    remote = ""akka.tcp://[email protected]:666""
                }
            }
        }
        remote {
            dot-netty.tcp {
                port = 0
                hostname = localhost
            }
        }
    }
");

using (var system = ActorSystem.Create("system1", config))
{
    Console.ReadLine();
}

Server Code:

var config = ConfigurationFactory.ParseString(@"
akka {  
    log-config-on-start = on
    stdout-loglevel = DEBUG
    loglevel = DEBUG
    actor {
        provider = ""Akka.Remote.RemoteActorRefProvider, Akka.Remote""

        debug {  
            receive = on 
            autoreceive = on
            lifecycle = on
            event-stream = on
            unhandled = on
        }
    }
    remote {
        dot-netty.tcp {
            transport-protocol = tcp
            port = 666
            hostname = ""10.0.0.4"" //This is the local IP address 
        }
    }
}
");

using (ActorSystem.Create("system2", config))
{
    Console.ReadLine();
}

I can successfully connect when I run the actor process on another machine on my local network but when I distribute the same simple example onto a cloud VM I receive the following error:

[ERROR][11/9/2017 3:58:45 PM][Thread 0008][[akka://system2/system/endpointManager/reliableEndpointWriter-akka.tcp%3A%2F%2Fsystem1%40localhost%3A28456-1/endpointWriter#1657012126]] Dropping message [Akka.Remote.DaemonMsgCreate] for non-local recipient [[akka.tcp://[email protected]:666/remote]] arriving at [akka.tcp://[email protected]:666] inbound addresses [akka.tcp://[email protected]:666]
Cause: Unknown

I have also tried using "127.0.0.1" but that doesn't seem to work either locally or over the net.

Could anyone provide any input on what I might be doing wrong?

UPDATE:

I have tried to use the bind-hostname and bind-port options available in Akka.NET as this is supposed to get around the NAT issues I believe I am suffering. Unfortunately this doesn't seem to work either, I have tried various configuration options such as using the hostname and IP address as shown below:

remote {
    dot-netty.tcp {     
        port = 666
        hostname = "13.73.xx.xx"

        bind-port = 666
        bind-hostname = "0.0.0.0"

    }
}

The error message I receive when I try the above configuration is:

[ERROR][11/12/2017 5:19:58 AM][Thread 0003][Akka.Remote.Transport.DotNetty.TcpTransport] Failed to bind to 13.73.xx.xx:666; shutting down DotNetty transport.
Cause: System.AggregateException: One or more errors occurred. ---> System.Net.Sockets.SocketException: The requested address is not valid in its context

Answer 1

A few remarks:

In your server config have it bind to 0.0.0.0. (hostname = 0.0.0.0) This way the socket will bind to all local endpoints, in case your cloud hosted env uses multiple network endpoints. Then use set the public-hostname = xxx.australiasoutheast.cloudapp.azure.com. This way the hostname for the server instance is the same as the remoting address you are using in your remoting url.

Do note that the public-hostname (and hostname, if you are not using public-hostname) must be DNS resolvable.