------------------------- Week 08 Notes for CST8165 ------------------------- -Ian! D. Allen - idallen@idallen.ca - www.idallen.com Remember - knowing how to find out an answer is more important than memorizing the answer. Learn to fish! RTFM! (Read The Fine Manual) Keep up on your readings (Course Outline: average 4 hours/week homework) Your second midterm test is in Week 11. IETF Talk - Friday March 28 - Michael Richardson (Ottawa) will be here to talk about what it's like to be part of the IETF and author RFC documents News Last Week: http://www.news.com/8301-10784_3-9878655-7.html?tag=nl.e498 - more specific route "war" sends YouTube to Pakistan Review: ------ - TCP (layer three) - 85 pages on top of IP - TCP state diagram - three-way handshake to start a TCP session - simultaneous open - pseudo-headers - the TCP "ACK" field - selective ACK - SACK - TCP windowing - function of the "zero" window - fragmentation (three evils) - Path Maximum Transmission Unit (PMTU) discovery - congestion control - Explicit Congestion Notification (ECN) - incompatible change that breaks older routers - Slow Start Interpreting the RFC documents and the raw protocols ---------------------------------------------------- * The "Requirements for Internet Hosts" documents: RFC 1122 and 1123 http://tools.ietf.org/html/rfc1122 http://tools.ietf.org/html/rfc1123 - RFC1122 and 1123 are clarifications and examples of how the RFCs work - RFC1122 deals with "Communication Layers" (e.g. IP, TCP) - RFC1123 deals with "Application and Support" (e.g. SMTP, HTTP) * The overview discussion document: RFC1127 http://tools.ietf.org/html/rfc1127 - describes the history of the creation of 1122 and 1123 "This group of people struggled with a broad range of issues in host implementations of the Internet protocols, attempting to reconcile theoretical and architectural concerns with the sometimes conflicting imperatives of the real world. The present RFC recaps the results of this struggle, with the issues that were settled and those that remain for future work." "Indeed, many of these are simply restatements or reinforcement of requirements that are already explicit or implicit in the original standards RFC's. Some more cynical members of the working group refer to these as "Read The Manual" provisions. However, they were included in the HR RFCs because at least one implementation has failed to abide by these requirements. In addition, many provisions of the HR RFCs are simply applications of Jon Postel's Robustness Principle [1.2.2 in either RFC]." Comments on Application Protocols - RFC1123 ------------------------------------------- * RFC1123 - Requirements for Internet Hosts - Application and Support http://tools.ietf.org/html/rfc1123 - RFC1123 reviews and clarifies many major protocols and standards: - TELNET, FTP, TFTP, SMTP, RFC822 (message format), DNS "This RFC enumerates standard protocols that a host connected to the Internet must use, and it incorporates by reference the RFCs and other documents describing the current specifications for these protocols. It corrects errors in the referenced documents and adds additional discussion and guidance for an implementor." "A good-faith implementation of the protocols that was produced after careful reading of the RFC's and with some interaction with the Internet technical community, and that followed good communications software engineering practices, should differ from the requirements of this document in only minor ways. Thus, in many cases, the "requirements" in this RFC are already stated or implied in the standard protocol documents, so that their inclusion here is, in a sense, redundant. However, they were included because some past implementation has made the wrong choice, causing problems of interoperability, performance, and/or robustness." Q: Why was the RFC1123 "Application and Support" document written? Q: What are the purpose of RFC1122 and RFC1123 (and RFC1127)? Q: T/F The two "Requirements for Internet Hosts" documents were written to extend the existing RFCs with new features. ------------------------------------------------------------------------------ TCP Server: Handling multiple simultaneous connections ------------------------------------------------------ How does a Unix/Linux program handle multiple simultaneous TCP connections? - if your server process is blocked on an accept() or read(), it can't accept or process other client connections - if your client process is blocked reading your keyboard, it can't display input coming from the server; if it is blocked reading from the server, it isn't reading your keyboard - need to block and listen to multiple file descriptors at the same time and continue if input is received on *any* of them Three Solutions to concurrency: fork(), select(), threads A. fork() separate processes to handle each file descriptor - e.g. server forks a new child process for each new client connection - e.g. client forks into one process for keyboard, one for server socket - forking (duplicating process address space) is expensive - forked processes have limited means to communicate with each other - they don't share any address space; they are separate - you can use process signal()s to communicate simple events - you can explicitly set up inter-process communication sockets; but, then you again have the problem of how to manage reading/writing from two different places, which is why you used fork() in the first place! B. use one single process and the system call select() to listen to multiple file descriptors at the same time - one single process handles all the file descriptors - one single process provides inter-client data transfer among the many descriptors - shared address spece - no need to fork() - more complex than a forking server C. run separate process threads D. There is a fourth solution that I won't consider here: Use non-blocking sockets and go into an infinite loop polling your descriptors, using up all your CPU. One might get away with that on a single-use embedded system; but, it isn't appropriate to hog the CPU in a multi-user or multi-task environment. The fork() and select() methods are the traditional designs. Threads are relatively new and some thread libraries may be buggy (be careful). We already implemented a fork() client and server; our next try is select(): * Using select() to handle multiple connections: - the select() system call blocks and listens to multiple I/O descriptors all at the same time and unblocks when I/O is possible on *any* of them - you can set a time-out on how long to wait for I/O; default wait is "forever" - select() I/O descriptors are represented in bit vectors - the bit vectors have these macros to manipulate them: * FD_ZERO(fd_set *set) -- clears a file descriptor set * FD_SET(int fd, fd_set *set) -- adds fd to the set * FD_CLR(int fd, fd_set *set) -- removes fd from the set * FD_ISSET(int fd, fd_set *set) -- tests to see if fd is in the set 1) See section "6.2. select()--Synchronous I/O Multiplexing" in http://beej.us/guide/bgnet/output/html/singlepage/bgnet.html#select Do a read-through of chat server code that uses the select() syscall. 2) Write the detailed pseudocode for selectserver.c and rework it (and the code) to reduce the number of indentation levels. See the hints for reducing indentation in the Notes file: deep_indentation.txt More descriptions of how select() works are here: http://www.lowtek.com/sockets/select.html http://www.developerweb.net/forum/showthread.php?t=2933 Man pages are here: "man select_tut" (example code given: port forwarding program) http://swoolley.homeip.net/man.cgi/select_tut http://www.opengroup.org/onlinepubs/007908799/xsh/select.html Q: Name and describe four ways a server program can handle multiple simultaneous connections. Q: Discuss the appropriate and not-appropriate uses of non-blocking sockets. Q: Name and describe the four macros used to manipulate descriptors for the select() system call Q: Write the detailed pseudocode for the selectserver.c chat server program that uses select(). Q: T/F The select() system call always blocks until some I/O event is ready.