The Cipher Class provides a wrapper for encrypting data using a private key. The factory method to create a cipher takes an algorithm and the private key. The algorithms supported come from those compiled into your OpenSSL implementation.

Many modern cryptographic algorithms use block ciphers. This means that the output is always in standard sized "blocks." The block sizes vary between algorithms: Blowfish, for example, uses 40-byte blocks. This is signifant when using the Cipher API, because the API will always output fixed sized blocks. This helps prevent information from being leaked to an attacker about the data being encrypted or the specific key being used to do the encryption.

Like Hash and Hmac, the Cipher API also uses the update() method to input data. However, update works differently when used in a cipher. First, cipher.update() returns a block of encytped data if it can. This is where block size becomes important. If the amount of data in the cipher plus the amount of data passed to cipher.update() is enough to create one or more blocks, the encrypted data will be returned. If there isn't enough to form a block, the input will be stored in the cipher. Cipher also has a new method, Cipher.final() which replaces the digest() method. When cipher.final() is called, any remaining data in the cipher will be returned encyrpted, but with enough padding to make sure the block size is reached.

> var crypto = require('crypto');
> var fs = require('fs');
>
> var pem = fs.readFileSync('key.pem');
> var key = pem.toString('ascii');
>
> var cipher = crypto.createCipher('blowfish', key);
> 
> cipher.update(new Buffer(4), 'binary', 'hex');
''
> cipher.update(new Buffer(4), 'binary', 'hex');
'ff57e5f742689c85'
> cipher.update(new Buffer(4), 'binary', 'hex');
''
> cipher.final('hex')
'96576b47fe130547'
> 

            

In order to make the example easier to read, I specified the input and output formats. The input and output format are both optional and will be assumed to be binary unless specified. For this example, I specified a binaryinput format because I'm passing a new Buffer (containing whatever random junk was in memory), along with hex output to produce something easier to read. You can see that the first time I call cipher.update(), with 4 bytes of data, I get back an empty string. The second time, because I have enough data to generate a block, I get the encrypted data back as hex. When I call cipher.final(), there isn't enough data to create a full block, so the output is padded and a full (and final) block is returned. If I sent more data than would in a single block cipher.final() would output as many blocks as it could before padding. Since Cipher.final() is just for outputting existing data, it doesn't accept an input format.

The Decipher class is the almost exact inverse of the Cipher class. You can pass encrypted data to a Decipher object using decipher.update(). It will stream it into blocks until it can output the unecrypted data. You might think that since cipher.update() and cipher.final() always give fixed length blocks, you would have to give perfect blocks to decipher, but luckily it will buffer the data, so you can pass it data you got off some other I/O transport such as the disk or network, even if this might give you block sizes different from those used by the encryption algorithm.

Let's take a look an example of encrypting data and then decrypting it:

> var crypto = require('crypto');
> var fs = require('fs');
> 
> var pem = fs.readFileSync('key.pem');
> var key = pem.toString('ascii');
> 
> var plaintext = new Buffer('abcdefghijklmnopqrstuv');
> var encrypted = "";
> var cipher = crypto.createCipher('blowfish', key);
> 
> encrypted += cipher.update(plaintext, 'binary', 'hex');
> encrypted += cipher.final('hex');
> 
> var decrypted = "";
> var decipher = crypto.createDecipher('blowfish', key);
> decrypted += decipher.update(encrypted, 'hex', 'binary');
> decrypted += decipher.final('binary');
> 
> var output = new Buffer(decrypted);
>
> output
<Buffer 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 75 76>
> plaintext
<Buffer 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 75 76>
> 

            

It is important to make sure both the input and output formats match up for both the plaintext and the encrypted data. It's also worth noting that in order to get a buffer, you'll have to make one from the strings returned by cipher and decipher.

Signitures verify that some data has been authenticated by the signer using the private key. However, unlike with HMAC, the public key can be used to authenticate the signiture. The API for Sign is nearly identical to that for HMAC. crypto.createSign() is used to make a sign object. It takes only the signing algorithm. sign.update() allows you to add data to the sign object. When you want to create the signature, call sign.sign() with a private key to sign the data.

