Introduction to OSI Model
The Internet has made incredible growth in the last two decades. Now we are in the era of high-speed internet networks (yeah, still growing) supported by numerous satellites those rove around the planet. But as software engineers most crucial thing to us is to have a complete understanding of inter-host communication. Let’s try to recall what we learn in engineering and understand it with real-life examples.
OSI Model stands for Open System Interconnection. The reference model describes how information from one computer’s application transfers through a physical medium to the application in another computer. In 1984 OSI model was published by ISO(Internation Organization for Standardisation ) as standard ISO 7498, and the renamed CCITT (now called the Telecommunications Standardization Sector of the International Telecommunication Union or ITU-T) as standard X.200. it is considered an architectural model for inter-computer communications.
OSI consists of seven layers, and in each layer, a set of particular network functions get performed.
There are plenty of resources available over the Internet to read about each layer’s OSI model functions and responsibilities. I have tried to accommodate my reading in the following diagram. Let’s look at that, and I will try to explain the OSI model with a real-life example.

For example, Aryan wants to send an email to Arjun.
What Happens at Aryan’s end.
Aryan opens an email application on his laptop, composes a message, and hits a send button. His email application will pass the message to “Application Layer,” which will pick protocol SMTP(Simple Mail Transfer Protocol) and pass the data along to the “Presentation layer.” The presentation layer will do the job of data compression and encryption. Once data is prepared and ready for communication, the “Session layer” will come into the picture, initializing the communication session; it could be either half-duplex or full-duplex. In the session layer, some checkpoints get added while transmitting the data in sequence. If some error occurs in the middle of data transmission, the transmission will resume again from the checkpoints.
Then data will hit the “Trasport layer,” where it will be segmented and ensured that messages are transmitted in the order they sent, and there is no data duplication. The transport layer takes care of flow control, sending data at a rate that matches the connection speed of the receiving device and error control. Here it uses protocol TCP where the connection between host established. Then Network layer takes the next job of breaking down segments into network packets and finding the best network path for transmission.
The data link layer establishes and terminates a connection between two physically-connected nodes on a network. It breaks up packets into frames and sends them from source to destination. This layer comprises two parts—Logical Link Control (LLC), which identifies network protocols, performs error checking, and synchronizes frames. Media Access Control (MAC) uses MAC addresses to connect devices and define permissions to transmit and receive data.
Now data comes to the physical layer, which includes the physical equipment involved in the data transfer, such as the cables and switches. And in this layer, the data will get converted into a bitstream of 1s and 0s.
Now data stream of 1/0 has been reached to Arjun computer after all seven layers processing and passing through the physical medium.
The data will flow through the same series of layers on his device but in the opposite order. The physical layer will convert bitstream(0s and 1s) to frames and pass them to the data link layer. The data link layer will reassemble frames into packets for the network layer. The network layer will then make segments out of the packets for the transport layer, reassemble the segments into one piece of data. The data will then flow into the session layer, which will pass the data along to the presentation layer, and then end the communication session will get completed. The presentation layer will then uncompress data and decrypt it before passing it to the application layer. Now the application layer will feed data to Arjun’s computer email software to read the email.

Leader Election

When working in distributed environments, sometimes you need to have a guarantee that you will always pick the same node Or only one node performing a special task, regardless of the cluster topology changes. Such nodes are usually called Leaders. All nodes are configured in the same way, leader election takes place at the run time. In case of leader election failure, remaining nodes again start the leader election process and choose the new leader.
In this blog article, I will try to describe what is leader election, its need, and how we can use consul for leader election.
Why Use Leader
A typical cloud application has many tasks acting in a coordinated manner. These tasks could all be instances running the same code and requiring access to the same resources, or they might be working together in parallel to perform the individual parts of a complex calculation.The task instances might run separately for much of the time, but it might also be necessary to coordinate the actions of each instance to ensure that they don’t conflict, cause contention for shared resources, or accidentally interfere with the work that other task instances are performing. For example, some potential use cases where we can use a leader:
- Task Scheduling
- Queue Consumer
- Partitioning
- Task Coordination
Leader Election Methods and Algorithms
Election algorithms choose a service instance from group of service instances to act as leader or coordinator to perform special tasks. If Leader crashed due to any reason then election algorithm re-triggered and new leader elected from instances.
Here I would try to describe some well know algorithms and techniques for leader Election.
- Bully and Ring Algorithm
- Distributed coordination Services
1. Bully and Ring Algorithm
These Election algorithms assume that every active instance in the service cluster has a unique priority number and they are interconnected. The service instance with the highest priority will be chosen as a new Leader/Coordinator. Hence, when a leader fails, this algorithm elects that active instance that has the highest priority number. Then this number is sent to every active instance in the distributed system to let the other instances know about the new leader.
Here are some links that describe these algorithms.
2. Distributed Coordination Services
Distributed Coordination service which provides reliable services to elect a leader for the distributed system. These systems simply work like Synchronous keyword in JAVA, the thread which gets lock only that can execute the critical section, on the same line instance which get ownership on coordination key treated as Leader. There are multiple services/tools which can be used for leader election as Distributed coordination service. Few enlisted below.
• Consul
• Zookeeper
• Database
• Redis
• Random Walks
Let’s focus on, how to use consul for Leader Election as part of this post.
How to use Consul as Coordination Service for Leader Election
A consul is a networking tool that provides a fully-featured service-mesh control plane, service discovery, configuration, and segmentation, for more information about consul please visit. On top of these core functionalities Consul also provides a session mechanism that can be used to build distributed locks. Sessions act as a binding layer between nodes, health checks, and key/value data(key/value store, useful for storing service configuration or other metadata). Sessions are designed to provide granular locking.
Imagine we have a set of service instances that are attempting to acquire leadership for a given service. All service instances that are participating should agree on a common key to coordinate. Let’s consider following kv store path on consul as the coordination key services/dev/<service name>/leader
High Level Architecture

