[MUD-Dev] Re: CORBA in MMOGs (and why Grex doesn't use it)

[ceo at grexengine.com]

In response to Bruce Mitchener's post... (only a few bits
are quoted).

I'm afraid I'm only now catching up on MUD-DEV posts from the xmas
period (argh! why does everyone have to get so chatty whilst I'm
away on holiday ? ;).

Brief answer to your questions...

CORBA happens to be one of those mainstream DS (Distributed System)
technologies that largely solves the "wrong" problems for MMOGs.

For architectural reasons, Server <-> Server communication is a
major bottleneck in our system design, or major *potential*
bottleneck. To be honest I don't see how you could avoid that,
whilst still providing any decent architecture for MMOGs (i.e. there
are clearly good ways, but they quickly reduce your options for MMOG
development - sensible game designs become impossible for artificial
technical reasons).

  c.f. the 7-layer OSI comms model, which is known for its lack of
  performance in favour of modularity, maintainability, etc. With
  some major critical execution paths running back and forth through
  the Server <-> Server comms [often multiple times for a single
  request], we have to be very conscious of maximal latency incurred
  etc. Worse-case scenarios for these LAN-dependent execution paths
  get rather nasty, and yet several of them are of core importance
  (module-balancing, request-balancing, and load-balancing enable
  the architecture to respond and reconfigure tiself dynamically to
  changing execution patterns; if a subset of the cluster is taking
  a huge performance hit, the messages to negotiate transfer of
  responsibility away have *got* to get through [although this is
  easiest to achieve with a second server-LAN, of course]). Aside
  from the core messages, many of the game messages have ultra-high
  importance to the gameplay (getting killed by a monster two
  seconds before it appears on your screen isn't going to make any
  player happy ;).

With a modern LAN, all you can do to reduce latency and increase
reliability AFAICS pretty much boils down to "put switches
everywhere, compress datastreams, stop sending quite so many
messages (i.e. clump them better)".

OTOH, with your software network stack/layers, you can: remove as
many intermediate layers as possible, compress as many protocols
into single protocols as posssible (Why parse thrice when you could
do it just once?) etc. My previous experience has usually been on
projects with the opposite intention - low-cost maintenance,
upgrading, and bug-fixing at all costs!

IME, CORBA is fundamentally providing a better, more efficient
development environment for human programmers to create reusable, OO
apps, that will run effectively and correctly (but not necessarily
fast) in a distributed system.  The speed that customers of
ORB-based apps are interested in is "request throughput" etc.

> What sort(s) of solution(s) did you end up going with instead of
> CORBA? Was it home grown or something off the shelf?  What sort of
> performance benefits are you seeing vs. amount of systems
> engineering effort expended?

The speed that we require is "low-latency, high-throughput
messaging". For this, several of the aspects of CORBA you mentioned
are no-go areas. Routing vendors would have an easier time because
routing is generally one/two layers only, and avoids much of the
overhead of e.g. having to go through all the rigaramole of the
Application layer + the Network layer + the wire layer etc etc.

These issues are a large subset of the first reference you cited (If
you look at the minutes of the Manchester meeting, the things I've
just said are referred to in about 10 different bullet points). It
does look like a promising working-group - but their focus is too
wide (for us - we need solutions to what appears to be only one of
the approx three biggest problems they were identifying), and sadly
as you pointed out it now appears to be in decline. We cannot wait
the possibly several years for anything substantial to emerge from
that WG.

So, something close to "home-grown": we use other comms standards,
which are less all-encompassing than CORBA. In addition, our
architecture promotes the same kind of heterogeneous clusters that
CORBA supports (e.g. our equivalent to ORBs are similarly
language-independent). You might want to imagine that we have
something that lies between RPC and CORBA - much of the efficiency
of the former, with some of the power (from a prorgrammer's POV) of
the latter.

Although I'm afraid I can't really go into more detail than that at
the moment, in summary our messaging tends to use the whole range of
layers, and so its impossible to optimise (significantly) unles you
either:

   A. Throw away layers (throw away CORBA)

   B. Break through layers (bastardise CORBA and break the
   standards, gently, in a way that will continue to kind of work,
   as long as developers stick to extra restrictions.)

If I were free to give a more detailed answer (wait until Grex
starts putting out articles, information etc next year :(, I'd show
what advantages the architecture provides that make these
disadvantages easy to accept, and also contrast distributed- gaming
systems to traditional DS's, showing where the
middleware/enterprise-ware (is that what's its called now? ;) for
the latter fails dismally for the former. Someone (Dave? Amanda?) 
recently gave a good example with mainstream enterprise DBs just
being completely orthogonal to the requirements of a current
stereotypical MMOG.

Adam M

_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev