If you haven't read part 1 of this article series, I recommend you to do so before continuing here.

In the previous article we wrote a skeleton for the public api functions in the application context module, and set up the root supervision tree. In this part we'll focus on the "Subnet Manager" GenServer that will be responsible for launching ping request tasks for hosts in a subnet and keep track on which hosts that's up or down.

Building the Subnet manager

Let's crack out some code! 
Create a new file <highlight-mono>lib/ping_machine/subnet_manager.ex<highlight-mono> and open it up in your favorite text editor. Write or paste the following code.

defmodule PingMachine.SubnetManager do
  use GenServer

  require Logger
  require IP.Subnet

  def start_link(subnet) when IP.Subnet.is_subnet(subnet) do
    GenServer.start_link(__MODULE__, subnet, name: via_tuple(IP.Subnet.to_string(subnet)))
  end

  def init(subnet) do
    # Send a message to our self that we should start pinging at once!
    Process.send(self(), :start_ping, [])
    {:ok, %{subnet: subnet, tasks: MapSet.new()}}
  end
  
  defp via_tuple(name), do: {:via, Registry, {PingMachine.Registry, name}}
end

Let's go through what we just did here.
At the very first line we define a module called <highlight-mono>PingMachine.SubnetManager<highlight-mono>.

Next we use GenServer. Just like we need to require stuff to expand macros in other modules, the use macro injects code from other modules into ours.
This means that when we <highlight-mono>use GenServer<highlight-mono>, functions, callbacks, imports, and so on from the GenServer module will be directly accessible in our module. Good! Now, the GenServer behaviour defines certain callback functions we can implement to make it useful for us. We'll use quite a few of them, but for now we'll focus on <highlight-mono>start_link/1<highlight-mono> and <highlight-mono>init/1<highlight-mono>.

start_link/1

Technically not a GenServer callback function, but this function will be called by the DynamicSupervisor whenever we start a new SubnetManager. The only thing we'll do in this function is to actally start the <highlight-mono>PingMachine.SubnetManager<highlight-mono> GenServer by calling the <highlight-mono>GenServer.start_link/3<highlight-mono> function. This function takes the GenServer module that's to be started as the first argument, an init argument, and list of options as the third argument. By supplying __MODULE__, we pass the current module, aka <highlight-mono>PingMachine.SubnetManager<highlight-mono>, as the first argument. Next we pass subnet, which is a reference to the argument passed to the function, and finally we pass a name through the <highlight-mono>via_tuple/1<highlight-mono> function we have defined at the bottom of the file.

<info>We use via-tuples to register processes in the process storage Registry. Once the Registry is started, we can register or look up processes using a {:via, Registry, {registry, key}} tuple. As a convenience, we have defined a function to generate this tuple for us.<info>

Finally, we also use the <highlight-mono>IP.Subnet.is_subnet/1<highlight-mono> guard to ensure that the value we receive in the init argument actually is a valid subnet. Guards in Elixir are compile-time checks, so by adding this here we can be certain that this function will never be called unless the given argument passes the guard!

init/1

The <highlight-mono>init/1<highlight-mono> callback is invoked when the GenServer is started and will receive the init argument given to the <highlight-mono>GenServer.start_link/3<highlight-mono> function. Depending on return values of this function, we can make the GenServer behave in different ways, but the most common usage is to return an <highlight-mono>{:ok, state}<highlight-mono> tuple, which in turn will make the GenServer enter its event loop.
‍
We send a message to ourself using <highlight-mono>Process.send/3<highlight-mono> that we should start pinging hosts in the subnet at once. In the next section, we'll see how to respond to that message, so we'll leave it at that for now.

Then we return the <highlight-mono>{:ok, state}<highlight-mono> tuple containing the initial state for the GenServer. We use a Map to store the state, and we need to keep track of two different values:

• Subnet - We need to know what subnet we're working on so we can create ping jobs for all IP addresses in the range.
• Tasks - We'll keep a reference for all the ping jobs we'll create, and we'll use a MapSet to store them. MapSet is a data structure that can contain only unique elements, which is a good fit for the use case. Whenever we create a ping job, we add a record to the MapSet, and whenever the job reports back to us we update it with the outcome of the ping request.

GenServer recap

