Web Application Development Tips, Tricks and Techniques
HTML 5 Web Sockets
Following the series of posts discussing AJAX calls, today we’ll see what is going to be its evolution: Web Sockets. It’s still a very new technology, and support is starting to be implemented in most major browsers and web servers. But don’t count on using it yet, since most of the clients of your web app will not be able to use them. I’ll discuss web sockets here just so you know what the future is going to bring to the web apps world.
The history: the beginning of AJAX
The world wide web and the Internet started as a stateless content delivery mechanism, taking a step backwards compared to traditional desktop applications. Early Internet applications needed to explicitly request every piece of information, and the server sent only the requested data.
Then came what we now call “Web 2.0 application development”: Dynamic HTML, heavy usage of JavaScript, AJAX, and various plugins (Adobe Flash and Microsoft Silverlight). These applications were dynamic and responsive, and they brought much of that rich interactive experience users enjoyed in desktop client/server applications to the Internet. However, due to the request and response architecture that these applications are based on, the latest Rich Internet Applications still cannot match the connectivity and the capability to get real-time data that client/server applications had more than a decade ago.
The reason is that these applications still need to initiate the communication from the web browser to get some data from the server: that is, the client part of the application running in the web browser has no way to know whether the server has some data for it.
The next logical step: polling and Comet programming techniques
Thus, software engineers started working in solving this problem. The client needed to be conscious of any request the server might have for it. But how to achieve this? Well, if communication can only be started by the client, then let’s just make it that way. We’ll make the client constantly ask the server whether there’s some data ready for it. This is what is called polling.
By using this technique, the web application essentially polls the server on a regular basis, based on a timer, using a simple HTTP request each time the timer expires. However, the cost of polling frequently is very high – both in terms of network bandwidth as well as server infrastructure needed to support a huge number of polling requests. The server must have the capability to buffer the data that it needs to send to the client until the next request comes from the client.
After a short while, this technique was seen totally unusable due to its great resource requirements. Then came the Comet programming techniques – long polling and streaming:
In long polling, also known as asynchronous polling, the browser sends a request to the server and the server keeps the request open for a set period. If a notification is received within that period, a response containing the message is sent to the client. If a notification is not received within the set time period, the server sends a response to terminate the open request and the browser resends the request to the server.
When streaming is used, the browser sends a complete request, but the server sends and maintains an open response that is continuously updated. A request is sent and kept open indefinitely (or for a set period of time) and the response is updated whenever a message is ready to be sent, but the server never signals to complete the response, thus keeping the connection open to deliver future messages.
But if you think about it, these techniques are just hacks, tricks used to simulate a technology that doesn’t exist: server-sent events. If the server could actually start the communication, none of these ugly tricks would be needed.
The evolution: server-sent events & Web Sockets
We had to wait until HTML 5 came to solve this problem. The Communication section in the HTML 5 specification section introduces server-sent events and Web Sockets. These new features enable a new paradigm of web application programming that will revolutionize the way to develop and deploy web applications.
Server-sent events are not quite the solution, but a formalization of Comet programming techniques. The server-sent event HTML 5 specification introduces a new DOM element called eventsource.
But the guy we must pay all our attention to is the HTML 5 Web Socket specification: the Web Socket interface defines a full duplex communications channel that is exposed via a JavaScript interface in HTML 5 compliant browsers.
When a new Web Socket connection is established, the browser opens an HTTP connection to the server first and then negotiates with the server to upgrade the connection to a dedicated and persistent Web Socket connection. This process automatically sets up a tunnel through to the server, solving numerous issues that the various Comet programming techniques encountered. Once established the Web Socket is a full duplex channel between the client and the server.
I’ve developed a Web Socket server and client implementation. Check it out for yourself and see what I’m talking about!
My name is Oliver Mezquita Prieto, and I'm a Software Engineer focused on web application development, both serverside and clientside, using ASP.NET technology.
Got something to say? Drop me a line!
June 9, 2010 - 09:40
It’s posts like this that keep me coming back and checking this site regularly, thanks for the info!
June 11, 2010 - 12:08
this post is very usefull thx!
June 16, 2010 - 08:02
Great site. A lot of useful information here. I’m sending it to some friends!
June 19, 2010 - 13:32
I’ve recently started a blog, the information you provide on this site has helped me tremendously. Thank you for all of your time & work.
June 22, 2010 - 14:09
Nice brief and this enter helped me alot in my college assignement. Say thank you you for your information.
June 22, 2010 - 17:31
nice post. thanks.
September 14, 2010 - 17:24
why it show that
“Trying to connect to the server …
Connection closed.”
when i click connection button?
there are some errors?
but the server side can get the request…
should i modify the setting when i test in localhost?
September 22, 2010 - 21:26
When loading the solution in Visual Studio, you’ll see that there’s two different projects. Well, you need to run both of them. The “Web Sockets Test – Server” project is the actual Web Socket Server. Start it, and you’ll see a command window will launch saying that the server is waiting for a connection request.
Once you have the server running, you can launch the web application that will test it. Go to the “Web Sockets Test – Web Application” project and start it. The default values you see in your web browser are the ones set in the server. If you want to change them you’ll need to take care of the server configuration as well. So, using “localhost:8181/test” should work.
Let me know whether this worked for you or not.
Cheers!
October 8, 2010 - 02:57
Thanks Oliver,
I was searching like this project, I am going to test it. My main objective to impement this project : i want to connect though internet on specific port on specific IP. can i use http://www.viobiz.com:8000 as server ? n get notified when client connect on site installed server or what could be solution.
October 10, 2010 - 19:15
Sure you can. Just set it up in your server with port set at 8000, and you’re ready to go!