Saturday, March 19, 2011

How will IE9 maintain momentum?

Unless you live under a rock, you must have noticed that Microsoft released Internet Explorer 9 this week.

I have been using IE9 since the first platform preview, and I think it's a very solid browser, outclassing every previous Microsoft browser by far. Microsoft finally built a browser which is capable of competing with other modern browsers.

The global consensus seems to be that Internet Explorer has regained serious momentum. Now I wonder how Microsoft plans on maintaining that momentum. IE9 still has some issues to address, and with the HTML5 specifications progressing at this rate, a ton of specs will be stable in the near future.

I think a big part of the future success of IE9 is directly proportional to the ability to leverage these fixes and new features.

As far as I know they are going to continue pushing browser updates through Windows Updates, and this raises a few concerns. A lot of people have disabled automatic Windows Updates. Either they are using a pirated OS, or they simply have disabled them. In corporate environments where IT administrators decide which updates get pushed, often only the essential - security - updates get pushed.

The way Google Chrome leverages updates is far better. Maybe you haven't noticed, but Chrome updates itself on a daily basis. If you open the Task Scheduler you will find GoogleUpdate tasks which run daily. I believe this is one of the key reasons Google Chrome is so popular in the developer community. This aggressive update progress enables Google to implement features, and fix them real quick when something is broken.

Do we really need to wait for IE10 to have support for more HTML5 features? Will the future bring an army of Frankenstein Internet Explorers?
Or will Microsoft revise their update strategy? Something I would like to see them do is decouple the IE update process from Windows Updates, especially for home users. Make web not war, right?

Tuesday, March 15, 2011

Running XBAP in IE9

By default you can't run XAML Browser Applications in IE9. You will get an "An error occurred in the application you were running" error.

To run an XBAP in IE9 you need to add the hosting site to your trusted sites..

.. or you could convert the application to Silverlight, or preferably HTML5 ;)

Saturday, March 12, 2011

Keeping WebSockets alive

The problem with using stateful connections on an imperfect place as the internet is that connections might drop. The server or an intermediary can drop the connection due to an idle timeout. Even a temporary problem at the server or a local network hiccup might kill your connection.

If you aren't prepared to handle these scenarios, you will not be able to fully rely on WebSockets.

A simple solution

The simplest solution is checking every few seconds whether the WebSocket is still opened. This might suffice in a good amount of scenarios, but a lot of other scenarios require more stable connectivity.

$(document).ready(function () {        
    setInterval(openWebSocket, 5000);
function openWebSocket(){
    if (websocket.readyState === undefined || websocket.readyState > 1) {


As mentioned before, the server or an intermediate might drop the connection when the connection becomes idle. To prevent this, you could make your server send keepalive messages at predefined intervals.

I implemented this in the HTML5 Labs WCF Server.

[ServiceBehavior(InstanceContextMode = InstanceContextMode.PerSession, 
                 ConcurrencyMode = ConcurrencyMode.Multiple)]
public class CadSubscriptionService : WebSocketsService {
    private static KeepAliveBroadcaster _keepAliveBroadcaster;
    public CadSubscriptionService() {           
        if (_keepAliveBroadcaster == null) {
            _keepAliveBroadcaster = new KeepAliveBroadcaster();
    public override void OnOpen() {
    protected override void OnClose(object sender, EventArgs e) {
        base.OnClose(sender, e);

The KeepAliveBroadcaster class maintains a list of connected sessions. Using a Timer it sends a message to each client every 15 seconds. This should stop the connection from dropping due to an idle timeout.

public class KeepAliveBroadcaster {
    private List<WebSocketsService> _services;
    private Timer _timer;
    public KeepAliveBroadcaster() {
        _timer = new Timer((o) => {
            if (_services == null) {
            lock (_services) {
                if (_services.Count > 0) {
                    foreach (var service in _services) {
                        service.Send("staying alive!");
        }, null, 100, 15000);              
    public void AddService(WebSocketsService service) {
        if (_services == null) {
            _services = new List<WebSocketsService>();
        lock (_services) {               
    public void RemoveService(WebSocketsService service) {
        lock (_services) {

Reopening ASAP

Something you could also implement is reopening the connection as soon as it closes.

Retry opening the connection when the onclose event fires. Think about limiting the number of retries, or you might end up with an infinite loop.

websocket.onclose = function (event) {            
    $('#status').html('Socket closed');    
function retryOpeningWebSocket(){
    if (retries < 2) {            
        setTimeout(openWebSocket, 1000);            

Some afterthought

Depending on what type of connectivity you require, these solutions might not suffice. If you can't afford to lose a single message, you might want to think about implementing queues at the client and server to overcome a gap of connection loss. Maybe you even want to implement some sort of acknowledge messaging. Something for a future post maybe!

Start experimenting yourself?

These links might get you started:

Tuesday, March 1, 2011

I will be talking at HTML5 WebCamps!

HTML5 WebCamps is a free event organized by Microsoft Belgium and will take place on April 6th at Living Tomorrow.

In my session I will be talking about WebSockets.
WebSockets on Fire

While the WebSockets API specification is not stable yet, various browser vendors have already implemented a prototype in their latest browser versions. Microsoft released their WebSockets prototype in December 2010. While there is no native implementation of WebSockets in IE9 just yet, for now they are providing a solution which works cross-browser, relying on a Silverlight client. Server-side a Windows Communication Foundation server is made available, which implements the latest version of the WebSockets protocol.

In this session, Jef covers the WebSockets fundamentals, demonstrates a proof of concept that could be used in various fire department web applications and deep-dives into the code of this proof of concept.

The full agenda of this event can be found here or here.

Register here. Seats are limited!

I hope to see you there.