gamedevlists-general

RE: [GD-General] Basic questions regarding networking games...

[Brian H. <bri...@py...>]

>   [A] For *Internet* games I assume service WWW sites like 
> GameSpot, etc, advertise the IP's and ports of game servers 
> -- or you can indicate the IP and port number of your server 
> through any other means (phone call, e-mail, chat, etc).
> 
>   QA1: Is this the dominant way to discover *Internet* games?

I think so, but I'm not sure.  That would seem to make the most sense
though.  Alternatively, if you have a dedicated lobby service then there
would be som existing protocol to negotiate that information.

> of broadcasting to all 64000 ports in a brute-force search.

Why not just pick an unused port and go with it?  Then also allow the
ability to override at the command line, e.g. the server can specify the
port.

>   QB2:  Might a server on a LAN advertise itself 
> periodically, like once per second?

Sure, no reason not to, but then your clients will have to be listening
on a port as well as broadcasting.

>   QC1: Sorry for my ignorance, but do you think it's okay
> to have all clients send UDP to the same server port
> for processing?  (So each UDP packet has a "Client ID"
> to demultiplex the packets.)

Yes.  You can demultiplex on source IP if you're an internet server, but
having a separate client ID that is some function of the low 16-bits of
their (local) IP address helps to disambiguate between two clients if
the source port gets remapped from underneath you.  I know Quake had to
do this because some older routers would just reassign the ports
somewhat randomly (I'm not sure if UDP specifies a lifetime for a source
port mapping).
 
>   QC2: Even if all UDP traffic can go to a single server
> port, do you think there might be some benefit to having
> a seperate port that is strictly for joining the game?

Not that I can think of.

