[ninux-dev] Alfred: strutture dati contenti i MAC degli host

[Germano Massullo]

Dato che non esiste una documentazione del codice di Batman/Alfred, sto
cercando di capire come Alfred client gestisce le strutture dati che gli
permettono di memorizzare tutti i MAC dei vari host. In particolare mi
interessa sapere come Alfred itera sui vari host (per qualsiasi azione).

Prima di porvi la domanda, affinché possa dare rapidamente un'occhiata
anche chi non abbia mai visto questo codice, ho scritto una breve e
becera cronologia delle azioni eseguite dal software alfred-vis (client)
[0] all'avvio, durante la richiesta di stampa di un output JSONDoc.
Inoltre, per riprodurre in maniera rapida un ambiente con il quale
"giocare" con il software, vi rimando a [10]

0) in vis.c vi è una variabile globale statica chiamata vis_globals di
tipo struct globals, la cui definizione è in vis.h [2];

1) Il main [3] istanzia un puntatore di tipo struct globals, dopodiché
esegue la funzione vis_init() che prende gli input da tastiera e ne
inserisce il contenuto nella variabile globale vis_globals;

2) dato che vis_init() restituisce un puntatore di tipo struct globals,
al punto [4] il main inserisce nella variabile globals l'indirizzo di
memoria della variabile globale vis_globals. In tal maniera ogni
operazione sulla variabile locale globals va ad influire direttamente
sulla variabile globale vis_globals;

3) lo switch presente nel main() entra nel caso OPMODE_CLIENT ed invoca
la funzione vis_get_data();

3.1) vis_get_data() invoca vis_request_data() che chiede al sistema una
socket UNIX e ne memorizza l'id in globals->unix_sock. Serve per far
comunicare il client alfred con alfred-master;

3.2) vis_get_data() [5] invoca la funzione vis_read_answer con parametro
globals;

3.2.1) vis_read_answer() [6] si occupa della lettura dei dati dal
processo (servizio?) alfred-master tuttavia non è chiara l'utilità di
strutture come

    struct vis_print_ops
    struct vis_v1
    struct vis_iface
    struct vis_entry

(al di là del codice C che è facilmente interpretabile).
Inoltre il while [8] legge i dati interenti tutti i nodi della rete
oppure i dati di un solo nodo? Andando a ritroso nella presente lista si
evince che la prima ipotesi dovrebbe essere corretta, anche perché
terminato il ciclo, la funzione ritorna, e la funzione chiamante
(vis_get_data()) termina anch'essa.

4) La scrittura a schermo dell'output JSONDoc viene effettuata
richiamando le funzioni presenti in static const struct vis_print_ops
vis_jsondoc_ops [9]

===Domanda===

Studiando il codice, ho dedotto che per ogni host vi è un array con
tutte le interfacce, dove a 0 è la primaria, dopodiché vengono le
interfacce secondarie. Ciò si evince ad esempio nella funzione
     static void vis_json_interfaces(uint8_t iface_n, struct vis_iface
*ifaces)

Vorrei chiedervi conferma della seguente cosa: file vis.c [1] , alla
riga 611 c'è
    mac_to_str(ifaces[vis_entries[i].ifindex].mac));
che ricava il MAC del router.
ifaces contiene l'intera collezione di indirizzi MAC di tutti gli host,
vis_entries[i] identifica il singolo host. La mia interpretazione è
corretta?



===NOTE ED URL===
[0]: N.B. batadv-vis è solamente un alfred-client
[1]: http://git.open-mesh.org/alfred.git/blob/HEAD:/vis/vis.c#l611
[2]: http://git.open-mesh.org/alfred.git/blob/HEAD:/vis/vis.h#l92
[3]: http://git.open-mesh.org/alfred.git/blob/HEAD:/vis/vis.c#l917
[4]: http://git.open-mesh.org/alfred.git/blob/HEAD:/vis/vis.c#l921
[5]: http://git.open-mesh.org/alfred.git/blob/HEAD:/vis/vis.c#l800
[6]: http://git.open-mesh.org/alfred.git/blob/HEAD:/vis/vis.c#l748
[7]: http://git.open-mesh.org/alfred.git/blob/HEAD:/vis/vis.c#l715
[8]: http://git.open-mesh.org/alfred.git/blob/HEAD:/vis/vis.c#l772
[9]: http://git.open-mesh.org/alfred.git/blob/HEAD:/vis/vis.c#l740
[10]: http://ml.ninux.org/pipermail/ninux-dev/2015-September/000506.html
[ninux-dev] Iniziare a generare output json* da batman/alfred
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://ml.ninux.org/pipermail/ninux-dev/attachments/20151019/cedf3bab/attachment-0001.html>