Client-Server vs. Peer-to-Peer Architecture: A DDS Perspective

🌐 A client-server network architecture, using a point-to-point communication model, and a peer-to-peer network architecture based on the publish subscribe communication model differ in several aspects.

To better illustrate this, let’s think gRPC as an example of technology for building client-server network architecture and Data Distribution Service (DDS) as an example of technology used for implementing peer-to-peer network architecture.

🖥️ Client-Server Architecture

In a client-server architecture, the roles of server and client are clearly defined,

• with the server holding the data and the clients accessing it.
• This results in a tightly coupled system where communication occurs between the server and individual clients usually in synchronous, request/replay model.
• This centralized approach facilitates data management and control but can lead to potential bottlenecks and single points of failure.

🌐 Peer-to-Peer Architecture with DDS

On the other hand, DDS utilizes a publish-subscribe communication model, creating a peer-to-peer network architecture.

• With DDS, the need to determine who is the server and who is the client is eliminated. Each peer in the network can publish and subscribe to data, creating a decentralized solution where peers have their own data.
• This enables more flexible and dynamic communication among peers without the need for a central server.
• This decentralized approach has benefits in scalability, loose coupling, fault tolerance, and asynchronous communication.

❓ Request/Reply in DDS?

But what to do when you need to use a request/reply communication in your system?

• It is possible to build request/reply on top of publish-subscribe communication model.
  • For that, you need to create
  • Request types and reply types
  • Request topic and reply topic.
• Then you need to use correlation Ids on both sides so you can pair the replies with the request.
• Setup ContentFilter for the reply topic to filter unwanted replies.

Unfortunately, it could get more complicated when you will need to be prepared for potentially multiple replies on a single request or when there are more repliers.

To help with this, RTI implementation has a ready-to-use solution within its Connext DDS.
eProsima provides a solution for its FastDDS with RPC over DDS.

But it can be done in a more asynchronous and easy and more natural way for DDS

🔄 Asynchronous Approach

You can do what is called an objective state design pattern.
👉 An application that wants some change in the system sends a request to the system, someone in the system gets this request and makes a change in the state of the system, then sends the event with the objective state (new state) as a reaction so the requestor gets the information that a change of the state has occurred. If something bad happens an error event is sent.

📈 Historical Data Retrieval

So this is the way how you would request an action in the system.
However, when it comes to retrieving historical data, DDS may not be the optimal choice. DDS is specifically designed to handle real-time data, commonly known as “Data In Motion,” rather than historical data retrieval. Therefore, if your primary requirement involves accessing past data records, alternative technologies may be more suitable for your needs.

💡 Architecture Decision Factors

Overall, the decision between a client-server and peer-to-peer architecture depends on factors such as data distribution needs, scalability requirements, fault tolerance considerations, and the desired level of system coupling.

If you need to combine request/reply and publish-subscribe approaches, I would probably consider using the Zenoh technology because these communication patterns are built into the technology and are not an afterthought. 🚀