1

I am having a strange behaviour on my akka Project. To summarize: I have two Actorsystems running on my hostsystem and want to connect from one to another to send messages. Now the Problem is, when I use the following akka configuration on my client:

akka {
  actor {
    provider = remote
  }
  remote {
    enabled-transports = ["akka.remote.netty.tcp"]
    netty.tcp {
      hostname = "127.0.0.1"
      port = 0
    }
 }
}

and the following on my server actorsystem:

akka {
  loglevel = "INFO"
  actor {
    provider = "akka.remote.RemoteActorRefProvider"
  }
  remote {
    enabled-transports = ["akka.remote.netty.tcp"]
    netty.tcp {
      hostname = "127.0.0.1"
      port = 5150
    }
    log-sent-messages = on
    log-received-messages = on
  }
}

I cannot connect to my server actorsystem using an actorselection as follows:

val selection = context.actorSelection("akka.tcp://ServerSystem@0.0.0.0:5150/user/receiver")

I would expect it to work with a wildcard IP address, because it means that it tried to connect to each IPv4 the hostsystem has. I am getting following error:

[WARN] [05/06/2019 08:57:03.738] [New I/O boss #3] [NettyTransport(akka://ClientSystem)] Remote connection to [null] failed with java.net.ConnectException: Connection refused: no further information: /0.0.0.0:5150
[WARN] [05/06/2019 08:57:03.738] [ClientSystem-akka.remote.default-remote-dispatcher-13] [akka.tcp://ClientSystem@127.0.0.1:8346/system/endpointManager/reliableEndpointWriter-akka.tcp%3A%2F%2FServerSystem%400.0.0.0%3A5150-0] Association with remote system [akka.tcp://ServerSystem@0.0.0.0:5150] has failed, address is now gated for [5000] ms. Reason: [Association failed with [akka.tcp://ServerSystem@0.0.0.0:5150]] Caused by: [java.net.ConnectException: Connection refused: no further information: /0.0.0.0:5150]

On the other hand it is working just fine if I change 127.0.0.1 on the server config to 0.0.0.0 when I run it inside a docker container and connect to it using the 0.0.0.0 address in the actor selection on my client, which is running on the host. So here it seems to work binding and connecting to the wildcard IP.

Does anyone have an explanation to this behaviour?

marcels93
  • 55
  • 9

1 Answers1

1

I think this is explained by this superuser.com answer.

127.0.0.1 is a private loopback network and can only be used to connect to other processes on the same computer. So if you bind the receiving socket to that address, you will not be able to receive connections from other computers.

0.0.0.0 is a pseudo-address that has various meanings depending on context. For a server it means that the socket is available from any incoming IP address on any network. For a client it probably means the default IP address of the current machine, though this depends on how the library chooses to treat it.

Tim
  • 26,753
  • 2
  • 16
  • 29
  • Thats true and im understanding that. Still im not sure it fully explains the behaviour above. I am using my 127.0.0.1 loopback when starting the server actorsystem. But then when I am connecting from it from the same host I use 0.0.0.0 as destination. So when 0.0.0.0 is the wildcard, it should include the ipv4 loopback address and successfully connect. – marcels93 May 06 '19 at 07:37
  • `0.0.0.0` is not strictly a wildcard, but rather a default/undefined value. The Akka client will use the default IP address, which is the IP address of the default interface.This is not on the same network as `127.0.0.1` so the server will reject it. – Tim May 06 '19 at 08:50
  • While using 0.0.0.0 for a server is common, I'm not sure using 0.0.0.0 is that well defined for a client when specifying what to connect to - use a specific IP for your client, e.g. 127.0.0.1 – nos May 06 '19 at 12:02
  • It would make sense if the Client chose the default interface being my eth0, or docker NAT interface. Because the 0.0.0.0 as a target in the ActorSelection works, while the Actor is running inside a docker container but if the actor runs on localhost it wont be reachable through 0.0.0.0 – marcels93 May 06 '19 at 12:15