In the previous article we briefly talked about what GenServers are, namely processes that can keep state. This is true, but not very precise. From the documentation on GenServers:

"A GenServer is a process like any other Elixir process and it can be used to keep state, execute code asynchronously and so on. The advantage of using a generic server process (GenServer) implemented using this module is that it will have a standard set of interface functions and include functionality for tracing and error reporting."

The goal of the GenServer is to abstract away the receive loop for developers, and we never want to use <highlight-mono>receive/1<highlight-mono> inside a GenServer. Instead, the GenServer have defined callback function for us which we can implement to respond to messages being sent to it. We have four callback functions for responding to different message types.

• <highlight-mono>handle_call/3<highlight-mono> - This callback is invoked to handle synchronous messages, and will block until a reply is sent.
• <highlight-mono>handle_cast/2<highlight-mono> - Invoked to handle asynchronous messages.
• <highlight-mono>handle_continue/2<highlight-mono> - Invoked to handle :continue instructions. We will not use this, but it can be used to ie. perform some work after initialization, or splitting work for a callback in multiple steps.
• <highlight-mono>handle_info/2<highlight-mono> - This is used to handle all other messages. We will use this to start the initial ping job, and receive messages from the ping request tasks.

Okay, so now we know how to respond to messages coming in. In our <highlight-mono>init/1<highlight-mono> function earlier, we invoked <highlight-mono>Process.send(self(), :start, [])<highlight-mono> to send a message to ourself that we want to start pinging hosts in the subnet at once. This message will end up in the :info "inbox" in our GenServer, therefore we need to implement a <highlight-mono>handle_info/2<highlight-mono> callback function to capture it.

Let's see how we can blend in another ingredient to the potion.

Starting ping workers

Just below the <highlight-mono>init/1<highlight-mono> function in the <highlight-mono>lib/ping_machine/subnet_manager.ex<highlight-mono> file, add the two following functions:

<info>We don't really send any ping requests in this project. This is trivial to implement, but besides the point of the tutorial. We simply sleeps between 100 and 1000ms to simulate some network delay, then we randomly choose if the request was successful or not with approximately 2/3 success rate.<info>

defmodule PingMachine.SubnetManager do
  
  # snip

  def handle_cast({:task, host}, state) do
    task =
      Task.Supervisor.async_nolink(
        PingMachine.TaskSupervisor,   # <- We can reference the task supervisor by name
        fn ->
          # Pretends to send a ping request by sleeping some time and then
          # randomly selecting a return value for the task. Fails approx 1/3 tasks.

          Enum.random(100..1000) |> Process.sleep()
          Enum.random([:ok, :ok, :error])
        end
      )

    # Register the task in the GenServer state, so that we can track which
    # tasks responded with a successful ping request, and which didn't.
    {:noreply, %{state | tasks: MapSet.put(state.tasks, %{host: host, status: :pending, task: task})}}
  end

  def handle_info(:start_ping, state) do
    Enum.map(state.subnet, fn host ->
      GenServer.cast(
        via_tuple(IP.Subnet.to_string(state.subnet)),
        {:task, IP.to_string(host)}
      )
    end)

    {:noreply, state}
  end
  
  # snip
  
end

‍

<info>All four callback functions for the GenServer is passed the GenServers own state as the last argument. This is useful in order to inspect and access the current state. All four callbacks are also expected to return a state; either the same or a new.<info>

handle_info/2

We'll start with this function since that's where the message sent in <highlight-mono>init/1<highlight-mono> ends up. In the function signature we can see that the function takes two arguments. The first being an atom :start_ping, and the next being the GenServer state.
Let's use this callback to fire off a new ping job for every IP address in the subnet range. Since we were clever enough to store the subnet in the state, it's easy for us to access it here. As we already know, the subnet value we have stored on the state is a valid subnet. Not only that, it is actually a pretty clever subnet. It is a <highlight-mono>IP.Subnet<highlight-mono> struct which implements the Enumerable protocol.

<info>In object oriented programming languages we often use inheritance to achieve polymorphism. Elixir uses a concept called Protocols to achieve polymorphism when we want certain behaviours depending on the type of data we're working with.<info>

The <highlight-mono>IP.Subnet<highlight-mono> struct is able to generate a list of all IP addresses in the subnet range just by us iterating over it, which is why we can pass it directly to Enum.map/2. This function takes an iterable, and a function that should be applied to all elements in the iterable.

