= La microfunc communicating_vessels =

La microfunc '''communicating_vessels''' implementa la seconda parte del meccanismo "''communicating vessels''" descritto nel documento topology.pdf. Qui un nodo che ha già fatto in precedenza la procedura di hooking, essendo un ''border node'' verifica se non sia venuto il momento di ripetere la procedura di hook in un suo gnodo vicino. La prima parte di questo meccanismo è infatti la fase di hooking implementata nella [[../MicrofuncHook|microfunc hook]].

La microfunc '''communicating_vessels''' può essere richiamata localmente dall'evento {{{ETP_EXECUTED}}}, oppure da remoto. Se viene chiamata localmente dall'evento {{{ETP_EXECUTED}}} significa che la mappa locale è cambiata, riceve nei parametri {{{old_node_nb}}} e {{{cur_node_nb}}} i valori vecchio e corrente del numero di nodi occupati nella mappa per ogni livello. Se è chiamata da remoto non riceve i parametri {{{old_node_nb}}} e {{{cur_node_nb}}}, perché la sua mappa non è cambiata.

Se viene richiamata per via di un cambiamento nella mappa locale:
 * viene eseguita la [[../GnodesSplit|funzione gnodes_split]] per verificare se c'è stato uno split. Se c'è stato uno split viene gestito dalla stessa gnodes_split; la {{{communicating_vessels}}} esce.
 * se non ci sono novità apportate dal ETP nel gnodo di livello 1, la {{{communicating_vessels}}} esce. Questo avviene perché, come detto nel documento topology.pdf, la {{{communicating_vessels}}} funziona anche prendendo in esame solo la mappa interna, ma quale strategia è migliore? E' ancora da decidere.

Di seguito trova i candidati tra la lista dei vicini (vedi la classe {{{Neighbour}}} nel [[../ModuloRadar|modulo Radar]] il relativo metodo {{{neigh_list}}}) selezionando solo quelli di un altro gnodo. Ecco qui che ci accertiamo di essere un ''border node''.
<<BR>>
Da questi nodi si informa quanti nodi liberi hanno (vedi il [[../ElencoRemotableFunctions|metodo remotable]] {{{free_nodes_nb(0)}}} della [[../ClasseMap|classe Map]] che da il numero di nodi liberi di livello 0).
<<BR>>
I vicini esterni (=quelli di un altro gnodo) che hanno più spazi liberi nel livello 0 di quanti ne abbiamo noi + 1 (come descritto nel documento topology.pdf) sono candidati ad un nostro ''hook''. Quelli che hanno meno spazi liberi di quanti ne abbiamo noi - 1 sono candidati a dover eseguire loro la {{{communicating_vessels}}}.
<<BR>>
Fra i candidati all'una e all'altra cosa prendiamo in esame solo quelli col divario maggiore.

Sul miglior candidato ad eseguire la {{{communicating_vessels}}} viene richiamata tale [[../ElencoRemotableFunctions|funzione remotable]]. Senza parametri.
<<BR>>
Sul miglior candidato al nostro ''hook'', attiviamo la [[../MicrofuncHook|microfunc hook]]. Ripetiamo dunque la prima parte del meccanismo "''communicating vessels''". Per la precisione, come lista dei vicini da esaminare viene passata la lista dei candidati, nessuno escluso, viene richiesto il controllo della condizione con gnumb=il numero di nodi liberi nel miglior candidato. Questa condizione sarà usata nella comunicazione con il '''coordinator node''' per evitare che avvengano contemporaneamente più rehook di quanti sia lecito.