What Does a Game Networking Library Need?
Here is the protocol stack I would build for a networked
game library, in order to serve a variety of action, MMO
and turn-based games in a variety of settings. The goal
would be to support different kinds of networked entity
implementations without necessarily imposing policy. The
closest to policy it would probably come would be the
entity state description, which by necessity needs to use
some form of meta-data description, which typically needs
to be statically defined. Possible options include:
- C++ type templates
- C-style format strings
- SunRPC, COM and CORBA style code generation
Persistency of objects can use some functions of this
protocol stack (such as marshalling and entity support),
but is not really a networking function (it's a database
function).
The numbers indicate what layer a specific functionality
group lives at. Thus, the lobbying, peer, server and client
groups all live at layer 4 within the system, on top of the
RPC and State sync layers.
Each line item needs a specific piece of support; some of
the line items are there to support items in layers above.
For example, message sequence numbers and acks must be
available to the messaging layer, so that it knows whether
to re-send queued reliable messages. As another example,
pretty much all layers will get data from the clock
estimator, telling them when the given message/event was
sent and received.
Other things to note:
- User identity lives in Lobbying and Server, but actually
needs to reach all the way down to packet framing, for
authentication purposes.
- Some of these concepts may eventually be removed from the
layer as such, and just represented as arguments. For
example, user identity could be represented in a separate
persistency database, and just passed in (together with a
key) as arguments.
Layer | Group | Feature | Etwork Support |
4. | Lobbying | Game name | |
Game type | |
User identity | |
User groups | |
Permissions | |
Chat | |
NAT traversal | |
Peer | Peer group management | |
Server election | |
Lobby connection | |
Peer connection | |
Server | Packet forwarding | |
Data validation | |
Lobby listing | |
Object lifetime | |
User <-> Client mapping | |
User identity | |
Server announcement | |
Client connection | |
Client validation | |
Client | Shadow object lifetime | |
Focus object messaging | |
Server discovery | |
Server connection | |
Lobby connection | |
3. | RPC | Application target | |
Function | |
Arguments | |
State sync | Entity id | |
State description / Marhshalling / Meta-data | |
Sync rules / Periodic re-send / Dirty re-send / Reliable update | |
Entity publishing / Priority sort / Bandwidth management | |
2. | Messages | Delivery guarantee / Per channel | |
Ordering guarantee / Per channel | |
Application targets | |
Payload / May include source as protocol data | |
1. | Packet framing | Message bundling | |
RTT estimation | |
Clock sync | |
Authentication | |
Sequence number | |
Sequence number ack | |
String table | |
Channel management | |
Keepalive transmission | |
Encryption | |
0. | Network packet I/O | Host addressing | 0.1 |
Host name resolution | 0.1 |
Connection | 0.1 |
Timeout | 0.3 |
Binary serialization | 0.3 |
Queuing | |
Delivery notification | 0.2 |