This is pretty straight forward. We iterate over all hosts in the subnet range. For each host we invoke <highlight-mono>GenServer.cast/2<highlight-mono>, passing the "via-tuple" reference for ourself as the first argument, and <highlight-mono>{:task, host}<highlight-mono> tuple as the message. Now, since we use the <highlight-mono>GenServer.cast/2<highlight-mono> function, we are sending all these messages asynchronously, and don't care about waiting for a reply. Once we're through the list, we send a <highlight-mono>{:noreply, state}<highlight-mono> response.

handle_cast/2

Since we used <highlight-mono>GenServer.cast/2<highlight-mono> to send the message, we need to implement <highlight-mono>handle_cast/2<highlight-mono> to receive the message.

We define a <highlight-mono>handle_cast/2<highlight-mono> function where the first parameter matches the argument we passed in the <highlight-mono>handle_info(:start_ping, state)<highlight-mono> function. The last argument is the GenServer state as always.
This function will receive a message - one for each host in the subnet range. So for each time we receive a message in this function, we spawn a new Task using the <highlight-mono>Task.Supervisor.async_nolink/2<highlight-mono> function. We pass the <highlight-mono>PingMachine.TaskSupervisor<highlight-mono> as the first argument, and defines a function that is to be executed in the task as the second argument. The return value is a Task struct which contains some information about the process we just spawned.

%Task{
  owner: #PID<0.782.0>,
  pid: #PID<0.1019.0>,
  ref: #Reference<0.1338424894.999096325.136017>
}

Since the <highlight-mono>handle_cast/2<highlight-mono> callback function is called asynchronously, we don't actually respond with a value. This is indicated by using the :noreply atom in the return value. We update the state by adding the newly created task, along with the host and a :pending status.

{:noreply, %{state | tasks: MapSet.put(state.tasks, %{host: host, status: :pending, task: task})}}

Remember that we don't have a return keyword in Elixir. Elixir functions always returns the last evaluated statement in the function. That means that for our ping job function, the return value will be either an :ok or :error atom. Now it's about time to implement some callback functions to capture the outcome of the ping jobs so that we can keep track of successful and failed requests.

Collecting results from ping workers

The potency of our brew is growing stronger! However, there's still a few ingredients missing.

We need a way to figure out which ping jobs succeeded and which failed. All Tasks we spawn from the <highlight-mono>PingMachine.SubnetManager<highlight-mono> GenServer will send back :info messages with the outcome of the job they have performed. Therefore we need to add some <highlight-mono>handle_info/2<highlight-mono> callback functions that can respond to those messages. Messages will be sent in the format {ref, response}, where the ref is a reference to the Task process, and response is whatever return value the process evaluated to.

Just below the previous <highlight-mono>handle_info/2<highlight-mono> callback function, add the following:

  # snip
  
  # The ping request succeeded
  def handle_info({ref, :ok}, state) do
    task =
      Enum.find(state.tasks, fn %{host: _host, status: _status, task: %{ref: r}} -> r == ref end)

    Logger.info("Successfully pinged host #{task.host}")

    # We don't care about the :DOWN message from the task anymore, so demonitor
    # and flush it.
    Process.demonitor(ref, [:flush])

    updated_tasks =
      MapSet.delete(state.tasks, task)
      |> MapSet.put(Map.put(task, :status, :success))

    {:noreply, %{state | tasks: updated_tasks}}
  end

This is the callback function for successful ping requests. As stated above, we pattern match the function signature on the <highlight-mono>{ref, :ok}<highlight-mono> return value from the Task. In Elixir we can use pattern matching on function arguments (combined with function arity) as control flow mechanisms. In our case that means that both successful and failed ping jobs will deliver their results to separate functions. As a result we get small and clean functions which can focus on a single task. As always, we also receive the GenServer state so we can update the outcome of the current ping job.
To find the correct job to update state for, we simply pass it through Enum.find/3 and compare the ref argument with Task references we already have stored in the state. Next, add a log message for good measures, and then demonitor the process.

In Elixir we have different methods of binding processes together. One method is linking, which is bidirectional. If a linked process dies, all processes linked to it is doomed. It doesn't matter which process dies first, it's going to be a massacre and they all die!
Monitoring on the other hand, is unidirectional. A process can monitor other processes, and be notified of what's going on with them. If they die, the monitoring process might be a bit sad, but not much else.

