[MUD-Dev] Networking architecture overview

[Daniel.Harman at barclayscapital.com]

From: Brian Hook [mailto:brianhook at pyrogon.com]

> So I finally called up a friend of mine (John Carmack) that
> really, really understands real-time networking and asked him to
> core dump on me how he has implemented his networking.  The answer
> is not what I expected, but it's a damn elegant solution.

I've been thinking about this solution, and whilst really elegant
for a FPS, I see a couple of potential problems compared to the more
complex UDP reliable option:

  - Dropping the bandwidth reqs by lowering the sampling rate is
  unlikely to work well. By moving to this architecture from the UDP
  reliable one, ones changing from a near continuous sampling
  paradigm to a discrete sampling one. When the sample rate is high,
  this will work fine, but when you lower it I suspect the
  'blocking' will be more apparent (drawing a parallel to digital TV
  here and how it degrades more catastrophically than analogue).
  With the reliable queue type paradigm, you can send updates pretty
  much continuously as events occur. So whilst more complex to
  maintain, I think that you'll get better performance on limited
  bandwidth.

  - Lower ratio of shared data in an MMORPG. i.e. In an FPS, most
  state is relevent to most players, and whilst the server can trim
  the info it sends to a given player based on whether X is in the
  LOS of Y, or was within the last few seconds (Unreal does this,
  dunno about Quake et al.) most of this data is shared. For an
  online RPG a lot of the data is on a per player basis, this will
  have a detrimental impact on the size of the state buffers.

> Addressing a question from someone else about "are there
> advantages to using multiple ports?".  There is one significant
> advantage that I don't think was mentioned, and that's that the OS
> buffers incoming data _per port_.  So if you have a chance of a
> port buffer overflow, then multiple ports may not be a bad idea.

That was my question, and thats a good point.

> Aside from application level delta compression, Q3 also does
> per-packet Huffman compression.  Works great, simple to implement,
> and the upside to something more aggressive is very low.

I wonder how many cycles this takes per client. Might scale quite
well 2000 player per server games as hopefully the lower per client
bandwidth utilisation will offset the number of clients.

> Damn that's smooth.

Definitely a great solution. Just a slightly different problem
domain. It reminds me why I'm a Carmack fanboi.

Dan

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