CS 3214 Computer Systems Godmar Back

HTTP Uses and TRENDS Part 2 Some of these slides are substantially derived from slides provided by Jim Kurose & Keith Ross. Copyright on this material is held by Kurose & Ross. Used with permission. The textbook is Computer Networking: A Top Down Approach Featuring the Internet Jim Kurose, Keith Ross, Addison-Wesley, July 2004 Part 2 HTTP Uses and TRENDS CS 3214 Fall 2014

Benchmarking Tools Httperf [Mosberger 1998] Wrk [2014] See Mark Nottingham on http benchmarking [2011], lists a number of noteworthy points CS 3214 Fall 2014

Mashups Web applications that combine and mix data from different sources CS 3214 Fall 2014

Base Server http://www.lib.edu Source A http://www.lib.edu/sourceA Mash-Up Server http://mashup.lib.edu Source B http://opac.lib.edu/sourceB HTML Source C http://any.host.domain/sourceC Client Browser Base Page A C B Server-side Mash-Up CS 3214 Fall 2014

Base Server http://www.lib.edu Source A http://www.lib.edu/sourceA HTML+JavaScript Proxy http://www.lib.edu/proxy Source B http://opac.lib.edu/sourceB XMLHttpRequest Source C http://any.host.domain/sourceC Client Browser Base Page A C B Proxy-Based Mash-Up CS 3214 Fall 2014

Base Server http://www.lib.edu Source B http://opac.lib.edu/sourceB HTML+JavaScript Same Origin Restriction Same Domain Restriction Source A http://www.lib.edu/sourceA XMLHttpRequest + XML/Text XMLHttpRequest + XML/Text No Domain Restriction Client Browser Base Page Source C http://any.host.domain/sourceC A B C B (via hidden frame) <SCRIPT> + JSON Client-side Mash-Up CS 3214 Fall 2014

HTTP & JSON In modern web applications, HTTP is increasingly initiated from code Either directly, e.g., XMLHttpRequest Or indirectly, via SCRIPT/JSON Example: http://books.google.com/books?jscmd=viewapi&bibkeys=0060731338&callback=callThisFunction callThisFunction({"0060731338":{"bib_key":"0060731338", "info_url": "http://books.google.com/books?id=HCInGwAACAAJ\x26source=gbs_ViewAPI", "preview_url": "http://books.google.com/books?id=HCInGwAACAAJ\x26source=gbs_ViewAPI",“ preview":"noview", "embeddable":false}}); CS 3214 Fall 2014

HTTP & AJAX AJAX Frameworks no longer build entire web pages from an HTML description Rather: bootstrap small amount of code, then dynamically load and update page “piece-by-piece” CS 3214 Fall 2014

Goal – Use of AJAX Page 1 Page 2 Page 3 Conventional Navigation Model Submit button pressed Submit button pressed Page 1 Servlet1 Servlet1-1 Update portion of page HTML Page returned Page 2 Submit button pressed Mouse Hover Servlet 2 Servlet 1-2 Page 3 HTML Page returned Update Portion of Page Popularity of ajax over recent years because of advtgs AJAX is the technology responsible for the Web 2.0 hype. Many companies have started using AJAX for their projects because of the notable advantages that it offers in terms of user-interaction Our first goal was to implement the Edition Builder as a web application because Web-applications can be accessed by any user with a computer and an Internet connection. Moreover , web applications can be updated and maintained without installation of software on the client side. Hence, deployment of changes and updates can be done transparently from the user and in an expedited fashion. Problems in conventional navigation model Disruptive page refreshes after each user-interaction Confusing because of hyper-links and page layout AJAX Asynchronous JavaScript and XML Incremental update of pages (No page refreshes) Higher levels of interactivity and responsiveness Explain Working of AJAX An AJAX application has an intermediate layer between the user and the server called the AJAX engine. Each user interaction results in a call to the AJAX engine. The AJAX engine decides, whether a call requires action from the server. If the AJAX engine itself can service a call, it does so without resorting to communication with the server. In this way, unnecessary http requests to the server are avoided and user-interaction can proceed smoothly with other components that do not require server-processing at that moment. Thus, due to the interposition of the AJAX engine, a user interacts with the application without interruptions Conventional Navigation Model AJAX Navigation Model CS 3214 Fall 2014

Server centric vs. Client centric AJAX frameworks Browser Browser Generated HTML+ JavaScript Client Side AJAX Engine Application HTML+ JavaScript Client Side AJAX Engine Dom Dom Server Side AJAX Engine Web Application Web Application Scraps of sample code that you find on the Web and that you can cut and paste into your own application, to comprehensive frameworks. Just above the level of code scraps are individual JavaScript components that present an API for a specific purpose. Some of these represent UI widgets that will appear on a Web page, like the Dojo Button, and others are for solving lower-level, plumbing-related issues like communicating with the server or manipulating the browser DOM (for example the Prototype APIs). Fundamental choices Give examples of toolkits that follow either model Explain dom If you look at the diagrams in Figure 2 below, you can see that in the server-centric model, the application programmer develops the entire application in what appears to the programmer to be server-side code. Of course, DHTML and JavaScript are involved when the application runs, but the framework does not expose these to the programmer. The framework provides both a server-side and client-side Ajax engine. The server-side engine generates HTML and JavaScript that is served into the browser along with a client-side engine, which provides APIs used by the generated code to manipulate the browser DOM, receive events, and push them back to the server-side engine, which communicates events back to the application. A client-side framework, on the other hand, expects the application programmer to write both the server side of the application and the part that will run in the browser. The client-side code is served into the browser along with the Ajax engine, which performs the same intercession functions between the DOM and the application code that it does in the server-centric model An advantage of client side frameworks is that developers can leverage JavaScript skills to combine features from various frameworks and create a complex application. But, client side frameworks entail significant amount of JavaScript programming, which can still give rise to unmaintainable JavaScript code. Moreover, with client-centric AJAX frameworks, the programmer needs to take the responsibility of sending client state to the server periodically. If the client fails to send state information to the server then the server may not be able to retain consistency of the application based on the client-state. Server Server Server-Centric Client-Centric Framework code Application Code Generated Code CS 3214 Fall 2014

