Remote systems cannot be ignored. They are the heart of actor programming. The ability of an actor application to smoothly scale out geographically is a tremendous advantage in meeting the challenges of growth. Today we will learn the basics of setting up for remote interaction between actors. If you wish to set up to try coding a set of remote actor systems and do not as yet have a development environment see either of the last two posts for directions.

Actor Paths and Actor References

In previous exercises we have exclusively used the class ActorRef to instantiate actor references that enable messaging between actors. This works for a local actor system but does not extend to remote actor systems. An actor reference is an object that refers to a living instance of an actor object. When an actor ceases to exist all actor references to it become invalid. An actor path is different. An actor path defines a way to send a message to an actor. The existence of an actor path says nothing about whether or not there is a live actor residing at the end of the path. An analog to an actor path is a land line telephone number to a service at a certain house address. You can call anytime. Someone may or may not be home to receive your call. But in either case the phone number is still valid. Actor paths are the same way. An understanding of actor paths is key to understanding both the configuration and application coding of remote actors systems.

Actor Paths in Detail

An actor path is implemented as an ordinary text string. An actor path may be absolute or relative. Here is an example absolute actor path specifying an IP address that is not in service.


Let's take this apart.


Transport Specifier

First we have "akka.tcp://". This is always