Remoting actor

[zio]

Remoting actor

[mtsokol]

@softinio @mijicd Sure, I also think that we can close this issue as you explained.

[mtsokol]

@jdegoes @mijicd Hi, I'm thinking about trying to start it.

Recently I've been working on zio-nio mdoc microsite and did a draft use case page "remoting zio actors" with stub remote actors and sending messages via AsynchronousSocketChannel.

I've looked into akka-remote and akka-typed and have some thoughts right now, mostly based on them.

So for zio-remote there would be to do:

1. Introduce ActorSystem that takes as parameter some Stateful (like akka-typed because it's also an actor) with optional arguments host and port (or defined in application.conf), that if present it opens internal ServerSocketChannel that listens on messages.
2. Make actors spawning possible only within an actor (actor will contain context for spawning actors like akka-remote. Every spawn will also register in context (ActorSystem) so the incoming messages can be routed across actor tree)
3. All actors have to be named
4. Like akka-remote let's give to ActorSystem (so as well to context) an actorSelection(uri: String) method for creating stubs for remote actors. Internally it opens SocketChannel for sending messages to some remote ActorSystem for some actor name (like "zio.tcp://[email protected]:2552/myActor1").
5. As mentioned there will be serialization module, like in akka.serialization but I'm still diving into it. The middleware protocol would send a tuple (message, actorName) so after ActorSystem receives messages it also gets target actor, which can be found if registered via context.

Is it doable? Is such design acceptable?

[softinio]

@mtsokol Is this issue still relevant?

[mijicd]

I vote for closing this one, as we have basic remoting in place. More specific issues should be opened for tackling some deficiencies in the current implementation, but the foundation is there.

@mtsokol what do you think?