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

Simulation Engines TDA571|DIT030 Network programming Tommaso Piazza 1

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 IDC | Interaction Design Collegium 2

Networked games  Most games are played against some form of opponent  Last lecture we spoke about computer controlled opponents  This lecture we will discuss human controlled opponents  Human opponents often allows a lot more interesting gameplay  Massively Multiplayer Online Games are interesting examples IDC | Interaction Design Collegium 3

Example: Counterstrike  One of the most successful online games ever  Hundreds of thousands of active players IDC | Interaction Design Collegium 4

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 IDC | Interaction Design Collegium 5

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 IDC | Interaction Design Collegium 6

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!). IDC | Interaction Design Collegium 7

Fundamentals  Packet loss  Most networks are not perfect, and packets might be lost due to corrupted links or collisions. Packet loss is a measure of 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. IDC | Interaction Design Collegium 8

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. IDC | Interaction Design Collegium 9

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 IDC | Interaction Design Collegium 10

Protocols  A protocol typically defines the following  Detection of the underlying physical connection (wired or 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 IDC | Interaction Design Collegium 11

Protocol families  Of the protocol families listed here, we are mostly interested in the last one, Internet protocol suite IDC | Interaction Design Collegium 12

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 one end of a bi-directional communication link between two programs IDC | Interaction Design Collegium 13

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 IDC | Interaction Design Collegium 14

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 IDC | Interaction Design Collegium 15

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... IDC | Interaction Design Collegium 16

Socket tutorial  A brief overview IDC | Interaction Design Collegium 17

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); IDC | Interaction Design Collegium 18

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) IDC | Interaction Design Collegium 19