HTML5 Web Sockets API reloaded

One of the most exciting upcoming features of HTML5 is the ability to open persistent bidirectional sockets to a remote host.

As far as I know, one of the early proposals was about allowing web applications almost complete control over sockets, including the ability to create raw sockets and to listen for incoming connections exactly like a typical network daemon/server, but this proposal was later scraped because of security implications.

Fast forward to today and the Web Sockets API, even if still under development, are starting to get a stable shape and they will probably be implemented soon by the most forward-looking browser vendors.

The problem is, though, that the original proposal got crampled along the way and therefore there won’t be any means to create peer-to-peer connections between users, something that could enable all kinds of cool distributed systems.

That is, unless someone does something: what I’m thinking about right now is a kind of wrapper/extension around the Web Sockets API that does simply a few things:

  1. allows a web application to register for incoming connections
  2. opens up the required ports on the firewall/NAT
  3. when a connection arrives, perform the handshaking required by the ws:// protocol and forwards a WebSocket object representing the connection to the application

Talking IDL, that would mean (the WebSocket interface is the current WHATWG proposal, while WebSocketListener is my addition):

[Constructor(in DOMString url, optional in DOMString protocol)]
interface WebSocket {
  readonly attribute DOMString URL;

  // ready state
  const unsigned short CONNECTING = 0;
  const unsigned short OPEN = 1;
  const unsigned short CLOSED = 2;
  readonly attribute unsigned short readyState;
  readonly attribute unsigned long bufferedAmount;

  // networking
           attribute Function onopen;
           attribute Function onmessage;
           attribute Function onclose;
  boolean send(in DOMString data);
  void close();
};

[Constructor(optional in short port, optional in DOMString protocol)]
interface WebSocketListener {
  readonly attribute short port;

  // ready state
  const unsigned short OPENING = 0;
  const unsigned short LISTENING = 1;
  const unsigned short CLOSED = 2;
  readonly attribute unsigned short readyState;

  // networking
           attribute Function onconnection;
  void close();
};

Talking about the Mozilla platform, points 1 and 3 are straightforward (once the Web Sockets API has been implemented), whereas point 2 will be platform-dependent and, therefore, trickier. Nevertheless, I think that all of this can be handled (with some work) by a Firefox extension.

Once Firefox will gain Web Sockets support I’ll definitely try to see if it is possible to add it.

A DHT for Mozilla?

I’ve been thinking in the last few days about writing a DHT implementation for Mozilla, some kind of generic library (packaged as an add-on) that may be used in a tons of different ways, like:

  • a distributed version of Weave (for Firefox)
  • a shared cache/proxy/CDN system (that would allow users to reach otherwise unreachable resources, be it because of server downtime or because of censorship policies)
  • a file sharing platform (for Songbird: imagine being able to see in your library not only your songs, but also everyone else’s)
  • a distributed computing platform (more on this in a later post)
  • the Next Big Thing™

BTW, much of this is partly already implemented in any bittorrent client (and the rest is already on track), what’s needed is just glueing the pieces together. As soon as my exams are over I’ll give it a try…