**3.2 Architectural model peer-to-peer**

The second architectural model used to share virtual collaboration is the peer-topeer model. The basic difference from the client–server model is the absence of a node (server), which centralizes the information provided by clients and their subsystems. Data sharing is replicated each other among clients (**Figure 6**). Each client actively sends its own data to all users in real time. The use of a peer-to-peer architecture is most suitable for data sharing only within smaller user groups [4]. Typical examples are environments/games with a limited number of users/players. This condition applies to both local and globally shared virtual environments.

When using the peer-to-peer model, the precondition for the emergence of requirements for higher performance of client devices is here, especially for the need to ensure communication with other clients [31]. In this way, it is complicated to optimize the client's performance so that an effective level of interaction as well as visual feedback can be achieved.

Data consistency is compromised when sharing user interactions if clients approach a collaborative environment with devices with different computing performances. In this case, there is a problem in synchronizing the multiuser interaction. Clients with higher computing performance are able to process interactions much faster compared to clients with low computing performance and high latencies. It is difficult to synchronize client interactions without losing any shared data [32], due to the absence of a central node (server). Another problem arises when globalization of such an architecture is needed. It is necessary to use a centralized communication node in global systems with a peer-to-peer architecture. Without its use, different latencies with high deviations can occur among clients.

This problem can manifest itself in a high inconsistency of shared data. This can be quite a problem, especially in action games. Due to these complications, the use

**Figure 6.** *Topology of virtual collaboration with the peer-to-peer architectural model.* of peer-to-peer architecture is only possible in purpose-specific environments with a limited number of users.

Despite the mentioned disadvantages, it is necessary to emphasize the principle of using this architecture as a suitable solution in the case of systems based on the client– server architectural model [33]. For the needs of failure of securing client connections in the event of client–server architecture failures, it is appropriate to use the peer-topeer architecture as a backup mechanism for sharing game data or communication among players.

### **3.3 Distributed server architecture**

There are cases when it is necessary to process complex databases or nonstandard data types. In the case of virtual collaboration, the deployment of virtual environments for specific purposes is often present. For example, in addition to the standard architecture, it is necessary to connect clients to other separate server nodes (e.g., to payment systems of games).

Simultaneous data transfer among multiple clients and servers is provided by the distributed server architecture, as shown in **Figure 7**. An example is the sharing of modeling CAD/editing systems [34]. In them, virtual collaboration depends on several externally available servers. Each of the servers is responsible for providing specific functionality. Then, it deploys full computing performance for this functionality. The main goal of the mentioned architecture is to separate the primary functionality associated with the virtual collaboration game and the secondary functionality providing specific data [35].

From a topological point of view, a distributed server architecture consists of at least one primary and one secondary server. The primary server manages clients' accesses, manages the sharing of user interactions, and ensures the availability of a common virtual/game environment. The secondary server is associated with different types of subsystems. These are used in addition and they need separate computing performance. The secondary server processes complex data needed for collaboration or game details.

During the collaboration, the data obtained from the server nodes are sorted and passed only to the specified context of the game environment [36]. The integrations of data from external servers (e.g., the weather conditions, the existing systems status, the notification, and payment data and records or the nodes with artificial intelligence for bots control) are frequent in simulation game systems.

However, if the primary and secondary servers were centralized in a single server, their level of reliability and services would be severely affected by computing

**Figure 7.** *Topology of using distributed server architecture in the concept of virtual collaboration.* performance decrease. This would also significantly limit its performance for complex computational operations.
