[bf1942] Console

[Scratch Monkey]

--On Friday, April 11, 2003 11:07 AM +1000 David Harrison
<trogspam at games.telstra.com> wrote:

> My big concerns with
> it as an exclusive administration system are a) lack of ability to control
> remotely from a console (which I do allllll the time with all our other
> servers) and b) security

Remote control from a console is no harder than it would be with a UDP-based
protocol. Security of TCP is arguably better because of the initial connection
handshake to eliminate source spoofing. TCP also offers reliability that one
would otherwise have to build from scratch using UDP. Once you have TCP, it's
not a big leap to add SSL to that to secure the connection.

> Most current common server software that uses an rcon system (eg, Half-Life,
> Quake/Quake 2/Quake 3, SOF2, MOH, RTCW, etc) just has a very simple
> interface - you just send a UDP packet to the query port along with a
> password string and then you get a response (Half-Life's is a bit more
> complicated but still relatively simple). It is very handy to quickly and
> easily retrieve/set server settings, message players on the server, kick/ban
> players, etc. We have a fairly complicated infrastructure built up around
> our Half-Life servers to manage them more efficiently, built almost solely
> out of the ability to easily remotely admin the servers.

It sounds like this is a low-bandwidth bursty connection, and hence doesn't
need the performance enhancement of UDP. I'd much prefer the reliability of
TCP. If you do everything in printable ASCII (as in FTP, SMTP, and HTTP), you
can use a common telnet app to shake things out before you build your pretty
front-end.

> IMO, the key thing is making it simple but having a stack of functions
> available - this works well for Half-Life (easily the most feature-packed
> dedicated server software available) and allows server managers to maintain
> their servers either by downloading any number of user-created server
> manangement packages, or creating their own from scratch. Valve's only sign
> of competance (again, imho :) has been their willingless to listen to server
> administrators and add in the functionality that they've requested -
> ultimately, we're the people running the servers, and without them, noone
> can play their games, after all!

No argument there!

To me, a game server is a lot like a net-enabled piece of process equipment.
(Think conveyor belts and chemicals flowing through pipes.) It would be
fruitful to look at the protocols used in that domain and leverage tools used
to communicate with those devices. I can tell you from personal experience
that some of the higher-layer protocols are pretty brutal in their complexity,
but the low-level sensor/actuator stuff should be pretty easy.

BTW, for the networked home appliance programmer, check this out:

http://www.tivo.com/developer/