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

[Tom H. <to...@3d...>]

At 02:23 PM 9/23/2002, Colin Fahey wrote:
>   [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?

No. The dominant way is to use a lobby server. GameSpy provides a generic 
interface for different games to use, and it's supported by just about 
every game out there these days. It used to be that every game made their 
own lobby server protocol in addition to GameSpy, but I wouldn't be 
surprised if they've all shifted to GameSpy only at this point. This is 
probably more true for FPS games than other genres.

>   [B] For Internet games the port(s) can be fairly arbitrary
>(anything above 1024 and below 65536, right?), but for
>convenient "discovery" of servers on a LAN it might be nice
>to have a few preferred port candidates to try -- instead
>of broadcasting to all 64000 ports in a brute-force search.
>
>   QB1:  How might one select "default" port ranges for the
>convenience of LAN clients searching for servers?

In practice, each game sets up a default range of ports (or only a single 
port in many cases). These ports should be different from game to game, but 
even if they're not you're still OK. Remember, getting the port is only 
part of the process ... if the traffic sent back and forth doesn't match, 
then you're not running on a valid server. The ports can typically be 
changed by the end-users in one way or another if they have to resolve 
"bad" conflicts (another application crashes or behaves badly when it gets 
a packet it doesn't recognize ... this should be very rare).

>   QB2:  Might a server on a LAN advertise itself periodically,
>like once per second?...Perhaps only during the "join" phase of
>a game (if players can't just jump in at any time)?
>This sounds pointless when clients can essentially do
>the queries as needed, but maybe when the server is on
>a totally random port (but advertises itself on a known
>port), it might make it easier for clients to discover
>the server (just by listening on a known port for the
>unsolicited broadcasts of the server).

It is much better for the clients to broadcast a packet that says, "If 
you're a server, send a response back please" than it is for the servers to 
periodically pulse out a heartbeat. You also need the ability to enter an 
IP address by hand for networks that have disabled broadcast.

>   [C] Some applications have one "well-known" port for
>initiating sessions and create ports for handling those
>sessions.
>
>   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. This is the preferred way to do it for the relatively small number of 
users in these types of games. Larger games (MMP) may do better to spread 
the traffic over multiple ports, but that's going to be heavily dependant 
on the OS and such. Fortunately, you're not asking how to build a MMP 
networking system ;)

>   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?
>(The "real" game might be some RANDOM port, but the
>service for joining the game might be on the "well-known
>port range".)

I don't see what the benefit would be, and it would only seem to make 
things more difficult for . It's useful to have the lobby server traffic on 
a different port than the game server port, but unless you're doing 
something painful in the authentication, there shouldn't be any reason to 
break it off.

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

I can't speak for all FPS games, but the one I've worked on did ;) I'm 
under the impression that all the others do it that way as well.

>I basically want to learn from the experience of others
>regarding the basic mechanics of "discovering"
>servers (Internet and LAN), choosing port(s), and
>choosing a total number of used ports for a single server.

1. Use GameSpy for a lobby server for internet play.
2. Use a broadcast packet from the client on a known port to discover 
servers for LAN play.
3. Use a single (different) UDP port for all authentication / gameplay traffic.

There is one option to consider ... include authentication of CD keys as 
part of the lobby server functionality (I think this is how Q3A works, but 
it's been a while).

Tom