I am Zef

I think that it’s well-established by now that the majority of desktop software will move to the browser at some point. It happened to e-mail, calendar, word processing and many more applications already. But here’s a crazy idea: what if we move the server to the browser as well?

The past week I’ve been playing with socket.io in mobl, my language for developing mobile web apps. Socket.io is a library that greatly simplifies building real-time web applications — applications that keep a connection (a socket) open to the server, allowing the server to push content to the client and vice versa. It was pretty straight-forward to build a library enabling use of socket.io from mobl.

The first thing I built was mobl draw (only works in modern versions of Chrome, Safari or Firefox). The client code, written in mobl, is pretty straight-forward. It uses the HTML5 canvas and responds to touch/mouse events. When you click/tap and drag, it will draw a line at that position and buffers your movements locally. A couple of times per second it pushes the buffer of movements to the server. The server broadcasts the update to all other connected clients. The result: everybody connected at the same time, can draw together in real-time. A pretty cool demo. In addition, the server keeps track of the entire drawing history, resulting in a quick replay of all the drawing that happened when you first open the page. The client part of mobl draw is written in mobl, of course, but the server component (albeit small) is written in server-side Javascript, using node.js.

Then, a colleague suggested building a game using mobl. I decided to build a multi-player snake variant. The client code was quick enough to build. The server-component, however, contained all the “interesting” stuff. The game logic was all written as part of the server, written using Javascript. Wasn’t this supposed to be a mobl exercise? Mobl currently focusses purely on the client-side of things, it does not (yet) have a server-side component. If I wanted to build the server in mobl as well, I had two options: (1) add a server-component to mobl, or (2) build a generic light-weight peer-to-peer message relay server in node.js once, enabling servers to also run in the browser.

I decided to do the latter. This brings back memories from networked games I used to play, where you could either join or host a server that would run on your computer.

So, in mobl there’s now a library called mobl::peersocket that has two types:

• ServerSocket, to instantiate a server
• Socket, to connect to a server

To start a server, you use ServerSocket.create:

var ss = ServerSocket.create("my-server",
             onconnect=handleConnect,
             ondisconnect=handleDisconnect,
             onmessage=receiveMessage);
ss.broadcast("Waddup!?");

Then, you can connect to it:

var cs = Socket.join("my-server",
             onmessage=clientReceiveMessage);
cs.send("Hello");

What this will do is establish a connection with the node.js relay server and register this mobl application as a server with the name “my-server”. Whenever a client connects to this server (using Socket.join("my-server")), the server app will be notified (onconnect will be triggered), and any messages sent to my-server, will be relayed to the mobl server app. All the node.js relay server does is handle the creation of servers, handle connection to servers and pass messages around between clients and servers. It does not contain any game logic whatsoever, all of that is in the mobl server code.

The result is running here. To start, it presents you with a list of currently running servers (if any), and a link to the page to host your own server. After picking a server you pick a player name and start playing. Multiple servers can be run at the same time and each has its own playing field. An issue seems to be latency. If the server does not have a low-latency internet connection, it can take a while for it to register left/right movements, which is sort of annoying. Of course, the latency is higher that typical, because every message between client and server is relayed through the node.js server. It’s a quite fun game though, one of my colleagues even built a simple bot using Greasemonkey.

Although it’s a thought-provoking experiment, what’s the point of running a server in your browser? In my case the reason was to be able to write the server in mobl as well, but how does that help anybody else? To be honest I’m not entirely sure yet.

It could be a secure way to let third parties host their own code on your servers. A third party would upload their code to your servers and they would run the uploaded server software in their own browser, which is completely secure — the server code can only communicate with its clients through your relay server and use resources available in the browser (e.g. a local database and CPU cycles). But who knows, there may be other reasons to do this as well. Any thoughts?