Simulation Engines TDA571|DIT030 Network programming Tommaso - - PowerPoint PPT Presentation

Simulation Engines TDA571|DIT030 Network programming

Tommaso Piazza

1

IDC | Interaction Design Collegium

Administrative stuff

• Next week NO LECTURES
• Mon 30/11 Wed 2/12
• but I will put up some times for supervisions, no

specific topic. Sign up if you fell your group needs it

• Last lecture is on the 7/12
• on that week physics presentation will take place
• 7/12 - 9/12 Doodle Poll
• Demo day 18/12 - 10:00-12:00 von Neumann

2

IDC | Interaction Design Collegium

Networked games

• Most games are played against some form of
• pponent
• Last lecture we spoke about computer controlled
• pponents
• This lecture we will discuss human controlled
• pponents
• Human opponents often allows a lot more

interesting gameplay

• Massively Multiplayer Online Games are

interesting examples

3

IDC | Interaction Design Collegium

Example: Counterstrike

• One of the most successful online games ever
• Hundreds of thousands of active players

4

IDC | Interaction Design Collegium

Example: World of Warcraft

• Ridiculously successful MMOG, released by

Blizzard on November 23rd, 2005

• 200 000 accounts were created during the first day
• more than 10 million players

5

IDC | Interaction Design Collegium

Networking issues

• Regardless of whether we want to create a small-scale

networked game such as Counterstrike or a huge MMOG like WoW the following issues need to be looked in to

• Which network architecture is suitable for our game? Client/

server or peer-to-peer (or a combination)?

• What kind of network protocols are useful for a computer game?
• How will we handle the issues of high lag (latency), low

bandwidth, and packet loss that exist on the Internet?

• The type of game naturally affects which kind of network

programming techniques we will use. What differs from a small- scale and a massive-scale multiplayer game?

• Chalmers has many interesting courses on networking

programing in general and Internet programming in particular

6

IDC | Interaction Design Collegium

Fundamentals

• Packet
• Network message. All information sent over the information

is split up into indivisible packets. Packets can be lost and may have to be resent depending on the protocol.

• Latency
• Network “lag” or latency is the delay associated with the time

between sending a message from a source and receiving it at the destination.

• Bandwidth
• Maximum information rate that can be sent over a particular

network connection (remember to distinguish bandwidth from latency!).

7

IDC | Interaction Design Collegium

Fundamentals

• Packet loss
• Most networks are not perfect, and packets might be lost

due to corrupted links or collisions. Packet loss is a measure

• f how high ratio of all packets are lost in transmission.
• Protocol
• Data format specification for embedding packets as well as

routines for reliability, acknowledgment, transfer, etc.

• Network architecture
• Topology of a particular network (or subset of a network)

involved in a particular system or protocol instance. Most common examples in this context include peer-to-peer (P2P) and client-server (C/S) architectures.

8

IDC | Interaction Design Collegium

Terms more related to games

• 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

• game. In order to avoid jerky in-game behavior, each client extrapolates the

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.

9

IDC | Interaction Design Collegium

Protocols

• Definition
• A protocol is a convention or standard that

controls or enables the connection, communication, and data transfer between two computing endpoints

• In computer networks protocol standards take the

for of Request for Comments (RFC)

• Memorandum published by the Internet

Engineering Task Force (IETF)

• TCP v4: http://tools.ietf.org/html/rfc793

10

IDC | Interaction Design Collegium

Protocols

• A protocol typically defines the following
• Detection of the underlying physical connection (wired
• r wireless), or the existence of the other endpoint or node
• 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

(error correction)

• How to detect unexpected loss of the connection, and

what to do next

• Termination of the session or connection

11

IDC | Interaction Design Collegium

Protocol families

• Of the protocol families listed here, we are

mostly interested in the last one, Internet protocol suite

12

IDC | Interaction Design Collegium

Socket programming

• The standard way of doing Internet programming

is to make use of a network socket library

• Berkeley sockets originated with the 4.2BSD system

in 1983

• The Windows implementation of the BSD Socket API

is called WinSock and includes a number of extensions specific to network sockets on Windows

• Definition of Socket
• A socket can be used in computer networking to form
• ne end of a bi-directional communication link

between two programs

13

IDC | Interaction Design Collegium

Socket programming

• The following header files are involved in C

programming with BSD sockets under UNIX (similar on Windows)

• 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

14

IDC | Interaction Design Collegium

Socket programming

• A socket is an endpoint in a two-way

communication link between two parties

• An Internet (TCP/IP) socket is (explicitly or

implicitly) bound to a specific address (hostname and port number) and can be connected to another socket with another address

• Potentially on another computer

15

IDC | Interaction Design Collegium

Internet address

• Internet addresses are
• 32-bit numbers, usually represented as four bytes on the form xxx.yyy.zzz.www
• They are also identified by a 16-bit port number
• Normal connection sockets do not care about the exact address,

