Question

I’m just starting to play with Node.js today, and thought I’d start with what I thought would be a simple script: Connecting to a server via sockets, and sending a bit of data, and receiving it back. I’m creating a command line utility. Nothing in the browser.

An example of a server would be memcached, beanstalkd, etc. It seems the net module is the right tool for the job, but I’m still a bit fuzzy on the Node.js way of doing things. Some help would be appreciated.

Update #1

Let me see if I can break this down in into a couple smaller questions. I hate even asking questions like this, but the Node.js documentation is very sparse, and most documentation written 6 months ago is already out dated.

1) So I can use net.stream.write() to send data to the remote server, but I don’t know how to get a response back. I’m not even sure how to test when write() is finished, because it doesn’t take a callback.

2) A few clues on how the whole event.emit thing works would be great. I think that’s really the key stone I’m missing in those whole thing.

Update #2

Here’s where I’m still confused on implementing a client program. Let me diagram a typical send request => get response system:

1) I bind callbacks to the net module to get responses and other events, including the necessary bindings to get a response from the server.

2) I use stream.write() to send a request to the server.

3) I then do nothing, because my bound “data” event will get the response from the server.

Here’s where things get tricky. Suppose I call stream.write() twice before my bound “data” event is called. Now I have a problem. When the “data” event does happen, how do I know which of the 2 requests it’s a response for? Am I guaranteed that responses will take place in the same order as requests? What if responses come back in a different order?

Answer 1

First of all, let’s make clear what a EventEmitter is. JavaScript and therefore Node.js are asynchronous. That means, instead of having to wait for incoming connections on a server object, you add a listener to the object and pass it a callback function, which then, “as soon” as the event happens, gets executed.

There’s still waiting here and there going on in the background but that has been abstracted away from you.

Let’s take a look at this simple example:

// #1) create a new server object, and pass it a function as the callback
var server = net.createServer(function (stream) {


    // #2) register a callback for the 'connect' event
    stream.on('connect', function () {
        stream.write('hello\r\n'); // as
    });


    // #3) register a callback for the 'data' event
    stream.on('data', function (data) {
        stream.write(data);
    });

    // #4) register a callback for the 'end' event
    stream.on('end', function () {
        stream.write('goodbye\r\n');
        stream.end();
    });
});

// #5) make the server listen on localhost:8124 
server.listen(8124, 'localhost');

So we create the server and pass it the callback function, this function is not yet executed. Passing the function here is basically a shortcut for adding a listener for the connection event of the server object. After that we start the server at #5.

Now what happens in the case of an incoming connection?

1. Since the function we passed to createServer was bound to the connection event, it now gets executed.

2. It adds the connect, data and end event listeners to the stream object (which represents the individual connection) by hooking up callbacks for the events.

3. After that, the stream fires the connect event, therefore the function passed at #2 gets executed and writes hello\r\n to the stream. How does the function know which stream it should write to? Closures are the answer, the function inherits the scope it was created in, therefore inside the function stream is still referencing to the individual connection that triggered this very callback we’re in right now.

4. Now the client sends some data over the connection, which makes the stream object call its data event, since we bound a function to this event at #3 we now echo the incoming data back to the client.

5. In case the client closes the connection, the function we’ve bound at #4 gets called, which writes goodbye\r\n and after that closes the connection from our side.

Does this make things a little bit more clear? Well it definitely makes the whole thing a lot easier. Node is, just as well as JavaScript is inside Browsers, single threaded. There’s only one thing happening at a given point time.

To describe it simple, all these callbacks end up in a global queue and are then called one after another, so this queue may(abstracted) look like this:

 | connection event for a new stream
 | data event for stream #12
 | callback set via setTimeout
 v close event of yet another stream

These are now get executed top to bottom, nothing will ever happen in between those. There’s no chance, that while you’re doing something in the callback bound to the data event, something will other will happen and magically change the state of the system. Even if there is a new incoming connection on the server, its event will get queued up and it will have to wait until everything before it, including the data event you’re currently in, finishes.