Network Programming Simulation Engines 2008 Chalmers University of - - PowerPoint PPT Presentation
Network Programming Simulation Engines 2008 Chalmers University of Technology Markus Larsson markus.larsson@slxgames.com 08-11-26 Simulation Engines 2008, Markus Larsson 1 Networked games Most games are played against some form of
08-11-26 Simulation Engines 2008, Markus Larsson 1
08-11-26 Simulation Engines 2008, Markus Larsson 2
Most games are played against some form of
Last lecture we spoke about computer controlled
This lecture we will discuss human controlled
Human opponents often allows a lot more
Massively Multiplayer Online Games are
08-11-26 Simulation Engines 2008, Markus Larsson 3
One of the most successful online games ever
Hundreds of thousands of active players
08-11-26 Simulation Engines 2008, Markus Larsson 4
Ridiculously successful MMOG, released by
200 000 accounts were created during the first day
08-11-26 Simulation Engines 2008, Markus Larsson 5
Which network architecture is suitable for our game?
What kind of network protocols are useful for a computer
How will we handle the issues of high lag (latency), low
The type of game naturally affects which kind of network
08-11-26 Simulation Engines 2008, Markus Larsson 6
Network message. All information sent over a
Network “lag” or latency is the delay associated with
Maximum information rate that can be sent over a
08-11-26 Simulation Engines 2008, Markus Larsson 7
Most networks are not perfect, and packets might be lost
Data format specification for embedding packets as well as
Topology of a particular network (or subset of a network)
08-11-26 Simulation Engines 2008, Markus Larsson 8
Lobby service
Players often need a virtual meeting place outside the game itself where they can meet, chat, and form games. This place is often called a “lobby”, and a lobby service is a middleware allowing for the creation of such lobbies.
Dead reckoning
The imperfect nature of the Internet means that games will be plagued by high latency and high packet loss. This means that we will often be unable to send frequent updates of the object state to the players participating in a
position of the objects given their old position and velocity.
Security
There are lots of malicious users on the Internet and we must take care to protect our game as well as the players from these. Security in multiplayer games is a whole lecture in itself (maybe even a whole course!), but we will just talk briefly about this subject.
08-11-26 Simulation Engines 2008, Markus Larsson 9
Definition
A protocol is a convention or standard that controls
08-11-26 Simulation Engines 2008, Markus Larsson 10
Detection of the underlying physical connection (wired or
Handshaking Negotiation of various connection characteristics How to start and end a message How to format a message What to do with corrupted or improperly formatted messages
How to detect unexpected loss of the connection, and what
Termination of the session or connection
08-11-26 Simulation Engines 2008, Markus Larsson 11
Of the protocol families listed here, we are
08-11-26 Simulation Engines 2008, Markus Larsson 12
The standard way of doing Internet programming is to
Berkeley sockets originated with the 4.2BSD
The Windows implementation of the BSD Socket
Definition of Socket A socket can be used in computer networking to
08-11-26 Simulation Engines 2008, Markus Larsson 13
The following header files are involved in C programming
sys/socket.h Definitions for the most basic of socket structures sys/types.h Basic data types associated with structures within the API netinet/in.h Definitions for socketaddr in and other base data structures sys/un.h Definitions and data type declarations for SOC UNIX streams sys/select.h Definitions for the use of the select family of functions
08-11-26 Simulation Engines 2008, Markus Larsson 14
A socket is an endpoint in a two-way
An Internet (TCP/IP) socket is (explicitly or
Potentially on another computer
08-11-26 Simulation Engines 2008, Markus Larsson 15
32-bit numbers, usually represented as four bytes on the form
They are also identified by a 16-bit port number
Such a server socket listens for inbound connections and then
Port numbers below 2000 are ordinarily reserved Port numbers below 1024 need Root access to bind
08-11-26 Simulation Engines 2008, Markus Larsson 16
A brief overview
08-11-26 Simulation Engines 2008, Markus Larsson 17
int sockfd, newsockfd, portno, clilen, n; struct sockaddr_in serv_addr, cli_addr; char buffer[256]; sockfd = socket(AF_INET, SOCK_STREAM, 0); // (1) bzero((char *) &serv_addr, sizeof(serv_addr)); serv_addr.sin_family = AF_INET; serv_addr.sin_port = htons(port_number); serv_addr.sin_addr.s_addr = INADDR_ANY; bind(sockfd, (struct sockaddr *) &serv_addr, sizeof(serv_addr)); // (2) listen(sockfd, 5); // (3) clilen = sizeof(cli_addr); newsockfd = accept(sockfd, (struct sockaddr *) &cli_addr, &clilen); // (4) bzero(buffer, 256); n = read(newsockfd, buffer, 255); // (5) printf("Message: %s\n", buffer);
08-11-26 Simulation Engines 2008, Markus Larsson 18
int sockfd, portno, n; struct sockaddr_in serv_addr; struct hostent *server; sockfd = socket(AF_INET, SOCK_STREAM, 0); // (1) server = gethostbyname(server_name); bzero((char *) &serv_addr, sizeof(serv_addr)); serv_addr.sin_family = AF_INET; bcopy((char *) server->h_addr, (char *) &serv_addr.sin_addr.s_addr, server->h_length); serv_addr.sin_port = htons(port_number); connect(sockfd, &serv_addr, sizeof(serv_addr)); // (2) fgets(buffer, 255, stdin); write(sockfd, buffer, strlen(buffer)); // (3)
08-11-26 Simulation Engines 2008, Markus Larsson 19
The client/server examples only support one client and one server
In a real system, we will want to continue listening to other connections on the connect socket while simultaneously handling communication with the already connected clients as well
There are two approaches to this
Input/Output multiplexing
Switch the communication sockets to be non-blocking and use the
select() system call to manage input and output from a number of sockets in a sequential way (select() allows you to wait for input/output
Introduce concurrency
Implement concurrency in our server program so that different parts of
the server can handle the clients and the connections simultaneously.
The traditional UNIX way is to fork() child processes off the main server
process to handle clients; this is however not very practical for a game server where clients co-exist in the same virtual world, so here it is better to assign individual threads to users.
08-11-26 Simulation Engines 2008, Markus Larsson 20
The previous example used TCP (Transmission Control Protocol) for the transfer
TCP is a reliable stream-based protocol that guarantees ordered delivery
Bad connectivity and high packet loss might produce a large
UDP (User Datagram Protocol) is an unreliable message-based protocol where information is sent in variable-sized chunks called datagrams
UDP datagrams have no guarantee of delivery, but this is sufficient for non-critical game information
In order to create an UDP socket, we specify SOCK DGRAM instead of SOCK STREAM when creating our socket. In addition, we use the sendto() and recvfrom() calls for sending and receiving datagrams, respectively.
08-11-26 Simulation Engines 2008, Markus Larsson 21
It often makes sense to have two connections
A TCP socket for game-critical information
A UDP socket for non-critical information (position
TCP-like functionality can be manually
08-11-26 Simulation Engines 2008, Markus Larsson 22
The network architecture of a game specifies the topology of the hosts involved in the game and their communication structure and protocol
Typically, game developers will implement their own game protocol on top of TCP/UDP and design it to fit the network architecture selected
Client/Server
Star network with a central server through which all clients (hosts)
the game itself.
Client/Server cluster
Similar as C/S architectures, except the server load is shared among a cluster of interconnected computers instead of a single one.
Peer-to-Peer
No central server, all peers communicate (more or less) directly with each other. Truly distributed system.
08-11-26 Simulation Engines 2008, Markus Larsson 23
A client/server multiplayer game has two kinds of entities
Clients
The normal computers playing the game over the network
Servers
The coordinating hosts storing the universal game state and arbitrating the
actions of individual clients
Benefits
Relatively easy to implement
Synchronization and consistency easy
Cheating can be controlled by the server
Communication is minimized
Drawbacks
All communication goes through the server
Usually requires planning in the design stages of a game, adding it last will be difficult
Single point of failure; If the server goes down, the whole game goes down
08-11-26 Simulation Engines 2008, Markus Larsson 24
08-11-26 Simulation Engines 2008, Markus Larsson 25
No single point of failure, no bottleneck Simple implementation Easy to build on top of an existing game
Lots of communication Synchronization and consistency can become difficult Scalability is poor without an extremely well thought out design Easy to cheat on clients Firewalls can be a major pain in the ***
08-11-26 Simulation Engines 2008, Markus Larsson 26
08-11-26 Simulation Engines 2008, Markus Larsson 27
There are many obvious drawbacks to P2P mechanisms for multiplayer games, here are a few possible solutions
Poor scalability
Clearly, not everyone in the world needs to know about every event that
affects other peers, especially if they are not geographically close. Use an interest-management technique to filter out relevant information.
Costly communication
Use techniques for broadcast and multicast (group communication) to
cut down on communication costs (problem: not supported by all network hardware, must be implemented in software).
Easy to cheat
Involve a trusted (or randomly selected) third party to arbitrate all critical
transactions (i.e. ask C whether A hit B). Can be difficult (but not impossible) to solve.
Many of these areas are still being researched and very few commercial games use peer-to-peer communication
08-11-26 Simulation Engines 2008, Markus Larsson 28
08-11-26 Simulation Engines 2008, Markus Larsson 29
An extremely basic multiplayer game loop might
In the following slides, we will look at the issues
08-11-26 Simulation Engines 2008, Markus Larsson 30
The Internet is dreadful for multiplayer gaming simply due to
We may have to encrypt our network data to avoid
Many players are behind firewalls on the Internet, yet still want
Players can be denied access to a game, usually through
08-11-26 Simulation Engines 2008, Markus Larsson 31
Limited bandwidth The data transfer rate over a network is limited and
Packet loss Networks are unreliable and packets are often lost in
High latency The delay between sending and receiving a message
08-11-26 Simulation Engines 2008, Markus Larsson 32
Static data
Caching
Transmit information once and thereafter use a integer identifier for it
Initialization
Transmit static information once when the client connects, never during
actual game play
Data compression
Packing
Use an algorithm to tightly pack messages; encode booleans as bits, floats
as fixed point numbers, etc
Compression
Use a data compression scheme (i.e. Huffman coding) to compress
messages
Relevance filtering
Define a metric to decide whether a specific event is relevant or not for a specific client
08-11-26 Simulation Engines 2008, Markus Larsson 33
Message prioritization Important messages should not be clogged down by
Incremental updates Game objects rarely change their whole state at the
08-11-26 Simulation Engines 2008, Markus Larsson 34
Use two connections per client, one TCP and one UDP. This is a
Implement our own protocol on top of UDP that provides us with
08-11-26 Simulation Engines 2008, Markus Larsson 35
We have already remarked that there are different kinds of network data
Important and less important
Because of this, it makes sense to provide different policies in our network protocol
Guaranteed order
Messages are required to be guaranteed delivery at the
destination in the same order they were sent. This is the strongest transmission policy and is essentially the same as TCP.
Guaranteed
Messages are required to be delivered at the destination, but not
necessarily in the order they were sent.
Unguaranteed
Messages have no requirements on delivery; they are processed
by the destination if they arrive and are not resent if they do not.
08-11-26 Simulation Engines 2008, Markus Larsson 36
Latency (or lag) is the delay from the sender sending a
Caused by hardware and the limited speed of light In network gaming we are often mostly interested in
Roundtrip times of 250 milliseconds are not
All clients involved in a network game see an
08-11-26 Simulation Engines 2008, Markus Larsson 37
Interpolation
Interpolation is used perform smooth transitions between old and new object state (usually position and velocity) to avoid visible “pops”.
Extrapolation
We take our best guess at the new state of an object given its past state and predict future behaviour
Positional state is easily extrapolated by adding the velocity vector times the time difference to the old position vector
If we know the acceleration vector of the object, we can update the velocity vector as well
Client-side prediction
Player-controlled entities move unpredictably and cannot be easily extrapolated
In some cases, it is possible to forward the input commands of one player to
behavior
08-11-26 Simulation Engines 2008, Markus Larsson 38
We have virtually no control over which networks our
Symmetric encryption Two parties communicating over a shared but
The key is used for both encoding and decoding the
Requires secure key exchange
08-11-26 Simulation Engines 2008, Markus Larsson 39
Assymetric encryption
Also known as public key cryptography, this scenario also involves two parties on an insecure connection, but here each user has a public and a private key. A user’s public key is used to encode messages for a that user so that only the user himself can decode it using his private key.
Computationally much more expensive than symmetric encryption
Very useful for key exchange for symmetric encryption
Message authentication
In order to detect malicious tampering with messages, we can tag each message with a message authentication code (MAC) generated using a secure cryptographical hashing function
Digital signatures and certificates
Certificates and signatures allow for the verification of the public key of a user to avoid Man-in-the-Middle attacks
08-11-26 Simulation Engines 2008, Markus Larsson 40
In a game networking layer it might be a good idea to raise the abstraction level from sockets and packets to distributed objects
One useful metaphor for implementing distribut,ed objects is the RPC mechanism (Remote Procedure Call)
Allows nodes to remotely execute methods in an object over the network
Allows us to implement our game objects as first-class object-
method invocations
Also allows programmers to specify properties for different parts of the state of a game object to control updates and relevance filtering
For example, a client in a first-person shooter can receive a network
to call methods such as Player.Shoot(), Player.Run(), Player.Duck(), etc.
08-11-26 Simulation Engines 2008, Markus Larsson 41
We will take a brief look at two existing game
OpenTNL
The open source version of the Torque Network
Quazal Net-Z
A commercial multiplayer engine
08-11-26 Simulation Engines 2008, Markus Larsson 42
The Torque Network Layer (TNL) and OpenTNL is the network layer on the Torque engine
UDP based delivery notification connection protocol
Two-phase connect for prevention of IP spoofing attacks
Client-puzzle system for server CPU depletion Denial of Service protection
ECC key exchange and certificate authentication
AES symmetric encryption with SHA-256 message authentication
Efficient packet streaming architecture for consistent bandwidth utilization
Bit-level compression for optimal bandwidth utilization
Huffman encoded strings and common substring skipping
Simple and efficient event and RPC (remote procedure call) framework
Extensible master server framework
08-11-26 Simulation Engines 2008, Markus Larsson 43
Quazal Net-Z API is a commercial multiplayer
Used in Company of Heroes, Supreme
The key feature is that it deals with distributed
Client programmers only have to worry about
08-11-26 Simulation Engines 2008, Markus Larsson 44
Duplicated objects
Decentralized, distributed objects describing all the network-relevant information about that game object
Duplicated object migration
Duplication master objects can migrate from one station to another
DObject & session fault tolerance
When a station fails, any distributed objects will migrate to another station to ensure that the object survives the fault
Dead reckoning
Net-Z’s dead reckoning (data extrapolation) reduces bandwidth usage by avoiding sending unnecessary updates across the network
Latency masking techniques
Application topology
Objects are known globally but programmers can dictate who controls what
Synchronized user inputs
Functionality for to propagating and synchronizing user inputs across the network
08-11-26 Simulation Engines 2008, Markus Larsson 45
The rise of the Internet led to the development of text-only
MUDs, modern computer graphics and conventional
Some of the first commercial 3D MMOGs include Meridian
Nowadays people tend to think about games such as
These games show potential for a lot of business but bring
08-11-26 Simulation Engines 2008, Markus Larsson 46
With thousands of simultaneous connected users, the issue of
Competitive online games are very welcome targets for malicious
The more players we have connected to our server, the more
08-11-26 Simulation Engines 2008, Markus Larsson 47
Relevance filtering
Managing the interest of players and only sending
Operating system limits
In some cases, we may for instance have to
08-11-26 Simulation Engines 2008, Markus Larsson 48
Based on the same principles as Net-Z, but has been
Dynamically configurable objects that partition the virtual
Control over how information is sent over the network,
08-11-26 Simulation Engines 2008, Markus Larsson 49
Load balancing
Duplicated objects migration allowing for exploiting
Fault tolerance
Automatic migration of duplicated objects to ensure
Hierarchical messaging
Individual stations (server or client) to update all of
08-11-26 Simulation Engines 2008, Markus Larsson 50