Step 1, Create Session: The first step is to create a session using the Session HTTP API. See the following sample API call to the consul to create sessionId.
$ curl -X PUT -d '{"Name": "my_service_name"}' http://localhost:8500/v1/session/create
{ "ID": "4ca8e74b-6350-7587-addf-a18084928f3c" }
Here, API call responded with session Id : 4ca8e74b-6350-7587-addf-a18084928f3c
and this session-Id will be used for further actions.
Step2– Acquire Session Lock: Next step is to acquire lock on kv path for this instance using session created in previous step. Have look on following sample API call.Here we may send current instance/node information(whatever information required to communicate with leader) as body content. It my be JSON(instance host, port and unique id ), this information will be nothing but the value of our coordination key.
$ curl -X PUT -d <body> http://localhost:8500/v1/kv/services/dev/my_service_name/leader?acquire=4ca8e74b-6350-7587-addf-a18084928f3c
Sample Body =>
{
"serviceName": "my-service",
"nodeId" : "<unique-id-for-service-instance>",
"host" : "198.99.93.9",
"port" : 8080
}
Either this will return true or false. If true, then lock has been acquired and the calling instance is Leader. But if false, then some other instance might have acquired a lock and that instance is the leader.
Here instance will not only get a lock but write body content of this API call i.e. calling instance information(instance host, port and unique id ), So anytime if we wish to know who is the leader then that can be achieved by reading coordination KV store value which will nothing but locking instance information.
Step3 – Watch the Session: Next important step is to watch for any changes on the coordination key because the lock might have been released or an instance in which the acquired lock might be failed/crashed. Here leader also has to keep watch on the coordination key because its session might expire by the operator. Watching for KV store changes is done via a blocking query against. If they ever notice that the Session of is blank, there is no leader, and then should retry lock acquisition
Give up leadership: If a leader ever wanted to give up leadership then it can be done by releasing the lock on the coordination key.
$ curl -X PUT http://localhost:8500/v1/kv/services/dev/my_service_name/leader?release=4ca8e74b-6350-7587-addf-a18084928f3c
To Know who is Leader: Non-leader instances may wish to know who is leader. Instance can found that by reading coordination key(consul key path). If it has value with session that means there is leader. Read KV value which is nothing but a node’s information which we written as part of step2 request of acquiring lock on coordination key.
$ curl -X GET http://localhost:8500/v1/kv/services/dev/my_service_name/leader
{
"LockIndex": 6,
"Key": "service/dm/core/dev/<service name>/leader",
"Flags": 0,
"Value": "eyJzZXJ2aWNlTmFtZSI6ImxlYWRlcmVsZWN0aW9udGVzdDIiLCJwb3J0Ijo3Nzc3LCJhZGRyZXNzIjoicHVuLW1vcmVyLW0iLCJub2RlSWQiOiJmMzMwZjRhZS1hYWM4LTRmYTEtYWNjYi1hZjk1ZGNmZGY0MzUifQ==",
"Session": "4ca8e74b-6350-7587-addf-a18084928f3c",
"CreateIndex": 26863,
"ModifyIndex": 27400
}
Remember here value is BASE64 encoded, either you can decode it or we can get raw value by appending “raw” parameter to rest call to get decoded value from KV store.
curl -X GET http://localhost:8500/v1/kv/service/dm/core/dev/<service name>/leader?raw
{ "serviceName": "my-service", "nodeId" : "<unique-id-for-service-instance>", "host" : "198.99.93.9", "port" : 8080 }
Consul is a good option to implement Leader election in services if it is already part of your infrastructure considering its scalability and reliability. Consul session API are simple to use and readymade libraries for Consul APIs are available, have a look at consul libraries and SDKs.
Hope this article will help you understand what is Leader and Leader Election.