All Tasks are monitored by default. That's how we're being notified when they are done processing their job. So when the ping job has reported that it's done with a successful outcome, we can demonitor it; we don't really care about it anymore and don't need to receive any more messages from it.
Finally we build a new task list by deleting the current task from the state, and add it back again with an updated :success status.

Next up is the callback function for failed ping requests. It's almost identical to the success function, so I won't go into much details here. Add it below the function we just wrote.

  # snip
  
  # The ping request failed
  def handle_info({ref, :error}, state) do
    task =
      Enum.find(state.tasks, fn %{host: _host, status: _status, task: %{ref: r}} -> r == ref end)

    Logger.error("Failed to ping host #{task.host}")

    Process.demonitor(ref, [:flush])

    updated_tasks =
      MapSet.delete(state.tasks, task)
      |> MapSet.put(Map.put(task, :status, :failed))

    {:noreply, %{state | tasks: updated_tasks}}
  end

Again, we pattern match on <highlight-mono>{ref, :error}<highlight-mono>,  demonitor the process and return a :noreply tuple with the updated state.

One last piece of the puzzle. Remember all Tasks are monitored? That means that if the Task itself fails, it will deliver a <highlight-mono>{:DOWN, ref, :process, pid, reason}<highlight-mono>. Let's add a callback function to catch those messages just in case.
In this final callback function we have the opportunity to handle crashed processes. We could add a log message, try to reschedule it or some other wizardry. But, since this application only sends ping requests, a missed host once in a while is probably not that big of a deal, so we'll just capture the message and do nothing.

Add this just below the :error callback function.

  # snip
  
  # The task itself failed
  def handle_info({:DOWN, _ref, :process, _pid, _reason}, state) do
    {:noreply, state}
  end

‍

Listing results

The final pieces of the <highlight-mono>PingMachine.SubnetManager<highlight-mono> is to add functionality so we can list successful and failed hosts for a given ping scan. We'll continue the path using callback functions, but these two functions need to actually return some data. Therefore we're going to use the <highlight-mono>handle_call/3<highlight-mono> callback functions for these.

They are simple enough; to list all hosts which succeeded the ping request, filter the GenServer state for all tasks with :success status and return their host attribute. For failed requests, filter by :failed status.

Add the following callback functions right after the <highlight-mono>init/1<highlight-mono> function near the top of the file.

  # snip
  
  def handle_call(:successful_hosts, _from, state) do
    success =
      Enum.filter(state.tasks, fn task -> task.status == :success end)
      |> Enum.map(fn task -> task.host end)

    {:reply, success, state}
  end

  def handle_call(:failed_hosts, _from, state) do
    failed =
      Enum.filter(state.tasks, fn task -> task.status == :failed end)
      |> Enum.map(fn task -> task.host end)

    {:reply, failed, state}
  end

  # snip

The <highlight-mono>handle_call/3<highlight-mono> callback functions takes 3 arguments; a message - we're just passing either a :successful_hosts or :failed_hosts atom for this, a from argument - a tuple containing the PID and the reference of the calling process, and of course the GenServers own state (as always). Since we don't really care about who the caller is, we prefix the from argument with an underscore, indicating that we won't access that variable.
For each respective function, filter out the data we're interested in from the state and return a <highlight-mono>{:reply, response, state}<highlight-mono> tuple.

That concludes our ping machine! I you wish to take a look at the original file, it's right here!

Refactoring the context module

It's time to refactor the context module so that the "public api" for the application actually do something. Open the <highlight-mono>lib/ping_machine.ex<highlight-mono> file in your text editor and refactor the <highlight-mono>start_ping/1<highlight-mono> function first.

  # snip
  
  def start_ping(subnet) when is_binary(subnet) do
    with {:ok, subnet} <- IP.Subnet.from_string(subnet),
         {:ok, pid} <- start_worker(subnet) do
      Logger.info("Started pinging all hosts in range #{IP.Subnet.to_string(subnet)}")
      {:ok, pid}
    else
      {:error, {:already_started, pid}} ->
        Logger.warn("Already running the #{subnet} range")
        {:ok, pid}

      {:error, :einval} = reply ->
        Logger.error("#{subnet} is not a valid subnet range")
        reply
    end
  end

  # snip
  
  # Add this function at the bottom of the module (before the last "end").
  defp start_worker(subnet) when IP.Subnet.is_subnet(subnet) do
    DynamicSupervisor.start_child(
      PingMachine.PingSupervisor,
      {PingMachine.SubnetManager, subnet}
    )
  end
