1. CS 3214 Computer Systems
Godmar Back

2. 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

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

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

5. Base Server http://www.lib.edu Source A
Mash-Up Server
Source B
HTML
Source C
Client Browser
Base Page A C B
Server-side Mash-Up
CS 3214 Fall 2014

6. Base Server http://www.lib.edu Source A
HTML+JavaScript
Proxy
Source B
XMLHttpRequest
Source C
Client Browser
Base Page A C B
Proxy-Based Mash-Up
CS 3214 Fall 2014

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

8. HTTP & JSON
In modern web applications, HTTP is increasingly initiated from code
Either directly, e.g., XMLHttpRequest
Or indirectly, via SCRIPT/JSON
Example:
callThisFunction({" ":{"bib_key":" ",
"info_url": "
"preview_url": "
preview":"noview", "embeddable":false}});
CS 3214 Fall 2014

9. 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

10. 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

11. 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

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

13. 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

14. Server Models
CS 3214 Fall 2014

15. 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

16. 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

17. 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

18. 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

19. 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

20. 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

21. 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

22. 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

23. 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

24. 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

25. 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

26. 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

27. 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