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 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 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 modulo Radar il relativo metodo neigh_list) selezionando solo quelli di un altro gnodo. Ecco qui che ci accertiamo di essere un border node.
Da questi nodi si informa quanti nodi liberi hanno (vedi il metodo remotable free_nodes_nb(0) della classe Map che da il numero di nodi liberi di livello 0).
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.
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 funzione remotable. Senza parametri.
Sul miglior candidato al nostro hook, attiviamo la 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.