but a server usually binds a specific server socket to a pre- defined address

• Such a server socket listens for inbound connections and then creates a new

socket for the actual client-server communication

• Only one socket can be bound to a specific address at any

time

• Port numbers below 2000 are ordinarily reserved
• Port numbers below 1024 need Root access to bind
• HTTP is port 80, FTP is port 21, Telnet is port 23, etc...

16

IDC | Interaction Design Collegium

Socket tutorial

• A brief overview

17

IDC | Interaction Design Collegium

Socket tutorial: Server code

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);

18

IDC | Interaction Design Collegium

Socket tutorial: Client code

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)

19

IDC | Interaction Design Collegium

Managing several clients

• 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 on a set of sockets).

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

20

IDC | Interaction Design Collegium

UDP datagrams

• The previous example used TCP (Transmission Control Protocol) for

the transfer

• TCP is a reliable stream-based protocol that guarantees ordered

delivery of all information sent over the socket

• Bad connectivity and high packet loss might produce a large overhead when

resending and reordering packets

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

21

IDC | Interaction Design Collegium

Final words about sockets

• It often makes sense to have two connections

per client

• A TCP socket for game-critical information

(messages, deaths, etc)

• A UDP socket for non-critical information

(position updates, etc)

• TCP-like functionality can be manually

recreated using UDP

22

IDC | Interaction Design Collegium

Network architectures

• 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
• n 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) communicate.

The server may or may not be an active participant in 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.

23

IDC | Interaction Design Collegium

Client/Server

• 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

24

IDC | Interaction Design Collegium

Client/Server

25

IDC | Interaction Design Collegium

Peer-to-peer

• A peer-to-peer networked game has no single server, but

rather the world state is shared among the various peers which are all

• Benefits
• No single point of failure, no bottleneck
• Simple implementation
• Easy to build on top of an existing game
• Drawbacks
• 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

26

IDC | Interaction Design Collegium

Peer-to-peer

27

IDC | Interaction Design Collegium

Advanced P2P techniques

• 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
• ther 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
• n 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

28

IDC | Interaction Design Collegium

Network programming for games

• An extremely basic multiplayer game loop might look like

this

• Receive messages from other peers (or the server)
• Process messages, updating local copy of game

state accordingly

• Send message about my status to other peers (or

server)

• Render the frame and perform other world updates
• In the following slides, we will look at the issues that effect

these steps as well as take a peek at middleware solutions that can be of assistance

29

IDC | Interaction Design Collegium

A few issues

• The internet
• The Internet is dreadful for multiplayer gaming simply due to his

high lag, low bandwidth, and high packet loss. We need to come up with ways to provide a playable game despite this

• Encryption
• We may have to encrypt our network data to avoid eavesdropping

by malicious users

• Firewalls
• Many players are behind firewalls on the Internet, yet still want to

participate in multiplayer games

• Denial-of-service
• Players can be denied access to a game, usually through flooding

30

IDC | Interaction Design Collegium

Lag, bandwidth and packet loss

• Three fundamental issues that we must face as

network programmers

• Limited bandwidth
• The data transfer rate over a network is limited and certainly

magnitudes smaller than that within the internal memory bus

• f a computer.
• Packet loss
• Networks are unreliable and packets are often lost in transit.
• High latency
• The delay between sending and receiving a message over

the network can be long, especially for games played over the Internet.

31

IDC | Interaction Design Collegium

Managing bandwidth

• 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

32

IDC | Interaction Design Collegium

Managing bandwidth

• Message prioritization
• Important messages should not be clogged down by

less important messages; implement a priority scheme to allow client programmers to specify the importance of a message

• Incremental updates
• Game objects rarely change their whole state at the

same time. We cannot rely on incremental updates indefinitely; sooner or later, packet loss will ensure that the players’ view of the game objects will drift from their true state. Once in a while we need to synchronize game object state

33

IDC | Interaction Design Collegium

Managing packet loss

• TCP does a good job of ensuring reliable message transfer,

but the considerable overhead associated with the protocol is not a desirable property for a real-time networked simulation

• Similarly, the totally unreliable UDP protocol is also not

suitable for a real-time simulation where we may have to ensure message delivery for some messages

• Two basic solutions
• Use two connections per client, one TCP and one UDP. This is a

workable solution that is used by a few games, but which results in slightly more complex network code than for just one connection

• Implement our own protocol on top of UDP that provides us with

the features we need

34

IDC | Interaction Design Collegium

Our own UDP-based protocol

• 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
• rder they were sent. This is the strongest transmission policy and is essentially

the same as TCP.

• Guaranteed delivery
• Messages are required to be delivered at the destination, but not necessarily in

the order they were sent.

• Non-guaranteed delivery
• Messages have no requirements on delivery; they are processed by the

destination if they arrive and are not resent if they do not.

35

IDC | Interaction Design Collegium

Managing latency

• Latency (or lag) is the delay from the sender

sending a message to the receiver actually receiving it

