Proto.Actor V2 wishlist

[rogeralsing]

• [x] Remove Routers
• [x] Remove Persistence - use whatever lib you want
• [x] Merge all ibs into one. no use to having Proto.Remote as a separate lib
• [ ] Remove static Logging factory - make better use of DI
• [ ] async Send, which does not thread block on bounded mailbox queues
• [ ] IdentityLookup strategies per ClusterKind
• [ ] Ability to check if a virtual actor is activated, and where
• [ ] Remove Supervision (Cool features, but not much use in virtual actors, routers could still exist in library form)
• [ ] Built-in WebSocket bridge (e.g. for OCPP or similar)
• [ ] More built-in cluster Context strategies. retries are nice in some cases, but should not be the default
• [ ] Tweak default Remote retry reconnects. mostly not useful to retry 8 times over a long period of time
• [ ] Support typed local actors, much like grains

WiP PR https://github.com/asynkron/protoactor-dotnet/pull/1979

Feel free to add your own ideas

[juliolitwin]

Hey @rogeralsing,

Would adding support for (R)UDP/KCP be viable to the project, or would it be reinventing the wheel? Since compared to gRPC, in a perfect world, KCP for example, would give greater performance.

[rogeralsing]

@juliolitwin interesting. have you worked with KCP? can you send bytearrays and receive them as a single block, or do I have to do manual framing etc?

[juliolitwin]

@rogeralsing when you refer to single block, are you referring to which block that sends, would receive the packet as async/await or callback? If so, it really is manual.

If my memory serves me right, the ET project, made this implementation in his actor to make that both ways.

[marcinbudny]

Hi @juliolitwin , can you explain the use case where KCP support in proto.actor would make sense? AFAIK KCP focuses on reducing the latency over unreliable networks. Do you deploy in scenarios where cluster members are talking to each other over unreliable network?

[WoLfulus]

I'd love to see compatibility with Unity (client at least). ~Some libraries has proper targets, but some doesn't.~ ~For example, I'm able to reference Proto.Actor but not Proto.Cluster (missing netstandard target).~

Edit: I now know why exactly Proto.Cluster doesn't have a netstandard target (AspnetCore dependency), but would be nice to at least have a way to communicate with the cluster from a netstandard2.x client.

Also, https://github.com/asynkron/protoactor-dotnet/issues/1432

[marcinbudny]

@WoLfulus We were actually thinking about dropping netstandard2.1 support from the framework and requiring at least netcoreapp3.1 everywhere. Are you currently using proto.actor inside Unity projects? Can you describe the use case?

[WoLfulus]

@marcinbudny We're building an MMO with proto.actor. We use it to maintain the persistent world state across different zones, in which each zone is an unity dedicated server instance. Player session handoffs occurs very frequently between zone servers when a player passes through a portal (zone a -> zone b), and when the connection is made, the state if fetched from the cluster, which also acts as a "smart cache" to avoid hitting the database. Actors will eventually persist the state to the database, but most of them lives in-mem as an actor.

Some services also lives within the cluster as an actor (like zone server discovery, account status, authentication, character management, global chat and more).

[marcinbudny]

@WoLfulus that sounds awesome, thanks for sharing.

From what you wrote before I assume you'd like to connect the game client directly to the cluster. Proto.Cluster has a concept of "client members" however that requires the client to access the membership provider (e.g. connect to Consult or Kubernetes API) so it's not really feasible to have game clients as client members of the cluster. Normally, you would communicate client applications with the cluster over some form of an API, e.g. gRPC or REST.

So assuming you would be connecting to the cluster over an API, is there still a need to reference proto.actor libraries from a Unity project?

[WoLfulus]

@marcinbudny It's not a game clients (used by players), it's a dedicated server instance (different build type) that is also developed in Unity but hosted only by us - it's a completely different thing. The "game client" only connects to this dedicated server instance, in which offloads state to the Proto.Actor cluster.

  Unity        Unity           .NET6
[ Game ] <-> [ Server ] <-> [ Cluster ]
                         ^- Missing client libraries

So assuming you would be connecting to the cluster over an API, is there still a need to reference proto.actor libraries from a Unity project?

Right now yes, the server is talking to the cluster using MagicOnion (grpc), but this is still an additional (uneeded) layer just to gap the missing Proto.Actor cluster client, since all implementation just forwards a call to the proper actors.

[npehrsson]

Be able to set max limit of actors per instance.

Why? the hosting may be controlled an calculated how many actors there should be per instance for Stable operations.

Be able to turn on a wanted number of actors per instance which the cluster would automatically try to adapt to slowly (how slow may be configureable).