> var sign = crypto.createSign('RSA-SHA256');
> sign.update('abcdef');
{}
> sig = sign.sign(key, 'hex');
'35eb47af5260a00c7bad26edfbe7732a897a3a03290963e3d17f48331a42d48cc0753621e95c374c917424574be237e112c2be2a5eff74c200697b58e275a846f46da5e6f53ba69a0532b1db7e93aba49e3a463620f53461e7215189ae4a1658f4a57720174dddc5a9eaffbd34982ca4a3eefc03886f3caa53e013c3f03aa81b'
> 

            

The Verify API works uses a method like the ones we've seen, verify.update(), to add data. When you have added all the data to be verified against the signiture verify.verify() validates the signiture. It takes the cert (the public key), the signature, and the format of the signature.

> var crypto = require('crypto');
> var fs = require('fs');
> 
> var privatePem = fs.readFileSync('key.pem');
> var publicPem = fs.readFileSync('cert.pem');
> var key = privatePem.toString();
> var pubkey = publicPem.toString();
> 
> var data = "abcdef"
> 
> var sign = crypto.createSign('RSA-SHA256');
> sign.update(data);
{}
> var sig = sign.sign(key, 'hex');
> 
> var verify = crypto.createVerify('RSA-SHA256');
> verify.update(data);
{}
> verify.verify(pubkey, sig, 'hex');
1

            

process is an instance of EventEmitter, so it provides events based on systems calls to the Node process. The exit event provides a final hook before the Node process exits. Importantly, the event loop will not run after the exit event, so only code without callbacks will be executed:

process.on('exit', function () {
  setTimeout(function () {
   console.log('This will not run');
  }, 100);
  console.log('Bye.');
});

          

Since the loop isn't going to run again, the setTimeout() code will never be evaluated.

An extremely useful event provided by process is uncaughtException. After you've spent any time with Node, you'll find that exceptions that hit the main event loop will kill your Node process. In many use cases, especially servers that are expected to never be down, this is unacceptable. The uncaughtException event provides an extremely brute force way of catching these exceptions. It's really a last line of defense, but it's extremely useful for that purpose.

process.on('uncaughtException', function (err) {
  console.log('Caught exception: ' + err);
});

setTimeout(function () {
  console.log('This will still run.');
}, 500);

// Intentionally cause an exception, but don't catch it.
nonexistentFunc();
console.log('This will not run.');

          

Let's break down what's happening. First we create an event listener for uncaughtException. This is not a smart handler; it simply outputs the exception to stdout. If this Node script were running as a server, stdout could easily be used to log into a file and capture these errors. However, because it captures the event for a non-existent function, Node will not exit. However, the standard flow is disrupted. We know that all the JavaScript runs once, and then any callbacks will be run each time their event listener emits an event. In this scenario, since nonexistentFunc() will throw an exception, no code following it will be called. However, any code that has already been run will continue to run. This means the setTimeout() will still call. This is significant when writing servers. Let's consider some more code in this area:

var http = require('http');
var server = http.createServer(function(req,res) {
  res.writeHead(200, {});
  res.end('response');
  badLoggingCall('sent response');
  console.log('sent response');
});

process.on('uncaughtException', function(e) {
  console.log(e);
});

server.listen(8080);

          

This code creates a simple HTTP server and then listens for any uncaught exceptions at the process level. In our HTTP server, the callback deliberately calls a bad function after we've sent the HTTP response. Let's look at the console output for this script.

Enki:~ $ node ex-test.js 
{ stack: [Getter/Setter],
  arguments: [ 'badLoggingCall' ],
  type: 'not_defined',
  message: [Getter/Setter] }
{ stack: [Getter/Setter],
  arguments: [ 'badLoggingCall' ],
  type: 'not_defined',
  message: [Getter/Setter] }
{ stack: [Getter/Setter],
  arguments: [ 'badLoggingCall' ],
  type: 'not_defined',
  message: [Getter/Setter] }
{ stack: [Getter/Setter],
  arguments: [ 'badLoggingCall' ],
  type: 'not_defined',
  message: [Getter/Setter] }

          

When we start the example script, the server is available and I have made a number of HTTP requests to it. Notice that the server doesn't shut down at any point. Instead the errors are logged using the function attached to the uncaughtException event. However, we are still serving complete HTTP requests. Why? The deliberate prevented the callback in process from proceding and calling console.log(), but it affected only the process we spawned and the server kept running, so any other code was unaffected by the exception encapsulated in one specific code path.

