Gestione dell'aggiornamento dei nod

5.2.3.3.1. Aggiunta di nodi

CTHCollection è la classe che si occupa principalmente di gestire la mappa dei dispositivi e

l’albero gerarchico dei nodi, mentre in CoAPTreeHandler sono presenti tutte le operazioni di notifica.

Nel momento in cui un nodo tenta di collegarsi alla gerarchia, invia o una rootRequest o una

parentRequest e il CTH richiamerà la specifica funzione sulla CTHCollection, grazie

all’implementazione dell’interfaccia CTHListener.

La Collection. in base alla gerarchia del nodo che ha effettuato la richiesta decide:

1. Se aggiungerlo come root (con dominio * e gruppo *) quando non è presente nessun nodo radice e se è già presente viene restituito l’indirizzo di quello memorizzato in modo tale da ottenere gestione dei duplicati a livello 0. In questo modo se il nodo radice ha una failure, nell’intervallo successivo, il broker di backup rieffettuerà la richiesta di root e non essendo presente più il precedente gli verrà restituito il suo stesso riferimento. Da quel momento in poi tutti i nodi Kura di primo livello invieranno ad esso gli aggiornamenti delle risorse.

2. Se aggiungere il nodo come nodo di livello superiore allo zero. Si ha un

comportamento simile al precedente perché quando abbiamo un duplicato viene aggiunto solo come figlio del nodo originale (che si trova sullo stesso path). È comunque in grado di effettuare RemoteResource query ed è in grado di restituire riferimenti alle proprie risorse locali, quindi effettuare POST sulle RD remote. Non è invece in grado di avere nodi figli dato che non verrà mai restituito come potenziale parent in una ricerca effettuata in seguito ad una parent request.

vecchio riferimento (che può comunque restare ancora connesso). Il motivo è che il nodo poteva essere associato precedentemente con un determinato padre e solo in seguito, dopo una nuova parent request, è stato abbinato ad un broker più specifico per quanto riguarda il gruppo di appartenenza.

Infatti nella CTHCollection.searchNewParentNode si parte dal nodo con il gruppo più specifico e si risale la gerarchia per ottenere il parent con il path più vicino al gruppo di appartenenza del nodo che ha inviato la request.

Ecco alcuni esempi di possibili casi:

• Aggiunta di un nodo radice duplicato

Viene solamente aggiunto come nodo figlio della root e non compare nella lista dei dispositivi.

• Aggiunta di un nodo di livello superiore allo zero

Stesso comportamento del precedente con la differenza che diventa nodo child del nodo originale.

Quando un nodo si disconnette normalmente richiama la propria funzione

disconnectFromTree che invia un messaggio al CTH. Il CTH quindi si occupa di avvertire

tutti gli altri nodi che non è più disponibile e verranno effettuati tutti gli aggiornamenti necessari in base alla gerarchia.

Ecco alcuni esempi di possibili casi:

• Esempio con rimozione di un nodo radice

In caso di rimozione della root non è possibile più effettuare RemoteQuery verso domini diversi da quello di appartenenza. In caso di presenza di un duplicato della root, entrerà a far parte della gerarchia e tutti i nodi rimasti senza parent avranno il riferimento verso il nuovo broker a cui invieranno gli aggiornamenti delle risorse presenti.

Il CTH, tramite modifiche alle Collection locali e invio di messaggi MQTT ai nodi interessati, assicura che i nodi rimasti parent-less siano associati alla root (fino all’arrivo di un nuovo nodo con le stesse proprietà di quello non più disponibile).

• Esempio con rimozione di un nodo di livello 2 (o maggiore di 2)

Non ci sono particolari precauzioni da prendere in questo caso, tranne che notificare il nodo

bologna che il figlio non è più disponibile e che quindi deve cancellare le risorse

precedentemente associate (con eventuale propagazione di aggiornamenti lungo la gerarchia). • Esempio di rimozione di un duplicato

In questo caso non ci sono comunque problemi dato che il nodo non era presente tra i

dispositivi della gerarchia (era presente solo come nodo child) e quindi devono essere rimossi solo gli eventuali attributi salvati sul nodo originale e poi eliminarlo dalla ParentTree.

5.2.3.3.3. Rilevamento dei failure dei broker

Nel caso in cui invece un nodo si disconnetta senza richiamare la funzione specifica verrà utilizzato LWT (Last Will and Testament) di MQTT.

Per determinare con esattezza il nodo disconnesso, si è deciso di utilizzare un pattern che permettesse il riconoscimento sia del percorso nella gerarchia che dell’ID del dispositivo (considerando il MAC address).

Le scelte possibili erano:

1. Topic specifico del dispositivo.

⁃ Schema:

Topic : #MAC/MQTT/LWT Payload : nullo

⁃ Una soluzione simile non sarebbe fattibile in un ambiente con molti dispositivi perché ci sarebbero troppe subscribe da parte del DataService del CTH e si dovrebbe mantenere comunque un vettore di tutti i MAC address che sono presenti in quel momento. Nel caso il CTH si ricolleghi e non abbia quelle informazioni si troverà in difficoltà a gestire le disconnessioni.

2. Utilizzo di un topic generico con payload dinamico.

⁃ Schema:

Topic : MQTT/LWT

Payload : #client-id

⁃ Questo sarebbe lo schema ideale in quanto si deve effettuare un’unica

subscribe da parte del DataService del CTH e si ottiene il nome del dispositivo caduto dal payload. Il problema è che non si può sviluppare una soluzione simile in Kura dato che l’LWT non è modificabile tramite API.

3. Utilizzo di un topic generico, con specializzazione del suffisso per il riconoscimento del dispositivo.

⁃ Schema:

Topic : MQTT/LWT/#client-id

Payload : nullo ⁃ Il #client-id sarebbe composto da due campi:

2. MAC address per l’identificazione

Prima di avviare il server dovremmo inserire solo il percorso all’interno della sezione MQTT della Web UI in quanto il MAC address viene riconosciuto e aggiunto automaticamente. Il DataService del CoAPTreeHandler deve effettuare solo la subscribe verso MQTT/LWT/#

(dove # è la wildcard che indica che dovranno essere presi in considerazione tutti i sottotopic).

Quando il CoAPTreeHandler riceve un messaggio LWT:

1. Effettua il parsing della stringa relativa al topic definito in precedenza 2. Trovare il dispositivo dato il percorso gerarchico

3. Controllare che sia effettivamente quello il nodo caduto attraverso un operazione di matching con il MAC address. Questo è un passaggio importante in quanto

nell’aggiunta dei broker è stato scelto di considerare anche i duplicati che, essendo tali, hanno lo stesso percorso di almeno un altro nodo.

Ad esempio consideriamo il seguente schema:

Ad un certo punto il nodo attuatori diventa non più disponibile. Allora il CoAPTreeHandler riceverà l’LWT dal broker MQTT e prima di tutto deve effettuare il parsing del topic del messaggio ricevuto:

1. Viene estratto il percorso gianvito.net/bologna/attuatori 2. Viene estratto il MAC address 88:77:66:55:31:12

Una volta ottenute tutte le informazioni sul nodo, viene ricercato all’interno dell’albero e in caso di coincidenza di tutte le proprietà viene rimosso e vengono notificati gli altri broker interessati.