Link to image source

Client-server v/s Peer-to-peer

Let’s first compare a client-server network to a peer-to-peer network.

Client-server communications has two parts, a Server which has a known location like a static IP and is assumed to always be available, and a Client which is an edge on the network, that uses a server as a mediator.

Peer-to-peer communication on the other hand has entirely different properties. A Peer(node) in the connection doesn’t necessarily need to have a static location like a static IP. All the Peers in the network run the same program or similar programs to interact with each other. This could be for ease of use or to enforce a certain protocol that is used by all the nodes in the peer-to-peer network

These two communications can also be visualized as a Star Topology vs a Mesh Topology then let’s take a look at why would you choose one over the other.

Fig 1. Visualizing Client-server as Start Topology

Fig-2. Visualizing P2P as Mesh Topology

Why P2P?

So much of the internet runs on client-server architecture but there are many cases where it is not a good choice to run a system in a client-server architecture.

An example could be a file-sharing system, Let’s say a file needs to be shared to multiple different computers. And also the file is massive. At a small number of connections it could work, but as the connections increase and the file needs to be shared with more and more clients it will eventually create a bottleneck due to limited bandwidth on the serving computer, And to solve this problem peer to peer protocols like torrent can be used.

Another use case could be games that allow the creation of lobbies with 100’s of players. Serving 100s of players with an equally high number of concurrent lobbies could end up giving very bad latency and response times for the player. If we were able to somehow create networks where each player’s computer could connect to another player’s computer directly without a central server it would perform a lot better.

Why Client-Server?

Client-server architecture has a clear hierarchy and a good division of labor. Writing a system in this architecture is more likely to resolve in a more simple and secure system. Since all the connecting clients need to be working under specific protocols that are enforced by the server, maintaining infrastructure and optimizing performance can be much easier in a client-server architecture. Things like caching resources, and load balancing end up being a lot easier to add to servers since it is a centralized point of service and is under your control. But with this, there are also a few problems centralized servers have reduced availability, and high maintenance costs since your service will singularly serve all clients asking for resources and if it goes down everything stops working.

Discussing issues with P2P

A Peer-to-peer network is decentralized, with little to no connection to a central server. There are a few protocols like webRTC that attempt multiple ways to establish a connection and if all fails use a relay server to act as a forwarding point that connects to the requesting peers and forwards messages between them. With this, there are a few problems that are very common when creating peer-to-peer networks. Some of these problems are:

• Connectivity: Unlike a server, nodes in peer-to-peer networks don’t need to always have static locations like a static IP. This makes it difficult to reach the nodes consistently since their IP may change and on top of that a network inside a NAT is not accessible from the outside so we also have to develop some kind of a solution for that problem.
• Instability: Nodes in a peer-to-peer network aren’t always required to be online or be consistently connected to the network, so they are not reliable points of connection. Say, for example, you have created a system where specific nodes can act as relays for two other nodes. Now unlike a server a relay node may not always be there so you will have to develop a solution for that problem as well.
• Discovery: Where does our network start? In a client-server network, the network generally starts at the server in a publicly reachable location. But in a peer-to-peer network where do we start our network how do we find the desired information about the nodes in the first place?
• Security: Nodes in a peer-to-peer network can remain anonymous, so how would you regulate malicious action done by some nodes. In another case for easier discovery and connection, you may be broadcasting IPs of all the different nodes in the network which also is not a secure thing to do.

There are also other issues with peer-to-peer networks for this series we will just take a look at the presented four issues.

Generic guidelines for building a P2P network

Before writing any code or designing any protocols let’s take a look at a simple high-level implementation detail of a P2P framework. In this implementation, we will have two components which are:

1. Something that actively listens for any incoming connections
2. Something that provides us an interface to perform actions in the network like connecting to another client, sending messages, etc.

Fig 3. A framework for designing peers in a peer-to-peer network.

We are putting the simplest of solutions on how to design our peers. With other articles in the series we will iterate on this solution and solve a lot of its limitations, but for now, let us keep it as is. Let’s take a look at what communication might look like step by step.

1. We interact with the interface at peerA and ask it to send a message to peerB, the message will get sent out of a specific port. In our current design every packet going in and out will pass through the same port at least from our local computer.
2. The packet travels the internet and reaches the port of peerB.
3. A program will be listening for any incoming packets at the port at peerB.
4. The listener captures the packet and passes it to the handler.
5. Depending on the type of the packet and its contents one of the handlers will run and generate a response to send to peerA through the specified port at peerB.
6. The response message reaches peer A.
7. The packet is captured by the listener at peerA listening on the port.
8. The message is then handled accordingly.

In the next article, we will design a connection module for our peer-to-peer library.

This article is part of a series of articles where I learn more about P2P networks and as I complete sections of my studies I will post short segments of understanding so far. At the end of this series, I plan to have a simple P2P library which we will be using in another project to build a cool application