It's important to understand the way that listeners are implmented in Node.

EventEmitter.prototype.emit = function(type) {

...

  var handler = this._events[type];

...

  } else if (isArray(handler)) {
    var args = Array.prototype.slice.call(arguments, 1);

    var listeners = handler.slice();
    for (var i = 0, l = listeners.length; i < l; i++) {
      listeners[i].apply(this, args);
    }
    return true;

...

};

          

After an event is emitted, one of the checks in the run-time handler is to see whether there is an array of listeners. If there is more than one listener, the run-time calls the listeners is by looping through the array in order. This means the first attached listener will be called first with apply(), then the second, etc. What's important to note here is that all all listeners on the same event are part of the same code path. So an uncaught exception in one callback will stop execution for all other callbacks on the same event. However, an uncaught exception in one instance of an event won't affect other events.

We also get access to a number of systems events through process. When the process gets a signal, it is exposed to Node via events emitted by process. An operating system can generate a lot of POSIX system events, which can be found in the sigaction(2) man page. Really common ones including SIGINT, the interrupt signal. Typically, a SIGINT is what happens when you press CTRL-C in the terminal on a running process. Unless you handle the signal events via process, Node will just perform the default action, which in the case of a SIGINT would immediately kill the process. You can change default behavior (except for a couple signals that can never get caught) through the process.on() method.

// Start reading from stdin so we don't exit.
process.stdin.resume();

process.on('SIGINT', function () {
  console.log('Got SIGINT.  Press Control-D to exit.');
});

          

In order to make sure Node doesn't exit on it's own, we read from stdin (described later in the section called “Operating system input/output”) so the Node process continues to run. If you CTRL-C the program while it's running, the OS will send a SIGINT to Node, which will be caught by the SIGINT event handler. Here, instead of exiting, we log to the console instead.

Process contains a lot of meta-information about the Node process. This can be really helpful when you need to manage your Node environment from within the process. There are a number of properties that contain immutable (read-only) information about Node, such as:

There are also a number of things that you can get and set about the Node process. When the process runs, it does so with a particular user and group. You can get these and set them with process.getgid(), process.setgid(), process.getuid(), and process.setuid(). These can be very useful for making sure that Node is running in a secure way. It's worth noting that the set methods take either the numerical ID of group or username, or the group/username itself. However, if you pass the group or username, the methods do a blocking lookup to turn the group/username into an ID, which takes a little time.

The Process ID or PID of the running Node instance is also available as the process.pid property. You can set the title that Node displays to the system using the process.title property. Whatever is set in this property will be displayed in the ps command. This can be extremely useful when using multiple Node process in a production environment. Instead of having a lot of processes called node or possibly node app.js, you can set names intelligently to make them easy to refer to. When one process is hogging CPU or RAM, it's great to have a quick idea of which one is doing so.

