## 4 Implementation
### Collaborative Framework
#### 4.2.3 AR User Event Synchronization  
When all nodes are synchronized, they send their updates through small UDP packets as broadcast messages of about 30-50 bytes, so that all other nodes are aware of the changes in the shared experience.  
\begin{table}
\begin{tabular}{c c c} \hline \hline
**Framework** & **Relevant Features** & **Limitations** \\ \hline RAKNet & Native support C++, fast, multi-platform & Complex, requires a server \\ \hline UNET & Integrated with Unity, standard & Deprecated by unity, no replacement yet \\ \hline Photon & Integrated with Unity, used by Microsoft (2020) & Proprietary, requires cloud license \\ \hline Mirror & Integrated with Unity, open source, network discovery & Hard to make multi-platform \\ \hline Custom UDP-TCP & Lightweight, simple, custom made for the needs & Not standard \\ \hline \hline \end{tabular}
\end{table}
Table 1: Comparison of the different frameworks considered for the implemented system.  
Figure 3: Anchor request message exchange.  
Figure 2: Discovery process message exchange.  
Figure 4 shows an example of the exchanged messages when a master node broadcasts a shared \"move\" message, which indicates that a 3D object has changed its position. In addition, Figure 4 also shows that Slave1 sends a broadcast with a shared click message, which indicates that the user has interacted with an element of the environment.  
Figure 5 illustrates the message exchange flow. In such a sequence diagram, the beginning of the discovery process starts once the first AR node (i.e., the first pair of HoloLens glasses) executes the application. If there are no other devices on the network, no one will respond to the HELLO messages, so the first node will assume the role of master. When a second AR device connects to the network, it performs the discovery process as indicated, but then, the master will respond; thus, the second user assumes the role of slave. Once this point is reached, the connected devices start to automatically exchange messages with the objective of keeping track of the actions carried out by the different nodes and thus synchronizing the shared experience among all the devices. When a new user joins the shared experience (like the third user shown on the right of Figure 5), the application has to update the new user state, since the previous messages sent by the other two users will not be forwarded by them.  
Figure 4: Shared messages’ exchange.  
Figure 5: Flow diagram of a simple message exchange.  
There might be situations when actions from different users are contradictory; for example, when two users try to move the same object to different directions. This is considered to be an implementation-specific problem that every application may resolve in a different way. For instance, a flag can be set to act as a semaphore and then block the movement of a specific object to other users while such an object is moved. On the contrary, other solutions may opt for allowing users to take control of objects by requesting them from other users. Therefore, the specific implementation will depend on the desired behavior of each application. In the implementation described in this article, when users try to move an object, its location is smoothed by the framework between the new position set by the local user and the new one sent over the network, so the user will experience a \"spring effect\", as if both users were \"fighting\" to move the object.