1. Audience
  2. About
  3. Download
  4. Build
  5. Documentation

Node

Purely event-based I/O for V8 javascript.

An example of a web server written with Node which responds with "Hello World" after waiting two seconds: 

new node.http.Server(function (req, res) {
  setTimeout(function () {
    res.sendHeader(200, [["Content-Type", "text/plain"]]);
    res.sendBody("Hello World");
    res.finish();
  }, 2000);
}).listen(8000);
puts("Server running at http://127.0.0.1:8000/");

To run the server, put the code into a file example.js and execute it with the node program 

% /usr/local/bin/node example.js
Server running at http://127.0.0.1:8000/

See the API documentation for more examples.

Audience

This project is for those interested in

About

Node's goal is to provide an easy way to build scalable network programs. In the above example, the 2 second delay does not prevent the server from handling new requests. Node tells the operating system (through epoll, kqueue, /dev/poll, or select) that it should be notified when the 2 seconds are up or if a new connection is made—then it goes to sleep. If someone new connects, then it executes the callback, if the timeout expires, it executes the inner callback. Each connection is only a small heap allocation.

This is in contrast to today's more common model where OS threads are employed for concurrency. Thread-based networking is relatively inefficient and very difficult to use. Node will show much better memory efficiency under high-loads than systems which allocate 2mb thread stacks for each connection. Furthermore, users of Node are free from worries of dead-locking the process—there are no locks. No function in Node directly performs I/O, so the processes never blocks. Because nothing blocks, less-than-expert programmers are able to develop fast systems.

Node is similar in design to systems like Ruby's Event Machine or Python's Twisted. Node takes the event model a bit further. For example, in other systems there is always a blocking call to start the event-loop. Typically one defines behavior through callbacks at the beginning of a script and at the end starts a server through a call like EventMachine::run(). In Node, it works differently. By default Node enters the event loop after executing the input script. Node exits the event loop when there are no more callbacks to perform. The event loop is completely hidden from the user.

Node's HTTP API has grown out of my difficulties developing and working with web servers. For example, streaming data through most web frameworks is impossible. Or the oft-made false assumption that all message headers have unique fields. Node attempts to correct these and other problems in its API. Coupled with Node's purely evented infrastructure, it will make a solid foundation for future web libraries/frameworks.

But what about multiple-processor concurrency? Threads are necessary to scale programs to multi-core computers. The name Node should give some hint at how it is envisioned being used. Processes are necessary to scale to multi-core computers, not memory-sharing threads. The fundamentals of scalable systems are fast networking and non-blocking design—the rest is message passing. In the future, I'd like Node to to be able to spawn new processes (probably using the Web Workers API), but this is something that fits well into the current design.

Download

The git repo

Build

Node eventually wants to support all POSIX operating systems (including Windows with MinGW) but at the moment it is only being tested on Linux, Macintosh, and FreeBSD. The build system requires Python. V8, on which Node is built, supports only IA-32 and ARM processors. V8 is included in the Node distribution. There are no dependencies. 

./configure
make
make install

Then have a look at the API documentation.

To run the tests 

./configure --debug
make test