diff --git a/node.html b/node.html index a06fbe9380..280ce04cc8 100644 --- a/node.html +++ b/node.html @@ -1,99 +1,115 @@ - - node.js - -
+ +node.js + +
+
    +
  1. Motivation
  2. +
  3. Benchmarks
  4. +
  5. Download
  6. +
  7. Build
  8. +
  9. API
      -
    1. Motivation
    2. -
    3. Benchmarks
    4. -
    5. Download
    6. -
    7. Build
    8. -
    9. API +
    10. Timers +
    11. File System +
    12. TCP +
    13. HTTP
        -
      1. Timers -
      2. File System -
      3. TCP -
      4. HTTP -
      5. Modules +
      6. Server +
      7. Client
      -
    14. +
    15. Modules
    -
-
+ + +
+
-

Node

+

Node

-

Node is a purely evented I/O framework for V8 javascript. It enables easy development of - highly concurrent, efficent network programs. For example, this is a - simple web server which responds with "Hello World" after waiting two - seconds: +

Node is a purely evented I/O framework for V8 javascript. For example, this is a +simple web server which responds with "Hello World" after waiting two +seconds:

-node.http.server(function (msg) {
+new node.http.Server(function (msg) {
   setTimeout(function () {
     msg.sendHeader(200, [["Content-Type", "text/plain"]]);
     msg.sendBody("Hello World");
@@ -102,60 +118,67 @@ node.http.server(function (msg) {
 }).listen(8000, "localhost");
 
-

While one request is waiting the server will continue to accept and - serve other requests. This little server can handle hundreds of - concurrent requests while using little CPU or memory—see benchmarks. The example demonstrates - efficency that is needed for handling long held "comet" requests. +

This script can handle hundreds of concurrent requests while using +little CPU or memory—see benchmarks. +Check out the documentation for more examples. -

Node is free to download, use, and build upon.

+

Node is free to download, use, and build upon.

-

Motivation

+

Motivation

-
    -
  1. Evented programming makes sense -
      -
    1. difference between blocking/non-blocking design -
    2. latency figures -
    3. purely evented interfaces rule out a lot of stupidity -
    -
  2. Evented programs are more efficient -
      -
    1. pthread stack size - 2mb default stack size on linux (1mb on windows, 64kb on FreeBSD) - of course this is adjustable -
    2. context switching benchmark -
    3. Apache vs. Nginx -
    4. event machine vs mongrel (neverblock) -
    -
  3. The appropriateness of Javascript -
      -
    1. No I/O -
    2. No Threads -
    3. Good compiler -
    4. Universality of the language -
    -
+
    +
  1. Evented programming makes sense +
      +
    1. difference between blocking/non-blocking design +

      There are many methods to write internet servers but they can + fundamentally be divided into two camps: evented and threaded; non-blocking + and blocking. A blocking server accepts a connection and launches a new + thread to handle the connection. Because the concurrency is handled by + the thread scheduler, a blocking server can make function calls which + preform full network requests. - Threads are a bad model. +

      var response = db.execute("SELECT * FROM table");
      +// do something
      -

      - I/O latency -

      -    l1 cache ~ 3
      -    l2 cache ~ 14
      -         ram ~ 250
      -        disk ~ 41000000
      -     network ~ 240000000
      -    
      +

      An evented server manages its concurrency itself. All connections + are handled in a single thread and callbacks are executed on certain + events: "socket 23 is has data to read", "socket 65's write buffer is + empty". An evented server executes small bits of code but never + blocks the process. In the evented world callbacks are used + instead of functions +

      db.execute("SELECT * FROM table", function (response) {
      +// do something
      +});
      +
    2. I/O latency +
      +l1 cache ~ 3
      +l2 cache ~ 14
      +     ram ~ 250
      +    disk ~ 41000000
      + network ~ 240000000
      +
      +
    3. purely evented interfaces rule out a lot of stupidity +
    +
  2. Evented programs are more efficient +
      +
    1. pthread stack size + 2mb default stack size on linux (1mb on windows, 64kb on FreeBSD) + of course this is adjustable +
    2. context switching benchmark +
    3. Apache vs. Nginx +
    4. event machine vs mongrel (neverblock) +
    +
  3. The appropriateness of Javascript +
      +
    1. No I/O

      Javascript is without I/O. In the browser the DOM provides I/O, but non-browser javascript interpreters have only non-standardized functions to allow them print to console or access the network. - -

      Javascript is without the concept of threads. - +

    2. No Threads +
    3. Good compiler +
    4. Universality of the language

      Contemporary computer infrastructure has two irreplaceable languages: C and Javascript. C is the language of operating systems. POSIX, the universal operating system API, is defined in C. So while you @@ -166,59 +189,159 @@ node.http.server(function (msg) { end browsers must be interfaced with in Javascript. Portable low-level systems tend to be written in C and portable web-level systems are written in Javascript. +

    +
-

Evented vs Threaded Servers

+

Benchmarks

-

There are many methods to write internet servers but they can - fundamentally be divided into two camps: evented and threaded; non-blocking - and blocking. A blocking server accepts a connection and launches a new - thread to handle the connection. Because the concurrency is handled by - the thread scheduler, a blocking server can make function calls which - preform full network requests. +

TODO -

var response = db.execute("SELECT * FROM table");
-// do something
+

Download

-

An evented server manages its concurrency itself. All connections - are handled in a single thread and callbacks are executed on certain - events: "socket 23 is has data to read", "socket 65's write buffer is - empty". An evented server executes small bits of code but never - blocks the process. In the evented world callbacks are used - instead of functions +

TODO -

db.execute("SELECT * FROM table", function (response) {
-  // do something
-});
+

Build

+
configure
+make
+make install
-

Benchmarks

-

Download

+

Application Programming Interface

- -

Build

+

The node executable should be given an argument pointing to a +javascript file. -

configure
-make
-make install
+

Timers

+ +

The timer API is the same as in the browser. The functions +setTimeout, setInterval, clearTimeout, and clearInterval + +

File System

+ +

TCP

+

HTTP (node.http)

-

Application Programming Interface

+

Node provides a fast web server and client interface. The interface is +rather low-level. Node, for example, will not parse +application/x-www-form-urlencoded message bodies—that is +for higher level code to manage. The interface does abstract the +Transfer-Encoding (i.e. chuncked or identity), Message boundarys, and +Keep-Alive connections. -

The node executable should be given an argument pointing to a - javascript file. +

HTTP Server (node.http.Server)

+
+
new Server(request_handler, options)
+
+

Creates a new web server. The options argument accepts + the same values as the options argument for + node.tcp.Server does. The options argument is optional. -

Timers

+

The request_handler is a function which is called on + each request with a Message object argument. +

+ +
server.listen(port, hostname) +
+

Begin accepting connections on the specified port and hostname. If the + hostname is omitted, the server will accept connections directed to any + address. +

+ +
server.close() +
+

Stops the server. Requests currently in progress will not be + interrupted. +

+
+ + +

HTTP Request Message (node.http.Message)

+ +

This object is only created internally—not by the user. It is passed +as an argument to the request_handler function in a web server. +

+
msg.method +
The request method as a string. Read only. Example: "GET", + "DELETE".
+ +
msg.uri +
The request URI as a string. Read only. + Example: "/index.html?hello=world".
+ +
msg.headers +
The request headers expressed as an array of 2-element arrays. Read only. + Example: +
+[ ["Content-Length", "123"]
+, ["Content-Type", "text/plain"]
+, ["Connection", "keep-alive"]
+, ["Accept", "*/*"]
+]
+
+ +
msg.http_version
+
The HTTP protocol version as a string. Read only. Examples: "1.1", + "1.0" + +
msg.connection
+
A reference to the node.tcp.Connection object. Read + only. Note that multiple messages can be sent on a single connection. +
+ +
msg.onBody
+
Callback. Should be set by the user to be informed of when a piece + of the message body is received. Example: +
+msg.onBody = function (chunk) {
+  puts("part of the body: " + chunk);
+}
+
+ A piece of the body is given as the single argument. The transfer-encoding + has been removed. + +
msg.onBodyComplete
+
Callback. Made exactly once for each message. No arguments. After + onBodyComplete is executed onBody will no longer be called. +
+ +
msg.sendHeader(status_code, headers)
+
+ Sends a response header to the request. The status code is a 3-digit + HTTP status code, like 404. The second argument, + headers, should be an array of 2-element arrays, + representing the response headers. + +

Example: +

+var body = "hello world";
+msg.sendHeader( 200
+              , [ ["Content-Length", body.length] 
+                , ["Content-Type", "text/plain"] 
+                ]
+              );
+
+ This method must only be called once on a message and it must be called + before msg.finish() is called. +
-

The timer API is the same as in the browser. The functions - setTimeout, setInterval, cancleTimeout, and cancleInterval +

msg.sendBody(chunk)
+
+ This method must be called after sendHeader was called. It + sends a chunk of the response body. This method may be called multiple + times to provide successive parts of the body. +
-

File System

+
msg.finish()
+
+ This method signals that all of the response headers and body has been + sent; that server should consider this message complete. + The method, msg.finish(), MUST be called on each response. -

TCP

+
-

HTTP

+

Modules

-

Modules

- +