AkkaNetworkPing

Initial state

In the initial version, only an Actorsystem (name Akka-Network-Ping) is created.

No Actors are created yet, but there's a command line parser that accepts the following commands from the command-line:

[pingerCount] pi|ping [pingCount] [pingInterval]
s|status
q|quit

The ping (alias pi) will, in a subsequent exercise, create pingerCount Pinger actor(s) that will ping a single PingServer actor. The PingServer actor should respond to a Ping message with a Response message to the actor who sent the Ping message.

In this state of the application, messages are logged at INFO level.

Note that the logging output is directed to a log file named pingpong.log in the project's root folder.

The overall Actor hierarchy will looks as follows:

                            /user
                              |
                     /PingResponseCoordinator
                              |
            +-----------------+----------------+
            |                                  |
       /pingMaster                           /pingServer
            |
  +---------+---------+---------+
  |         |         |         |
/pinger1   /pinger2    ...      /pingerN

In the first exercise, you will set-up actors PingResponseCoordinator, PingMaster, Pinger and PingServer.

Exercise 1

In this exercise, you will define four actors, PingResponseCoordinator, PingMaster, Pinger and PingServer, each with an empty behaviour and a definition of the messages, Ping and Response, relevant to the protocol we want to implement.

Your tasks:

1. Change the behaviour of the PingServer actor so that when it receives a Ping message, it responds to the sender of the message with a Response message. Note that both messages carry extra information:

• sequenceNumber: a number that is unique for each Ping message for a particular Ping actor.

2. In the Response response, the value of ref contained in the Ping message should be copied as-is.

3. Change the behaviour of the Pinger actor so that, after creation, it will send pingCount Ping messages to the PingServer actor. The sequenceNumber should be incremented between subsequent Ping messages. For the time being, ignore pingInterval: just send the messages in rapid succession.

4. Change the PingResponseCoordinator actor. When an instance of this actor is created, it should create a PingServer and a PingMaster actor as children. Name these actors pingServer and pingMaster respectively.

5. When PingResponseCoordinator receives a CreatePinger message, it should forward this message to the PingMaster actor.

6. Create the PingResponseCoordinator actor in PingResponseApp (look for the TODO in the code).

7. Change the PingMaster behaviour as to create a Pinger child actor when it receives a CreatePinger message.

8. Adapt the createPinger method in the PingResponseApp (look for the TODO in the code) as to send the appropriate messages to the right actor so that the requested number of Pinger actors are created.

9. Run the application, run some ping commands and verify that the output is what is expected.

Exercise 1 - Solution and discussion

This code implements a solution for the stated tasks. However, some questions may be raised:

• How to implement the pingInterval behaviour - when pingCount > 1: the first Ping should be sent immediately and subsequent Ping messages should be sent sequentially at pingInterval intervals.

• In the current application, there's an obvious memory leak: Ping actors are created and, after having performed their task, are never stopped...

• A number of tests have been added to the project that test the functionality of the Pinger and PingServer actors.

##Exercise 2 - Implementing pingInterval

1. Change Pinger to send the Ping messages at the specified interval. Have a look at an actor's access to the scheduler (context.system.scheduler.*). Note that we always send pingCount messages, i.e. regardless of the number of Response messages that are sent back in response.

2. Fix the memory leak, for example, let the Ping actor stop itself when it has done its job. For this, look at what's available under the actor's context.

##Exercise 2 - Solution & discussion

The sending of Ping messages at regular intervals can be implemented in many ways... In the given solution, the Pinger actor uses the scheduler to schedule delivery of the required Ping messages to itself at the right moment.

• Also note the utilisation of context.stop(self) to stop the Pinger actor.

• Notice the need to bring an (implicit) execution scope into context - this is needed by the scheduleOnce method

##Exercise 3 - Introduce reaction time in PingServer actor

In this exercise, we will let PingServer actor respond to Ping messages with a delay configurable in the application config settings. Change the signature of the PingServer actor as to accept this delay parameter of type FiniteDuration.

Name the configuration parameter AkkaNetworkPing.Response.responseDelay

Perform some ping tests with the responseDelay set to 2 seconds. What is the impact on the behaviour of the application? What is causing this effect?

##Exercise 3 - Solution & discussion

In the proposed solution, we make sure that the PingServer actor is really busy while responding to a Ping. We do this by ignoring any incoming message during during the processing of the Ping. In order to achieve this, we utilise the Akka Stash trait.

##Exercise 3 - Solution - Alternative Pinger implementation

An alternative for the utilisation of mutable state in the Pinger actor.

##Exercise 4 - Scale the PingServer actor

As observed during some testing, the single instance of the PingServer actor has become a limiting factor for the ping-pong throughput.

Use a pooled router with round-robin routing strategy configured via Akka configuration to scale the app.

##Exercise 4 - Solution & discussion

Making the Akka-Network-Ping scale can be achieved by removing the bottleneck in the PingServer actor by turning it into a pooled router. Notice the elegance by which this can be done: a simply change in the deployment configuration and a change on one line in the source code.

##Exercise 5 - Introduction of an unreliable PingServer actor

Let's make PingServer a bit unreliable by having it not send a reply to a Ping message at random:

• Define a configuration parameter named AkkaNetworkPing.Response.reliability with a value between 0 and 100.
• Change the signature of PingServer as to accept the reliability parameter of type Int.
• Change the behaviour of PingServer so that when it receives a Ping, it throws a dice by generating a random number between 0 and 100. If this number is greater than reliability, respond. Otherwise, ignore the message and continue waiting for a new Ping.