end

We replace the <highlight-mono>case .. do<highlight-mono> statement with a <highlight-mono>with .. do<highlight-mono> statement. The with statements continue execution down the happy-path as long as each condition is true. If any condition fails we move down to the else block, and can pattern match on whatever values we got, then act accordingly.
So as long as we receive <highlight-mono>{:ok, subnet}<highlight-mono> from <highlight-mono>IP.Subnet.is_subnet/1<highlight-mono> and we receive <highlight-mono>{:ok, pid}<highlight-mono> from <highlight-mono>start_worker/1<highlight-mono> we log a message "Started pinging..." and returns <highlight-mono>{:ok, pid}<highlight-mono>. If any of those failed, we can log an error message telling the user what's wrong and return an appropriate return value.

As for the more mysterious <highlight-mono>start_worker/1<highlight-mono> private function, this is where we start up new <highlight-mono>PingMachine.SubnetManagers<highlight-mono> running under the DynamicSupervisor we talked about earlier. We also pass the subnet as the init-argument to the GenServer, so it know what subnet it'll be working on. This function will return the process id of the SubnetManager it just started, which is what we captured in the <highlight-mono>start_ping/1<highlight-mono> function above. We'll use this pid for further communication with the GenServer.

Now, for the <highlight-mono>stop_ping/1<highlight-mono> function, we'll refactor it to take a pid as argument instead of the subnet string. We can then pass the pid to the <highlight-mono>DynamicSupervisor.terminate_child/2<highlight-mono> to stop a child process running under it.

  # snip
  
  def stop_ping(pid) when is_pid(pid) do
    DynamicSupervisor.terminate_child(PingMachine.PingSupervisor, pid)
  end

  # snip

‍

For the last two functions in our context module, they will list out either successful or failed hosts.

  # snip
  
  def get_successful_hosts(pid) when is_pid(pid) do
    GenServer.call(pid, :successful_hosts)
  end

  def get_failed_hosts(pid) when is_pid(pid) do
    GenServer.call(pid, :failed_hosts)
  end

  # snip

These functions also takes a pid as their only arguments, and sends a message to the <highlight-mono>PingMachine.SubnetManager<highlight-mono> GenServer with that process id. Since we're using <highlight-mono>GenServer.call/3<highlight-mono>, the messages will be received in the <highlight-mono>handle_call/3<highlight-mono> callback functions with matching signatures.

Here's a link to the final version of the context module.

Running ping scans

Let's try to fire off a ping scan. Open a terminal and launch the interactive Elixir shell using the <highlight-mono>iex -S mix<highlight-mono> command:

$ iex -S mix
Erlang/OTP 24 [erts-12.1] [source] [64-bit] [smp:12:12] [ds:12:12:10] [async-threads:1] [jit]

Compiling 2 files (.ex)
Interactive Elixir (1.13.0) - press Ctrl+C to exit (type h() ENTER for help)
iex(1)>

Start a new ping scan:

