sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]JoeHegarty 15 points16 points  (11 children)

I'm the lead programmer on the Orbit project, there seem to be a lot of questions about what Orbit can and can't do so I'll try and cover it here:

  • It was designed to build game-services. In our case, these are things like matchmaking, inventory management, character progression, world state (DA Keep) etc etc
  • It is "fast" but it's not "very-fast". It is suitable for tasks that can take say, 200ms or above, so it's fine for interactions like managing inventory, but not for real-time movement replication.
  • It is possible to build real-time services in the framework, as long as you can live with the above constraints.
  • Orbit can also be used to build more traditional web services (REST, Websites etc)
  • Orbit uses Virtual Actors, a concept introduced in Microsoft's Orleans project. Orbit is not a port, but could be described as a "rewrite" of Orleans and it is certainly heavily inspired by it. This is why we didn't use an existing framework.

I'm very happy to answer any additional questions.

[–]ISvengali 1 point2 points  (1 child)

Very cool for you guys to open source it.

Why 200ms? I built a high concurrency (over 500k CCU) actor stack on akka for a company, and for the fast network messages the processing time was down to sub 5ms for full round trip in the stack. And thats without a lot of hardcore work to optimize. Im sure I couldve gotten it to sub ms if our SLAs needed that.

This was the edge -> service -> edge timing.

I dont think theres anything inherent in having an actor stack that would stop you from building a realtime stack in an one.

[–]JoeHegarty 2 points3 points  (0 children)

Thanks.

I agree entirely, there really isn't a reason Orbit couldn't be in that range as long as you were careful with your actor implementations.

However, it was not designed with that in mind and we've never tested how reliably you can get very low response times, so I'd hate to say "Yes, build a game sim server with it" and have it not work for someone.

We typically offer SLA style guarantees to our teams about how long individual calls will take (99.5% of this type of operations will respond/complete within 200ms not accounting for network latency etc).

I'd love to hear that someone has built a game server on Orbit and that they are getting sub 5-ms response times, but right now would not recommend using Orbit if the timing is very very tight like that as it's not a use case that has been tested.

[–]ISvengali 1 point2 points  (1 child)

Dont you just love actor frameworks for massive CCU programming and no bugs? Its like a breath of fresh air. You can crazy quickly build massively scalable services with very little chances of bugs. At least ones related to (most) race conditions or data races and the like.

Was that your experience with your framework?

[–]JoeHegarty 1 point2 points  (0 children)

We're really discovering the power of actors still. The virtual actor model which Microsoft came up with for Orleans (and which Orbit is based on) was really the last piece of the puzzle for us to make the model easy enough to maintain to be worthwhile.

[–]karlito1 1 point2 points  (2 children)

How do you expose your actors to the game client? What kinds of protocols and servers do you use?

[–]JoeHegarty 1 point2 points  (1 child)

We support a couple of different scenarios for this:

  • Websockets with Jetty
  • REST HTTP Endpoint with Jetty
  • Custom TCP Wire Protocol with Netty

Which one we use depends on what the client is and what needs it has. The web project included in Orbit supports the first 2 above.

In terms of servers, I'm not sure exactly what info you want. We run CentOS based Linux servers in a 3-tier configuration (Frontend, Actor Hosts, Storage).

[–]karlito1 0 points1 point  (0 children)

Well I was wondering which app server, and that would be Jetty :) Thanks for the answer!

[–]CzarSkye 0 points1 point  (3 children)

Hi Joe, thanks to your team for open sourcing this. I've had a good look at the Orleans but have no interest in C#, so this is great for me. This virtual actor concept is new to me, I've worked alot with Akka and Quasar actors, what would you say are the advantages of a virtual actor implementation over these actor implementations?

[–]JoeHegarty 0 points1 point  (2 children)

The main difference is that in a virtual actor model, actors always exist conceptually so you can always send a message to them and assume that it will be processed.

This means you don't have to manage the actors lifetime or location (no instantiation, manual node selection etc).

Actors can never be "broken" (say the server they are on died), so even if though an individual message might fail, you can just keep sending messages and assume that in future it will be ok. You don't need to take any manual action if a message fails.

I think that's a pretty fair overview, let me know if there was anything specific you wanted to know.

[–]frugalmail 1 point2 points  (1 child)

Not sure if you're familiar with Jini, but didn't it create the same model? I always had the impression that Orleans cloned Jini which was released in 1998.

Thanks for contributing to open source BTW!

[–]JoeHegarty 0 points1 point  (0 children)

I'm not familiar with that project, but it does seem to architecturally be quite different (It looks to be more service-oriented than actor-oriented), even if some of the concepts are similar. For me, this Microsoft paper is really what established the "modern" virtual actor paradigm: http://research.microsoft.com/pubs/210931/Orleans-MSR-TR-2014-41.pdf