HTML and CSS Reference
In-Depth Information
accomplish this, you can use a capable protocol such as WebSockets or SPDY to build
the stack yourself. Or you can choose a service or project to manage the connections
and graceful degradation for you. In this chapter, you'll learn how to implement a raw
WebSocket server and the best practices surrounding the details of setting one up.
If you opt to leave the management to someone else, you have choices. Freemium serv‐
ices, such as Pusher ( ), are starting to emerge to do this, and companies
like Kaazing, which offers the Kaazing Gateway, have been providing adapters for
STOMP and Apache ActiveMQ for years. In addition, you can find plenty of wrapper
frameworks around WebSockets to provide graceful degradation—from Socket.IO to
CometD to whatever's hot right now. Graceful degradation is the process of falling back
to use older technologies, such as Flash or long polling, within the browser if the Web‐
Socket protocol is not supported. Comet, push technology, and long-polling in web apps
are slow, inefficient, inelegant and have a higher potential magnitude for unreliability.
For this topic, I am only covering the core WebSocket specification to avoid confusion
and to keep things simple.
As of August 2012, the WebSocket specification was in Working Draft
status. Implementers and editors were working to bring the spec into
Candidate Release status. Until that status is declared, be aware that
things could change in regard to the underlying protocol.
On the Server, Behind the Scenes
Keeping a large number of connections open at the same time requires an architecture
that permits other processing to continue before the transmission has finished. Such
architectures are usually designed around threading or asynchronous nonblocking IO
( NIO ). As for the debates between NIO and threading, some might say that NIO does
not actually perform better than threading, but only allows you to write single-threaded
event loops for multiple clients as with select on Unix. Others argue that choosing NIO
or threading depends on your expected workloads. If you have lots of long-term idle
connections, NIO wins due to not having thousands of threads “blocking on a read”
operation. Again, there are many debates over whether threads are faster or easier to
write than event loops (or the opposite) so it all depends on the type of use case you are
trying to handle. Don't worry, I'll show examples of both event loops and threads in this
Programming Models
As mentioned earlier, WebSockets present a new development model for server- and
client-side applications: the “real-time” Web. During every user connection under this
model, your web application's client side needs to communicate continuously with the
Search WWH ::

Custom Search