To really appreciate the advantages of binary data transfers and a persistent connection to the server, take a step back and consider how web browsers in traditional web applications connect to servers.
For years, web browsers would allow only two connections per domain. Because Flash Player uses the browser’s connection for running HTTP requests to the server, it shares the same limitations as all browser-based applications.
The latest versions of Internet Explorer (IE) and Mozilla Firefox increased the default number of simultaneous parallel HTTP requests per domain/window from two to six. It’s probably the biggest news in the AJAX world in the last three years. For the current crop of AJAX sites serving real WAN connections it means increasing the load speed and fewer timeouts/reliability issues. By the way, most of the Opera and Safari performance gains over IE and Firefox in the past are attributed to the fact that they allowed and used four connections, ignoring the recommendations of the W3C (which suggested allowing only two connections).
The fact that increasing the number of parallel connections increases network throughput is easy to understand. Today’s request/response approach for browser communications is very similar to the village bike concept. Imagine that there are only a couple of bikes that serve the entire village. People ride a bike and come back to give it to the next person in line. People wait for their turns, keeping their fingers crossed that the person in front of them won’t get lost in the woods during her ride. If that happens, they need to wait till all hope is gone (i.e., timeout) and the village authorities provide them with a new bike circa 1996.
Pretty often, by the time the new bike arrives it’s too late: the person decided to get engaged in a different activity (abandon this site). As the travel destinations become more distant (WAN), people are exposed to real-world troubles of commuting—latency (500 ms for a geostatic satellite network), bandwidth limitations, jitter (errors), unrecoverable losses, etc. Besides that, the users may experience congestion caused by the fact that your ISP decided to make some extra cash by trying to become a TV broadcaster and a Voice over Internet Protocol (VoIP) company but lacks the required infrastructure. The applications that worked perfectly on local/fast networks will crumble in every imaginable way.
Obviously, more bikes (browser connections) mean that with some traffic planning you can offer a lot more fun to the bikers (get much better performance and reliability). You might even allocate one bike to a sheriff/firefighter/village doctor so he will provide information on conditions and lost/damaged goods carried by the bikers. You can route important goods in parallel so they will not get lost or damaged that easily.
You can really start utilizing the long-running connection for real data push now. But first, let’s go back 10 years and try to figure out how the early adopters of RIAs developed with AJAX survived.
Note
Even though AJAX as a term was coined only in
2005, the authors of this book started using the
DHTML/XMLHttpRequest combo (currently known as AJAX)
in the year 2000.
In the beginning of this century, most of the enterprises we worked with quietly rolled out browser builds/service packs increasing the number of allowed HTTP connections. This was just a hack. For Internet Explorer, the following changes to Windows registry keys would increase the number of the browser connections to 10:
HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionInternet Settings MaxConnectionsPer1_0Server 10 MaxConnectionsPerServer 10
With Mozilla’s Firefox, you has to recompile the source code of the entire browser.
The hack does solve most of the performance and reliability issues for a short while. The main reason is that without imposed limits, software increases in size faster than transistor capacity under Moore’s Law. And unlike in private networks in enterprises, without a proper “city framework,” rampant requests will cause an overall Internet meltdown as the initial rollout of more capable browsers gives them an unfair advantage in terms of bandwidth share.
If a server receives eight connection requests, it’ll try to allocate the limited available bandwidth accordingly, and, for instance, Firefox’s requests will enjoy better throughput than those of Internet Explorer, which on older and slower networks will cause quality of service (QoS) problems. In other words, this solution has a very real potential to cause more of the same problems it’s expected to solve.
Most enterprises have to control QoS of their clients’ communications. For example, a company that trades stock has a service level agreement (SLA) with their clients promising to push the new price quotes twice a second. To keep such a promise, the enterprise should create and adopt a number of point-to-point solutions that provide more efficient communication models, which fall into three categories:
- HTTP batching and streaming of multiple requests in a single HTTP call and Comet communications
Comet, a.k.a. reverse AJAX, allows the web server to push data to the web browser, as opposed to a traditional request/response model. AMF performs automatic batching of the requests. If your program executes a loop that generates 50 HTTP requests to the server, AMF will batch them and will send them as one HTTP request.
Note
Imagine that someone wrote a loop in JavaScript that makes an HTTP server request on each iteration. The browser can batch these requests and send, say, 10 requests at a time. This is HTTP batching. In this scenario, the browser would assign a message ID to each request included in the batch, and arriving responses would contain correlation IDs that would allow the browser to find the matching requestors.
- Binary components that work with two-directional sockets
This is the case used in multimedia streaming, where there are two separate channels, and each is used for sending data in one direction: either to or from the server.
- Pluggable protocols, which are wrappers for standard protocols
Say you can develop some custom protocol called HTTPZ, which for the browsers will look like HTTP, but under the hood will use streaming or even a socket-based protocol like RTMP. The browser “believes” that it uses HTTP, the web server receives RTMP, and the translation is done by HTTPZ—every party is happy.
The pluggable protocol option did not become popular, even though it allows moving most of the problems from the browser to the OS level. The batching and streaming options, however, did.
Regular HTTP is based on the request/response model, which has an overhead of establishing a connection (and consequently disconnecting) on each request. In the case of streaming, this connection is opened only once (for more information, see the section Putting Streaming to Work).
HTTP batching and streaming is a combination of a few technologies with a close resemblance to how car traffic is controlled on some highways. There are dedicated lanes for high-occupancy vehicles (HOVs) that move faster during the rush hours. Such HOV lanes can be compared to the HTTP channels opened for streaming. For example, you can program network communications in such a way that one channel allows only two data pushes per second (a guaranteed QoS), while the other channel will try to push all the data, which may cause network congestion, delays, and queuing.
As an example, the Flex/Flash AMF protocol tries to squeeze out every bit of bandwidth and optimize queuing of the requests in the most efficient way—both on client and server. As a result, your application uses the maximum bandwidth, and request queues are short.
The results of such batching were so good that at Farata Systems,
we started recommending AMF to most of our customers (even those that
have to use WebService or HTTPService objects for communication). Using
AMF to proxy requests via an AMF-enabled server delivers results from
the HTTP servers more efficiently.
Note
If a client request uses a specific destination on a proxy
server, this destination can be configured to use an AMF channel, even
if an HTTPService object has been used as
a means of communications.
With AMF, the data gets loaded faster than with nonbatched requests/responses. And it plays nicely with the typical infrastructures that use firewalls as it piggybacks on the existing browser HTTP requests.
However, for critical applications built on plain infrastructures a problem remains: there is no QoS provided by the HTTP protocol, which may become a showstopper. For example, think of a financial application that sends real-time price quotes to its users. The server keeps sending messages, regardless of the current throughput of the network, which in the case of network congestion will be causing problems with queue overruns or lost packages.
Binary always on (re)connected socket protocols are a more logical and efficient solution. Unlike the request/response model, a typical socket connection is like a two-way highway, with data moving in opposite directions independently. But before we fully depart into the Communications 2.0 world, let’s make sure that you understand how HTTP is shaping up these days.
The disconnected model of HTTP 1.0 was not practical. The overhead
of connecting/disconnecting for each request was not tolerable, and for
the last eight years we have not seen a single web browser using it. It
has been completely replaced by HTTP
1.1—the protocol that keeps connections open beyond
request/response so the next communications with the server happen
faster. Under the hood, there are two-way sockets that stay open—but
browsers diligently follow the old model. They don’t create bidirectional pipe-like connections, as in
flash.net.NetConnection.
As web browsers started to host business applications, the need to process the real-time data forced people to look into solutions better than polling, and a few server-side push solutions were discovered. Although there were differences in implementations, the main theme remained the same—the server would get requests and hold them for a long time, flushing packages down when it became available.
The packages would reach the browser to be interpreted either by
programs upon arrival or executed in the iFrame (if packaged as <script/> sections of DHTML). The
important part was that people started to see that a server-driven model
was valid, and that it was a better fit for some applications. The
servers started controlling the clients.
Currently, there are two approaches to breaking the request/response paradigm: the Comet model and the model offered by the creators of the Jetty application server.
Note
When we started writing this book, the draft of the Java Servlet 3.0 specification (JSR-315) was based on asynchronous servlets implemented in the Jetty Servlet container. Then, the public review of JSR-315 was drastically changed. You can read more on the subject in the post titled “JSR-315: JSP Failings.”
A number of open source and commercial implementations of Comet exist in Java and Python. They can be very different, capitalizing on nonblocking I/O, using optimized threads, or offering more efficient native sockets support.
A servlet container in Jetty works in a half-duplex mode: it opens a dedicated streaming connection for flushing the data to the client, but also allows request/responses.
The Comet model is a full duplex that uses a two-way socket implementation (like in Apache Tomcat), which extends a conventional request/response model with events that are being sent on an established HTTP connection.
With Comet, the idea is that the server provides a second model
for the requests handler in addition to the conventional one. There is a
dedicated open connection that receives events related to the requests.
If you run a Java servlet, it will receive additional events from the
server: connect, read, error, and disconnect:
connectanddisconnectDefine the life span of the connection object available for communications.
errorNotifies the servlet of the low-level errors in the transmission protocol.
readDispatched when there is a request coming from the client; allows the server to read and process it. The server keeps connection and response objects and writes (flushes) the information to the client as needed.
Adding an event model to the server side brings symmetry to the client/server programming model and greatly simplifies the asynchronous programming. Unfortunately, existing implementations of this model are not overly reliable.
Note
If you want to use the two-way socket model, you will need to
write some custom code using the Flash NetConnection object to stream the data from
the client to the server, too.
Consider how this model is different for fine-grained requests common in today’s AJAX applications. Imagine that you’re in a coffee shop with a lousy WiFi connection sporting 1-second latency for a typical eBay response implemented as a web device, watching 30 items.
With the current browser settings (two connections per domain), it would take you 15 seconds to refresh all 30 items. With six allowed browser connections, this time is reduced to five seconds, but will require a more powerful infrastructure on the server side.
With the Comet-type requests, you can send all 30 requests without waiting for a single response (the same will be done with AMF HTTP batching) and will receive all 30 responses asynchronously. Meanwhile, with HTTP batching, you would get all 30 responses at once, and need some kind of sorting adapters on both sides to distribute batch members to the proper responders.