One of the absolute coolest things you can do in Akka.NET is remotely deploy actors over the internet to other machines. You can literally deploy code somewhere other than the immediate, local process making the call.

And the way this is accomplished is with the Akka.Remote package - it’s the module that adds remoting capabilities to our Akka.NET applications.

When Would I Want to Remotely Deploy an Actor?

There are two common scenarios for when you would want to deploy an actor remotely:

1. Work distribution - you need to be able to push work onto remote machines using a remote or clustered router. This is exactly what the Cluster.WebCrawler sample does.
2. Accessing machine-specific resources - if you wanted to gather PerformanceCounter data from an array of remote machines in order to get specific metrics from each machine, remote deployment is an effective tool for accomplishing that.

Outside of these two use cases, it’s far more efficient to contact remote actor systems via ActorSelection and remote IActorRefs than it is to work via remote deployments.

Read more

I have to level with you. Dealing with network programming in my applications has always freaked me out a little bit.

You know what I’m talking about, don’t you?

Let’s be real about it: low-level network programming is some scary shit. When you have to step beyond the nice client libraries that wrap the networking protocols, there are sharp edges that can gleefully poke you in the eye whenever you make the tiniest misstep in your code.

To put it lightly, low-level network programming has not been a very pleasant experience.

There’s Power Beyond The Pain

And yet… it’s CRAZY powerful. It’s the key to the kind of applications you want to be building in your future.

Want to create a serverless, peer-to-peer, multiplayer video game? Get ready to dive into the networking stack.

Want to build a realtime analytics system for a network of remote devices in the Internet of Things? Yeah, request/response ain’t gonna cut it.

What about creating a live trading or marketing automation system with single-digit-millisecond response times? Ciao, HTTP. It’s been fun while it lasted.

Most developers I know are THRILLED by the idea of working on applications like this. And yet for most, building applications like this seems out of reach. Somehow off the table.

WTF? What’s up with that?

An HTTP Too Far?

It’s actually very simple. The reason that bold ideas like this seem out of reach is because most of us have been conditioned to use HTTP for…wait for it…everything.

Read more

My favorite part about teaching Akka.NET to people is the questions I get. I never have any clue what someone is going to ask me, and that’s kind of exciting.

Last Thursday, we had an awesome group of developers participate in our advanced Akka.NET Design Patterns training for half the day. We covered a ton of material, but in that time, there was a basic question that came up:

When should I use an ActorSelection?

I loved this question, because there is more nuance to the seemingly mundane ActorSelection than meets the eye.

When Should I Use An ActorSelection?

The guideline I follow is to use an ActorSelection when:

1. I need to take advantage of wildcard selection in actor paths for some reason.
2. I need to communicate with an actor on a remote actor system, and I don’t have an actor reference for it yet.

Wildcard Routing

The first case when I usually use an ActorSelection is when I need to leverage wildcards in my actor paths. This is pretty rare, but one example could be if I needed to distribute a message to a number of actors who all lived at the same level in the hierarchy, or had a well-defined and predictable ActorPath.

For example, let’s imagine I had an OrderActor and needed to report on new orders to finance, marketing, and fulfillment. Let’s imagine that each of those concerns has its own hierarchy, with a NewOrderActor at the second level that is the ingestion point for new orders. It would look like this:

In this case, I could send the new order messages on to all three NewOrderActors...

Read more