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

[brian h. <bri...@py...>]

> 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?

Yes.  And you allow the server operator to override in case there is a 
conflict.

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

Quake simulated at 10 fps.  I think Q2 and Q3 were 20 fps.  The amount 
of data varies GREATLY depending on application and how well you 
compress.  The best thing to do is to sort out what your packets will 
look like and then how much delta compression you can manage.  I don't 
think you can really say there's a ball park estimate that's reasonable 
since it depends so much on your genre, core tech, and how aggressive 
you are about quantization, compression, and update rate.
 
>   Thus, I can place any client event in to a single
> server timeline, regardless of network glitches.

Hmmm, never really thought about that.  I'll let someone else answer, 
but my guess if that's actually what you want to do, then you can 
investigate a protocol like NTP.

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

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