Subject: RE: [Nel] Data Ownership

From: "John Hayes" <[email-masked]>
Date: Tue, 12 Feb 2002 19:22:39 -0500

What kind of information do you think would be suitable for each type of
server in the context of a game?

I would consider the data to be classified as asymmetric (or possibly
parallel?), synchronous, and static (data that does not change during
the runtime).

Asymmetric servers are most efficient when combined with optimistic
locking (that shares the assumption that you read more than your write)
- but the cost is requiring a transaction "replay" facility. A failure
will at least double the processing time (practical is closer to 10x for
a optimistic lock failure).

There's actually a third locking scheme that's a variation on symmetric
load balancing that I didn't cover. Instead of marshalling calls to
objects on other servers - you marshal the object to calls on other
servers. When a server requires use of an object it doesn't have, it
retrieves it from the current owning server.

So server A wants kick Monster #11 in the head - it marshals the entire
object from server B and makes it's call. Server A now owns Monster #11
and all subsequent calls are local.

The assumptions that make this scheme efficient are:

1. A user will access the same objects over and over or drift to new
objects slowly.
2. User's will access largely disjoint sets of objects - or, it's
possible to arrange users so that they access the same shared objects.
3. Users will read and write in approximately the same rate or write
slightly more often - and usually write the objects they read.

For these benefits, you accept that a small number of objects may thrash
between servers  and will probably represent most of your internal
network traffic. Sending an entire object may be large compared to a
single call - but that's amortized over a larger number of calls.

There's lots more detail to be covered in locking schemes.

John

> -----Original Message-----
> From: Thomas RIBO [mailto:[email-masked]]
> Sent: Tuesday, February 12, 2002 9:29 AM
> To: Nel ML
> Subject: Re: [Nel] Data Ownership

> Le Jeudi 7 Février 2002 18:18, Vincent Caron a écrit :
> > Well, for the moment, if you don't
> > have discussion peers you at least have an audience :). I'll try to
> > react to your last mail, but it's not a promise :(

> Let's try to be one of these peers ;-)
> I have no experience in the subject and waited a long time before 
> achieving reading your mail. It's very ineresting to have such a 
> comparative between these two maners of managing data.

> I can only propose a third solution: what do you thing about 
> a solution 
> which would take advatages of the ones you described? I am not good 
> enough to describe such a system by myself, but would it be possible? 
> For example, by separating data which needs advantages of symetric 
> balancing and data which needs advantages asymetric balancing... It 
> should add some complexity, but from my level, it seems that it 
> wouldn't be so hard...

---

From: Thomas RIBO <[email-masked]>
Date: Mon, 18 Feb 2002 20:06:09 +0100

Le Mercredi 13 Février 2002 01:22, John Hayes a écrit :
> What kind of information do you think would be suitable for each type
> of server in the context of a game?

Terrain data is in my opinion static. It could be distributed on 
geographical servers--in the sense of: one server manages one (or more) 
parts of the world-- or copied on all servers, or stay on a dedicated 
server. The players positions (and players objects in a whole) are 
typically dynamic data and we should consider that players should not 
meet all others at a given time. So, now, there are many maners to 
manage these players: the one you described, am I wrong? (I think I'm 
not able to go more forward, unfortunately :-( )

> parallel?), synchronous, and static (data that does not change during
Are you opposing asymetric and synchronous? So that we can recall 
synchronous "symetric" or asymetric "asynchronous"? I'm not sure to 
understand...

-- 
[email-masked]
"Le temps ne fait rien à l'affaire, quand on est con, on-est-con !"
-- Georges Brassens