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
The results of such batching were so good that at Farata Systems, we started recom-
mending AMF to most of our customers (even those that have to use
objects for communication). Using AMF to proxy requests via an AMF-
enabled server delivers results from the HTTP servers more efficiently.
If a client request uses a specific destination on a proxy server, this des-
tination can be configured to use an AMF channel, even if an
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 solu-
tion. 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 com-
munications 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
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
272 | | Chapter 6: Open Source Networking Solutions
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 ar-
rival or executed in the iFrame (if packaged as
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.
When we started writing this book, the draft of the Java Servlet 3.0
specification (JSR-315) was based on asynchronous servlets implemen-
ted 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.”
What Is Comet?
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:
Define the life span of the connection object available for communications.
Notifies the servlet of the low-level errors in the transmission protocol.
Dispatched 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.
HTTP Connection Management t | | 273
Adding an event model to the server side brings symmetry to the client/server pro-
gramming model and greatly simplifies the asynchronous programming. Unfortu-
nately, existing implementations of this model are not overly reliable.
If you want to use the two-way socket model, you will need to write
some custom code using the Flash
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
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
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 re-
sponses at once, and need some kind of sorting adapters on both sides to distribute
batch members to the proper responders.
Putting Streaming to Work
Imagine a small village by the river. There is one boat, and whoever needs to go to the
other bank to buy some food takes this boat. No one in the village can go to the other
bank until the boat’s back. This is in some sense similar to the HTTP request/response
model of communication.
At some point, people who lived in the same village built a two-lane bridge over this
river. Each lane allows walking in one direction. All of a sudden you see that lots of
people are moving in both directions at the same time. The number of trips to the other
riverbank is a lot higher now. Yes, people carrying the shopping bags may go slower,
but they are all moving at the same time. And each trip is faster, too; there is no need
to embark/disembark from the boat (connect/disconnect). This is streaming.
RTMP implementation offers two-lane traffic (a two-directional socket)
and is a lot more efficient than the request/response model. Each con-
nected computer just sends the data in one direction to a dedicated
socket, which allows you to measure and estimate delivery metrics in
each direction. RTMP is an open protocol available at http://www.adobe
274 | | Chapter 6: Open Source Networking Solutions
In multimedia applications, having an uninterrupted data delivery is a must, and the
request/response model doesn’t work here. When you go to http://www.youtube.com,
you expect to start watching the video immediately, without waiting until the entire
file is downloaded to the client. And after seeing the first frames of the video, you’d like
to have the rest in a smooth, uninterrupted mode, and this type of playback is supported
by buffering of the stream data.
Integrating Multimedia Solutions
For a long time, Flash Player was the de facto standard tool in delivering multimedia—
especially video. These capabilities are based on its
object and are em-
bedded in a number of classes, including
communicates with the server by establishing a full duplex open
connection—the two-way socket—and both the server and the client can initiate the
conversation. This is a far simpler programming model, and provides improved per-
formance for intensive two-way communications.
A standard solution is to separate the media portion into an instance (or a farm) of the
Flash Media Server. However, some applications might have different licensing and
integration requirements. Other alternatives include Red5, an open source server, and
Wowza, a commercial Java media server. The advantages of these drop-in servers is the
transparency in integration of streaming with the other parts of the application.
With the release of Flash 10, new sound capabilities with high-quality voice codecs and
audio capabilities open up a whole new world of human interaction. But the most
important feature driving new types of applications will be based on peer-to-peer (P2P)
support and User Datagram Protocol (UDP) communications built into Flash Player 10.
Unlike traditional web applications, they require very little infrastructure and band-
width as they use clients’ resources. These applications enable VoIP, teleconferencing,
screen sharing, and resource polling of applications on the widest deployment platform.
The users of the business Flex applications want to have the same experience, too. In
this case, the stream consists of the Flex code and the data, so it’s important to make
the right decision about the amount of code that will have to be downloaded to the
Consider a few types of web applications that benefit from breaking free from a tradi-
tional request/response model:
Applications built on the publish/subscribe model or the server-side push
In this scenario, the data is being sent to the client as soon as it becomes available
on the server. Typical examples of such applications are chat rooms, stock market
data feeds, and delivering videos to users.
Putting Streaming to Work k | | 275
Online transaction processing, analytical applications, and distributed services that need
to extend the request/response model
For example, a call center application has to broadcast the data modifications done
by one clerk to another to ensure that the second doesn’t work on the stale data.
For distributed request/response services, you can’t guarantee the response time,
because the response may sit on the server just because the client has a very limited
set of available connection objects, in which case your application would stall.
Applications that need to force the execution of the code on the client
Some applications benefit from the server-side components being able to directly
call methods on the objects that exist on the client side in Flash Player. Typical
cases are remote support and administration or workflow systems in which the
server needs to force the client to move to a new node of the workflow. BlazeDS
needs to be enhanced to support servers that can call clients.
Figure 6-3 illustrates three use cases of enterprise RIA:
Subscribe and publish
You send the data using BlazeDS and improve the scalability of the application.
You’ll see this demonstrated with the Jetty server scenario in the following section.
Remoting and SOA
A remote object takes care of publishing and subscribing, keeps track of the cor-
relation IDs of the messages received from the clients, and pushes the data to the
clients. In the service-oriented architecture (SOA) world, the data returned by the
service may change over time, and you can’t control it. In this model, you can’t
control the response time, either. SOA is a good use case for introducing data push
to a rich client.
You need to push the software or data updates to the client.
Figure 6-3. Use cases for streaming
276 | | Chapter 6: Open Source Networking Solutions
Documents you may be interested
Documents you may be interested