1 / 25

Operating Systems

This recitation explains the concept of a concurrent server, socket operations, and how to implement them in an operating system. It covers topics such as handling multiple connection requests, binding sockets, listening for incoming connections, accepting connections, forking child processes to handle requests, and using pipes for communication between parent and child processes. The recitation also includes examples of HTTP server functionality and parsing client requests.

bbartel
Télécharger la présentation

Operating Systems

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. Operating Systems Recitation 9, May 19-20, 2002

  2. Iterative server • Handle one connection request at a time. • Connection requests stored in queue associated with socket (avoid loosing them) server server application thread socket for individual connection socket for connection requests Q operating system

  3. Concurrent server • Handle multiple connection requests at a time. master server application thread slave slave slave sockets for individual connections socket for connection requests Q operating system

  4. client side socket connect send recv closesocket server side socket bind listen accept recv send closesocket Using socket calls

  5. bind • Specifies the local address for a socket; well-known port at which server will wait for connections. int bind(int socket, struct sockaddr* local_addr, int local_addr_len);

  6. listen • OS creates queue of connection requests: hold new connection requests that arrive while server is busy handling a previous request; separate queue (initially empty) for each socket. • Inserts connection requests arriving from clients. • When server asks to retrieve an incoming connection request from socket, the OS returns the next request from queue. • If queue is full when connection request arrives then it’s rejected.

  7. listen • Server calls listen to place a socket in passive mode and make it ready to accept incoming connections. Tells the OS to enqueue connection requests for a socket • Input: • socket descriptor • size of the queue int listen(int socket, int queue_size);

  8. accept • Extracts the next incoming connection request. • If connection request queue is not empty, accept returns immediately, otherwise system blocks the server until a client forms a connection. • Before accept, a request ties up the socket that is bound to well-known port. Accept re-routes it to a new socket allowing original socket to receive additional clients.

  9. accept • All the different sockets created by accept share the same port on the server side. host A port 1234 client A sd=3 sd=3 src=other well-known port IP server process src=1234@A sd=4 host B src=5678@B sd=3 client B sd=5 port 5678 IP IP

  10. accept • Input: • descriptor of a socket (that server has created and bound to a specific port with wildcard foreign destination) from which a connection should be accepted. • Output (when connection request arrives): • address structure of client that formed the connection and its length. • descriptor of new socket. • Server uses each new socket to transfer data for each new connection, and original socket to accept additional connection requests. int accept(int socket, struct sockaddr* client_addr, int* client_addr_len);

  11. Exercise description • Concurrent server, implemented by forking a child process to handle each connection request. • HTTP server providing dynamic content: client requests that server run a program; server runs program and returns output to client.

  12. Exercise description socket bind listen loop accept fork and child handles connection child forks & it’s child executes program

  13. Exercise description: server argument • Initial (main) program argument: port number that server binds to (above 1024 otherwise permission denied).

  14. Exercise description: server’s reply • Server runs a program as requested by a client and sends back: • status • output length • output type • output • Sending the output length before the output itself requires the server to use a buffer to store the output.

  15. Exercise description: server’s reply • Format: HTTP/1.0 200 OK Content-Length: 29 Content-Type: text/plain data • Status: 200 OK, if program run is successful; 300 ERROR, if program doesn’t exist or execv fails. • Actual length of program output. • Each line ends with \r\n

  16. Pipe • Half-duplex • Used only between processes that have a common ancestor. #include <unistd.h> int pipe(int filedes[2]); • Returns 0 if OK, -1 on error • filedes[0] is open for reading, filedes[1] for writing: output of filedes[1] is the input of filedes[0].

  17. child fork fd[1] fd[0] pipe kernel Using a pipe between parent and child • Pipe created by a process. • Process calls fork. • Pipe is used between parent and child in one direction. parent fd[1] fd[0]

  18. Exercise description: reading from standard output using a pipe & dup2 child pipe fork parentchild close(pipefd[1]) close(pipefd[0]) read(pipefd[0],buf,size) dup2(pipefd[1],1) execv standard output

  19. Duplicating an existing file descriptor #include <unistd.h> int dup(int filedes); int dup2(int filedes, int filedes2); • Returns new file descriptor if OK, -1 on error.

  20. Exercise description • Server replies only to GET requests from clients, receiving an entire GET request from client (message ends with \r\n\r\n) • Parses client requests in the format: GET http://nova.math.tau.ac.il:2000/date+-u HTTP/1.0\r\n • The server prints on screen all the HTTP requests it receives, from which you can tell the format of the browser request. machine running the server port program to run program arguments delimited with +

  21. Exercise description: server tests • Using a commercial web browser (IE), check your server, printout the results of two requests: http://nova.math.tau.ac.il:2000/ls+-l+-a and verify that the servers directory appears in the browser. http://nova.math.tau.ac.il:2000/date+-u and verify that you receive an updated date each time you refresh the browser. • Copy the programs you run, such as date and ls, from /bin to the servers directory. • Use the first four digits (after 0) of your ID number as the port.

  22. Exercise description You can incrementally implement the server in several steps, testing each one: • Iteratively handle each connection request, ignoring the URL and sending a constant message to the client, with the proper header. • Concurrency handle each client connection request by a new process. • Parse the URL and execute the requested program, replying to the client.

  23. Exercise submission • Chapter 7.8 in Toledo’s book, pages 135-139. • Submission: Monday, June 17th. • Software Directory: ~username/os02b/ex-serve Files: ex-serve.c Permissions: chmod ugo+rx (to above) • Hardcopy name, ID, login, CID ex-serve.c printout result of the two requests from web browser. submit in 281, Nir Neumark, nirn@post.tau.ac.il • Environment: Unix, Linux

  24. Exercise notes • You can use the functions recv/send or read/write (the latter receiving three arguments instead of four).

  25. References • Operating Systems, Sivan Toledo, Akademon, 2001. • Internetworking with TCP/IP, Vol 3: client-server programming and applications, Douglas Comer & David Stevens, Prentice-Hall, 1997. • Advanced programming in the Unix environment, Richard Stevens, Addison-Wesley, 1993. • Example program on course webpage.

More Related