|
Size: 25696
Comment:
|
← Revision 3 as of 2016-05-23 10:44:39 ⇥
Size: 108
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| = Modulo Identities - Analisi Funzionale = <<TableOfContents(4)>> == Ruolo del modulo == Il modulo Identities si occupa di organizzare le diverse identità che vivono nel nodo. Il modulo Identities consente la creazione di una prima ''identità'' all'avvio del nodo. In seguito il modulo, data una identità ''j'', consente di creare una nuova identità ''i'' che prende il posto di ''j''. In questo momento l'identità ''j'' resta in vita, ma in modo temporaneo. L'identità ''j'' diventa una identità ''di connettività''. Si veda la trattazione del modulo [[Netsukuku/ita/docs/ModuloQSPN/AnalisiFunzionale#Nodi_virtuali|QSPN]] per comprendere la funzione di una identità ''di connettività'' e per quale motivo essa sia temporanea. In contrapposizione al significato di una identità ''di connettività'' introduciamo il concetto di ''identità principale''. Un nodo ha sempre una e una sola identità ''principale''. La prima identità del nodo che viene creata all'avvio è dunque l'identità ''principale'' del nodo. Abbiamo detto che in seguito il nodo può creare una nuova identità ''i'' partendo da una precedente identità ''j''. L'identità ''j'' poteva essere in precedenza l'identità ''principale'' oppure una identità ''di connettività''. Dicendo che l'identità ''i'' prende il posto di ''j'', intendiamo significare, tra le altre cose, che se ''j'' era la ''principale'' allora adesso ''i'' diventa la ''principale''. Mentre se ''j'' era una identità ''di connettività'' allora adesso ''i'' diventa anch'essa una identità ''di connettività''. Ogni volta che il modulo crea una identità, inizializza un identificativo per tale identità, cioè una istanza di NodeID. . '''Nota.''' L'identificativo deve essere univoco a livello dei domini di broadcast dei diretti vicini del nodo. Questo significa che deve essere univoco nel nodo stesso e che nessuno dei suoi diretti vicini deve avere ''attualmente'' conoscenza di un identificativo equivalente. Per una prima implementazione possiamo assumere che un intero di 32 bit scelto a caso sia sufficiente a questo scopo, ma una corretta implementazione in futuro dovrebbe essere fatta. Il modulo Identities associa ad ogni identità che viene creata un numero di istanze di classi di altri moduli. Queste istanze sono semplicemente degli '''Object''' per il modulo Identities, in quanto esso non ha dipendenza sugli altri moduli dell'applicazione. Ogni istanza è individuata con una stringa. Cioè, data una stringa ed una identità abbiamo un solo oggetto. Il modulo Identities consente inoltre di gestire gli ''archi-identità''. Il modulo viene portato a conoscenza di archi che collegano il nodo corrente ad un altro nodo diretto vicino. Sopra ogni arco il modulo consente di creare e rimuovere uno o più ''archi-identità'' che collegano una certa identità del nodo corrente con una certa identità del nodo vicino. Il modulo Identities consente infine di rimuovere una identità dal nodo corrente. == Network namespace == Il modulo Identities assume che la creazione di una nuova identità comporta nel nodo la replicazione dell'intero stack di gestione del networking (detto ''network stack''). Quindi il modulo richiede che il sistema operativo sia in grado di realizzare questa replicazione. Volendo però essere agnostico rispetto al sistema operativo che gestisce il nodo, il modulo lascia che sia il suo utilizzatore ad eseguire le operazioni necessarie a richiedere al sistema operativo questa replicazione. Il modulo assume che ogni replica del network stack possa essere associata ad un nome, che d'ora in poi chiamiamo ''network namespace''. Il termine è preso in prestito dalla implementazione di questa feature presente nelle versioni recenti del kernel Linux. Inoltre assume di poter indicare con il nome "" (stringa vuota) il primo network namespace (o network namespace default) che è lo stesso sul quale è in esecuzione l'applicazione stessa. Il modulo richiede che il sistema operativo sia in grado di realizzare la costruzione di una pseudo-interfaccia di rete sopra una interfaccia di rete reale e di rendere operativa tale pseudo-interfaccia in una particolare replica del network stack (associarla ad un namespace). Anche in questo caso, il modulo demanda al suo utilizzatore l'esecuzione delle operazioni necessarie a richiedere al sistema operativo questa costruzione. == Archi-identità == Abbiamo detto che il modulo sa quali archi collegano il nodo corrente ad un altro nodo diretto vicino. Per la precisione un arco ''arc~-,,i,,-~'' collega una certa interfaccia di rete reale ''if~-,,j,,-~'' del nodo corrente ad una certa interfaccia di rete reale del nodo vicino, di cui il nodo corrente conosce il MAC address ''arc~-,,i,,-~.peer_mac'' e l'indirizzo link-local ''arc~-,,i,,-~.peer_linklocal''. Sopra l'arco ''arc~-,,i,,-~'' il modulo consente la creazione di uno o più ''archi-identità'' che collegano una certa identità del nodo corrente con una certa identità del nodo vicino. Consideriamo ad esempio l'identità ''id~-,,k,,-~''. Il modulo Identities può creare l'arco-identità ''id-arc~-,,0,,-~'' associato all'arco ''arc~-,,i,,-~'' e alla sua identità ''id~-,,k,,-~'' e che collega alla identità del vicino ''b~-,,q,,-~''. Può anche creare un altro arco-identità ''id-arc~-,,1,,-~'', sempre associato all'arco ''arc~-,,i,,-~'' e alla sua identità ''id~-,,k,,-~'', ma che collega alla identità del vicino ''b~-,,w,,-~''. Limitiamoci a considerare l'arco-identità ''id-arc~-,,0,,-~''. Consideriamo il vertice nel nostro nodo di ''id-arc~-,,0,,-~''. Sappiamo che esso è associato all'arco ''arc~-,,i,,-~'', il quale è stato fatto sulla interfaccia di rete reale ''if~-,,j,,-~'' del nodo corrente. Sappiamo anche che esso è associato all'identità ''id~-,,k,,-~'', la quale è associata ad un particolare network namespace ''ns~-,,k,,-~''. In questo network namespace, se non è quello default, opera una certa pseudo-interfaccia di rete costruita sull'interfaccia di rete reale ''if~-,,j,,-~'', chiamiamola ''if~-,,j,k,,-~''. Sappiamo che tale pseudo-interfaccia ha un suo MAC address e un suo indirizzo link-local che sono distinti da quelli di ''if~-,,j,,-~''. Facciamo delle considerazioni analoghe per il vertice nel nodo vicino di ''id-arc~-,,0,,-~''. Sappiamo che esso è associato all'identità del vicino ''b~-,,q,,-~''. Questa potrebbe non essere l'identità associata al network namespace default: quindi vogliamo mantenere l'informazione ''id-arc~-,,0,,-~.peer_mac'' e ''id-arc~-,,0,,-~.peer_linklocal'' che possono differire da ''arc~-,,i,,-~.peer_mac'' e ''arc~-,,i,,-~.peer_linklocal''. Riassumendo, un arco-identità ''id-arc~-,,0,,-~'' è associato ad una identità ''id~-,,k,,-~'' e ad un arco ''arc~-,,i,,-~'' ed ha queste caratteristiche (o membri): * ''peer_nodeid'' - L'identificativo dell'identità del vicino, cioè ''b~-,,q,,-~''. * ''peer_mac'' - Il MAC address dell'interfaccia (reale o pseudo) associata a ''b~-,,q,,-~''. * ''peer_linklocal'' - L'indirizzo link-local dell'interfaccia (reale o pseudo) associata a ''b~-,,q,,-~''. Aggiungiamo infine che, siccome vedremo in seguito che nel tempo nel nodo ''b'' può cambiare l'associazione fra l'identità ''b~-,,q,,-~'' e un network namespace, nel tempo i valori ''peer_mac'' e ''peer_linklocal'' di ''id-arc~-,,0,,-~'' possono cambiare. Eventuali cambiamenti sono gestiti in autonomia dal modulo Identities, cioè non è l'utilizzatore del modulo a richiederli. Questi cambiamenti però vengono notificati al suo utilizzatore con un segnale. == Operazioni == Il modulo fa uso delle [[Netsukuku/ita/docs/Librerie/TaskletSystem|tasklet]], un sistema di multithreading cooperativo. Il modulo fa uso del framework [[Netsukuku/ita/docs/Librerie/ZCD|ZCD]], precisamente appoggiandosi alla libreria di livello intermedio ''ntkdrpc'' prodotta con questo framework per formalizzare i metodi remoti usati nel demone ''ntkd''. Le operazioni del modulo sono implementate per la maggior parte in metodi di una classe chiamata !IdentityManager. Di essa viene creata una sola istanza dall'applicazione in esecuzione su un nodo. Di seguito ci possiamo riferire a tale istanza semplicemente con il termine ''manager''. Poiché il manager è uno solo nel nodo, diciamo che il modulo Identities è un modulo ''di nodo''. Si veda nella trattazione del modulo [[Netsukuku/ita/docs/ModuloNeighborhood/AnalisiFunzionale#Identit.2BAOA_multiple_in_un_nodo|Neighborhood]] la differenza tra moduli ''di nodo'' e moduli ''di identità''. Nel costruire l'istanza del manager, l'utilizzatore del modulo specifica quali sono i nomi delle interfacce di rete reali gestite dal nodo, i relativi MAC e gli indirizzi link-local (che gli sono stati definitivamente assegnati dal modulo Neighborhood). Inoltre gli passa un manager di network namespace, o ''netns-manager'', cioè un oggetto (si veda sotto la descrizione dell'interfaccia IIdmgmtNetnsManager) per svolgere le operazioni sui network namespace e le interfacce di rete. Nel costruttore il manager crea la prima identità, chiamiamola ''id~-,,0,,-~''. Il manager genera un identificativo per la prima identità, che è la ''principale''. Chiamiamo identità principale quella associata al network namespace default e che gestisce quindi in esso le interfacce di rete reali. Il manager gli associa un ''namespace'' uguale a stringa vuota. Il manager inoltre, per ogni interfaccia di rete reale ''dev~-,,i,,-~'' che gli è stata segnalata, associa alla coppia ''id~-,,0,,-~-dev~-,,i,,-~'' una struttura dati con le informazioni della interfaccia gestita dalla identità: ''dev'', ''mac'', ''linklocal''. Per la identità principale queste sono le interfacce reali. L'utilizzatore dice al manager di associare alcuni oggetti alla identità appena creata: un oggetto per "qspn", un oggetto per "peerservices", eccetera. In seguito, quando il nodo rileva la presenza di vicini, l'utilizzatore dice al manager che è stato formato un arco con un vicino, chiamiamolo ''arc~-,,0,,-~''. Dall'oggetto ''arco'' (si veda sotto la descrizione dell'interfaccia IIdmgmtArc) si può risalire alla interfaccia di rete reale su cui è stato realizzato, chiamiamola ''ir(arc~-,,0,,-~)''. La prima volta questo evento accadrà quando il manager ha creato una sola identità. Ma in seguito nel tempo questo evento può accadere anche quando il manager ha più di una identità. Il manager associa alla coppia ''id~-,,0,,-~-arc~-,,0,,-~'' un contenitore, inizialmente vuoto, nel quale potranno essere aggiunte strutture dati che rappresentano un ''arco-identità''. In seguito, l'utilizzatore dice al manager di aggiungere un ''arco-identità'', relativamente alla propria identità ''id~-,,0,,-~'', sull'arco ''arc~-,,0,,-~'', con un identificativo ''b~-,,j,,-~'' che rappresenta una identità nel nodo vicino. In questa richiesta specifica: * ''peer_nodeid'' - Un NodeID. L'identificativo ''b~-,,j,,-~''. * ''peer_mac'' - Il MAC address da associare alla identità ''b~-,,j,,-~'' raggiunta tramite l'arco ''arc~-,,0,,-~''. * ''peer_linklocal'' - L'indirizzo link-local da associare alla identità ''b~-,,j,,-~'' raggiunta tramite l'arco ''arc~-,,0,,-~''. Nel tempo, l'utilizzatore può: * Aggiungere un arco che è stato realizzato dal nodo. * Rimuovere un arco non più funzionante. * Aggiungere su un arco già segnalato un arco-identità. * Rimuovere da un arco già segnalato un arco-identità. * Aggiungere una interfaccia di rete reale a quelle gestite dal nodo. In questo caso indica il nome, il MAC e l'indirizzo link-local. * Rimuovere una interfaccia di rete reale da quelle gestite dal nodo. In questo caso indica il nome. Può capitare (vedremo fra poco in quali occasioni) che il modulo Identities in autonomia aggiunga o rimuova o modifichi un arco-identità. Questo evento è notificato all'utilizzatore del modulo con un segnale che esso può ascoltare. ---- Ad un certo punto l'utilizzatore del modulo può richiedere al manager di realizzare la duplicazione di una sua identità a causa di una migrazione. Se la migrazione è di un singolo nodo allora le operazioni da fare sono alquanto semplici. Tuttavia anche in questo caso vedremo che un certo numero di comunicazioni vengono fatte ai nodi vicini e di questo si occupa il manager. Se invece la migrazione è di un cluster di nodi allora le operazioni sono alquanto complesse. Si rende necessaria una concertazione delle operazioni, inizialmente con tutti i nodi del cluster e in seguito con i diretti vicini del nodo. La prima parte, cioè la concertazione con tutti i nodi del cluster, mira a far conoscere a tutti i nodi del cluster alcune informazioni sulla migrazione stessa e fra queste un ''identificativo di migrazione'' condiviso: questa parte non è di competenza del modulo Identities. La seconda parte, cioè la concertazione coi diretti vicini, mira a far sì che la duplicazione degli archi-identità avvenga in modo corretto anche fra due nodi che appartengono entrambi al cluster che migra. Ad esempio, supponiamo che l'identità ''a~-,,0,,-~'' nel nodo ''a'' e l'identità ''b~-,,0,,-~'' nel nodo ''b'' siano collegate con un arco-identità. Supponiamo che entrambe le identità appartengano ad un cluster che migra e si formino a causa di questa migrazione le identità ''a~-,,1,,-~'' nel nodo ''a'' e ''b~-,,1,,-~'' nel nodo ''b''. Allora deve persistere l'arco-identità ''a~-,,0,,-~-b~-,,0,,-~'' e si deve aggiungere l'arco-identità ''a~-,,1,,-~-b~-,,1,,-~''. Non devono invece formarsi né ''a~-,,0,,-~-b~-,,1,,-~'' né ''a~-,,1,,-~-b~-,,0,,-~''. Invece, supponiamo che l'identità ''a~-,,0,,-~'' nel nodo ''a'' e l'identità ''b~-,,0,,-~'' nel nodo ''b'' siano collegate con un arco-identità. Supponiamo che solo l'identità ''a~-,,0,,-~'' appartenga ad un cluster che migra e si formi a causa di questa migrazione l'identità ''a~-,,1,,-~''. Allora deve persistere l'arco-identità ''a~-,,0,,-~-b~-,,0,,-~'' e si deve aggiungere l'arco-identità ''a~-,,1,,-~-b~-,,0,,-~''. Quest'ultimo esempio vale anche per i casi in cui la migrazione sia di un singolo nodo, in questo esempio ''a~-,,0,,-~'' nel nodo ''a''. Della concertazione coi diretti vicini si occupa il modulo Identities. Questa è particolarmente complessa quando entrambi i vicini partecipano (con una o più identità) alla migrazione. Per realizzare questa concertazione si ha una prima fase in cui, tramite un meccanismo che non è di pertinenza del modulo Identities, su tutti i nodi del cluster viene chiamato il metodo ''prepare_add_identity(migration_id, old_id)''. Soltanto al termine, cioè quando tutti i nodi del cluster hanno processato il metodo ''prepare_add_identity'', viene chiamato su tutti i nodi il metodo ''add_identity(migration_id, old_id)''. Al resto pensa il modulo Identities. Al termine delle operazioni, cioè al ritorno del metodo ''add_identity'', l'utilizzatore del modulo viene portato a conoscenza dell'identificativo della nuova identità. ---- Ad un certo punto l'utilizzatore del modulo può richiedere al manager di rimuovere una sua identità ''id~-,,j,,-~''. Il manager per prima cosa rimuove tutti gli archi-identità associati a ''id~-,,j,,-~''. Per ogni arco-identità ''id-arc~-,,k,,-~'' associato a ''id~-,,j,,-~'', indicando con ''arc~-,,q,,-~'' l'arco su cui esso è formato, il manager tenta anche (ma non è necessario che vi riesca) di comunicare al nodo vicino attraverso l'arco ''arc~-,,q,,-~'' che va rimosso l'arco tra ''id~-,,j,,-~'' e ''id-arc~-,,k,,-~.peer_id''. Poi il manager notifica il segnale che è stato rimosso un ''arco-identità''. Rimossi tutti gli archi, il manager usa il ''netns-manager'' per rimuovere le pseudo-interfacce e il network namespace associati a ''id~-,,j,,-~''. Rimuove infine dalla sua memoria tutte le associazioni che manteneva per ''id~-,,j,,-~''. == Memoria del modulo == Il modulo mantiene un elenco, chiamato ''dev_list'', dei nomi delle interfacce di rete reali attualmente gestite dal nodo. Il modulo mantiene un elenco, chiamato ''arc_list'', degli archi attualmente realizzati dal nodo con i suoi vicini. Da un arco può risalire al nome dell'interfaccia di rete reale su cui è stato realizzato. Il modulo mantiene un elenco, chiamato ''id_list'', delle identità attualmente presenti nel nodo. Inoltre mantiene un riferimento, chiamato ''main_id'', alla identità ''principale''. Il modulo mantiene una associazione chiamata ''namespaces'' che partendo da una identità ''id~-,,0,,-~'' del nodo corrente, con ''id~-,,0,,-~ ∈ id_list'', individua il nome del network namespace che essa gestisce. Il modulo mantiene una associazione chiamata ''handled_nics'' che partendo dalla coppia ''id~-,,0,,-~-dev~-,,i,,-~'' (una identità e il nome di una interfaccia di rete reale), con ''id~-,,0,,-~ ∈ id_list'' e ''dev~-,,i,,-~ ∈ dev_list'', individua la relativa istanza di !HandledNic. Il modulo mantiene una associazione chiamata ''identity_arcs'' che partendo dalla coppia ''id~-,,0,,-~-arc~-,,0,,-~'' (una identità e un arco), con ''id~-,,0,,-~ ∈ id_list'' e ''arc~-,,0,,-~ ∈ arc_list'', individua il relativo contenitore di istanze di !IdentityArc. == Requisiti == L'utilizzatore deve fornire al modulo fin dalla sua inizializzazione questi requisiti: * L'elenco delle interfacce reali gestite dal nodo nel network namespace default. Di ognuna di esse va indicato il nome, il MAC, il link-local assegnato dal modulo Neighborhood. * Un manager di network namespace, o ''netns-manager'' (si veda sotto la descrizione dell'interfaccia IIdmgmtNetnsManager). Durante il tempo l'utilizzatore potrà fornire al modulo altre informazioni: * Aggiungere una interfaccia di rete reale gestita dal nodo. * Rimuovere una interfaccia di rete reale che non è più gestita dal nodo. * Aggiungere un arco che il nodo ha realizzato. * Rimuovere un arco che non è più valido. == Deliverable == Il modulo Identities risponde a queste richieste: * ''NodeID get_main_id()'' - Ottenere il NodeID della identità ''principale'' del nodo. * ''Gee.List<NodeID> get_id_list()'' - Ottenere i NodeID di tutte le identità del nodo. * ''string get_namespace(NodeID id~-,,0,,-~)'' - Ottenere il nome del network namespace gestito dalla identità ''id~-,,0,,-~''. * ''Gee.List<NodeID> get_identity_arcs(IIdmgmtArc arc~-,,0,,-~, NodeID id~-,,0,,-~)'' - Dato un arco e una identità nel nodo (passata come NodeID) ottenere tutti i NodeID delle identità nel nodo diretto vicino collegato tramite questo arco per cui esiste il relativo ''arco-identità''. * ''bool identity_arc_exists(IIdmgmtArc arc~-,,0,,-~, NodeID id~-,,0,,-~, NodeID peer_id)'' - Dato un arco, una identità nel nodo (passata come NodeID) e una identità nel nodo diretto vicino collegato tramite questo arco, dire se esiste il relativo ''arco-identità''. Il modulo Identities permette queste operazioni: * Creazione della prima identità. Nel costruttore. * Duplicazione di una identità a seguito di una migrazione. Eventualmente in due fasi se la migrazione è di un cluster. Metodi ''prepare_add_identity'' e ''add_identity''. * Associazione di un oggetto ad una identità. Metodi ''set_identity_module'' e ''get_identity_module''. . Come detto prima, ad ogni identità si possono associare diversi oggetti, ognuno identificato da un nome. Di norma un oggetto per ogni modulo ''di identità''. * Aggiunta di un arco-identità. Metodo ''add_arc_identity''. * Rimozione di un arco-identità. Metodo ''remove_arc_identity''. * Rimozione di una identità che era ''di connettività''. Metodo ''remove_identity''. Il modulo Identities segnala questi eventi: * Aggiunta di un arco-identità. Questo può anche avvenire senza che ci sia stata una diretta richiesta da parte dell'utilizzatore del modulo. Segnale ''identity_arc_added'' * Modifica dei valori ''peer_mac'' e ''peer_linklocal'' di un arco-identità. Questo avviene senza che ci sia stata una diretta richiesta da parte dell'utilizzatore del modulo. Segnale ''identity_arc_changed'' * Rimozione di un arco-identità. Questo può anche avvenire senza che ci sia stata una diretta richiesta da parte dell'utilizzatore del modulo. Segnale ''identity_arc_removed'' == Classi e interfacce == Il netns-manager è un oggetto di cui il modulo conosce l'interfaccia IIdmgmtNetnsManager. Tramite essa il modulo può: * Creare un network namespace con un dato nome. Metodo ''create_namespace''. * Costruire una pseudo-interfaccia di rete sopra una data interfaccia di rete reale e metterla su un dato network namespace. Metodo ''create_pseudodev''. * Assegnare un dato indirizzo IP link-local ad una data pseudo-interfaccia di rete su un dato network namespace. Metodo ''add_address''. * Aggiungere/rimuovere un collegamento diretto da un dato indirizzo IP link-local locale ad un dato indirizzo IP link-local attraverso una data interfaccia di rete (pseudo o reale) su un dato network namespace. Metodi ''add_gateway'' e ''remove_gateway''. . Un tale collegamento diretto non va mai "cambiato". Infatti un indirizzo link-local di un vicino individua sempre univocamente un arco tra una specifica interfaccia del nodo corrente e una specifica interfaccia del nodo vicino. Non può formarsi un altro arco verso lo stesso indirizzo link-local da una diversa interfaccia di rete del nodo corrente. L'unico scenario possibile è la creazione di una diversa identità nel nodo corrente (ma comunque si tratta di una aggiunta su un diverso network namespace) o nel nodo vicino (ma si tratta di una aggiunta con un diverso indirizzo link-local del vicino). * Eliminare una data pseudo-interfaccia di rete da un dato network namespace. Metodo ''delete_pseudodev''. * Eliminare un dato network namespace. Metodo ''delete_namespace''. ---- La classe Identity è interna al modulo. All'esterno del modulo una identità è rappresentata da un NodeID, sia per le identità del nodo corrente che per quelle dei vicini. La classe Identity incapsula un NodeID. Fornisce inoltre un metodo ''to_string'' che produce (a partire dal NodeID) una stringa che la identifica univocamente. ---- La classe usata per l'identificativo di una identità, cioè NodeID, è una classe serializzabile definita nella libreria [[Netsukuku/ita/docs/Librerie/Common|Common]]. Il modulo Neighborhood ha una dipendenza su questa libreria, quindi conosce tale classe. Il modulo Identities crea le istanze di questa classe relative alle identità di questo nodo. Il modulo Identities riceve anche istanze di questa classe relative alle identità di nodi vicini. Naturalmente sa accedere alle informazioni in essa contenute. ---- Un arco che il nodo ha realizzato è rappresentato con una classe che il modulo non conosce. Il modulo espone l'interfaccia IIdmgmtArc che tale oggetto deve implementare. L'interfaccia IIdmgmtArc consente di: * Leggere il nome dell'interfaccia di rete reale su cui l'arco è realizzato (metodo ''get_dev''). ---- La classe !HandledNic è una struttura dati interna al modulo. Essa si riferisce ad una interfaccia di rete (reale o pseudo) la quale è associata ad una data interfaccia di rete reale ed è gestita da una data identità del nodo corrente. Ad esempio, se il modulo nel nodo ''a'' vuole recuperare il nome della pseudo-interfaccia di rete che la sua identità ''id~-,,0,,-~'' (la quale non è la principale) gestisce e che è stata costruita sulla interfaccia reale "eth0", il modulo esamina l'associazione ''handled_nics(id~-,,0,,-~-eth0)'' e ottiene una istanza di !HandledNic; quindi guarda il suo membro ''dev'', che ad esempio contiene "ntkv0_eth0". Relativamente a questa interfaccia di rete (reale o pseudo) la struttura dati contiene: * ''dev'' - Una stringa. Il nome. * ''mac'' - Una stringa. Il MAC address. * ''linklocal'' - Una stringa. L'indirizzo link-local assegnato. ---- La classe !IdentityArc è una struttura dati interna al modulo. Essa si riferisce ad una interfaccia di rete (reale o pseudo) gestita da una identità di un nodo vicino. Il vicino è collegato al nodo corrente tramite un dato arco e esiste un arco-identità tramite quella identità del nodo vicino e una data identità del nodo corrente. Ad esempio, supponiamo che nel nodo corrente ''a'' abbiamo l'identità ''id~-,,0,,-~''. Inoltre abbiamo un arco ''arc~-,,1,,-~'' che collega una interfaccia del nodo ''a'', diciamo ''if~-,,a1,,-~'', ad una interfaccia del nodo ''b'', diciamo ''if~-,,b1,,-~''. Se voglio vedere quali archi-identità collegano l'identità ''id~-,,0,,-~'' di ''a'' ad altre identità di ''b'' tramite l'arco ''arc~-,,1,,-~'', allora il modulo esamina l'associazione ''identity_arcs(id~-,,0,,-~-arc~-,,1,,-~)'' e ottiene una lista di istanze di !IdentityArc; le esamina una ad una accedendo ai suoi membri. La classe !IdentityArc contiene questi dati: * ''peer_nodeid'' - Un NodeID. L'identificativo di una identità nel nodo ''b'' per la quale esiste un arco-identità con la nostra ''id~-,,0,,-~'' costruito sull'arco ''arc~-,,1,,-~''. * ''peer_mac'' - Una stringa. Il MAC address dell'interfaccia gestita dalla ''peer_nodeid'' nel nodo ''b'' costruita sulla ''if~-,,b1,,-~''. * ''peer_linklocal'' - Una stringa. L'indirizzo link-local assegnato all'interfaccia gestita dalla ''peer_nodeid'' nel nodo ''b'' costruita sulla ''if~-,,b1,,-~''. Forniamo la classe !IdentityArc del metodo ''copy'' per facilitare la duplicazione degli archi-identità quando viene aggiunta una nuova identità al nodo. |
[[https://github.com/lukisi/documentation/blob/master/ita/ModuloIdentities/AnalisiFunzionale.md|Redirect]] |
- Diff for "Netsukuku/ita/docs/ModuloIdentities/AnalisiFunzionale"