"#' %#& Lecture 7: Organizing Game Clients and Servers. Socket: Network communication endpoints. IP address: IP-level name of a machine

Transcription

1 Lecture 7: Organizing Game s and Servers! Socket: communication endpoints Analogous to a file descriptor Apps read/write to/from sockets system handles delivery IP address: IP-level name of a machine One IP address may map to multiple machines Multiple IP addresses may map to the same machine IP level does not care delivers packets to machine w/ IP address Port: Transport level name of a socket/endpoint Servers listen on a designated port number s send to (and listen for responses from) a port number When you create a socket, you typically bind it to a particular remote IP address and port number "#$ %#& connect(); send(); recv(); // Reply close bind(); listen(); accept(); recv(); // Request send(); // Reply close SERVER Windows-isms CLIENT "#' %#& connect(); send(); recv(); // Reply close(); bind(); recvfrom(); // Request sendto(); // Reply close(); SERVER Windows-isms ( #&# Problem: In our simple TCP servers, once we accept one client s connection, we ignore the rest! Solution: Need to keep listening for connection requests so that we can accept() them. How? Option 1: Create a truly concurrent server» Spawn a new thread or process per client (fork())» Use thread to listen for input from that client only Option 2: Fake concurrency» Use non-blocking I/O» Key system call select() CLIENT

2 )$ %)** &!#+,- // Create TCP socket int sock = socket(af_inet, SOCK_STREAM, IPPROTO_TCP); // Set up address info struct sockadd_in adr; struct hostent *H = gethostbyname( foo.com ); adr.sin_family = AF_INET; adr.sin_port = htons(port); adr.sin_addr.s = INADDR_ANY; bzero(adr.sin_zero, 8); // Bind socket to address bind(sock, &adr, sizeof(adr)); // Go into passive mode listen(sock, 6); struct sockaddr_in connaddr; int caddrsize; int newsock=accept(socket, &connaddr, &caddrsize); // Spawn handler switch(fork()) { case 0: // child comm(newsock, commadr); exit(); case -1: // error! exit (-1); default: close(newsock); break; Non-blocking I/O: Calls to I/O device (network) do not block if no is ready How do we utilize asynchronous I/O? int on=1; ioctlsocket(socket, FIONBIO, &on); select(maxfd, readset, writeset, acceptset, timeout);» Returns if there is activity on any socket in sets of file descriptors described by {readset, writeset, acceptset)» Final parameter is timeout value if non-zero» If no activity on any socket, select() returns after timeout secs» Returns number of sockets ready (-1: error, 0: timeout )$ %#* int msgsock; char buf[1024]; fd_set rdy; // set of sockets int maxsocks; // Create TCP socket int sock = socket( ); // Set up address info struct sockaddr_in adr; adr.sin_family = ; bind(sock, &adr, sizeof(adr)); listen(sock,6); FD_ZERO(&rdy); // init empty FD_SET(sock, &rdy); // add socket while(1) { struct timeval to; to.tv_sec = 5; to.tv_usec = 0; // Any socket activity??? select(maxsocks, &rdy, 0, 0, &to); if (FD_ISSET(sock, &rdy)) { // Accept new connection msgsock = accept(sock, 0, 0); maxsocks++; else { // Process Which design do you think is preferable? Why? Concurrent server:» Much simpler communication infrastructure» Natural load balanacing» Need to worry about concurrency control (locking) Pseudo-concurrent (select)» Complex communication infrastructure» Need to worry about blocking I/O while processing request» Less need to worry about concurrency control What gets used in practice? Beats me, but I suspect largely event-drive, thread-oriented For large-scale systems, asynchronous I/O tends to scale better $/"#/ -. -.# General principles: Not all apply to games -server Dispatcher Clusters Peer-to-peer

3 #&/ Separation of functionality: s: Users (applications) who desire service Servers: Providers of service shared by (potentially) many clients 1. NFS server () starts up -server in action: s bundle up request information into message(s) Use generic IPC mechanism to transmit requests to server Server examines message and performs requested action Server bundles up reply information Transmit reply to client Reply treated like syscall reply Requests Replies recv() 1. NFS server () starts up 2. NFS client binds to Stub socket() 1. NFS server () starts up 2. NFS client binds to stub sends msg to server fread(buf,sz,file) Stub READ filename offset sz 1. NFS server () starts up 2. NFS client binds to Stub 1. NFS server () starts up 2. NFS client binds to Stub stub sends msg to server stub sends msg to server 4. server stub receives msg 4. server stub receives msg Operands decoded by stub Operation invoked Results encoded & sent to client fread(buf,sz,file) Operands decoded by stub Operation invoked Results encoded & sent to client 5. NFS client receives response Decodes response Returns from user call

