Ports: at last!

Posted 4 years ago | Originally written on 16 Apr 2008

Now, I don't want to seem like a block-head but I'm sure that's what anyone who reads this will think. It has taken the longest time to finally grasp the idea of what ports (in TCP/IP) are. If you are like me you will probably gain; if not, you might get a new perspective or you might think it's a waste of time.

I once asked a colleague what a port is. To him it was obvious. He could not understand how I could not understand what and why they are. However, when I asked him to explain it to me (I remember having an irritation of ignorance) none of his explanations were making any sense. The proof I have that his explanations were not making sense is the fact that I cannot remember at all what he said. I just know I got nothing. (Woe to him if he reads this article!)

However, with time, my irritation of ignorance has eased to the point that I could accept them without the fear that they would spring a fast one on me. But I still hadn't nailed it down the way we've nailed down how 1+1=2 (OK, wrong example...!)

It's only today, more than a year and a half later that I can confidently say that I understand them.

You see, ports are really simple things. Their simplicity is even more stark the moment you get the point why they exist.

The essence of ports is best understood in the context of a layered network architecture. The whole essence of layering is to isolate primitive functions from user-friendly ones. The user-friendly functions (tasks) are on the highest layer with the highest level of abstraction (i.e. more related to real-life) while the primitive functions have very little abstraction (i.e. there is a perceptible relational between the problem and the implementation of its solution). So, in a network, we have the highest layer, called the Application Layer, which does appreciably useful tasks like email, displaying web-pages and such activities and layers below it of increasing primitiveness up to the Physical Layer, where electrons and their currents now do the actual work. Obviously, there have to be gaps that are crossed when translating the Physical Layer domain to the Application Layer and this is where ports come in.

Without going into the whole TCP/IP layering architecture, it suffices to say that whatever activity you have taking place on the Application Layer is achieved by having a dedicated application that responds only to particular requests. These are called services, hence, a server provides one or more services. In other words, we have applications on the Application Layer (duh!) and these form the services. So, a mail server will run a mail service - a dedicated application that does only one thing: send and receive email. A server can be configured to have multiple services that might even talk to each other. Hence, we might have a server that has both a mail server and an application that can send text messages such that you can convert email to text messages. There are a lot of things that you can do with services but you get the point...

So, imagine that you have multiple services running on a server. The simple problem we'll face is: How do we identify that messages sent are for that particular service? Simple! Use ports. Ports are the 'addresses' of services/applications running on the Application Layer. The messages will have, embedded in them, the address (read 'port number') of the application for which they are intended.

When you think about it, this is really simple. But I seriously wonder how many people will struggle like I did, trying to understand something that is quite simple but never gets presented in a way that voids it of any serious thought.

And that's what education should be like!