CSE 565 – Fall 2005
Hardware Acceleration of Gaming Algorithm
Semantic Processing of TNL Game Traffic
Abdel Rigumye
Washington University in St. Louis
[email protected]
Copyright 2005
CSE 565 – F’05 – Rigumye
1
Torque Network Protocol
• Torque Network Library (TNL) Implements Torque Notification
Protocol
– Deals with packet loss
– Minimize bandwidth usage
• Semantic Aspect of the Protocol
– Specifies Format of packets exchanged between client
and server
– Packet Format detailed in Homework2
• Behavioral Aspect of the Protocol
– Specifies the behavior of clients and servers during packet
exchange
CSE 565 – F’05 – Rigumye
2
TNL Connection Establishment
• Notify is a Connection Oriented Protocol
•
client sends connection request packet to server
•
server sends connection response: client ID & puzzle
Client
Server
Client Proxy
Event List
•
Client sends puzzle solution & client ID Client Proxy
•
send notice of success
Event List
Connection
Connection
Ghost List
CSE 565 – F’05 – Rigumye
Ghost List
3
Processing Loop
•
After a connection is established Server/Client sit in the
following loop
1. Read Incoming Packets
2. Simulation Level Processing
3. Write Outgoing Packets
1. READ
CSE 565 – F’05 – Rigumye
2. Process
3. Write
4
Managers Logical View
• Read and Write stages handled by
•
•
•
•
Ghost Manager: Manages the delivery of Ghost Data
Move Manager: Manages the delivery of Move Data
Event Manager: Manages the delivery of Event Data
Stream Manager: Provides an API to write into Packet
Logical View
Simulation Layer
Ghost
Move
Event
Manager
Manager
Manager
Stream
Layer
Stream Manager
Connection Layer
CSE 565 – F’05 – Rigumye
5
Managers Actual View
• Actual View
– Move Manager Implemented by GameConnection Object
– Ghost Manager Implemented by GhostConnection Object
– Event Manager Implemented by EventConnection Object
• Class Hierarchy very Important
– Determines the order in which data appears in the packet
Connection
NetConnection
EventConnection
Event List
GhostConnection
Ghost Array
GameConnection
Client Proxy
CSE 565 – F’05 – Rigumye
6
Game – Manager Interaction
• Game Represented by an Object
– RetrieveGame, SoccerGame, RabbitGame
• Game Maintains a reference to GameConnection
– When game has an event to sent
• Uses EventConnection::postNetEvent(NetEvent *event) Interface
• Event added to Event List
– When Game Ghosts an object
• Uses GhostConnect::objectInScope(NetObject* object) Interface
• Ghost added to Ghost Array
Connection
NetConnection
EventConnection
Event List
Ev
GhostConnection
Ghost Array
Gh
GameConnection
Client Proxy
Ev
Game
CSE 565 – F’05 – Rigumye
7
Packet Sending
•
When Sending out data, a bitstream is created
– GameConnection will ask its client proxy to pack its state into the bitstream as
MoveData
– EventConnection will write its EventList in the EventData section
– GhostConnection will write its GhostArray in the Ghost section
– NetConnection will store all event and ghost data into a PacketNotify data structure
PacketNotify
Ev
Ev
Game Packet Header
Connection
NetConnection
Head
er
Gh
Move Data
Eventnection
EList
Event
Data
GhostConnectio
n
GArray
Ghost
Data
GameConnection
Client Proxy
Body
Game
CSE 565 – F’05 – Rigumye
8
Packet Reading
•
When Receiving a packet
– Based on the mLastSeqRecvd and AckFlag in the Game Header you can determine
out-of-order or lost packets
– In order-packets will cause deletion of the PacketNotify structure
– Out-of-order packets will cause the retransmission of data in the PacketNotify structure
– GameConnection will use its proxy to unpack MoveData and update the state of the
8 bits
client proxy
GP
SendSeq lsbits
PT
SendSeq msbits
RecvSeq msbits
PacketNotify
Ev
AckCount
Ev
Ack Fgs
SendDelay lsbits
RC
Connection
NetConnection
Gh
8 bits
Eventnection
Obect ID
GhostConnectio
n
CRC
CV
Pos x
Game
GameConnection
CSE 565 – F’05 – Rigumye
Client Proxy
9
Move Data Unpacking
•
To understand how the game connection unpacks data examine
Ship::readControlState(BitStream* stream)
[Ship.cpp ]
{
stream->read(&mMoveState[ActualState].pos.x);
stream->read(&mMoveState[ActualState].pos.y);
stream->read(&mMoveState[ActualState].vel.x);
stream->read(&mMoveState[ActualState].vel.y);
……..
…….
…….
stream->readRangedU32(0, WeaponCount);
}
CSE 565 – F’05 – Rigumye
10
Event Data Unpacking
•
Event Data treated differently
•
For each Event in the packet, the EventConnection:
– Reads the EventID and uses this create an EventObject
– The EventObject is responsible for unpacking the EventParam field
– After unpacking the Event, the EventObject executes the function
8 bits
Event ID
Unordered EventParam
Event ID
Connection
1. Read ID
NetConnection
Unordered EventParam
Event ID
Ordered EventParam
Eventnection
EventObject
GhostConnectio
n
2. Create
Event
3. Unpack
Ghost Data
Event Data
Execute function
GameConnection
CSE 565 – F’05 – Rigumye
11
Event Unpacking Continued
•
Event Data processing implements TNL’s Remote Procedure Call (RPC)
mechanism
•
Entire Process handled by Macros
•
Look at Macro definition to determine the content of the EventParam field
•
TNL_DECLARE(function_name, (param1, param2, param3) )
TNL_DECLARE_RPC(s2cSetGameOver, (bool gameOver) );
TNL_DECLARE_RPC(s2cLevelInfo, (StringTableEntry levelName, StringTableEntry levelDesc) );
CSE 565 – F’05 – Rigumye
12
Handling Strings
•
In order to conserver bandwidth TNL
– Uses Huffman Compression to transmit strings
– Maintains a cache of transmitted strings
• First time string is transmitted it is stored in a String Table
• Every entry in this table is associated with an ID
• Next time string is transmitted send ID instead of entire string
•
Problem
– Because Monitor sits between client and server must
• Implement Huffman Decoding in Hardware
• Cache strings in Hardware
• Change the way string are transmitted
String
String
Table
Table
String
Table
FPX
Game Server
Network
CSE 565 – F’05 – Rigumye
Network
Client
13