4 0 1 "# ( #&$ / How did client locate and bind to server? In this example, hostname from mount and well known port More generally need a directory service (e.g., ldap & portmap) How did client pass buffer to server (and back)? Cannot pass references need to create and pass copies of Why did msg from client to server include filename? NFS is a stateless server does not maintain client state info Question: What are advantages/disadvantages of this design? How did server know what operation to invoke? Operation id encoded as part of request packet What kinds of operands can be passed? Easy: literals, strings, buffers Hard: trees, graphs, etc. Idea: Implement service in a layered fashion Decompose service into individual components Build hierarchy of services Software engineering principle: hierarchical decomposition Three tiered system Business logic Backend storage Can extend hierarchy Just keep decomposing SAN ( #&/ / Business logic modules: Both clients and servers Export business logic to clients, store in storage servers Question: Should they communicate with one another? How? Question: What issues arise if they communicate? Benefits? SAN: Storage Area Very high speed LAN (Gb/s) Fiberchannel, ATM, Infiband, Modern ones have RDMA (remote DMA) capabilities» can PUT/GET directly to/from server memory» PUT/GET capabilities arbitrated via shared keys» Example: Infiniband Storage layer: Disks (network-attached storage) vs. filesystems vs. base # If one server good multiple servers better? Issues: How do we distribute service across individual servers?» Do we replicate the entire service on all servers?» Do we divide service across servers? If so, how? How do we distribute requests across individual servers?» Do subsequent requests from same client go to same server?» Do we need to load balance and if so, how? How do we detect server failures? How do we keep state distributed across servers consistent?» How much state is exchanged between servers and when?» What happens when servers cannot talk for a while (e.g., failures or network partitions)? 3 4 ' #5 0 1 "#' # Examples of clusters: Clustered web servers (e.g., Yahoo, Google, etc.) Clustered file servers (e.g., VAXclusters) Compute clusters (e.g., Microsoft s Beowulf, Linux clusters, ) Distributing requests to individual nodes: Goals: High throughput, load balancing, efficient recovery Option 1: Round-robin DNS tricks Option 2: Dispatcher node (front end) Option 3: binding Option 4: Multicast Distributing services across servers Option 1: Fully replicated Option 2: Decomposed 1. : GET IP address routes to cluster 2. Dispatcher chooses server Dynamic vs static decision? How is service distributed across cluster? What about load balancing? How do we handoff connections? 3. Server performs operation Reply to dispatcher? To client? Does connection persist? Does server store state? 4. receives response? Bound to server? If so, how? s Dispatcher Some issues: Web servers Stateful vs stateless servers Persistent connections vs cookies State management (consistency) Proxies (really separate issue)

5 ! / %"# Centralization is often a problem: Performance bottlenecks and hotspots Single point of failure less fault resistant Load imbalance Long latency Characteristics of a good distributed algorithm: No machine has/requires complete info about system state» Make decisions based on local information» Avoid single points of failure» Do not assume shared clock (global synchronization) Minimize inter-node communication» Caching and replication are very important (but problematic)» Piggyback info (#bytes less important than #messages)! / %"# Characteristics of a good distributed algorithm: Consider offloading work to clients» Replicating work can be ok» Often fits well with replication of» Introduces its own set of issues Be judicious about using synchronous communication» Asynchronous communication generally more scalable» but introduces its own set of issues, too Minimize synchronization requirements» Takes a long time to come to global agreement Distribute work across nodes» Load balancing (even simple, static) can significantly improve scalability But trying to squeeze out the last bit often futile and counter-productive! / %"# Separate policy from mechanism Encapsulation is good (components, IDLs, ) System provides mechanisms Users/admins choose policies Designers need to avoid imposing policies in their designs Layered protocols Decompose functionality into independent layers Layers logically communicate with their peer on remote machine Advantage: Modularity» Each layer is relatively simple and independently built/tested» Can replace a layer w/o affecting other layers (e.g., IPv6)» Independent failure modes Disadvantage: Lose information at layer boundaries slower ( %"# End-to-end argument: Consider carefully where you put functionality in a complex system Only put functionality in middle if won t be replicated at ends Example: Reliable end-to-end communication (e.g., TCP) vs hopby-hop link layer reliability Saltzer, Reed, and Clark: End-to-End Arguments in System Design, ACM Transaction on Computer Systems, Nov Design issues to consider: Interrupts are expensive Storage/memory costs have plummeted Computation is typically less of a bottleneck than communication Bandwidth is easier to buy/build than latency '" 6 Next time Discussion of MazeWar project Two-person teams Project handouts will be online later today Due in ~3 weeks, including 1 st week writing design documents Next Tuesday 1 st paper discussion (tentative) I will lead the first discussions You need to» Read and think about the papers» Prepare evaluations before class» Take part in the discussion Afterwards lots of student-led discussion for a while (initial set of papers online soon)