iex(1)> {:ok, pid} = PingMachine.start_ping("192.168.1.0/24")
00:29:40.079 [info]  Started pinging all hosts in range 192.168.1.0/24
{:ok, #PID<0.225.0>}
00:29:40.205 [info]  Successfully pinged host 192.168.1.74
00:29:40.205 [info]  Successfully pinged host 192.168.1.168
00:29:40.215 [info]  Successfully pinged host 192.168.1.232
00:29:40.226 [error] Failed to ping host 192.168.1.180
00:29:40.228 [info]  Successfully pinged host 192.168.1.28
00:29:40.230 [info]  Successfully pinged host 192.168.1.97
00:29:40.230 [error] Failed to ping host 192.168.1.254
...

Awesome! Let's try to list out some results.

iex(2)> PingMachine.get_successful_hosts(pid)
["192.168.1.79", "192.168.1.161", "192.168.1.50", "192.168.1.117",
 "192.168.1.235", "192.168.1.72", "192.168.1.22", "192.168.1.44",
 "192.168.1.211", "192.168.1.144", "192.168.1.25", "192.168.1.246",
 "192.168.1.99", "192.168.1.172", "192.168.1.39", "192.168.1.96",
 "192.168.1.145", "192.168.1.158", "192.168.1.141", "192.168.1.218",
 "192.168.1.13", "192.168.1.228", "192.168.1.76", "192.168.1.69",
 "192.168.1.62", "192.168.1.74", "192.168.1.9", "192.168.1.229", "192.168.1.91",
 "192.168.1.148", "192.168.1.159", "192.168.1.220", "192.168.1.27",
 "192.168.1.165", "192.168.1.248", "192.168.1.169", "192.168.1.168",
 "192.168.1.197", "192.168.1.130", "192.168.1.156", "192.168.1.83",
 "192.168.1.107", "192.168.1.97", "192.168.1.95", "192.168.1.49",
 "192.168.1.29", "192.168.1.217", "192.168.1.35", "192.168.1.149",
 "192.168.1.102", ...]
 
iex(3)> PingMachine.get_failed_hosts(pid)
["192.168.1.14", "192.168.1.241", "192.168.1.207", "192.168.1.2",
 "192.168.1.238", "192.168.1.16", "192.168.1.162", "192.168.1.87",
 "192.168.1.112", "192.168.1.7", "192.168.1.208", "192.168.1.71",
 "192.168.1.230", "192.168.1.115", "192.168.1.200", "192.168.1.5",
 "192.168.1.34", "192.168.1.61", "192.168.1.146", "192.168.1.147",
 "192.168.1.167", "192.168.1.32", "192.168.1.92", "192.168.1.20",
 "192.168.1.81", "192.168.1.15", "192.168.1.223", "192.168.1.202",
 "192.168.1.109", "192.168.1.68", "192.168.1.151", "192.168.1.198",
 "192.168.1.160", "192.168.1.6", "192.168.1.190", "192.168.1.210",
 "192.168.1.251", "192.168.1.126", "192.168.1.201", "192.168.1.101",
 "192.168.1.19", "192.168.1.231", "192.168.1.88", "192.168.1.193",
 "192.168.1.82", "192.168.1.245", "192.168.1.57", "192.168.1.128",
 "192.168.1.65", "192.168.1.153", ...]
iex(4)>

Pretty good. Now, if you try to start another scan on the same subnet you should receive a warning. We can stop it using <highlight-mono>PingMachine.stop_ping/1<highlight-mono>.

iex(5)> {:ok, pid} = PingMachine.start_ping("192.168.1.0/24")
00:38:55.910 [warning] Already running the 192.168.1.0/24 range
{:ok, #PID<0.225.0>}
iex(6)> PingMachine.stop_ping(pid)
:ok

So let's run multiple ping scans in parallel!

iex(7)> results = ["192.168.1.0/24", "192.168.2.0/24", "192.168.3.0/24"] |> Enum.map(&PingMachine.start_ping/1)
00:43:06.175 [info]  Started pinging all hosts in range 192.168.1.0/24
00:43:06.175 [info]  Started pinging all hosts in range 192.168.2.0/24
00:43:06.176 [info]  Started pinging all hosts in range 192.168.3.0/24
[ok: #PID<0.495.0>, ok: #PID<0.496.0>, ok: #PID<0.497.0>]
00:43:06.278 [info]  Successfully pinged host 192.168.1.40
00:43:06.279 [error] Failed to ping host 192.168.2.27
00:43:06.280 [info]  Successfully pinged host 192.168.3.37
00:43:06.281 [info]  Successfully pinged host 192.168.1.73
00:43:06.282 [info]  Successfully pinged host 192.168.1.113
00:43:06.284 [error] Failed to ping host 192.168.3.136
00:43:06.287 [error] Failed to ping host 192.168.3.28
00:43:06.288 [info]  Successfully pinged host 192.168.1.15
00:43:06.289 [info]  Successfully pinged host 192.168.2.41
00:43:06.290 [info]  Successfully pinged host 192.168.1.3
00:43:06.291 [info]  Successfully pinged host 192.168.3.25
00:43:06.291 [info]  Successfully pinged host 192.168.1.198
00:43:06.294 [info]  Successfully pinged host 192.168.1.242
00:43:06.295 [info]  Successfully pinged host 192.168.3.105
...

And get the successful hosts...

iex(8)> results |> Enum.reduce([], fn {:ok, pid}, acc -> [PingMachine.get_successful_hosts(pid) | acc] end)
[
  ["192.168.3.162", "192.168.3.41", "192.168.3.196", "192.168.3.21",
   "192.168.3.200", "192.168.3.234", "192.168.3.32", "192.168.3.155",
   "192.168.3.183", "192.168.3.100", "192.168.3.122", "192.168.3.129",
   "192.168.3.191", "192.168.3.123", "192.168.3.202", "192.168.3.111",
   "192.168.3.165", "192.168.3.105", "192.168.3.73", "192.168.3.60",
   "192.168.3.135", "192.168.3.106", "192.168.3.35", "192.168.3.22",
   "192.168.3.5", "192.168.3.224", "192.168.3.204", "192.168.3.251",
   "192.168.3.157", "192.168.3.150", "192.168.3.6", "192.168.3.110",
   "192.168.3.153", "192.168.3.137", "192.168.3.237", "192.168.3.24",
   "192.168.3.253", "192.168.3.59", "192.168.3.186", "192.168.3.198",
   "192.168.3.233", "192.168.3.77", "192.168.3.228", "192.168.3.184",
   "192.168.3.54", "192.168.3.43", "192.168.3.241", "192.168.3.4",
   "192.168.3.23", ...],
  ["192.168.2.128", "192.168.2.216", "192.168.2.207", "192.168.2.240",
   "192.168.2.20", "192.168.2.217", "192.168.2.165", "192.168.2.249",
   "192.168.2.50", "192.168.2.124", "192.168.2.183", "192.168.2.63",
   "192.168.2.214", "192.168.2.43", "192.168.2.54", "192.168.2.151",
   "192.168.2.39", "192.168.2.87", "192.168.2.37", "192.168.2.116",
   "192.168.2.149", "192.168.2.125", "192.168.2.150", "192.168.2.120",
   "192.168.2.72", "192.168.2.74", "192.168.2.212", "192.168.2.11",
   "192.168.2.177", "192.168.2.206", "192.168.2.182", "192.168.2.164",
   "192.168.2.107", "192.168.2.2", "192.168.2.162", "192.168.2.56",
   "192.168.2.233", "192.168.2.237", "192.168.2.235", "192.168.2.84",
   "192.168.2.46", "192.168.2.111", "192.168.2.187", "192.168.2.178",
   "192.168.2.224", "192.168.2.152", "192.168.2.98", "192.168.2.38", ...],
  ["192.168.1.16", "192.168.1.122", "192.168.1.46", "192.168.1.30",
   "192.168.1.120", "192.168.1.107", "192.168.1.6", "192.168.1.230",
   "192.168.1.23", "192.168.1.163", "192.168.1.246", "192.168.1.145",
   "192.168.1.188", "192.168.1.10", "192.168.1.139", "192.168.1.166",
   "192.168.1.80", "192.168.1.42", "192.168.1.106", "192.168.1.238",
   "192.168.1.201", "192.168.1.211", "192.168.1.183", "192.168.1.52",
   "192.168.1.124", "192.168.1.49", "192.168.1.31", "192.168.1.93",
   "192.168.1.222", "192.168.1.4", "192.168.1.119", "192.168.1.17",
   "192.168.1.40", "192.168.1.126", "192.168.1.89", "192.168.1.202",
   "192.168.1.2", "192.168.1.208", "192.168.1.82", "192.168.1.253",
   "192.168.1.160", "192.168.1.95", "192.168.1.81", "192.168.1.249",
   "192.168.1.200", "192.168.1.180", "192.168.1.20", ...]
]

‍

Great! We can inspect our supervision tree in Beam observer by running <highlight-mono>:observer.start<highlight-mono> and clicking the "Applications" tab.

‍

Summary

This concludes the tutorial. We have built a concurrent network pinger from scratch using the Elixir programming language. We have used core OTP behaviours like Supervisors, GenServers and Tasks to run concurrent ping jobs in parallel, and built a simple interface for communicating with them.

If you have any comments or questions, please reach out to me at rolf.havard.blindheim@intility.no.