Architectures and Protocol on top of HTTP REST: Representational State Transfer URL represent resources SOAP: Remote-procedure call abstraction CS 3214 Fall 2014

Trends & Alternatives Key weakness in HTTP/1.1: Websockets (URL) Per connection overhead Inefficient pipelining due to FIFO restriction (clients rather reconnect than risk for requests to be queued) Header overhead Still unidirectional Unwanted interaction with TCP slow start Websockets (URL) Google’s SPDY HTTP/2 IETF effort CS 3214 Fall 2014

Server Models CS 3214 Fall 2014

Server Models Should more than one more client at a time be supported? No: use iterative approach: one at a time If Yes: How do we manage n clients (and be able to accept more at the same time)? Option 1: use multiple execution contexts (aka “thread-based”, concurrent model) Option 2: multiplex multiple connections in single execution context (aka “event-based”, achieves “apparent concurrency”) CS 3214 Fall 2014

High-Concurrency Servers Ideal Key goal: Maintain throughput: measure of useful work seen by clients Peak: some resource at max Performance Overload: some resource thrashing Load (concurrent tasks) Source: von Behren, SOSP 2003 CPU and resource management is critical Must weigh which connections to accept vs. to drop Ensure that requests in pipeline are completed CS 3214 Fall 2014

Multiple Contexts Option A: fork a new process for every connection on-demand Option B: fork a new thread for every connection to handle it Option C/D: pre-fork a certain number of processes (or threads) and hand connections to them CS 3214 Fall 2014

Handling multiple clients using multiple execution contexts A/B: # grows & shrinks A B C/D: fixed # C D Q.: When would you use which? CS 3214 Fall 2014

Multiplexing Multiple Connections Problem: need to avoid blocking Different solutions: Always test before you read/write (would I block?) NB: does not require use of nonblocking mode Use socket in nonblocking mode: try to read, let it fail if it would block Then try again later (when?), or: use in combination with notification: send a signal or event if the socket becomes readable. Many combinations possible CS 3214 Fall 2014

Multiplexing multiple connections in a single execution context Use an event-based programming style Problem: need to avoid blocking Split code in before and after part, assign an event to ‘after’ part, record all information needed to continue “stack ripping” Can make event-based code hard to write See TAME [Krohn 2007] CS 3214 Fall 2014

OS interfaces to avoid blocking Different solutions: Always test before you read/write (would I block?) NB: does not require use of nonblocking mode Use socket in nonblocking mode: try to read, let it fail if it would block Then try again later (when?), or: use in combination with notification: send a signal or event if the socket becomes readable. Many combinations possible CS 3214 Fall 2014

select(2) fd_set’s are bit vectors that implement a set of integers int select(int maxn, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout); FD_CLR(int fd, fd_set *set); FD_ISSET(int fd, fd_set *set); FD_SET(int fd, fd_set *set); FD_ZERO(fd_set *set); fd_set’s are bit vectors that implement a set of integers maxn is max{fds in set} + 1 If fd is in return set, read/write will not block Java implementation is in java.nio.* CS 3214 Fall 2014

Problems with select() select(2) is portable, but not scalable: Time to scan fd_sets depends on maximum fd value – O(n) OS must scan entire fd_set every time (+copy-in from user space, +copy-out to user space) [Banga Mogul 1998] Found some systems spend >53% of time in select() Led to development of new mechanisms CS 3214 Fall 2014

Alternative 1: poll() poll(2) Win if ready set is sparse Specify array with fds of interest OS returns (shorter) array with ready fds Win if ready set is sparse Otherwise same problems as select Before call 0 RWE ??? 1 RWE ??? 5 RWE ??? 9 RWE ??? 1 RWE R-- 9 RWE --E After call CS 3214 Fall 2014

Alternative 2: epoll() Linux: epoll(4) Specify interest set to OS only once Then refer to it by descriptor Add new fds to set, remove fds from set Edge-triggered vs. Level-triggered versions ET: Notify on change Adopted from Solaris’s: /dev/poll Further improve performance by mmap’ing /dev/poll CS 3214 Fall 2014

Alternative 3: RT signals Key idea: RT Signals carry fd information with them in their siginfo struct (unlike SIGIO) Avoid delivery overhead by polling for them with sigwaitinfo Problem: Finite signal queue requires overflow mechanism Discussed in [Chandra Mosberger 2001] “multi-accept” select – reduce frequency of select by accepting multiple connections CS 3214 Fall 2014

libevent http://libevent.org/ Library to support platform-independent, efficient, event-based programming Abstract different OS-specific interfaces, including recently developed ones CS 3214 Fall 2014