Rick Winfrey

A Socket's Story

January 23, 2013 » 4 minutes (804 words)

Even as I write this blog post in a text editor, what is actually happening at a lower level in my computer is a stream of data transfer from the moment I input via the keyboard to the storage of these characters in a file. This basic flow essentially has four steps:

  1. open a connection (between a sender and a receiver)
  2. sender writes some data to the receiver
  3. receiver reads some data from the sender
  4. close the connection

In the coming days, I’ll do a deep dive into sockets. There are a couple things about how sockets work that are fuzzy in my brain. Like, how actually do they encode data? How do sockets prepare data as TCP or UDP datagrams? Can sockets send and receive data simultaneously? What manages the queue for data being transmitted via sockets (on both the receiver and sender sides)?

But for today, I’d like to offer a fun picture explanation about the basics of how web sockets work. Enjoy!


In the middle of working on a tic tac toe challenge, Rick has a thought:

It's the most honest thought he could think to write.

Luckily, the friend lives close by, at Port Apt #8080.

Rick sends his message in the sending recepticle (the mail box).

Away it goes, through a series of unknown channels and mysterious passages.

Until the message reaches Port Apt #8080.

News of a message is a special alert reserved for just such an occasion.

The message must be checked.

The message body is not as much a request as it is a means for establishing a connection it seems.

What to do?

It's best to offer help even when it is not asked for.

The reply message is packaged, with correct socket postage affixed.

And into the sending recepticle (also sometimes curiously functioning as the receiving recepticle, too) the response goes.

This time through a traceable path but whose loops and paths are so difficult to imagine.

Until it comes to rest right back from where the original message was sent.

Anxiously awaiting the reply, news of the response is happy relief!

Its contents are so carefully unpacked, so as to make sure the intention of the message is perfectly understood.

Now the connection has been made, a real request can be sent back!

And so it is, a socket's story.


My own personal visualization of socket connections between senders (in) and receivers (out). Queues are built up for both the sending and receiving sides. When the input socket is ready to transmit more data, it takes the next thing from the input queue. This data is transferred using a few protocols like TCP, or UDP. These get broken down into smaller segments but we won’t worry about that yet. Eventually the datagrams make their way to the intended receiver, but it looks like the receiver has an output queue, and it’s currently serving process #81. Once the receiver has processed the sender’s request, the receiver becomes the sender and responds with the appropriate data. It’s a simple idea, whose implementation details grow complex very quickly. How do we ensure a request is received by the receiver? How do we ensure that datagrams hold their integrity while they criss-cross across all types of network links? Can we control the throughput of certain network links so we can manage the requests effectively? So many questions requiring answers if this thing called the internet is to work whenever we want it to.