This is the third part in the series What is a protocol. In the last part we accompanied a message on its journey across the world. In this part we look at the software that support these protocols.
The purpose of a protocol is to exchange information. Ask yourself where are you in the information exchange? Are you a sender, a receiver or relay? Depending on what line of business you are in, you could actually one or more of those.
But if you happen to be a sender or a receiver, then gear up. Because you are going to have to support every layer in the protocol. For example, if you wish to send a SS7 MAP message you must support MAP – TCAP – SCCP – MTP. But if you are a SS7 relay node like a Signal Transfer Point (STP)1, then you can skip a few layers. You might scrape by supporting just the MTP and SCCP.
Now that you know what layers you must have, the next question is how to actually do it. Which kind of computers do you use, which programming language you write your code in, or how do you design your software. You might stop and ask, “Just because I am using this protocol do I have to develop my software the way the protocol tells me to?”
The answer is no. Just because two nodes talk using the same protocol, does not mean that they must be designed and developed in a similar manner. That is the beauty of a protocol. It simply defines the contract between the two entities. It does not bind them into any specific way of fulfilling this contract.
The protocol contract specifies what kind of conversations can happen between two nodes. It also defines how the data exchanged in these conversations must be structured. But it does not define how a node should implement the protocol.
Every node is free to choose a technology of its choice2.
A software running on a HP server can talk to its counterpart running on a Dell laptop. A software can choose the operating system it runs on. That is why a Windows laptop can open this blog that is running on a Red Hat Linux server. You can have one software written in Java sending data to another software coded in C++.
Every node can have its own unique architecture.
On one side you can have a software which has all layers clubbed into one big fat program. On the other side you can have an intricately layered architecture where there is a different program for each layer.
In other words, a protocol helps two completely different strangers to talk to each other. Think about you and me. We have different physical characteristics and different backgrounds. But still, you are able to read and understand the words I have written, thanks to this bridge called English language between us.
A protocol is that bridge. It gives to a software the same thing that a language gives to you and me. It is the language in which the digital world talks.
