Hey folks just starting to look at Proto.Actor for an upcoming AAA online-only game prototype using Unreal Engine 4. I'm Rhino, nice to meet everybody.
The prototype (and eventual game) leverages an existing centralized global data store for all all account / player / inventory and world data exposed via a REST API, but due to latency requirements we will have presence throughout the world in many datacenters to minimize latency between grouped players who are matched up. Matches are simulated by a Unreal Engine Dedicated Server instance that has all players for that match connected, and we choose the location of that server from the available datacenter presences to provide best overall experience for the players who are to be grouped up. Players are matched with an algorithm that optimizes latency quality and equality.
The idea is to keep as much traffic local to a presence as possible during a match to increase responsiveness, reduce overall load on the global system. So I'm thinking the dedicated servers will speak to microservices / actors within the local environment, and those will in turn sync-up with the global system on an as-needed basis. This will allow both goals to be achieved: providing a more responsive API layer to the dedicated simulation servers, while reducing overall load upon the global system. We also want to keep as much of the game services logic outside of the dedicated server process, and have it stick to what it does well: simulate movement, combat, physics, etc.
The first things that come to mind with this plan are:
1) Given protoactor is Go / C#, what's he best way to integrate with UE C++ / Blueprints for our dedicated servers? Do you know of anybody who has done this? UE4 has a nice plugin architecture and I could certainly write a plugin in C++ that interfaces with C# via COM Interop. Alternatively, I could leverage Kestrel (ASP.Net Core web server) running locally on the dedicated nodes, and the dedicated server would communicate over local IP stack using HTTP REST, and within the Controllers within Kestrel I would interact with Proto.Actor. This would present a REST interface to the UE dev's, but everything would still be inherently message based. I would have the JSON messages deserailzie into the same POCO's needed for protoactor. I'm leaning toward this solution, but if somebody somewhere has a general purpose UE4 / proto.actor bridge, I'd be all up for checking it out!
2) Can I write a custom loader so that when the say a local Player actor spawns, it loads itself from the centralized global system? That way the latest globally persisted state is always available. Conversely, upon despawn the global system would be updated with the local data.
3) Does protoactor have the concept of a portable locality so that a Player actor instance can automatically "migrate" between datacenters so that it lives closer to the dedicated client who is currently accessing it? Or would this have to be built upon what's there?
4) How does protoactor provide HA / crash recovery? I'm used to Service Fabric Reliable Services whereby the data for the actor is replicated between active and secondary partitions, embracing the "let it crash" model and guaranteeing no data loss at the cost of write latency.
I'm sure I can think of more later, but these are the primary things I'm facing ATM...
Proto.Actor doesn't have a web server as part of it's solution. It speaks protobuf / gRPC.
There was a discussion about the concept of Proto.Http front-end quite some time ago here:
Roger's comment here makes a lot of sense to me:
"So for normal actors, just let Asp.NET be Asp.NET but we provide some easy way to unwind the HTTP Context + payload and transform into message + headers and pipe to a PID
Least amount of magic, fully configurable and works with other things.
Yet easy to use and integrate"
That totally makes sense to me, and if it was already built, we'd use it. We'll probably end up building this as part of the prototype, and if I can get approval to contribute it back, I will.
But yet, I'd love to see a nuget package out there with a piece of ASP.Net middleware that acts as a simple gateway to Proto.Actor.
Good day. Can you please tell me if I use remote, then 1 and 2 nodes should have a static ip and an open port? Or I do not understand something?
It comes out to me ... There is a server that connects an n-number of clients to it and after that I send them a message. And when I add them to my dictionary. That pid local, but not external. Well, even if you send an external ip, then while the port is closed the client does not receive a message from the server.
may i ask some coding question?
why not directly assign variable tp to ref.t?
cluster.[REMOTE] - Started EndpointWriter,
cluster.[REMOTE] - EndpointWriter connecting,
cluster.[REMOTE] - EndpointWriter failed to connect,
cluster.[REMOTE] - [ACTOR] Recovering
Task ReceiveAsync(IContext context)and forwards these to a driver that someone else wrote. This works very well and the client is happy since most calls are returned within a few milliseconds (up to a second) . However one of the calls from the client instructs the driver to measure something for more than 60 seconds and the driver is written in such a fashion that it does not return until the measurement is finalized. Obviously the client might like to cancel that ongoing process and here is where I run into problems.
public async Task<T> RequestAsync<T>(PID target, object message, TimeSpan timeout)performs something like
var context = new RootContext();
var response = await context.RequestAsync<T>(target, message, timeout);
RequestAsyncit gets stuck in the
await context.RequestAsynccall and this call never makes it to the server.
targetPID is always the same. Maybe this is my problem ?)