Other available information includes process.execPath, which shows the execution path of the current Node binary (e.g., /usr/local/bin/node). The current working directory (to which all files opened will be relative) is accessible with process.cwd(). The working directory is the directory you were in when Node was started. You can change it using process.chdir() (this will throw an exception if the directory is unreadable or doesn't exist). You can also get the current memory usage of the current Node process using process.memoryUsage(). This returns an object specifying the size of the memory usage in a couple of ways: rss show how much RAM is being used and vsize shows the total memory used, including both RAM and swap. You'll also get some V8 stats: heapTotal and heapUsed show how much memory V8 has allocated and how much it is actively using.

There are a number of places where you can interact with the OS (besides making changes to Node process the program is running in) from process. One of the main ones is having access to the standard OS IO streams. stdin is the default input stream to the process, stdout is the process's output stream, and stderr is its error stream. These are exposed with process.stdin, process.stdout and process.stderr respectively. process.stdin is a readable stream, whereas process.stdout and process.stderr are writable streams.

process.stdin.resume();
process.stdin.setEncoding('utf8');

process.stdin.on('data', function (chunk) {
  process.stdout.write('data: ' + chunk);
});

process.stdin.on('end', function () {
  process.stdout.write('end');
});

            

process.stdin.resume();
process.stdin.pipe(process.stdout);

            

console.log(process.argv);

          

Enki:~ $ node argv.js -t 3 -c "abc def" -erf       foo.js
[ 'node',
  '/Users/croucher/argv.js',
  '-t',
  '3',
  '-c',
  'abc def',
  '-erf',
  'foo.js' ]
Enki:~ $ 

          

If you've done work with JavaScript in browsers, you'll be familiar with setTimeout(). In Node we have a much more direct way to access the event loop and defer work that is extremely useful. process.nextTick() creates a callback to be executed on the next "tick" or iteration of the event loop. While it is implemented as a queue, it will supersede other events. Let's explore that a little bit:

> var http = require('http');
> var s = http.createServer(function(req, res) {
... res.writeHead(200, {});
... res.end('foo');
... console.log('http response');
... process.nextTick(function(){console.log('tick')});
... });
> s.listen(8000);
>
> http response 
tick
http response
tick

          

This example creates an HTTP server with a callback that creates a callback on process.nextTick(). No matter how many requests I make to the HTTP server, the "tick" will always occur on the next pass of the event loop. Unlike other callbacks, nextTick() callbacks are not a single event and thus are not subject to the usual callback expcetion brittlness:

process.on('uncaughtException', function(e) {
  console.log(e);
});

process.nextTick(function() {
  console.log('tick');
});
process.nextTick(function() {
  iAmAMistake();
  console.log('tock');
});
process.nextTick(function() {
  console.log('tick tock');
});
console.log('End of 1st loop');

          

Enki:~ $ node process-next-tick.js 
End of 1st loop
tick
{ stack: [Getter/Setter],
  arguments: [ 'iAmAMistake' ],
  type: 'not_defined',
  message: [Getter/Setter] }
tick tock
Enki:~ $ 

          

Despite the deliberate error, unlike other event callbacks on a single event each of the ticks is isolated. Let's walk through the code. First we set an exception handler to catch any exceptions. Next we set a number of callbacks on process.nextTick(). Each of these outputs to the console, however the second has a deliberate error. Finally we log a message to the console. When Node runs the program, it evaluates all the code, which includes outputting 'End of 1st loop'. Then it calls the callbacks on nextTick() in order. First 'tick' is outputted, then we throw an error. This is because we hit our deliberate mistake on the next tick. The error causes process to emit() an uncaughtException event which runs out function to output the error to the console. Since we threw an error 'tock' was not outputted to the console. However, 'tick tock' still is. This is because every time nextTick() is called each callback is created in isolation. You could consider the execution of events to be emit() which is called inline in the current pass of event loop, nextTick() which is called at the beginning of the event loop in preference to other events, and finally other events in order at the beginning of the event loop.

Let's start with exec() as the most straight-forward use case. Using exec(), you can create a process that will run some program (possibly another Node program) and then return the results for you in a callback:

var cp = require('child_process');

cp.exec('ls -l', function(e, stdout, stderr) {
  if(!e) {
    console.log(stdout);
    console.log(stderr);
  }
});

          

When you call exec(), you can pass a shell command for the new process to run. Note that the entire command is a string. If you need to pass arguments to the shell command, they should be constructed into the string. In the example, I passed ls the -l argument to get the long form output. You can also include complicated shellfeatures, such as | to pipe commands. Node will return the results of the final command in the pipeline.

The callback function receives three arguments: an error object, the result of stdout, and the result of stderr. Notice that just calling ls will run it in the current working directory of Node, which you can retrieve by running process.cwd().

It's important to understand the difference between the first and third arguments. The error object returned will be null unless an error status code is returned from the child process or there was another exception. When the child process exits, it passes a status up to the parent process. In Unix, for example, this is 0 for success and an 8-bit number greater than 0 for an error. The error object is also used when the command called doesn't meet the constraints placed on it by Node. When an error code is returned from the child process, the error object will contain the error code and stderr. However, when a process is sucessful, there may still be data on stderr.

exec() takes an optional second argument with an options object. By default this object contains the following:

var options = { encoding: 'utf8',
                timeout: 0,
                maxBuffer: 200 * 1024,
                killSignal: 'SIGTERM',
                setsid: false,
                cwd: null,
                env: null };

          

The properties are:

Let's set some of the options to put constraints on a process. First let's try restricting the buffer size of the response:

> var child = cp.exec('ls', {maxBuffer:1}, function(e, stdout, stderr) {
... console.log(e);
... }
... );
> { stack: [Getter/Setter],
  arguments: undefined,
  type: undefined,
  message: 'maxBuffer exceeded.' }

          

In this example, you can see that when we set a tiny maxBuffer (just 1 kilobyte), running ls quickly exhausted the available space and threw an error. It's important to check for errors so that you can deal with them in a sensible way. You don't want to cause an actual exception by trying to access resources that are unavailable because you've restricted the child_process. If the child_process returns with an error, its stdin and stdout properties will be unavailable an attempts to access them will throw an exception.

It's also possible to stop a Child after a set amount of time:

> var child = cp.exec('for i in {1..100000};do echo $i;done',
... {timeout:500, killSignal:'SIGKILL'},
... function(e, stdout, stderr) {
...   console.log(e);
... });
> { stack: [Getter/Setter], arguments: undefined, type: undefined, message: 'Command failed: ', killed: true, code: null, signal: 'SIGKILL' }

          

This example define a deliberately long-running process (counting from 1 to 100,000 in a shell script), but I also set a short timeout. Notice that I also specified a killSignal. By default, the kill signal is SIGTERM, but I used SIGKILL^[14] to show the feature. When we get the error back, notice there is a killed property that tells us that Node killed the process and that it didn't exit volunarily. This is also true for the previous example. Since it didn't exit on its own, there isn't a code property or some of the other properties of a system error.

spawn() is very similar to exec() however it is a more general purpose method that requires you to deal with streams and their callbacks yourself. This makes it a lot more powerful and flexible but it also means more code is required to do the kind of one shot system calls we did with exec(). This means that spawn() is most commonly used in server contexts to create subcomponents of a server. This is the most common way people make Node work with multiple cores on a single machine.

While it performs the same function as exec() the API for spawn() is slightly different. The first argument is still the command to start the process with however, unlike exec() it is not a command string, but just the executable. The process' arguments are passed in an array as the (optional) second argument to spawn(). It's like an inverse of process.argv instead of the command being split() across spaces you provide an array to be join()ed with spaces.

Finally, spawn() also takes an options array as the final argument. Some of these options are the same as exec() but we'll cover that in more detail shortly.

var cp = require('child_process');

var cat = cp.spawn('cat');

cat.stdout.on('data', function(d) {
  console.log(d.toString());
});
cat.on('exit', function() {
  console.log('kthxbai');
});

cat.stdin.write('meow');
cat.stdin.end();

          

Enki:~ $ node cat.js 
meow
kthxbai
Enki:~ $

          

In this example I'm using the UNIX program cat. Cat simply echoes back whatever input it gets. You can see unlike exec() we don't issue a callback to spawn() directly. That's because we are expecting to use the Streams provided by the Child Class to get and send data. I named the variable with the instance of Child "cat". I can access cat.stdout to set events on the STDOUT stream of the child process. I set a listener on cat.stdout to watch for any data events, and I set a listener on the child itself in order to watch for the exit event. I can send my new child data using STDIN by accessing its child.stdin stream. This is just a regular writable stream. However, as a behaviour of the cat program when I close STDIN the process exits. This might not be true for all processes but it is true for cat, which only exits to echo back data.

The options that can be passed to spawn() aren't exactly the same as exec(). This is because you are expected to manage more things by hand with spawn(). The env, setsid and cwd properties are all options for spawn() as are uid and gid to set the user ID and the group ID respectively. Like process setting the uid or the gid to a username or a group name will block briefly while the user or group is looked up. There is one more option for spawn() which doesn't exist for exec(). You can set custom file descriptors that will be given to the new child process. Let's take a little bit of time to cover this topic because it's a little complex.

A file descriptor in UNIX is a way of keeping track of which programs are doing what with which files. Since UNIX lets many programs run at the same time there needs to be a way to make sure that when they interact with the file system they don't accidentally overwrite someone else's changes. The file descriptor table keeps track of all the file which a process wants to access. The kernel might lock a particular file to stop two programs writing to the file at the same time, as well as other management functions. A process will look at its file descriptor table to find the file descriptor representing a particular file and pass that to the kernel to access the file. The file descriptor is simply an integer.

The important thing is that not just pure files are represented by file descriptors. The name is a little deceptive because network and other sockets are also allocated file descriptors. UNIX has inter-process communications (IPC) sockets which lets processes talk to each other. We've been calling them STDIN, STDOUT and STDERR. This is interesting because spawn() let's us specify specific file descriptors when starting a new child process. This means instead of the OS assigning a new file descriptor we can ask a child processes to share an existing file descriptor with the parent process. That file descriptor might be a network socket to the Internet or just the parent's STDIN, the point is that we have a powerful way of delegating work to child processes.

How does this work in practice? When passing the options object to spawn() we can specify customFds to pass our own three file descriptors to the child instead of them creating a STDIN, STDOUT and STDERR file descriptor.

var cp = require('child_process');

var child = cp.spawn('cat', [], {customFds:[0, 1, 2]});

          

Enki:~ $ echo "foo"
foo
Enki:~ $ echo "foo" | node

readline.js:80
    tty.setRawMode(true);
        ^
Error: ENOTTY, Inappropriate ioctl for device
    at new Interface (readline.js:80:9)
    at Object.createInterface (readline.js:38:10)
    at new REPLServer (repl.js:102:16)
    at Object.start (repl.js:218:10)
    at Function.runRepl (node.js:365:26)
    at startup (node.js:61:13)
    at node.js:443:3
Enki:~ $ echo "foo" | cat
foo
Enki:~ $ echo "foo" | node fds.js 
foo
Enki:~ $ 

          

The file descriptors 0, 1 and 2 represent STDIN, STDOUT and STDERR respectively. In this example we create a child and pass it STDIN, STDOUT and STDERR from the parent Node process. We can test this wiring using the command line. The echo command outputs a string we did it. If we pass that directly to node with a pipe (STDOUT to STDIN), we get an error. We can however pass it to the cat command which echoes it back. If we pipe to the Node process running our script it echoes back. This is because we've hooked up the STDIN, STDOUT and STDERR of the Node process directly to the cat command in our child process. When the main Node process gets data on STDIN then it get passed to the cat child process which echoes it back on the shared STDOUT. One thing to note is that once you wire up Node process this way the child process loses it's child.stdin, child.stdout and child.stderr file descriptor references. This is because once you pass the file descriptors to the process they are duplicated and the kernel handles the data passing. This means that Node isn't in between the process and the file descriptors so you cannot add events to those streams.

var cp = require('child_process');
var child = cp.spawn('cat', [], {customFds:[0, 1, 2]});
child.stdout.on('data', function(d) {
  console.log('data out');
});

          

Enki:~ $ echo "foo" | node fds.js 

node.js:134
        throw e; // process.nextTick error, or 'error' event on first tick
 foo
       ^
TypeError: Cannot call method 'on' of null
    at Object.<anonymous> (/Users/croucher/fds.js:3:14)
    at Module._compile (module.js:404:26)
    at Object..js (module.js:410:10)
    at Module.load (module.js:336:31)
    at Function._load (module.js:297:12)
    at Array.<anonymous> (module.js:423:10)
    at EventEmitter._tickCallback (node.js:126:26)
Enki:~ $ 

          

When custom file descriptors are specified the streams are literally set to null and are completely inaccessible from the parent. It is still preferable in many cases though because the kernel is much faster at routing than if we did something like stream.pipe() with Node to connect the streams together. However STDIN, STDOUT and STDERR aren't the only file descriptors worth connecting to child processes. A very common use case is connecting network sockets to a number children which allows multi-core utilization.

Say we are creating a web site, or a game server or anything that has to deal with a bunch of traffic. We have this great server which has a bunch of processors each of which has 2 or 4 cores. If we just started a Node process running our code we'd have just one core being used. While CPU isn't always the critical factor for Node we want to make sure we get as close to CPU bound as we can. We could start a bunch of Node processes with different ports and load balance them with Nginx or Apache Traffic Server. However that's inelegant and requires use to use more software. We could create a Node process that creates a bunch of child processes and routes all the requests to them. This is a bit closer to our optimal solution, but we just created a single point of failure. There is one Node process which routes all the traffic. This isn't ideal. This is where passing custom FDs comes into it's own. In the same way we can pass the STDIN, STDOUT, STDERR of a master process we can create other sockets and pass those in to child processes. However, because we are passing file descriptors instead of messages the kernel will deal with the routing. This means while the master Node process is still required it isn't bearing the load for all the traffic.