[MUD-Dev] MMORPG/MMOG Server design
J C Lawrence
claw at kanga.nu
Fri Feb 21 13:26:42 CET 2003
On Fri, 21 Feb 2003 14:27:27 -0000
Daniel Harman <Daniel.Harman at barclayscapital.com> wrote:
> Whilst this is attractive in its simplicity, it adds an extra hop
> which doesn't strike me as ideal. Furthermore if the login server
> goes down, you lose all active connections too. EQ for instance
> has a login server, but only talks to it for initial auth, thus
> you don't have such a major single point of failure.
Two concerns:
1) Extra-hop induced latency
2) Single point of failure
Given a reasonably fast system with a faster back-haul the injected
latency from a connection proxy should be in the realm of very low
double digit milliseconds or less. Not a concern or problem. This
is well known non-rocket science space.
SPOF I suspect is also not terribly interesting (tho building fault
tolerant systems is always a fascinating process):
-- How many 9's are really needed for a connection proxy?
-- How many of those 9's can be transparently made up for by
adding either a fault-redirector in front of your proxy and/or
extending your client to cycle across your pool of connection
proxies upon TCP RESET?
-- What is the real impact if a connection proxy burps, drops
its connections, and the players see a lag/burp in their game
experience but otherwise continue on unaffected? (You'd have to
add some similar logic to the back-haul response lines, or do
transaction rollbacks/re-synchronisation but neither is a hugely
horrible space).
While its nice when connection proxies have five 9's, I really doubt
its necessary, especially given that some very minor slight of hand
can make even three 9's look damned close to five subjectively.
--
J C Lawrence
---------(*) Satan, oscillate my metallic sonatas.
claw at kanga.nu He lived as a devil, eh?
http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live.
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev
More information about the mud-dev-archive
mailing list