Posts Tagged: node.js

General — View Comments
30
Aug 10

Moving the Server to the Browser

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?

General — View Comments
2
Dec 09

Event-Programming: The Highway to Concurrency?

nodejsYesterday I watched this talk by Ryan Dahl about node.js. node.js is a environment, based on Google’s v8 javascript engine, to build high-performance servers using the Javascript language. Here’s a simple hello world HTTP server:

var sys = require('sys'), 
   http = require('http');

http.createServer(function (req, res) {
  res.sendHeader(200,
    {'Content-Type': 'text/plain'});
  res.sendBody('Hello World');
  res.finish();
}).listen(8000);

You may ask yourself "why the hell would you use Javascript for server-side programming?" And that’s a valid question. However, in the case of node.js it seems like a good fit. Why? Because Javascript in the browser is very event-based: mouse over, click, drag and timeout events, for instance. Events are Javascript’s programming model in the browser. Node.js brings this idea to the server. Everything requiring I/O in node.js happens asynchronously, with everything you can provide a callback function, or set an event handler to handle events such as "data", when a block of data has been read from a stream. This results in improved performance.

Some people are really excited about node.js, but I’m not so sure. My feeling is that events are today’s goto statements: they lead to code for which it is is very difficult to determine what happens in which order. It’s bad enough that we have to do it this way in user interfaces and browser, do we really want this at the server as well?

Is performance more important than program comprehensibility?