1 / 100

Computer System Chapter 12. Concurrent Programming

Computer System Chapter 12. Concurrent Programming. Lynn Choi Korea University. Web Services. Web History. 1945: Vannevar Bush, “As we may think”, Atlantic Monthly, July, 1945. Describes the idea of a distributed hypertext system.

lada
Télécharger la présentation

Computer System Chapter 12. Concurrent Programming

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Computer SystemChapter 12. Concurrent Programming Lynn Choi Korea University

  2. Web Services

  3. Web History • 1945: • Vannevar Bush, “As we may think”, Atlantic Monthly, July, 1945. • Describes the idea of a distributed hypertext system. • A “memex” (memory+index) that mimics the “web of trails” in our minds. • Hypothetical proto-hypertext system, a device in which an individual would compress and store all of their books, records, and communications, "mechanized so that it may be consulted with exceeding speed and flexibility • 1989: • Tim Berners-Lee (CERN) writes internal proposal to develop a distributed hypertext system. • Connects “a web of notes with links.” • Intended to help CERN physicists in large projects share and manage information • 1990: • Tim has built the first web browser, the first web server, and the first web pages, which described the World Wide Web project. • Tim BL writes a graphical browser for Next machines.

  4. Web History (cont) • 1992 • NCSA server released • 26 WWW servers worldwide • 1993 • Marc Andreessen releases first version of NCSA Mosaic browser • Mosaic version released for (Windows, Mac, Unix). • Web (port 80) traffic at 1% of NSFNET backbone traffic. • Over 200 WWW servers worldwide. • 1994 • Andreessen and colleagues leave NCSA to form "Mosaic Communications Corp" (now Netscape).

  5. Internet Hosts

  6. Web Servers • Clients and servers communicate using the HyperText Transfer Protocol (HTTP) • Client and server establish TCP connection • Client requests content • Server responds with requested content • Client and server close connection (usually) • Current version is HTTP/1.1 • RFC 2616, June, 1999. HTTP request Web client (browser) Web server HTTP response (content)

  7. Web Content • Web servers return content to clients • content: a sequence of bytes with an associated MIME (Multipurpose Internet Mail Extensions) type • Example MIME types • text/html HTML document • text/plain Unformatted text • application/postscript Postcript document • image/gif Binary image encoded in GIF format • image/jpeg Binary image encoded in JPEG format

  8. Static and Dynamic Content • The content returned in HTTP responses can be either static or dynamic. • Static content: content stored in files and retrieved in response to an HTTP request • Examples: HTML files, images, audio clips. • Dynamic content: content produced on-the-fly in response to an HTTP request • Example: content produced by a program executed by the server on behalf of the client. • Bottom line: All Web content is associated with a file that is managed by the server.

  9. URLs • Each file managed by a server has a unique name called a URL (Universal Resource Locator) • URLs for static content: • http://www.cs.cmu.edu:80/index.html • http://www.cs.cmu.edu/index.html • http://www.cs.cmu.edu • Identifies a file called index.html, managed by a Web server at www.cs.cmu.edu that is listening on port 80. • URLs for dynamic content: • http://www.cs.cmu.edu:8000/cgi-bin/adder?15000&213 • Identifies an executable file called adder, managed by a Web server at www.cs.cmu.edu that is listening on port 8000, that should be called with two argument strings: 15000 and 213.

  10. How Clients and Servers Use URLs • Example URL: http://www.aol.com:80/index.html • Clients use prefix(http://www.aol.com:80) to infer: • What kind of server to contact (Web server) • Where the server is (www.aol.com) • What port it is listening on (80) • Servers use suffix (/index.html) to: • Determine if request is for static or dynamic content. • No hard and fast rules for this. • Convention: executables reside in cgi-bin directory • Find file on file system. • Initial “/” in suffix denotes home directory for requested content. • Minimal suffix is “/”, which all servers expand to some default home page (e.g., index.html).

  11. Anatomy of an HTTP Transaction unix> telnet www.aol.com 80Client: open connection to server Trying 205.188.146.23... Telnet prints 3 lines to the terminal Connected to aol.com. Escape character is '^]'. GET / HTTP/1.1 Client: request line host: www.aol.com Client: required HTTP/1.1 HOST header Client: empty line terminates headers. HTTP/1.0 200 OK Server: response line MIME-Version: 1.0 Server: followed by five response headers Date: Mon, 08 Jan 2001 04:59:42 GMT Server: NaviServer/2.0 AOLserver/2.3.3 Content-Type: text/html Server: expect HTML in the response body Content-Length: 42092 Server: expect 42,092 bytes in the resp body Server: empty line (“\r\n”) terminates hdrs <html> Server: first HTML line in response body ... Server: 766 lines of HTML not shown. </html> Server: last HTML line in response body Connection closed by foreign host. Server: closes connection unix> Client: closes connection and terminates

  12. HTTP Requests • HTTP request is a request line, followed by zero or more request headers • Request line: <method> <uri> <version> • <method> is either GET, POST, OPTIONS, HEAD, PUT, DELETE, or TRACE. • <uri> is typically URL for proxies, URL suffix for servers. • <version> is HTTP version of request (HTTP/1.0 or HTTP/1.1)

  13. HTTP Requests (cont) • HTTP methods: • GET: Retrieve static or dynamic content • Arguments for dynamic content are in URI • Workhorse method (99% of requests) • POST: Submit data to be processed, • May create a new (or updated) content • OPTIONS: Get server or file attributes • HEAD: Like GET but no data in response body • PUT: Write a file to the server! • DELETE: Delete a file on the server! • TRACE: Echo request in response body • Useful for debugging.

  14. HTTP Requests (cont) • Request headers: <header name>: <header data> • Provide additional information to the server. • Major differences between HTTP/1.1 and HTTP/1.0 • HTTP/1.0 uses a new connection for each transaction. • HTTP/1.1 also supports persistent connections • multiple transactions over the same connection • Connection: Keep-Alive • HTTP/1.1 requires HOST header • Host: kittyhawk.cmcl.cs.cmu.edu • HTTP/1.1 adds additional support for caching

  15. HTTP Responses • HTTP response is a response line followed by zero or more response headers. • Response line: <version> <status code> <status msg> • <version> is HTTP version of the response. • <status code> is numeric status. • <status msg> is corresponding English text. • 200 OK Request was handled without error • 403 Forbidden Server lacks permission to access file • 404 Not found Server couldn’t find the file. • Response headers: <header name>: <header data> • Provide additional information about response • Content-Type: MIME type of content in response body. • Content-Length: Length of content in response body.

  16. Serving Dynamic Content • Client sends request to server. • If request URI contains the string “/cgi-bin”, then the server assumes that the request is for dynamic content. GET /cgi-bin/env.pl HTTP/1.1 Client Server

  17. Serving Dynamic Content (cont) • The server creates a child process and runs the program identified by the URI in that process Client Server fork/exec env.pl

  18. Serving Dynamic Content (cont) • The child runs and generates the dynamic content. • The server captures the content of the child and forwards it without modification to the client Client Server Content Content env.pl

  19. Issues in Serving Dynamic Content • How does the client pass program arguments to the server? • How does the server pass these arguments to the child? • How does the server pass other info relevant to the request to the child? • How does the server capture the content produced by the child? • These issues are addressed by the Common Gateway Interface (CGI) specification. Request Client Server Content Content Create env.pl

  20. CGI • Because the children are written according to the CGI spec, they are often called CGI programs. • Because many CGI programs are written in Perl, they are often called CGI scripts. • However, CGI really defines a simple standard for transferring information between the client (browser), the server, and the child process.

  21. add.com: THE Internet addition portal! • Ever need to add two numbers together and you just can’t find your calculator? • Try Dr. Dave’s addition service at “add.com: THE Internet addition portal!” • Takes as input the two numbers you want to add together. • Returns their sum in a tasteful personalized message. • After the IPO we’ll expand to multiplication!

  22. The add.com Experience input URL host port CGI program args Output page

  23. Serving Dynamic Content With GET • Question: How does the client pass arguments to the server? • Answer: The arguments are appended to the URI • Can be encoded directly in a URL typed to a browser or a URL in an HTML link • http://add.com/cgi-bin/adder?1&2 • adder is the CGI program on the server that will do the addition. • argument list starts with “?” • arguments separated by “&”

  24. Serving Dynamic Content With GET • URL: • http://add.com/cgi-bin/adder?1&2 • Result displayed on browser: Welcome to add.com: THE Internet addition portal. The answer is: 1 + 2 = 3 Thanks for visiting! Tell your friends.

  25. Serving Dynamic Content With GET • Question: How does the server pass these arguments to the child? • Answer: In environment variable QUERY_STRING • A single string containing everything after the “?” • For add.com: QUERY_STRING = “1&2” /* child code that accesses the argument list */ if ((buf = getenv("QUERY_STRING")) == NULL) { exit(1); } /* extract arg1 and arg2 from buf and convert */ ... n1 = atoi(arg1); n2 = atoi(arg2);

  26. Serving Dynamic Content With GET • Question: How does the server pass other info relevant to the request to the child? • Answer: In a collection of environment variables defined by the CGI spec.

  27. Some CGI Environment Variables • General • SERVER_SOFTWARE • SERVER_NAME • GATEWAY_INTERFACE (CGI version) • Request-specific • SERVER_PORT • REQUEST_METHOD (GET, POST, etc) • QUERY_STRING (contains GET args) • REMOTE_HOST (domain name of client) • REMOTE_ADDR (IP address of client) • CONTENT_TYPE (for POST, type of data in message body, e.g., text/html) • CONTENT_LENGTH (length in bytes)

  28. Serving Dynamic Content With GET • Question: How does the server capture the content produced by the child? • Answer: The child generates its output on stdout. Server uses dup2 to redirect stdoutto its connected socket. • Notice that only the child knows the type and size of the content. Thus the child (not the server) must generate the corresponding headers. /* child generates the result string */ sprintf(content, "Welcome to add.com: THE Internet addition portal\ <p>The answer is: %d + %d = %d\ <p>Thanks for visiting!\r\n", n1, n2, n1+n2); /* child generates the headers and dynamic content */ printf("Content-length: %d\r\n", strlen(content)); printf("Content-type: text/html\r\n"); printf("\r\n"); printf("%s", content);

  29. Serving Dynamic Content With GET bass> ./tiny 8000 GET /cgi-bin/adder?1&2 HTTP/1.1 Host: bass.cmcl.cs.cmu.edu:8000 <CRLF> kittyhawk> telnet bass 8000 Trying 128.2.222.85... Connected to BASS.CMCL.CS.CMU.EDU. Escape character is '^]'. GET /cgi-bin/adder?1&2 HTTP/1.1 Host: bass.cmcl.cs.cmu.edu:8000 <CRLF> HTTP/1.1 200 OK Server: Tiny Web Server Content-length: 102 Content-type: text/html <CRLF> Welcome to add.com: THE Internet addition portal. <p>The answer is: 1 + 2 = 3 <p>Thanks for visiting! Connection closed by foreign host. kittyhawk> HTTP request received by Tiny Web server HTTP request sent by client HTTP response generated by the server HTTP response generated by the CGI program

  30. Proxies HTTP request HTTP request HTTP response HTTP response • A proxy is an intermediary between a client and an origin server. • To the client, the proxy acts like a server. • To the server, the proxy acts like a client. Origin Server Client Proxy

  31. Why Proxies? Request foo.html foo.html Request foo.html foo.html Request foo.html foo.html • Can perform useful functions as requests and responses pass by • Examples: Caching, logging, anonymization Client A Origin Server Proxy cache Slower more expensive global network Client B Fast inexpensive local network

  32. For More Information • Study the Tiny Web server described in your text • Tiny is a sequential Web server. • Serves static and dynamic content to real browsers. • text files, HTML files, GIF and JPEG images. • 220 lines of commented C code. • Also comes with an implementation of the CGI script for the add.com addition portal.

  33. Concurrent Servers

  34. Iterative Servers • Iterative servers process one request at a time. client 1 server client 2 call connect call connect call accept ret connect ret accept call read write ret read close close call accept ret connect ret accept call read write ret read close close

  35. Fundamental Flaw of Iterative Servers • Solution: use concurrent servers instead. • Concurrent servers use multiple concurrent flows to serve multiple clients at the same time. client 1 server client 2 call connect call accept ret connect ret accept call fgets call read Server blocks waiting for data from Client 1 call connect User goes out to lunch Client 1 blocks waiting for user to type in data Client 2 blocks waiting to complete its connection request until after lunch!

  36. Concurrent Servers • Concurrent servers handle multiple requests concurrently. client 1 server client 2 callconnect call connect call accept ret connect ret accept call fgets fork child 1 call accept call read User goes out to lunch Client 1 blocks waiting for user to type in data ret connect call fgets ret accept fork write child 2 call read call read ... write end read close close

  37. Three Basic Mechanisms for Creating Concurrent Flows • 1. Processes • Kernel automatically interleaves multiple logical flows. • Each flow has its own private address space. • 2. I/O multiplexing with select() • User manually interleaves multiple logical flows. • Each flow shares the same address space. • Popular for high-performance server designs. • 3. Threads • Kernel automatically interleaves multiple logical flows. • Each flow shares the same address space. • Hybrid of processes and I/O multiplexing!

  38. Process-Based Concurrent Server /* * echoserverp.c - A concurrent echo server based on processes * Usage: echoserverp <port> */ #include <ics.h> #define BUFSIZE 1024 void echo(int connfd); void handler(int sig); int main(int argc, char **argv) { int listenfd, connfd; int portno; struct sockaddr_in clientaddr; int clientlen = sizeof(struct sockaddr_in); if (argc != 2) { fprintf(stderr, "usage: %s <port>\n", argv[0]); exit(0); } portno = atoi(argv[1]); listenfd = open_listenfd(portno);

  39. Process-Based Concurrent Server (cont) Signal(SIGCHLD, handler); /* parent must reap children! */ /* main server loop */ while (1) { connfd = Accept(listenfd, (struct sockaddr *) &clientaddr, &clientlen)); if (Fork() == 0) { Close(listenfd); /* child closes its listening socket */ echo(connfd); /* child reads and echoes input line */ Close(connfd); /* child is done with this client */ exit(0); /* child exits */ } Close(connfd); /* parent must close connected socket! */ } }

  40. Process-Based Concurrent Server(cont) /* handler - reaps children as they terminate */ void handler(int sig) { pid_t pid; int stat; while ((pid = waitpid(-1, &stat, WNOHANG)) > 0) ; return; }

  41. Implementation Issues With Process-Based Designs • Server should restart accept call if it is interrupted by a transfer of control to the SIGCHLD handler • Not necessary for systems with POSIX signal handling. • Our Signal wrapper tells kernel to automatically restart accept • Required for portability on some older Unix systems. • Server must reap zombie children • to avoid fatal memory leak. • Server must close its copy of connfd. • Kernel keeps reference for each socket. • After fork, refcnt(connfd) = 2. • Connection will not be closed until refcnt(connfd)=0.

  42. Pros and Cons of Process-Based Designs • + Handles multiple connections concurrently • + Clean sharing model • descriptors (no) • file tables (yes) • global variables (no) • + Simple and straightforward. • - Additional overhead for process control. • - Nontrivial to share data between processes. • Requires IPC (interprocess communication) mechanisms FIFO’s (named pipes), System V shared memory and semaphores • I/O multiplexing provides more control with less overhead...

  43. Event-Based Concurrent Servers Using I/O Multiplexing • Maintain a pool of connected descriptors. • Repeat the following forever: • Use the Unix select function to block until: • (a) New connection request arrives on the listening descriptor. • (b) New data arrives on an existing connected descriptor. • If (a), add the new connection to the pool of connections. • If (b), read any available data from the connection • Close connection on EOF and remove it from the pool.

  44. The select Function • select() sleeps until one or more file descriptors in the set readset are ready for reading. #include <sys/select.h> int select(int maxfdp1, fd_set *readset, NULL, NULL, NULL); • readset • Opaque bit vector (max FD_SETSIZE bits) that indicates membership in a descriptor set. • If bit k is 1, then descriptor k is a member of the descriptor set. • maxfdp1 • Maximum descriptor in descriptor set plus 1. • Tests descriptors 0, 1, 2, ..., maxfdp1 - 1 for set membership. select()returns the number of ready descriptors and sets each bit ofreadset to indicate the ready status of its corresponding descriptor.

  45. Macros for Manipulating Set Descriptors • void FD_ZERO(fd_set *fdset); • Turn off all bits in fdset. • void FD_SET(int fd, fd_set *fdset); • Turn on bit fd in fdset. • void FD_CLR(int fd, fd_set *fdset); • Turn off bit fd in fdset. • int FD_ISSET(int fd, *fdset); • Is bit fd in fdset turned on?

  46. select Example /* * main loop: wait for connection request or stdin command. * If connection request, then echo input line * and close connection. If stdin command, then process. */ printf("server> "); fflush(stdout); while (notdone) { /* * select: check if the user typed something to stdin or * if a connection request arrived. */ FD_ZERO(&readfds); /* initialize the fd set */ FD_SET(listenfd, &readfds); /* add socket fd */ FD_SET(0, &readfds); /* add stdin fd (0) */ Select(listenfd+1, &readfds, NULL, NULL, NULL);

  47. select Example (cont) • First we check for a pending event on stdin. /* if the user has typed a command, process it */ if (FD_ISSET(0, &readfds)) { fgets(buf, BUFSIZE, stdin); switch (buf[0]) { case 'c': /* print the connection count */ printf("Received %d conn. requests so far.\n", connectcnt); printf("server> "); fflush(stdout); break; case 'q': /* terminate the server */ notdone = 0; break; default: /* bad input */ printf("ERROR: unknown command\n"); printf("server> "); fflush(stdout); } }

  48. select Example (cont) • Next we check for a pending connection request. /* if a connection request has arrived, process it */ if (FD_ISSET(listenfd, &readfds)) { connfd = Accept(listenfd, (struct sockaddr *) &clientaddr, &clientlen); connectcnt++; bzero(buf, BUFSIZE); Rio_readn(connfd, buf, BUFSIZE); Rio_writen(connfd, buf, strlen(buf)); Close(connfd); } } /* while */

  49. Event-based Concurrent Echo Server /* * echoservers.c - A concurrent echo server based on select */ #include "csapp.h" typedef struct { /* represents a pool of connected descriptors */ int maxfd; /* largest descriptor in read_set */ fd_set read_set; /* set of all active descriptors */ fd_set ready_set; /* subset of descriptors ready for reading */ int nready; /* number of ready descriptors from select */ int maxi; /* highwater index into client array */ int clientfd[FD_SETSIZE]; /* set of active descriptors */ rio_t clientrio[FD_SETSIZE]; /* set of active read buffers */ } pool; int byte_cnt = 0; /* counts total bytes received by server */

  50. Event-based Concurrent Server (cont) int main(int argc, char **argv) { int listenfd, connfd, clientlen = sizeof(struct sockaddr_in); struct sockaddr_in clientaddr; static pool pool; listenfd = Open_listenfd(argv[1]); init_pool(listenfd, &pool); while (1) { pool.ready_set = pool.read_set; pool.nready = Select(pool.maxfd+1, &pool.ready_set, NULL, NULL, NULL); if (FD_ISSET(listenfd, &pool.ready_set)) { connfd = Accept(listenfd, (SA *)&clientaddr,&clientlen); add_client(connfd, &pool); } check_clients(&pool); } }

More Related