Date: Fri, 9 Aug 1996 15:01:23 +0200 (MET DST)
From: Bernd Kreimeier <Bernd.Kreimeier@NeRo.Uni-Bonn.DE>
Message-Id: <199608091301.PAA05183@marvin.nero.uni-bonn.de>
To: quake-dev@gamers.org, bernd@marvin.nero.uni-bonn.de
Subject: Info from John Carmack (QuakeWorld 2)
Another mail on QuakeWorld details (published on
http://acs.tamu.edu/~stm9233/qworld.txt), and one message
from Michael Abrash distributed by Mike Wilson - there is
an unsupported Win32 dedicated server release now, at
ftp://ftp.idsoftware.com/idstuff/unsup/qwded103.exe.
b.
---------------------------------------------------------------------------
From: John Carmack <johnc@idnewt.idsoftware.com>
To: jep@sclsis.navy.mil
Subject: Quake World
Date: Wednesday, August 07, 1996 11:03 AM
Qspy is cool.
Want to be the official front end for the QuakeWorld project?
I think the initial research releases of QuakeWorld are going to be native
win32 apps only, and they will listen on a control socket, so an external
windows app can very nicely send them from server to server.
If you are interested, I can go over the new features we are considering
that would be pertinent, and solicit some opinions from you.
John Carmack
--------------------------------------------------------------------------
From: John Carmack <johnc@idnewt.idsoftware.com>
To: "Joe E. Powell" <jep@sclsis.navy.mil>
Subject: Re: Quake World
Date: Wednesday, August 07, 1996 01:36 PM
Ok, the basic structure looks like this:
A single master server running at a well known address at idsoftware.com.
Freely available client and server win-32 executables.
The servers do not require well known port numbers, because they register
with the master, so you can just start up ten servers on a pp200, one after
the other.
When a server is started up, it configures all of its options, then sends a
heartbeat out to the master to let it know it is alive. Heartbeats are
sent once a minute, and contain all server information, a list of all
connected clients, and all of the frags that have taken place in the last
minute. They are udp packets fired into the void, so I'm not guaranteeing
100% accurate logging, but it should do just fine for all my purposes.
External programs can request information directly from a server, but
because they won't know the port number, they will generally be forced to
ask the master for at least an address. (they MUST go through the master to
connect to a server, they can't just go there directly)
Any program can request current server information from the master. I'm
still unsure exactly how I want to handle this. I want to have a rough
idea of how to scale this setup to around 1000 active servers and 5000
active users, which impacts options a bit. In addition to the current
quake info (level, current users, max users), the master will also have a
set of key/value pairs from the server that can be used for arbitrary
information, like which skill ranks are allowed.
I am currently torn between having some form of a query sent to the master
to pare down the number of returned servers vs just dumping some form of
the entire list to let the client search it. I am leaning toward the
dump-the-list aproach, because I know I can change it if it looks like it
is going to get overloaded, and it gives max flexibility. Comments?
The master will also be able to return the public information for any
userid, so you can print out proper named rosters for each server. It will
be cool to be able to find out if any of your friends are playing on
servers anywhere in the world.
User accounts consist of a user id, a password, and two sets of arbitrary
key/value pairs. The user modifiable set will be for name, color, clan,
etc. The protected (master-modifiable only) will be for rankings and other
read only rights that can only be changed by the master server. I don't
know all the things we are going to want to try, so I think the
unstructured pair lists will give the best flexebility.
When a user requests a connection to a server, the master sends their
account information and ip address in a message to the server they
requested. Servers ignore connect messages from any address but the
master.
The individual servers are the final authorities for admission of a user.
They can accept a user connect command from the master, and simply refuse
to honor it for whatever reason (wrong rank, on the banned list, etc).
There is an internal ping command in the servers, which should be used over
a regular internet ping for quality testing, because the turnaround time
for it will also be somewhat influenced by the current server load.
There is a "logon" protocol message to the master that returns the current
userdata and masterdata for an account if the proper password is given. It
isn't really establishing any connection, because you must present user id
and password for the connect
The first real game extension that I want to add is a centrally
administered ranking scheme. Start everyone at private, and let them
advance. This gives everyone something to achieve, and will also be used
to limit servers to various skill levels.
There are millions of other things I want to try, especially with teams,
but I want to take this in small managable steps.
I am presenting this as research-in-progress, so I'm not going to feel any
guilt for downing the master at various times or doing frequent updates to
the client/server exes.
I would like to move user account creation and logon out of Quake proper,
into the GUI app.
My vague vision of the gui front end looks like:
Launch Quake and get the port number that it running at, which will be
needed for connect messages.
An initial choice to either logon with an existing userid / password, or
create a new account.
If logon, fetch the current information from the master and display it.
The user data should only change when the user directs it, but the master
data will be updated sparadically. The user should be able to see that he
advanced in rank before searching for servers.
If newuser, prompt for a name, color, and password then fire off a message
to the master that will respond with a new userid. Perform a logon to see
if any masterdata was generated for the new account.
Once the app has a valid userid/password, fetch the server list from the
master, and do all the qspy like performance sorting and filtering.
When one is selected, send a message to Quake to try to actually log in.
These messages will be heeded at any time, so a user can just drop out of
full screen Quake mode and click on another server if they like.
I am totally open to comments and suggestions.
John Carmack
---------------------------------------------------------------------------
>From mikew@idsoftware.com Thu Aug 8 23:22 MET 1996
----------
From: Michael Abrash[SMTP:mikeab]
Sent: Thursday, August 08, 1996 4:14 PM
Subject: Win32 dedicated Quake server
I have placed a native Win32 dedicated Quake
server, on the ftp site in
idstuff/unsup/qwded103.exe. Please let people
know about this.
This is an unsupported release, but we have
tested it quite a bit over the last few days,
and it seems to be the best Internet Quake
server available at the moment--and of course it
support NT, so it should make a lot of people
happy. One note: you have to have the
registered Quake levels to run this dedicated
server.
--Michael
---------------------------------------------------------------------------