[CF-Devel] CFMP exciting new ideas.

[Mark Wedel]

dnh wrote:
>
     
     
     >
     
      Today I have had a very long discussion with Joris (MiDS) about future
     
     >
     
      client and server handelling of the metaserver. We quickly came to the
     
     >
     
      conclusion that the metaserver is the key, and that statistical data
     
     >
     
      supplied by it is a needed features. Currently information can be found at
     
     >
     
      crossfire.real-time.com/metaserver and
     
     >
     
     
      http://mids.student.utwente.nl/~crossfire/.
      
       The question is, why do we
     
     >
     
      have this split up system based on http?
     
     
 The reason of the split is largely because I wrote the metaserver.pl program to
do what was asked for - provide information of other servers.  Part of that
design was not to gather statistical data or do other complex things.

 Now I can't speak for the Tanners, but perhaps they would want to run that data
collection script on their server of mirror it or something.

 I'm a little reluctant to make the metaserver.pl script overly complex. 
Keeping it simple means it is easier to install and easier to make secure.  If
it relies on other external programs, who knows - the site(s) running the
metaserver may not have/may not want to install those additional packages (I
will note that for some systems, adding a package is just not a simple matter of
going and getting an rpm - even for many mainstream systems, it requires getting
the source and doing a compile).


>
     
      Why don't we incorporate
     
     >
     
      everything into the Crossfire Management Protocol. Basically the idea is
     
     >
     
      that each server has inbuilt scripts which when activated, send
     
     >
     
      information in a strict format to the metaserver which can then disect it
     
     >
     
      and create statistical information. Average users, hours up, are obvious
     
     >
     
      features. What makes this idea so much better is that the client also
     
     >
     
      follows the CFMP, and so it can gather this information at its own leisure
     
     >
     
      and supply it to gamers. A new gcfclient is planned, and with it I hope
     
     >
     
      will come a great change in the way we bind server and client. Within the
     
     >
     
      server selection window on startup, this client would have all the
     
     >
     
      metaserver information; Ping, #players, Build date, platform, hardware,
     
     >
     
      bandwidth. With this information players can more easily choose and play
     
     >
     
      on the most efficient, most active or most quiet server.
     
     
 Note that the current metaserver protocol does support a comment which the
adminstrator of the server can put in whatever information they want (platform,
hardware, bandwidth could easily be included, and are not things that change
very often).

 Currently, the client does not display the comments simply due to display
reasons - trying to display hundreds of characters of comments in the 40 char
wide window made things look pretty ugly.  If a better metaserver selection
method is done (say pop up window), then presumably it could display the
comments in a prettier form.

 platform & hardware, while nice to know, are not something I would really want
to try and collect automatically.  In my work, I've seen various scripts that
try to collect stuff like that, and they get pretty ugly pretty quickly.  Plus,
this may be information the server admin doesn't want to share.

 I know of no good way to determine bandwidth.  this is something that the
server admin probably knows better.

 Now it certainly may be a good idea to add some note to the settings file about
what type of things the server admin should perhaps put in the comment.

>
     
     
     >
     
      Simply put, MiDS is going to use MySQL and friends plus perl, to create a
     
     >
     
      far more intelligent metaserver that both dx and gtk clients can use.
     
     >
     
      Adding yet another hopefully, hopefully roWer, njh and I can start the new
     
     >
     
      GTK client very soon and all these features will be availible to Windows
     
     >
     
      and Linux users.
     
     >
     
     
     >
     
      I would greatly appreciate any ideas you have regarding CFMP and the
     
     >
     
      metaserver. More posts will probably come with updates on client status
     
     >
     
      and metaserver status, good luck.
     
     
 Perhaps I'm missing something, but I'm failing to see the current major
shortfall of the current metaserver.  Now I am probably be biased, and I'll note
that having average number of users on the server may be an interesting stat,
but is it really going to change many peoples decision on what server to connect
to?  For example, if I want to play on a server with a bunch of people, I'll see
what server has a bunch of people on it right now - the fact that server Z has
an average of 10 players but right now only has 1 probably means I'll still play
on server Y if it has 6 players on right now even if its average is only 4.

 That said, I can think of a few enhancements to the current metaserver stuff:
1) The server itself can report load/time issues to the server (some for of
interpertation that you get from the 'time command), 2) Perhaps some idea of
multiple metaservers and cross peering (so you would have regional metaservers -
so europe, north america, australia/asia, etc).  This may be more relevant if
the number of actual servers gets fairly large, as more likely you may want to
keep the numbers reported to a reasonable number and play local to you.  I'm not
sure best way to deal with that - my initial thought is that the metaservers
will send data in a similar form which lists how many servers they know about,
ie:

 Europe (knows about 5 servers)
 America (knows about 10 servers)

 The europe server will periodically tell the america metaserver that it knows
about 5 servers, but not actually report the servers.  And the america
metaserver periodically tells the europe metaserver it knows about 5
metaservers.

 This data would be reported to the client - so when a client connects to the
europe metaserver, it gets the information about the 5 servers it knows about
and also the fact there is an american metaserver that knows about 10 servers. 
If the user requests the america option, then the client goes and contacts the
america metaserver and then presents those 10 servers to the user, and so on.