# Virtual Replication of IoT Hubs in the Cloud:
## 3 Architecture
### Synchronization Protocol  
The diagram presented in Figure 6 illustrates the operations and involved message exchange during the synchronization phases between involved actors. The operations related to the IoT Hub are detailed as follows:  
* The IoT Hub discovers existing Smart Objects that are deployed in the same network using multiple service discovery mechanisms such as ZeroConf [25,26] and UPnP [27] and the list of all the resources that they host. * The IoT Hub starts observing all the discovered resources, according to [24] to receive updates related to state changes. * Any time the IoT Hub receives such updates it populates/refreshes its resource cache. * The IoT Hub publishes a message (using an MQTT topic bound to the resource and the IoT Hub) related to the resource state change to the Cloud Broker to let Virtual Replicas update their mirrored state. The operations related to the Virtual Replicas are detailed as follows:  
* Upon launch the Virtual Replicas subscribe to the Broker to receive updates for topics related to a target IoT Hub. * Any time the IoT Hub publishes an update for a resource the Virtual Replica will receive a message and will update its state accordingly. Client applications that wish to interact with resources operate in the following ways:  
* Local Clients issue CoAP requests directly to the Smart Objects (if it implements CoAP) or to the IoT Hub otherwise. * Remote and External Clients may interact with a Smart Objects only through the Virtual Replica which will be publicly accessible using its REST interface. Figure 5: Message flow for the Pushing scenario: a smart object acting as a CoAP client posts and updates resources on the IoT Hub, which acts as origin server. All replicas are kept in sync using the synchronization protocol. External client can request resources, which will served by a replica. The synchronization protocol used in the architecture implements a pub/sub communication model. In fact, communication follows a one-to-many pattern from the IoT Hub to all of its replicas. All messages are sent by the IoT Hub to an MQTT message broker (hosted on the Cloud platform and illustrated in Figure 7a) using specific MQTT topics (which can be used to selectively target one, many, or all replicas in order to implement unicast, multicast, or broadcast communications respectively) that is managed by the Cloud platform, using a VPN connection, for security and addressing reasons, as shown in Figure 7a. The IoT Hub and its replicas are all identified by a system-wide identifier, assigned by the designed Cloud platform. Each IoT Hub includes a Replica Manager (RM), which is a dedicated software module responsible for the synchronization among the IoT Hub and its replicas. The RM is composed by the following items, as shown in Figure 7b. * A _Replica Registry_ (RR), which contains the list of the identifiers of all the replicas of the IoT Hub. * An _MQTT subscriber_, which registers to the broker to receive messages related to two topics: (i) its own identifier (\(id_{i}\)) and (ii) the identifier of the actual IoT Hub (\(id_{hub}\)); these may coincide in the case of the actual IoT Hub. * An _MQTT publisher_, which publishes messages to the broker, using the method \(pub(t,m)\), where \(t\) is the topic and \(m\) is the message to be published. The IoT Hub is in charge of keeping full synchronization of its resources with its replicas, in order to ensure that all requests are served in the same way, regardless of the specific replica that was targeted by the client. Synchronization comes into play every time a resource on the IoT Hub changes. This can be caused by different events. At startup, a replica of the IoT Hub needs to synchronize with the actual IoT Hub. The procedure is shown in Figure 8. The RM of the replica publishes its \(id_{i}\) to the topic \(id_{hub}\), in order to inform of its creation (\(pub(id_{hub},id_{i})\)).