Re: CF: crossfire design

[Scott Wedel <scott@campy.Tymnet.COM>]

Andrew,
My question is what are you trying to solve?  Even on a single CPU
machine it is quite likely that threading will improve performance as
there is no need to wait for disk to load maps and so on.  I don't think
there is any sort of issue with too many people playing on one server
where the desired solution would be to add the complexities of
simultaneous cooperating servers.  If there is an overloaded server
then it'd be far easier to thread CF and make the CF server a multiCPU
machine than to go far down the distributed processing route.

The point about possibly having different continents on different 
machines (so player moving between continents transfers player to a
different server) is that removes the need for tightly coupling the
two servers.  As it is a different continent then artifacts and so
on could be different without it making things absolutely bizarre.

I might have missed something, but with X stuff removed from CF, but
in single player mode, I see server machine being pretty lightly loaded.
If it gets slower with more players then that is some programming that
needs to be cleaned up either by fixing the algorithms at fault and/or
threading CF.

A thread per map would minimize contention issues since there is very
little on a map that affects other maps.  It might also be worth it to
have a thread per each player as a frontend to client which handles
non map actions (such as inventory/equipment, eating, and so on) and
passes player events to and from the map thread.

Threads are also a wonderful way to simplify logic since you can write
single user code that blocks waiting for input (for example) and simply
works it's way through a routine as compared to multi-user code which
has to save info/states and be able to leave, handle other users and
then continue handling this user. 

							sdw

> From: Andrew Sutton <sutton@bay.cats.ohiou.edu>
> To: Mark Wedel <mwedel@scruznet.com>
> Cc: crossfire@ifi.uio.no
> Subject: Re: CF: crossfire design
> Date: Tue, 20 Jul 1999 19:07:58 -0400 (EDT)
> X-Authentication: none
> Mime-Version: 1.0
> 
> >  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]

-
[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]