Re: CF: crossfire design

[Andrew Sutton <sutton@bay.cats.ohiou.edu>]

>  This of course requires some amount of cooperation between server A and B.
> There are some other issues:
> 
>  1) Server A and B have to agree to this, and not have anything in thier server
> world that will greatly upset the other (great artifacts or easy ways to get
> exp)
>  2) Both server A and B need to be up for the game to be playable (to some
> extent, this may provide more fault tolerance - it depends on the nature of the
> dungeon - if it is just a small standalone dungeon on server B, if only server B
> is up, it doesn't help out the bulk of people on server A since they can't even
> log on)
>  3) Network location/latency could become an issue.  A player may choose server
> A because of relative close proximity/speed relative to where he is.  Server B
> may not have those same attributes relative to the player.  IT would be
> frustating player on a relatively fast server to find out you can't explore
> dungeons due to their relative network slowness.

of course your right... i was thinking of a more subtle 
distribution that would result in something like 
clustering: moving popular parts of the same server onto 
other computers that communicated thru a well defined 
server-to-server protocol that were geographically close. 
they might not need to be, but for consistency in network 
latency it would be a nice property.

>  For example, a more logical approach compared to dungeons on different servers
> would be to seperate in terms of continents or other large reasons.  This has
> one nice advantage that the characteristics of the server could be very
> different (different plant life and monsters) without having to duplicate the
> archs of the first.  But such a split may not help if one continent is very
> popular and the other is not.

that was one of the reasons i had in mind. i just forgot to 
mention it.
 
>  To answer the question more concisely:  Player transferance between servers may
> happen at some point, but as of now, that some point is a ways off as there are
> many things that need to be considered and many other things that I would
> consider more important to do than all that.

of course, this isn't something that _needs_ to happen 
immediately, and probably isn't even relevant to most 
administrators or players needs. it was only an 
observation. i was just trying to puzzle out how it could 
be done and what the benifits would be. i figure there 
should be at least three additions to the server and some 
modifications to the client (i haven't looked at that code 
very closely).

1) a player registry that acts as an independent server. 
this maintains a consistent and final list of players that 
use that server.

2) an authentication service that may or may not be 
packaged with the registry. players login and obtain 
credentials (like kerberos or other security modules) then 
use those credentials to identify themselves to the game 
server.

3) a well defined server-to-server communication protocol 
for moving characters from server to server, and possibly 
load balancing.

and the client would be modified to support those changes. 
but as i said, it's more of an exercize then an important 
addition to the game.

----------------------
Andrew Sutton
     sutton@bay.cats.ohiou.edu

-
[you can put yourself on the announcement list only or unsubscribe altogether
by sending an email stating your wishes to crossfire-request@ifi.uio.no]