> (The "real" game might be some RANDOM port, but the
> service for joining the game might be on the "well-known
> port range".)

Okay...so why the random port instead of just choosing one?

>   QC3: To your knowledge, do many first-person shooter 
> deathmatch games just feature a single UDP port for all 
> game-related traffic?

Don't know, but I think it's easy enough to find out -- in fact, many
NAT box/routers include specific instructions for each game.

I personally think everything should be done with as few ports as
possible because this simplifies things for those people that rely on
port forward (forwarding one port is often easier than forwarding a
range).

For my stuff, I have two server ports, a game port and a control port.
The control port is strictly used for server management, stat queries,
etc. by remote admins.  The game port is for all game play.  I have a
hardcoded port # that can be altered if necessary, which seems to be the
norm.

Brian

[GD-General] Re: Basic questions regarding networking games...

[Colin F. <cp...@ea...>]

2002 September 23rd
Monday

QUESTIONS:

[1] Okay, let's say I want to come up with some
default port number for my game server.  My instinct
would be to pick some random number (1024<-->65535)
and then do a WWW search to see if there were any
hits for "port 12345" (or whatever).

Then I would guess the probability of a person
running MY application and simultaneously running
whatever other applications might use that port
number by default.

Is that pretty much the state of the art of
port-choosing technology?



[2] I know this depends greatly on the genre of
game, and how real-time the action is, but what
is an example of the packet rate (packets/sec)
sent from server to client?  What is the size
of data in each packet?

I just want to get a sense of the order of
magnitude of the traffic that typical,
small scale first-person shooters use
successfully -- for LAN and Internet cases.

I've heard of packet rates as low as 10 packets per
second (average) for Internet games with 64 players.
I don't know what the data size was for these packets.

Anyhow, I know that this question is almost too 
general to answer, but I'd like to hear about
working concrete numbers, in any game play genre,
for LAN or Internet games.



[3] Let's say you want a server to establish the time that
someone pressed a key on a client computer.  Let's say
that the server wants to express the client key press time in
terms of its local time.

  Basically, each client has its own local time, and
the server has its local time.  I'd like to compute
the delta's between the server's time value and each
client time value, and vice versa.

  Thus, I can place any client event in to a single
server timeline, regardless of network glitches.

  So, I'm thinking that when the "connection" is
first initiated (player joins the game), the server
makes a bunch of pings to the client, asking for
the client local time values.  Then, through some
round-trip time math, etc, we can pin down the time
difference.

  Okay, here's are the questions:  Is this common
practice?  Do games try to improve the measurement
of the time delta throughout game play?  What are
some techniques for arriving at this value?

[NOTE: The time delta should be an exact number (per client)
that is essentially a constant throughout a typical
game duration -- assuming the high resolution timers
or performance counters don't drift in any significant
way on the client machines or the server.  If you had
instant communication between two machines you would 
get this time delta exactly.
My computer says it's 12:34:56 AM, and your computer
says it's 12:34:58 AM at that same instant; perhaps
we're both way off the "real" time, but I just want
to know that your machine will report times that 
should be adjusted by -2.0 seconds before using
in my time line.  This time delta has nothing to do
with any network variability or lag.]

To make this even clearer, one simple-minded way
of getting this time delta is the following:

  [1] I send a "ping" from machine "A" at local time TA1 
  [2] Machine "B" receives "ping" at its local time TB1,
       and sends TA1 and TB1 back to machine "A".
  [3] Machine "A" receives packet at its local time TA2,
       and the packet contains values TA1 and TB1.

The round-trip time was (TA2 - TA1).  Assuming the
lag was symmetric (an assumption that could be 
very wrong, as with cable modems where upload speed
is way slower than download, etc), you might decide
that the time delta was:

    TDeltaConvertBToA = (TA1 - TB1) + ((TA2 - TA1)/2);

In other words, just compute the delta as if the
reported machine time values were at the same instant,
and then correct for the lag by using half of the
known round-trip time.

  Another method might be just sending lots of pings
from server to client, and returning the minimum of
all computed (TA1 - TB1).

  Anyhow, there's probably a technique that converges
on the exact time, maybe in just a couple of exchanges
between server and client.  


This is like those annoying middle school problems: 

"A train going east at 50 MPH leaves station X at 3:00 PM,
and another train leaves station Y, 400 miles away, 
at 4:00 PM at 60 MPH...  When the trains collide they
produce two new identical trains, with one standing still
and the other moving at 0.99c heading for Alpha Centauri.
Will humanity be ready when the second train returns from
Alpha Centauri loaded with Schrodinger Cats and magnetic
monopoles?"


--- Colin
cp...@ea...
www.colinfahey.com

Re: [GD-General] Re: Basic questions regarding networking games...

[Colin F. <cp...@ea...>]

2002 September 23rd
Monday

>>> This sounds more complicated than necessary.  Why do you need sync 
>>> times that tightly?

I don't know!  Crazy, huh?

I guess I thought I might be to tell the precise
sequence of all of the client events (across all players)
and support a tiny bit of "revisionist history" --
re-simulate a few past time steps if new "evidence"
(client events that should have changed history but
weren't previously considered due to brief lag) was
later received.

But, frankly, I can't remember what ever made me think
that synchronization (or determining precise time differences
between each client and the server) would be worthwhile.

I guess one of my other ideas was that the server would
leave most deterministic things unspecified -- and so
if a client was precisely synchronized, then both client
and server would essentially have the same impression
of the deterministic aspects of the environment.
So, if you jump on to a rising elevator platform,
the server doesn't need to send authoritative feedback, since
both client and server know exactly how your jump will
turn out.  If the client simulation of deterministic
processes was out of synch with the server simulation,
then we're forced to send more update information.
The client always sends player actions, but we just don't
need to send so many authoritative updates about the
outcome of those actions.
(NOTE: This example doesn't include the effects of
non-deterministic factors: constantly changing 
movements of other players, and other player-initiated
events, like firing weapons.  But we just have to
determine how these events "screw up" the deterministic
aspects of the game, and notify/update affected clients.)

Well, I think I have enough feedback to get me started
with an initial design.  I'll restrain myself from asking
more silly questions until I attain the next level of
insanity.

Thanks to all for the very enlightening comments.

--- Colin
cp...@ea...
www.colinfahey.com

Re: [GD-General] Re: Basic questions regarding networking games...

[Colin F. <cp...@ea...>]

2002 September 24th
Tuesday

Someone pointed out that letting a client timestamp
events has allowed cheating in Quake.

Now I'm trying to figure out just how far people
take the principle of "never trust the client".

I'd like to know if anyone has experienced any
of the following scenarios, or even more bizarre
scenarios.

[1] Someone does a "tcpdump" (or similar) and
reverse-engineers the packets and writes a
stand-alone application that sends packets
that fools the game server in some way
for the purpose of cheating.
----------------------------------------------
ASSUMPTIONS:
  The only resource available to the hacker
  is the binary dump of TCP and/or UDP traffic.
  (i.e., no source code or details of packet format)
SOLUTION:
  Encrypt packets.



[2] Someone reverse-engineers the assembly
language of the client and works out the
packet format and encryption algorithm.
Or, the hacker just finds out the packet
format and encryption algorithm from social
engineering or a leak from the company.
The hacker either alters the code to transmit
different information, or writes another application 
to supplement or act independently of the
regular game client.
----------------------------------------------
SOLUTION:
  Uh, I guess you have to limit the client
  to sending the most basic events imaginable,
  scarcely more than keystrokes (essentially),
  and the server assumes nothing about the
  actual time the client events occurred --
  instead the server pretends that the 
  event occurs when it is received!
  Players with lag get punished proportional
  to their lag, but that's life!

  Is this the only practical solution?



[3] Someone gets source code sufficient to rebuild
the client -- with any desired logic modification.
----------------------------------------------
NO SOLUTION:
  Well, this allows the hacker to create "bot"-like
  shooting accuracy and scripted movement patterns
  (like running directly to all ammo spawn points,
  or pursuing enemies with the most efficient,
  minimal paths).
  Even if we totally distrust the client beyond
  receiving the most basic events possible, it
  doesn't seem possible to detect players that
  are "too perfect"!

 
[4] Someone writes a separate application that controls
  a legitimate version of the client.
-------------------------------------------------------
NO SOLUTION:
  What can be done?  The user (hacker) is communicating
with the application in a way that is indistinguihable
from a human hitting keys on the keyboard and moving
the mouse.
  It could be as simple as recording keystroke macro's
in your physical keyboard -- so you can do complex
operations in StarCraft just by hitting a single key.
  Or you could write an application that sent keyboard
and mouse messages to your game client so that you
could execute complex actions at high speed.



Anyhow, I guess I'm really just interested in a way
to make the client event timestamping work.  Also,
I guess that EVERYTHING depends on how much you think
hackers will diminish the value of your game by each
mode of hacking and cheating.  So, if I am fairly confident
that hackers won't go to the trouble of reverse-engineering
the encryption scheme, and if I'm confident that the
packet format and encryption scheme won't be leaked,
then maybe I can accept the risk of allowing the 
client to timestamp its own events.


I guess the scenarios mentioned above apply to servers,
too -- but if a server is hacked, then all of game
reality can be violated.  Question Authority!
"Yes" means "No", and "Left" means "Right"!
"1 + 1 = 3"!  **** You could do the nutty thing of CLIENTS
not trusting SERVERS! **** So, if you have a legitimate
client, and the (hacked) server starts cheating like crazy,
you could at least detect this condition and notify
the user that the server is run by a no-good hacker.


Anyhow, I'm fascinated by stories of how far hackers
will go to cheat.  I like funny pranks that can be
recognized as pranks and have obvious parameters and
limits, but I have no respect for hackers who think
it's fun to create an artificial advantage for themselves
in games and destroy the experience for other players.
I heard of simple stuff, like turning EVERYTHING semi-
transparent, so you can see people through the walls.
I could see how that might be fun for about 30 seconds,
especially if I had money riding on that game!
Okay, enough random gripes.  ;-)

--- Colin
cp...@ea...
www.colinfahey.com

Re: [GD-General] Re: Basic questions regarding networking games...

[Mads B. D. <ma...@ch...>]

On Tue, 24 Sep 2002, Colin Fahey wrote:

> 2002 September 24th
> Tuesday
> 
> Someone pointed out that letting a client timestamp
> events has allowed cheating in Quake.

Yep. Trusting the client (at all) did this.

> 
> Now I'm trying to figure out just how far people
> take the principle of "never trust the client".
> 

Very far, I would assume.

> I'd like to know if anyone has experienced any
> of the following scenarios, or even more bizarre
> scenarios.
> 
> [1] Someone does a "tcpdump" (or similar) and
> reverse-engineers the packets and writes a
> stand-alone application that sends packets
> that fools the game server in some way
> for the purpose of cheating.

Now, that is what _everybody_ does. The usually do a proxy though.


> ----------------------------------------------
> ASSUMPTIONS:
>   The only resource available to the hacker
>   is the binary dump of TCP and/or UDP traffic.
>   (i.e., no source code or details of packet format)
> SOLUTION:
>   Encrypt packets.

Encryption packets here have the basic problem that you deal with UDP 
traffic and you usually have a fixed format for the payload. Even if you 
pad with random strings it will still be possible, and see next point:

> 
> 
> 
> [2] Someone reverse-engineers the assembly
> language of the client and works out the
> packet format and encryption algorithm.

How about; someone traces the application, figures out the point where 
packets are decrypted (which is a lot easier than figuring out the 
algorithm) and does some fancy debugging scripts (trivial with gdb, don't 
know about others) that dumps encrypted and unencrypted packages to files 
for later analysis?

Yep, seen that done (almost, purpose not related to games). In a perl
script, btw, that used gdb breakpoint on a wellknown binary.

> 
> [3] Someone gets source code sufficient to rebuild
> the client -- with any desired logic modification.
> ----------------------------------------------
> NO SOLUTION:
>   Well, this allows the hacker to create "bot"-like
>   shooting accuracy and scripted movement patterns
>   (like running directly to all ammo spawn points,
>   or pursuing enemies with the most efficient,
>   minimal paths).
>   Even if we totally distrust the client beyond
>   receiving the most basic events possible, it
>   doesn't seem possible to detect players that
>   are "too perfect"!

I agree with the no solution stuff. The whole issue of cheating in online 
games have been debated heavily in the OSS communities, espec. following 
the release of the Quake 1 source code. You might want to look some of 
these discussion up.

> I heard of simple stuff, like turning EVERYTHING semi-
> transparent, so you can see people through the walls.

Yep, everything is a tradeof.

Mads


-- 
Mads Bondo Dydensborg.                               ma...@ch...
FAITH, n. Belief without evidence in what is told by one who speaks without
knowledge, of things without parallel.
                        - Ambrose Bierce (The Devil's Dictionary)