• Caused by hardware and the constant speed of light
• In network gaming we are often mostly interested

in roundtrip times (the time for server->client- >server)

• Roundtrip times of 250 milliseconds are not uncommon
• All clients involved in a network game see an outdated

version of the world; only the server knows the real version

36

IDC | Interaction Design Collegium

Managing latency

• 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 behavior

• 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
• bserving players so that they can more accurately predict the player's behavior

37

IDC | Interaction Design Collegium

Security and encryption

• We have virtually no control over which

networks our data is sent, and in many cases we send sensitive information (i.e. credit card information etc.)

• Symmetric encryption
• Two parties communicating over a shared but

insecure connection and sharing a common and secret key

• The key is used for both encoding and decoding the

data so that no malicious eavesdroppers can read it

• Requires secure key exchange

38

IDC | Interaction Design Collegium

Security and encryption

• Asymmetric 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 cryptographic 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

39

IDC | Interaction Design Collegium

Distributed objects

• In a game networking layer it might be a good idea to raise the

abstraction level from sockets and packets to distributed

• bjects
• One useful metaphor for implementing distributed 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-oriented

distributed entities living on the network and which support 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
• bject reference to a Player-object residing on the server, allowing it

to call methods such as Player.Shoot(), Player.Run(), Player.Duck(), etc.

40

IDC | Interaction Design Collegium

Existing game networking APIs

• We will take a brief look at two existing game

network engines

• OpenTNL
• The open source version of the Torque Network

Layer

• Quazal Net-Z
• A commercial multiplayer engine

41

IDC | Interaction Design Collegium

Torque Network Layer

• 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

42

IDC | Interaction Design Collegium

Quazal Net-Z

• Quazal Net-Z API is a commercial multiplayer

engine for games

• Used in Company of Heroes, Supreme

Commander, Hitman, etc

• The key feature is that it deals with distributed

game objects described using DDL (Data Definition Language)

• Client programmers only have to worry about

integrating Net-Z objects into their game code

43

IDC | Interaction Design Collegium

Quazal Net-Z

• 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

44

IDC | Interaction Design Collegium

Massively Multiplayer Online Games

• The rise of the Internet led to the development of text-
• nly multiplayer games known as MUDs
• MUDs, modern computer graphics and conventional

single-player games eventually combined to spawn a whole new generation of MMOGs

• Some of the first commercial 3D MMOGs include

Meridian 59, Everquest and Asheron's Call

• Nowadays people tend to think about games such as

WoW, Eve Online, Lineage, Aion, AoC

• These games show potential for a lot of business but

bring a whole new array of network issues

45

IDC | Interaction Design Collegium

Special issues for MMOGs

• Network architecture
• With thousands of simultaneous connected users, the issue of which

network architecture to choose is difficult: a single server can quickly become a bottleneck. Cluster architectures are common

• Security and cheating
• Competitive online games are very welcome targets for malicious

users who want to gain an upper hand. Therefore, we must work hard to minimize possibilities of tampering with the client or the network traffic to cheat

• Reliability, patching and updating
• The more players we have connected to our server, the more

unhappy customers we will get if the server goes down (planned or not). We have to deal with issues how to update (or “patch”) the game as well as the clients

46

IDC | Interaction Design Collegium

Special issues for MMOGs

• Relevance filtering
• Managing the interest of players and only sending

them information that is relevant to them is vital in a game with thousands of connected users

• Operating system limits
• In some cases, we may for instance have to

increase the total number of open sockets in the

• perating system to support a huge online game

47

IDC | Interaction Design Collegium

Example: Quazal Eterna

• Eterna is Quazal's middleware framework for

MMOGs

• Based on the same principles as Net-Z, but has been

adapted to support large-scale network applications

• Duplication spaces
• Dynamically configurable objects that partition the virtual

world based on a publish/subscribe mechanism

• Configurable network topology
• Control over how information is sent over the network,

including restrictions on where Duplicated Objects are created, where they reside, who may discover them, and who may modify them

48

IDC | Interaction Design Collegium

Example: Quazal Eterna

• Load balancing
• Duplicated objects migration allowing for exploiting

the server cluster’s available processing power and reduce bandwidth usage via workload distribution

• Fault tolerance
• Automatic migration of duplicated objects to ensure

their survival

• Hierarchical messaging
• Individual stations (server or client) can update all of

their duplicates using a hierarchy of intermediate stations

49

IDC | Interaction Design Collegium

Summary

• Multiplayer functionality in computer games has become more

and more important as connectivity increases

• There are lots of issues plaguing networked games that we

have to take into account; network programming for games is (much) more than sockets and packets

• Different network architectures are suitable for different kinds
• f games
• The three major factors of network programming are low

bandwidth, packet loss, and high latency

• We also have to consider aspects of security and encryption
• Massively-multiplayer online games (MMOGs) introduce a

whole new set of issues that we have to deal with to create a successful game

50