Hacker School Day 10: About TCP/IP & a Node.js Hello World

.Where. .to. .begin. .?.

I began today slightly bored of Nefario Teaches Typing. There’s a WHOLE lot more I could do with it, but I won’t learn anymore by doing those things. I mean, sure, I’d get a little faster at some simple stuff, but I’m ready to be CHALLENGED, PUZZLED, PERPLEXED. So I put that on the shelf for now (I think I’ll still work on it in the evenings, as a little side-project) and sought some facilitator advices. M suggested that I either delve into a meaty client-side project such as a drum music simulator thing or that I try to write my own super-simple, crappy web server. Since I know little (NOTHING) of sockets and such, I figured that’d be a worthy pursuit. I proceeded to spend the rest of today reading up on Node.js, packets, sockets, TCP/IP, and other bizarre terms. From this, I think I’ve extracted a bit of knowledge. Please see below:


The what? TCP stands for Transmission Control Protocol. That means nothing. What they should call it is: Reliable Communication Command Center, the RCCC. Because that’s what it does. TCP is a protocol (read: set of rules or instructions) for sending and receiving lil’ packets of info between and within computers. [NOTE: feel free to well-actually me in the comments: I won’t be offended, I’ll merely learn better.] Okay, so, from what I understand, TCP works with the IP (Internet Protocol, another set of instructions) to coordinate communication between computers in packet-switched networks.
“What’s a packet-switched network?” I’m glad you asked! It’s when things (computers in this case) transfer data in little packets instead of via a constant bit stream. This means: you can send some data then stop, then send more; the packets can travel via different routes to get to the same place; you can check for errors in delivery, and you can grab data from multiple hosts (computers serving up data). Packets are great! Let’s talk more about what a packet actually is:


Packets are like datagrams, but not quite. Datagrams are little chunks of data, packed light for travel. Datagrams contain some header info about where they’ve come from and where they’re headed and what type of data they contain, then they have some sort of body of data, called the data payload. I picture this as a Chinese Dragon head that barfs up addresses and types, stuck to a dump-truck of solid gold data bars. (It’s been a long day.) The thing about datagrams is they don’t pay attention to their own survival. They contain no way to tell whether they’ve reached their final destination, and no data about error-checking for their missing friends or limbs. No guarantees! Sent then forgotten. Packets, on the other hand, are souped-up dragon-trucks: in addition to the basic datagram info, packets also contain info about which of them belong together and in what order, and they (somehow) have ways to instruct their receiver about how to test them for errors (I think this has to do with some magical size computation that would detect missing data).

IP Addresses

This is just cool. You know how when you get your IP address it just seems like a bunch of numbers? Well, it is, but there is a little logic to it. Everything in the header of these packets has a specified (by the protocol) amount of data it can take up, which I imagine makes it easier to parse and such. The amount allotted for an IP address is 4 bytes (each 8 bits long), which means the “address” is 4 “numbers” long, each separated by a period, each between 0 and 255 (which are all the numbers you can make with 8 bits: 00000000 – 11111111), hence something like Cool, huh? I thought so. Also, IP addresses are the personal address of your computer. Something like that.


Today I read a bunch about node and learned how to write the teeniest web server. Here it is:

// require the http module in node:
var http = require('http');

// write a listener function that will do something (send a response, ideally) when the server receives a request:
var webListener = function (request, response) {
    if (request.method == 'GET') { // what to do if this is a GET request (most are!)
        console.log("Request was a GET"); // just tell the terminal that it was a get request for now
        console.log("URL: " + request.url); // tell me that url, please!
    response.writeHead (
        200, // that code means the request was successful, tell the client "200, yay!"
        { 'Content-Type' : 'text-plain' } // We're going to send back some plain ol' text
    response.end('Hello World!'); // end our response with the data (text) that we want to send back

// make a new instance of the server object and pass it our fancy listener function from above
var server = new http.createServer(webListener);

// tell the server to listen up! (and give it a port number to listen on and a host to use -- localhost)
server.listen(8124, "");

// tell me you're working, server!
console.log("Server running at");

Oh right, first install node (use homebrew!). Then put the above code in a file, and call it example.js. Save it somewhere, navigate to that place in Terminal (someday I’ll write a super-teeny Terminal intro), then type “node example.js”. BAM! Web server, up n’ runnin’.
Phew! That’s it. I’ll go into more detail tomorrow about what the particulars of each of these are, but in general, the client (your computer) connects to a host (now my computer) and they say “coo’, let’s talk.” So your client computer requests something from mine (you want to see my website, of course) at the address that is my computer, connected to the port that my server is listening to. My server gets that request and responds however I tell it to (in this case by sending you back “Hello World!”). Tomorrow’s goal: send back an html file. I guessed that I would have to read a file’s content into some sort of buffer and send it appended to a packet, and I think I’m right. I haven’t yet looked too far into the details of that, but I’ve got a general idea of how it’ll work.

Stay tuned, folks! And thanks for reading.

FORGOT! Here’s my illustrated understanding of TCP and IP:photo

Leave a Reply

Your email address will not be published. Required fields are marked *