Vous ne pouvez pas sélectionner plus de 25 sujets Les noms de sujets doivent commencer par une lettre ou un nombre, peuvent contenir des tirets ('-') et peuvent comporter jusqu'à 35 caractères.

netsukuku.ita 60KB

12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879808182838485868788899091929394959697989910010110210310410510610710810911011111211311411511611711811912012112212312412512612712812913013113213313413513613713813914014114214314414514614714814915015115215315415515615715815916016116216316416516616716816917017117217317417517617717817918018118218318418518618718818919019119219319419519619719819920020120220320420520620720820921021121221321421521621721821922022122222322422522622722822923023123223323423523623723823924024124224324424524624724824925025125225325425525625725825926026126226326426526626726826927027127227327427527627727827928028128228328428528628728828929029129229329429529629729829930030130230330430530630730830931031131231331431531631731831932032132232332432532632732832933033133233333433533633733833934034134234334434534634734834935035135235335435535635735835936036136236336436536636736836937037137237337437537637737837938038138238338438538638738838939039139239339439539639739839940040140240340440540640740840941041141241341441541641741841942042142242342442542642742842943043143243343443543643743843944044144244344444544644744844945045145245345445545645745845946046146246346446546646746846947047147247347447547647747847948048148248348448548648748848949049149249349449549649749849950050150250350450550650750850951051151251351451551651751851952052152252352452552652752852953053153253353453553653753853954054154254354454554654754854955055155255355455555655755855956056156256356456556656756856957057157257357457557657757857958058158258358458558658758858959059159259359459559659759859960060160260360460560660760860961061161261361461561661761861962062162262362462562662762862963063163263363463563663763863964064164264364464564664764864965065165265365465565665765865966066166266366466566666766866967067167267367467567667767867968068168268368468568668768868969069169269369469569669769869970070170270370470570670770870971071171271371471571671771871972072172272372472572672772872973073173273373473573673773873974074174274374474574674774874975075175275375475575675775875976076176276376476576676776876977077177277377477577677777877978078178278378478578678778878979079179279379479579679779879980080180280380480580680780880981081181281381481581681781881982082182282382482582682782882983083183283383483583683783883984084184284384484584684784884985085185285385485585685785885986086186286386486586686786886987087187287387487587687787887988088188288388488588688788888989089189289389489589689789889990090190290390490590690790890991091191291391491591691791891992092192292392492592692792892993093193293393493593693793893994094194294394494594694794894995095195295395495595695795895996096196296396496596696796896997097197297397497597697797897998098198298398498598698798898999099199299399499599699799899910001001100210031004100510061007100810091010101110121013101410151016101710181019102010211022102310241025102610271028102910301031103210331034103510361037103810391040104110421043104410451046104710481049105010511052105310541055105610571058105910601061106210631064106510661067106810691070107110721073107410751076107710781079108010811082108310841085108610871088108910901091109210931094109510961097109810991100110111021103110411051106110711081109111011111112111311141115111611171118111911201121112211231124112511261127112811291130113111321133113411351136113711381139114011411142114311441145114611471148114911501151115211531154115511561157115811591160116111621163116411651166116711681169117011711172117311741175117611771178117911801181118211831184118511861187118811891190119111921193119411951196119711981199120012011202120312041205120612071208
  1. Netsukuku
  2. - Close the world, txEn eht nepO -
  3. --
  4. 0. Preface
  5. 1. The old wired
  6. 2. The Netsukuku wired
  7. 2.1 Gandhi
  8. 2.2 No name, no identity
  9. 2.3 So, WTF is it?
  10. 2.4 Other implementations
  11. 2.5 The born
  12. --
  13. 3. Netukuku Protocol v7: the seventh son of Ipv7
  14. 3.1 #define Npv7
  15. 4. Npv7_II: Laser Broadcast
  16. 5. Npv7 Hybrid Theory: the final way
  17. 5.1 QSPN: Quantum Shortest Path Netsukuku
  18. 5.1.1 QSPN screenshot
  19. 5.1.2 Continual qspn starters
  20. 5.1.3 The Qspn sickness: RequestForRoute
  21. 5.1.4 Qspn round
  22. 5.2 Npv7_HT Hook & Unhook
  23. 5.2.1 Qspn Hook & Unhook
  24. 5.3 The truly Gnode^n for n<=INFINITE
  25. 5.3.1 Groupnode: one entity
  26. 5.3.2 Gnode fusion
  27. 6. Broadcast: There can be only one!
  28. 6.1 Tracer pkt: one flood, one route
  29. 7. ANDNA: Abnormal Netsukuku Domain Name Anarchy
  30. 7.1 ANDNA Metalloid elements: registration recipe
  31. 7.1.1 ANDNA hook
  32. 7.1.2 Don't rob my hostname!
  33. 7.1.3 Count again
  34. 7.1.4 Registration step by step
  35. 7.1.5 Endless rest and rebirth
  36. 7.1.6 Hash_gnodes mutation
  37. 7.1.7 Yaq: Yet another queue
  38. 7.8 Hostname resolution
  39. 7.8.1 Distributed cache for hostname resolution
  40. 7.8.2 noituloser emantsoh esreveR
  41. 7.9 dns wrapper
  42. 8. Heavy Load: flood your ass!
  43. 9. Spoof the Wired: happy kiddies
  44. 10. /dev/Accessibility
  45. 11. Internet compatibility
  46. 12. Implementation: let's code
  47. 13. What to do
  48. 14. The smoked ones who made Netsukuku
  49. --
  50. 0. Preface
  51. Questo documento ed il codice sorgente relativo sono disponibili su:
  52. http://netsukuku.freaknet.org
  53. Le future modifiche e aggiunte a questo documento possono essere trovate
  54. e proposte qui: http://lab.dyne.org/Netsukuku
  55. Nota: questa NON e' l'ultima versione del documento.
  56. L'ultima versione e' quella inglese:
  57. http://netsukuku.freaknet.org/doc/netsukuku
  58. Se vuoi tradurre le parti mancanti, non fare complimenti ;)
  59. 1. The old wired
  60. Internet e' una rete gerarchica gestita da multinazionali ed enti che vengono
  61. supportati dai governi. Ogni bit di traffico dati passa attraverso le loro
  62. backbone e i loro router.
  63. Gli Internet Service Provider offrono la connettivita' a tutti gli utenti,
  64. che si trovano nelle parti piu' basse di questa scala gerarchica.
  65. Non esiste alcun modo per condividere la proprieta' di Internet e quindi,
  66. gli utenti, per connettersi alla grande Rete, sono costretti a sottostare
  67. alle pesanti condizioni imposte dalle mega-corporation.
  68. Internet e' oggi il mezzo di comunicazione per eccellenza che permette la
  69. diffusione e la condivisione globale del sapere e dell'informazione.
  70. Circa 1 miliardo di persone possono connettersi a questa grande rete
  71. proprietaria, ma le restanti 5 miliardi, che non hanno sufficienti
  72. risorse economiche, aspettano tutt'ora che le multinazionali offrano loro
  73. un servizio realmente accessibile.
  74. Internet e' nato per garantire una comunicazione sicura e inattaccabile tra
  75. i vari nodi della rete, ma adesso, paradossalmente, quando un ISP decide di
  76. non fornire piu' il suo servizio intere sono immediatamente tagliate fuori
  77. da Internet.
  78. Inoltre, Internet non e' una rete anonima: gli ISP e le multinazionali
  79. possono intercettare e analizzare il traffico che passa dai loro server
  80. senza alcun vincolo.
  81. La struttura gerarchica e centralizzata di Internet crea, di conseguenza,
  82. altri sistemi identici che poggiano su di essa, come ad esempio il DNS.
  83. I server del Domain Name System vengono anch'essi gestiti dai vari ISP, i
  84. domini vengono letteralmente venduti e le maglie di un sistema centralizzato
  85. rimangono immutate.
  86. Questo tipo di struttura permette, in modo semplice ed efficace, di
  87. localizzare fisicamente qualsiasi computer connesso ad Internet in
  88. pochissimo tempo e senza alcuno sforzo.
  89. In Cina, l'intera rete e' sorvegliata continuamente da numerosi computer che
  90. filtrano il traffico Internet: un cinese non potra' mai vedere e in ogni
  91. caso venire a conoscenza di un sito che contiene delle parole chiavi
  92. censurate dallo Stato. Se, poi, egli osasse esprimere sulla rete un pensiero
  93. contrario alla dottrina politica del governo, rischierebbe perfino la pena
  94. di morte.
  95. Internet e' nato per soddisfare le esigenze di sicurezza militare
  96. dell'amministrazione della difesa degli USA, e nel corso del tempo, la
  97. sua struttura originaria non e' cambiata, ne' mai potra' mutare.
  98. La liberta' di comunicazione e d'informazione su Internet saranno sempre
  99. negate: per comunicare saremo sempre costretti a chiedere il preventivo
  100. beneplacito di autorita' statali e mendicare il supporto di gigantesche
  101. multinazionali che, in tal modo, continueranno ad espandere il proprio
  102. dominio.
  103. Se, di fatto, i tentativi di rendere Internet il mezzo di comunicazione
  104. libero per eccellenza, sono destinati a fallire, allora non ci resta altro
  105. da fare che sostituirlo.
  106. Come?
  107. Con una rete distribuita, decentralizzata e pienamente efficiente, una rete
  108. che non possa essere sottoposta a nessun tipo di governo.
  109. 2. The Netsukuku wired
  110. Netsukuku e' una mesh network o un sistema p2p che si crea e si mantiene
  111. autonomamente.
  112. Netsukuku e' stato progettato per gestire un numero illimitato di nodi con
  113. un minimo uso di CPU e memoria. Questa sua caratteristica puo' essere
  114. sfruttata per costruire, senza il supporto di alcun server o ISP, una rete
  115. globale distribuita, anonima e non controllata, separata da Internet.
  116. Questa rete e' formata da computer collegati fisicamente tra loro, quindi
  117. non e' costruita su alcuna altra rete. Netsukuku si occupa solamente di
  118. costruire le rotte che collegano tutti i computer della rete.
  119. In altre parole, Netsukuku sostituisce il livello 3 del modello iso/osi con
  120. un altro protocollo di routing.
  121. Poiche' Netsukuku, e' una rete distribuita, e non centralizzata, e'
  122. possibile implementare su di essa effettivi sistemi distribuiti, come ad
  123. esempio l'Abnormal Netsukuku Domain Name Anarchy (ANDNA), che sostituira'
  124. l'attuale sistema gerarchico e centralizzato dei DNS.
  125. 2.1 Gandhi
  126. Netsukuku si crea e si gestisce da se'.
  127. Un nodo si aggancia a Netsukuku, la rete si auto-riscrive e tutti gli altri
  128. nodi conoscono quali sono le strade piu' veloci ed efficienti per comunicare
  129. con il nuovo arrivato.
  130. I nodi non hanno privilegi o limitazioni rispetto ad altri nodi, fanno parte
  131. della rete e contribuiscono alla sua espansione ed efficienza.
  132. Con l'aumentare del loro numero, la rete cresce e si perfeziona.
  133. In Netsukuku non vi e' alcuna differenza tra reti private e pubbliche e non
  134. ha piu' alcun significato parlare di LAN.
  135. Netsukuku non puo' essere controllato ne' distrutto poiche' e' totalmente
  136. decentralizzato e distribuito. L'unico modo per sorvegliare o smantellare
  137. Netsukuku e' abbattere fisicamente ogni singolo nodo che lo compone.
  138. 2.2 No name, no identity
  139. In Netsukuku chiunque, in qualunque luogo e in qualsiasi momento puo'
  140. agganciarsi immediatamente alla rete senza dover passare attraverso
  141. adempimenti burocratici o contrattuali.
  142. Inoltre, ogni elemento della rete e' estremamente dinamico e non rimane mai
  143. uguale a se' stesso. L'indirizzo IP che identifica un computer e' scelto
  144. casualmente, quindi e' impossibile associarlo ad una localita' fisica
  145. precisa, e le stesse rotte, essendo formate da un numero innumerevole di
  146. nodi, tendono ad avere una complessita' e densita' talmente elevata da
  147. rendere il tracciamento di un nodo un'impresa epica.
  148. Poiche' non esiste alcun contratto con alcuna societa', la velocita' del
  149. trasferimento dei dati e' limitata unicamente dalla tecnologia attuale delle
  150. schede di rete.
  151. 2.3 So, WTF is it?
  152. Netsukuku e' una mesh network o rete p2p composta da un protocollo di rete
  153. per il routing dinamico, chiamato Npv7_HT.
  154. Attualmente esistono molti protocolli ed algoritmi per il routing dinamico,
  155. ma a differenza dell'Npv7_HT, vengono utilizzati solo per creare piccole e
  156. medie reti. Anche i router di Internet sono gestisti da vari protocoli come
  157. l'OSPF, il RIP o il BGP, che usano diversi algoritmi classici per trovare
  158. il percorso migliore per raggiungere un nodo in una rete.
  159. Questi protocolli richiedono un consumo di cpu e memoria elevatissimo, ed e'
  160. per questo motivo che i router di Internet sono dei computer appositamente
  161. dedicati. Sarebbe impossibile adottare uno di questi protocolli per creare
  162. e mantenere una rete come Netsukuku, dove ogni nodo e' a sua volta un
  163. router, perche' la mappa di tutte le rotte richiederebbe uno spazio, su
  164. ciascun pc connesso alla rete, di circa dieci Gb.
  165. L'Npv7 struttura l'intera rete come un frattale, ed usa un particolare
  166. algoritmo chiamato Quantum Shortest Path Netsukuku (QSPN) per calcolare
  167. tutte le rotte necessarie a collegare un nodo ad ogni altro nodo.
  168. Un frattale e' una struttura matematica che si puo' comprimere all'infinito,
  169. proprio perche', al suo interno, ogni sua parte e' formata dal frattale
  170. stesso. Si ha quindi una compressione elevata di una struttura che
  171. puo' espandersi infinitamente. Questo significa che bastano pochi Kb per
  172. mantenere l'intera mappa di Netsukuku.
  173. La struttura della mappa puo' anche essere definita in modo piu' preciso
  174. come un grafo altamente clusterizzato.
  175. Il QSPN, invece, e' un meta-algoritmo perche' non esegue una sequenza di
  176. istruzioni matematiche definite ma sfrutta il caso e il caos, che non
  177. richiedono nessun calcolo pesante.
  178. Il QSPN deve essere eseguito su una rete reale (o simulata). I nodi devono
  179. mandare i pacchetti QSPN per "eseguire" l'algoritmo, e per questo motivo
  180. non e' sempre vero che un determinato pacchetto sara' mandato prima di un
  181. altro.
  182. 2.4 Other implementations
  183. Netsukuku non e' limitato alla creazione di una rete di soli computer, e' un
  184. protocollo che implementa una rete pura, e cosi' come ogni protocollo di rete
  185. puo' essere usato in tutte le situazioni in cui si ha bisogno di collegare
  186. piu' nodi fra loro.
  187. Prendiamo in esame il caso dei cellulari. Anche la rete dei cellulari e' una
  188. rete gerarchica e centralizzata. Migliaia di nodi si appoggiano ad una
  189. stessa cella, che poi smistera' il traffico alle altre celle, che, infine,
  190. consegneranno i dati ai nodi destinatari. Bene, Netsukuku puo' essere
  191. adottato anche dai cellulari, rendendo superflua l'esistenza degli attuali
  192. gestori di telefonia mobile.
  193. Questo ragionamento puo' essere applicato a tutti i sistemi di comunicazione
  194. che esistono attualmente.
  195. 2.5 The born
  196. La storia di come si sia arrivati a Netsukuku e' lunga e travagliata.
  197. Durante un storica trasmissione di radio Cybernet, all'Hackmeeting del
  198. 2000, nasce l'idea dell'Ipv7, di nocoder e nocrypt: sono assurdi scherzi
  199. teorici che trattano protocolli di rete, compilatori intelligenti e
  200. programmi cryptografici.
  201. Nel lontano 2003, un gruppo di pazzi deliranti continua a espandere i
  202. concetti dell'Ipv7: una rete in cui tutti i pacchetti vengono mandati in
  203. broadcast, compressi con le zlib7, un algoritmo che comprime l'attuale
  204. Internet in 32 byte ( Vedi http://idiki.dyne.org/wiki/Zlib7 ).
  205. In Ipv7 nessun nodo possiede un indirizzo IP e la rete e' estremamente
  206. decentralizzata e libera. Quelle persone erano felici, e dopo la stesura del
  207. primo RFC, un sorriso sereno e una luce angelica avvolgeva le loro figure.
  208. Un anno trascorre, il progetto si perde tra le infinite diramazioni del
  209. tempo, ma dopo non molto la polvere viene scrollata dal grande libro
  210. dell'Ipv7. Si comincia a delirare sull'implementazione di una rete pura.
  211. I mesi passano. La rete viene definita sempre di piu', diventa quasi
  212. tangibile...
  213. <<Ma deve anche supportare una qualche forma di antiflood e antispoofing>>.
  214. <<Gia'! E si deve fare in modo che le rotte non siano mai uguali tra loro>>.
  215. <<Si, si, e perche' non facciamo che non esistano piu' in assoluto dei server
  216. centrali?>>.
  217. Tre mesi dopo, a seguito di numerosissime peregrinazioni mistiche, il cuore
  218. teorico e' pronto. Gli algoritmi sono definiti.
  219. Si comincia a codare. La maledizione dei coder di protocolli di rete del
  220. sacro faraone Mortedelprimogenito si riversa sul codice di Netsukuku. La
  221. pazzia e il delirio sono la giusta ricompensa a tutti coloro i quali
  222. osano addentrarsi nella creazione di protocolli di reti pure.
  223. Nonostante tutto, esattamente dopo un anno e 14 mila righe di codice,
  224. Netsukuku e' pronto e diventa Beta.
  225. Due mesi dopo la presentazione di Netsukuku all'Hackmeeting 2005, il
  226. protocollo di ANDNA, cosi' come il suo codice, e' completamente
  227. definito e documentato.
  228. In Ottobre, viene stata rilasciata la prima versione publica di Netsukuku.
  229. Nel corso dei mesi il protocollo e il demone sono stati profondamente
  230. migliorati e adesso, a Maggio del 2006, il codice ha raggiunto quaranta mila
  231. righe.
  232. Il resto giace in potenza e deve ancora divenire.
  233. --
  234. The Netsukuku Protocol
  235. Npv7
  236. 3. Netsukukuku protocol v7
  237. Netsukuku, usa l'Npv7 (Netsukuku protocol version 7), il suo protocollo, che
  238. deriva da tre precedenti versioni.
  239. La prima era strutturata in maniera simile agli attuali protocolli di rete
  240. utilizzati per il routing dinamico: la rete era divisa in gruppi di nodi,
  241. ogni nodo possedeva la mappa dell'intera rete.
  242. Questo sistema, non ottimale, non e' adottato da Netsukuku poiche' prevede
  243. l'aggiornamento continuo della mappa, ed ogni aggiornamento crea un overload
  244. nella rete. Inoltre, ogni volta che la mappa cambia bisogna ricalcolarsi tutte
  245. le rotte.
  246. 3.1 #define Npv7
  247. Le definizioni basilari utilizzate per Netsukuku sono state e, tuttora sono:
  248. src_node: Il Source node e' il nodo che manda un pacchetto al dst_node.
  249. dst_node: Destination node, il node the riceve il pacchetto mandato dal
  250. src_node.
  251. r_node: Considerando un nodo X, un remote node (r_node) e' un qualsiasi
  252. nodo direttamente collegato ad X.
  253. g_node: Group node, un gruppo di nodi, o un gruppo di gruppi di nodi, e
  254. cosi' via.
  255. b_node: Border node, un nodo che ha rnodes di diversi gnode.
  256. h_node: Hooking node, un nodo che si sta agganciando a netsukuku.
  257. int_map: Internal map, mappa interna. La mappa interna del nodo X e' la mappa
  258. che contiene le informazioni sui nodi che appartengono al gnode a cui
  259. appartiene X.
  260. ext_map: External map, mappa esterna. La mappa che contiene le informzioni sui
  261. gnode.
  262. bmap / bnode_map: Border node map. E' la mappa che tiene la lista dei
  263. border node.
  264. quadro_group: Un nodo, o un groupnode di qualsiasi livello, scomposto nelle
  265. sue parti essenziali.
  266. 4. Npv7_II: Laser Broadcast
  267. Npv7_II e' la seconda versione dell'Npv7.
  268. Netsukuku viene suddiviso in tanti piccoli groupnode che contengono al
  269. massimo 600 nodi. Ogni nodo di Netsukuku possiedera' solamente la mappa
  270. esterna, quella dei groupnode.
  271. Gli stessi groupnode vengono raggruppati in multi-groupnode, chiamati quadro
  272. groupnode.
  273. Per creare una rotta e raggiungere un determinato dst_node, il src_node,
  274. usando la mappa esterna, calcola il percorso migliore per raggiungere il
  275. gnode di destinazione a cui appartiene il dst_node.
  276. La rotta cosi' trovata viene memorizzata nel pacchetto che viene spedito in
  277. broadcast all'interno del gnode a cui appartiene l'src_node.
  278. I border_node del gnode del src_node ricevono il pkt e controllano se il
  279. prossimo gnode a cui deve essere mandato in broadcast il pkt e' proprio un
  280. gnode con cui confinano. Se la condizione viene rispettata, i border_node
  281. mandano in broadcast il pkt in quel gnode. In caso contrario il pkt viene
  282. ignorato.
  283. E cosi' via...
  284. In questo modo il pacchetto arrivera' al gnode di destinazione.
  285. Quando il dst_node riceve il pkt non deve far altro che settare una
  286. rotta inversa usando la rotta memorizzata nel pkt.
  287. L'Npv7_II e la sua versione precedente non vengono usate, ma sono alla base
  288. dell'Npv7_HT, l'attuale versione del protocollo Netsukuku.
  289. 5. Npv7 Hybrid Theory: the final way
  290. Dall'unione di Npv7 e Npv7_II e' derivato Npv7 Hybrid Theory.
  291. Questa nuova versione, sfrutta i vantaggi della mappa interna e del laser
  292. broadcast e cosi' facendo supera le loro imperfezioni.
  293. In Npv7_HT il numero massimo di nodi presenti in un group node (MAXGROUPNODE)
  294. e' pari a 2^8, i groupnode sono quindi relativamente piccoli.
  295. In Npv7_HT il cambiamento principale riguarda la sua stessa essenza, infatti,
  296. si basa su un algoritmo creato appositamente per Netsukuku, chiamato
  297. Quantum Shortest Path Netsukuku, che permette di ottenere in un solo colpo la
  298. situazione completa del g_node, tutte le rotte migliori, la riduzione del
  299. carico del g_node, un'efficace gestione dei gnode molto dinamici,
  300. l'abolizione del bisogno di autenticazione tra i nodi.
  301. 5.1 QSPN: Quantum Shortest Path Netsukuku
  302. In Netsukuku, come in natura, non vi e' alcun bisogno di usare schemi
  303. matematici. Un ruscello, per raggiungere il mare, calcolera' mai la strada
  304. che dovra' percorrere quando ancora si trova in cima alla montagna? Il
  305. ruscello scorrera' semplicemente, trasportato dal suo stesso flusso,
  306. trovando cosi', prima o poi, la sua rotta ideale.
  307. Netsukuku sfrutta lo stesso principio caotico. Il risultato finale
  308. restituito dall'algoritmo che esplora la rete puo' essere constituito da
  309. risultati intermedi ogni volta differenti, poiche' quest'algoritmo viene
  310. "eseguito" dalla rete stessa.
  311. L'uso di una mappa, in un protocollo di reti dinamiche, crea troppi
  312. problemi, dovendo tenerla sempre aggiornata. La soluzione e' semplice: non
  313. usare affatto una mappa e far diventare ogni richiesta mandata in broadcast
  314. un tracer_pkt (Vedi 6.1 Tracer pkt).
  315. In questo modo ogni nodo che ricevera' il pkt sapra' qual e' la rotta
  316. migliore per raggiungere il src_node e tutti i nodi che stanno
  317. in mezzo alla rotta, si memorizzera' queste info nella sua mappa interna,
  318. aggiungera' la sua entry nel tracer_pkt e fara' continuare il broadcast del
  319. pkt.
  320. Rimane un grosso problema: per avere tutte le rotte per tutti i nodi
  321. bisogna che tutti i nodi mandino in broadcast un tracer_pkt. In realta' questo
  322. problema e' del tutto inconsistente. Infatti, con il tracer_pkt possiamo
  323. ricavare anche le rotte per i nodi intermedi; questo vuol dire che abbiamo
  324. bisogno di un numero < di n pacchetti, dove n e' il numero dei nodi.
  325. Se ogni nodo rimanda indietro un tracer_pkt ogni volta che ne riceve uno,
  326. siamo sicuri che tutti i nodi ricevono tutte le rotte possibili, cosi'
  327. facendo ricaviamo lo stesso risultato raggiunto dal far mandare un
  328. tracer_pkt da tutti i nodi.
  329. Per chi ha presente la fisica delle onde, il funzionamento del qspn puo'
  330. essere facilmente compreso. Se lanciamo un sassolino in uno specchio d'acqua,
  331. contenuto in una bacinella, dal punto di impatto incominciano a propagarsi
  332. delle onde circolari. Ogni onda genera un'onda figlia che continua ad
  333. espandersi ed a generare figli che generano figli e cosi' via...
  334. Quando un'onda colpisce i bordi della bacinella, viene riflessa e ritorna
  335. verso il punto d'origine; lo stesso avviene se l'onda incontra un ostacolo.
  336. Il qspn_starter e' il sassolino gettato nel groupnode ed ogni onda e' un
  337. tracerpkt. Ogni onda figlia porta con se' l'informazione dell'onda padre.
  338. Quando l'onda arriva in un extreme_node (un ostacolo, un vicolo cieco) parte
  339. il qspn_open (l'onda riflessa).
  340. Il QSPN si basa su questo principio. Per iniziare il tracciamento del g_node,
  341. un qualsiasi nodo manda un qspn_pkt (chiamato qspn_close), questo nodo diventa
  342. quindi un qspn_starter.
  343. Un qspn_pkt e' un normale tracer_pkt, ma il modo in cui si diffonde in
  344. broadcast e' leggermente diverso dal normale.
  345. Ogni nodo che riceve il qspn_pkt "chiude" il link da cui ha ricevuto il pkt,
  346. e spedisce il pkt a tutti gli altri link. Tutti i successivi pacchetti
  347. qspn_close che arriveranno al nodo saranno mandati a tutti i link ancora non
  348. chiusi.
  349. Una volta che il qspn_close e' diffuso, alcuni nodi si troveranno con tutti i
  350. link chiusi. Questi nodi saranno gli extreme_node che invieranno un altro
  351. qspn_pkt di risposta (chiamato qspn_open), che contiene l'informazione gia'
  352. accumulata, a tutti i link, tranne a quello da cui hanno ricevuto l'ultimo
  353. qspn_close che li ha completamente chiusi a cui invieranno un qspn_open
  354. vuoto.
  355. Il qspn_open e' un normale qspn_pkt, quindi "apre" tutti i link alla stessa
  356. maniera del qspn_close. I nodi che si troveranno con tutti i link aperti non
  357. faranno assolutamente nulla, questo garantisce la fine del qspn_open.
  358. Un qspn_open possiede anche un sub_id, un numero che indentifica nella mappa
  359. interna l'extreme_node che l'ha creato. Il sub_id, che rimane inalterato per
  360. tutti i pacchetti qspn_open figli generati dal primo pacchetto, viene usato
  361. per gestire piu' qspn_pkt simultaneamente, poiche' ogni extreme_node genera
  362. un qspn_open ed ognuno dovra' essere indipendente dall'altro.
  363. Tutti i nodi con un solo link sono gli e_node per eccellenza, infatti non
  364. appena ricevono un qspn_close sono gia' chiusi.
  365. Una volta che un nodo ha mandato un qspn_open non rispondera' piu' a
  366. qualsiasi qspn_pkt che gli arrivera' (sempre relativamente alla sessione
  367. corrente), quindi non mandera' piu' qspn_close ne' qspn_open.
  368. Il qspn_starter, il nodo che ha innescato il qspn, si comporta come un
  369. normale nodo pero' non puo' mandare qspn_open perche' ha gia' mandato il
  370. primo qspn_close in assoluto, inoltre tutti i qspn_close che riceve li usa
  371. per aggiornare la sua mappa, ma se hanno gia' percorso piu' hop o se sono
  372. stati spediti da lui stesso, vengono ignorati; questo accorgimento garantisce
  373. la stabilita' nel caso ci siano piu' qspn_starter simultanei. La descrizione
  374. approfondita del qspn_starter e' nella sezione successiva 5.1.1.
  375. Alla fine i pacchetti di broadcast che vengono generati con qspn sono pari al
  376. numero degli e_node, ovvero 2 per ogni segmento di rete ciclico e 1 per un
  377. segmento singolo non ciclico.
  378. L'informazione per le rotte viene in ogni caso accumulata ogni volta che
  379. qualche tracer_pkt gira per la rete. Un nodo ricevera' molto probabilmente
  380. diverse rotte per raggiungere uno stesso nodo, ma memorizzera' solamente le
  381. prime MAXROUTES (10) rotte migliori.
  382. Il pkt_id dei qspn_pkt inizia da 1 e viene incrementato di 1 ogni volta che
  383. un nodo ne spedisce uno nuovo.
  384. Quindi, tutti i nodi conoscono il pkt_id corrente. Ogni qualvolta un nodo
  385. deve far aggiornare la mappa interna o esterna manda un qspn_close, solamente
  386. se non ha ricevuto entro i precedenti QSPN_WAIT secondi un altro qspn_close.
  387. Se due nodi mandano nello stesso momento un qspn_close, useranno lo stesso
  388. pkt_id, perche' nessuno dei due sa che ne e' stato gia' spedito un altro; in
  389. questo caso il funzionamento del qspn non cambia, anzi se i due qspn_pkt
  390. sono partiti da due luogi molto distanti allora il qspn_pkt si diffondera'
  391. molto rapidamente.
  392. Quando un nodo prende la mappa interna da un altro nodo, non deve
  393. far altro che aggiungere l'r_node, da cui ha preso la mappa, all'inizio
  394. di tutte le rotte. Se scarica la mappa da piu' r_node, dovra' confrontare
  395. tutte le rotte e scegliere la piu' breve. La mappa risultante avra' tutte
  396. le rotte migliori.
  397. Le rotte della mappa interna ed esterna verranno sempre ricopiate nella
  398. tabella di routing del kernel. In questo modo non ci sara' alcun bisogno di
  399. creare ogni volta la rotta necessaria per raggiungere il nodo di
  400. destinazione.
  401. 5.1.1 QSPN screenshot
  402. (A)-----(B)
  403. / | \ | \
  404. (E) | \ | (F)
  405. \ | \ | /
  406. (C)-----(D)
  407. Ricapitolando, tutti i nodi estremi dovrebbero inviare un tracer_pkt, ma non
  408. si puo' sapere quali essi siano. In questo disegnino e' facile individuarli,
  409. perche', appunto, la mappa e' disegnata, me nella realta' (nel codice di
  410. Netsukuku) non esiste una mappa topologica, quindi non si puo' sapere dove
  411. inizia un gruppo di nodi e dove finisce.
  412. Ecco cosa succede, in uno scenario immaginario, se il nodo E manda un
  413. qspn_close:
  414. E ha mandato il primo qspn_close del nuovo qspn_round, quindi e' diventato
  415. un qspn_starter.
  416. Consideriamo il caso in cui il nodo A riceve prima di C il qspn_close.
  417. A chiude il link E, manda il pkt a B, C, e D.
  418. C riceve il pkt, chiude il link E, lo manda ad A ed a D.
  419. C riceve da A, chiude il link.
  420. B e D hanno ricevuto, e chiudono i rispettivi link.
  421. Consideriamo il caso in cui il nodo B manda per primo il pkt ad F.
  422. D lo manda ad F subito dopo, ma nello stesso momento F lo manda a D.
  423. D ha ricevuto il pkt anche da B.
  424. D ed F hanno tutti i link chiusi.
  425. Mandano un qspn_open.
  426. Tutto avviene nel senso opposto.
  427. Finisce il qspn_open.
  428. Tutti hanno le rotte per raggiungere tutti.
  429. In genere, la topologia base a cui si riconduce il qspn e' un rombo con i
  430. nodi ai vertici, per renderla piu' complessa e' possibile aggiungere altri
  431. rombi uniti tra di loro con i vertici.
  432. Tutte le altre situazioni derivano piu' o meno da questa.
  433. 5.1.2 Continual qspn starters
  434. Se piu' qspn_starter che lanciano un qspn sono contigui fra loro allora
  435. il funzionamento del qspn varia leggermente. Un gruppo di nodi qspn_starter
  436. e' contiguo quando tutti i suoi nodi sono collegati a nodi che sono a
  437. loro volta dei qspn_starter. In questo scenario i qspn_starter continuano a
  438. inoltrare tra di loro solo i qspn_close mandati dai qspn_starter; si
  439. comportano quindi come dei normali nodi, infatti non appena ricevono dei
  440. pacchetti provenienti dall'esterno del gruppo contiguo di qspn_starters
  441. ritornano a seguire le loro istruzioni originarie. Quindi se A manda un
  442. qspn_close e B ha mandato pure un qspn_close, quando B riceve il qspn_close
  443. di A lo inoltra come un normale tracer_pkt con la flag BCAST_TRACER_STARTERS
  444. che si diffonde solo tra gli altri starter.
  445. Il motivo di tutto questo deriva dal fatto che in quel gruppo contiguo di
  446. nodi, ogni singolo nodi manda un tracer_pkt, quindi, i qspn_pkt vengono
  447. declassati a normali tracer_pkt.
  448. 5.1.3 The Qspn sickness: RequestForRoute
  449. /* Da codare, e non realmente necessario */
  450. L'unico grande difetto di qspn e' l'impossibilita' di avere molte piu' rotte
  451. per raggiungere uno stesso nodo. Con il qspn si e' sicuri di avere solamente
  452. le rotte migliori, e basta. In realta' il qspn puo' anche generare infinite
  453. rotte, basta che si lasci circolare il broadcast all'infinito (^_-).
  454. Ovviamente e' impensabile aspettare un'intera eternita' o due, quindi si usa
  455. il RequestForRoute! Il RFR verra' usato ogni volta che un nodo si connette
  456. ad un altro.
  457. Ecco cosa succede:
  458. il nodo manda a tutti i suoi rnode una richiesta RFR per una determinata
  459. rotta, questa richiesta contiene anche il numero di sub richieste
  460. (total_routes) che gli rnode devono mandare ai loro rnode. In pratica il
  461. nodo decide quante rotte ricevere e si calcola il numero di sub richieste
  462. che dovranno mandare i suoi rnode:
  463. subrfr = (total_routes - r_node.links) / r_node.links
  464. Dopo invia il RFR.
  465. I suoi rnode, dopo avergli mandato la rotta che loro usano per raggiungere il
  466. dst_node specificato nel rfr_pkt, mandano allo stesso modo un RFR che pero'
  467. ha total_routes pari a subrfr. Gli rnode degli rnode eseguiranno la stessa
  468. procedura e risponderanno direttamente al nodo interessato.
  469. 5.1.4 Qspn round
  470. Se un nodo riscontra un cambiamento attorno a se', ad esempio un suo
  471. rnode e' morto oppure l'rtt che lo distanzia dal suo rnode e' cambiato
  472. considerevolmente, allora mandera' un QSPN. Per evitare che vengano creati
  473. dei QSPN continuamente, il nodo deve prima verificare che il QSPN_WAIT_ROUND
  474. (60 secondi) sia scaduto. Il QSPN_WAIT_ROUND scade nello stesso momento per
  475. tutti i nodi appartenenti allo stesso gnode. Per far si' che i nodi che si
  476. agganciano al gnode siano sincronizzati ai nodi del gnode stesso, gli viene
  477. dato il numero di secondi che sono passati dal precedente QSPN, in questo
  478. modo tutti i nodi sapranno quando si verifichera' la prossima scadenza,
  479. ovvero avverra' dopo (current_time - prev_qspn_round) + QSPN_WAIT_ROUND
  480. secondi.
  481. Quando un qspn_starter manda un nuovo qspn_pkt, incrementa l'id del
  482. qspn_round di 1.
  483. Se il nodo che riceve un qspn_pkt, vede che il suo id e' maggiore del
  484. qspn_round id precedente che ha memorizzato, allora vuol dire che ha ricevuto
  485. un nuovo qspn_round; in questo caso aggiornera' il suo id locale e il suo
  486. qspn_time (la variabile che indica quando e' stato ricevuto/mandato l'ultimo
  487. qspn).
  488. Per aggiornare il qspn_time, dovra' settarlo a
  489. current_time - somma_degli_rtt_contenuti_nel_tracer_pkt.
  490. 5.2 Npv7_HT Hook & Unhook
  491. Un nodo, per entrare a far parte di Netsukuku, deve agganciarsi ai suoi
  492. rnode.
  493. L'hook in Netsukuku non si riferisce ad un aggancio alla rete "fisico",
  494. poiche' si presuppone gia' che un nodo sia linkato ad altri (r)_node.
  495. Quando un nodo si aggancia significa che comunica con un il suo rnode piu'
  496. vicino, se non gli risponde ne sceglie un altro. In pratica durante l'hook,
  497. il nodo si prende la mappa interna, quella esterna, la mappa dei border
  498. node, e si sceglie un IP libero. A questo punto fa ufficialmente parte della
  499. rete, quindi manda un normale tracer_pkt. I suoi rnode manderanno in seguito,
  500. un qspn.
  501. Ecco cosa avviene piu' in dettaglio:
  502. Il nodo si prende un IP compreso tra 10.0.0.1 <= x <= 10.0.0.1+256,
  503. rimuove le reti di loopback dalla tabella locale di routing e setta come
  504. default gateway l'IP scelto.
  505. Il primo passo e' quello di lanciare il primo radar per vedere quali sono i
  506. suoi r_nodes. Se non ci sono rnodes, crea un nuovo gnode e l'hook termina qui.
  507. Poi chiede all'rnode piu' vicino la lista di nodi liberi (free_nodes)
  508. presenti nel gnode dell'rnode. Se l'rnode non accetta la richiesta (il gnode
  509. potrebbe essere pieno), il nodo chiede la lista ad un altro rnode.
  510. Dai free_nodes ricevuti sceglie un IP e lo setta all'interfaccia di rete,
  511. modificando il default gw.
  512. A questo punto richiede la mappa esterna allo stesso rnode da cui ha preso la
  513. list di nodi liberi. Usando la lista di free_nodes vede se deve creare un
  514. nuovo gnode. Se non deve, prende l'int_map da ogni r_node.
  515. Unisce tutte le int_map ricevute in un unica mappa, in questo modo ha gia'
  516. tutte le rotte. Infine, si prende la bnode_map.
  517. Se tutto e' andato a buon fine, rilancia un secondo radar, manda un semplice
  518. tracer_pkt e aggiorna la sua tabella di routing. Fin.
  519. 5.2.1 Qspn Hook & Unhook
  520. Un nodo, dopo essersi agganciato al gnode, non deve far altro che mandare
  521. un tracer_pkt. In questo modo tutti i nodi avranno gia' la rotta esatta
  522. per raggiungerlo, aggiorneranno qualche rotta e saranno felici. Poi per
  523. quanto riguarda le rotte secondarie ci pensera' il round successivo di QSPN.
  524. Quando un nodo muore o si sgancia, non dice nulla a nessuno. I suoi rnode si
  525. accorgeranno della sua morte e manderanno un nuovo qspn_round.
  526. 5.3 The truly Gnode^n for n<=INFINITE
  527. Nel mondo ci sono 6*10^9 di persone, se andremo a colonizzare
  528. altri pianeti arriveremo a circa (6*10^9)^n, dove n e' un numero random > 0.
  529. E' anche vero che ci estingueremo molto prima in una delle solite stupide
  530. guerre. In sostanza netsukuku deve provvedere a un numero ENORME di nodi,
  531. per questo, come gia' sai, si usano i gnode.
  532. Ma questo non basta, perche' anche cosi' ci vorrebbero 300Mb circa per
  533. tenere l'intera extern map! Come si fa quindi?
  534. Si dividono i gnode in ulteriori gruppi, stavolta pero' questi gruppi non
  535. contengono nodi normali ma degli interi gnode, che vengono considerati dei
  536. nodi a tutti gli effetti... Procedendo recursivamente netsukuku puo'
  537. contenere all'incirca INFINITI nodi.
  538. Tutto rimane invariato.
  539. Per implementare questi gnode frattali e' necessario usare piu' di una mappa
  540. esterna che conterranno l'informazione su questi gruppi di gruppi. Questi
  541. "gruppi di gruppi" li continuiamo a chiamare groupnode.
  542. Ogni mappa di groupnode appartiene ad un determinato livello. Quindi il
  543. groupnode normale, che racchiude singoli nodi si trova a livello 0, la mappa
  544. del primo groupnode di gruppi di nodi si trova al primo livello, e la mappa
  545. di groupnode di groupnode di groupnode e' al secondo, e cosi' via.
  546. Un nodo per poter contattare qualsiasi altro nodo in qualsiasi parte del
  547. globo deve avere solamente la sua mappa interna, che non e' nient'altro
  548. che la mappa a livello 0 e poi le mappe di tutti i livelli superiori in
  549. cui lui e' presente. Facendo qualche calcolo con l'ipv4, per usare tutti
  550. gli IP, si devono usare solamente 3 livelli di mappe. Il che significa che
  551. prima c'e' il normale groupnode, poi ci sono MAXGROUPNODE di groupnode,
  552. e infine ci sono MAXGROUPNODE di questi ultimi. Nell'IPv6 invece, abbiamo
  553. una quantita' abnorme di IP, percio' i livelli ammontano a 16. Facendo una
  554. stima approssimativa, tutte le mappe esterne dei groups nell'IPv4 occupano
  555. 144K di memoria e nell'IPv6 1996K. Questo significa che nessuno si deve
  556. preoccupare di usare lo swap!
  557. Per trovare le rotte che connettono i vari gruppi verra' usato il QSPN,
  558. avevi dubbi -_^ ? Il qspn verra' ristretto e lanciato per ogni livello, in
  559. questo modo, ad esempio, trovera' tutte le rotte che legano i nodi
  560. appartenenti al secondo livello...
  561. Questo sistema dei livelli in relta' non e' complesso, basta tenere
  562. presente il funzionamento della mappa interna in unione a quello della
  563. mappa esterna ed applicare recursivamente ad ogni grouppo lo stesso concetto.
  564. Basta considerare ogni grouppo un singolo nodo.
  565. La rotta usata per raggiungere un groupnode, nella routing table, e' formata
  566. da range di IP (da IP x ad IP y) invece di un singolo IP.
  567. In questo modo, per poter raggiungere tutti i nodi presenti in netsukuku
  568. bisogna tenere nella routing table MAXGROUPNODE*(levels+1) rotte.
  569. Consideriamo il caso dell'IPv4 che ha 3 livelli.
  570. Intanto un nodo deve avere tutte le rotte per raggiungere tutti
  571. i nodi all'interno del suo groupnode, percio' gia' abbiamo MAXGROUPNODE
  572. di rotte, poi dobbiamo aggiungere tutte le rotte per raggiungere gli
  573. altri groupnode del suo livello superiore, percio' aggiungiamo altri
  574. MAXGROUPNODE di rotte. Proseguendo arriviamo all'ultimo livello ed abbiamo
  575. MAXGROUPNODE*(3+1). Con l'IPv4 abbiamo 1024 rotte, con l'IPv6 4352.
  576. Tutte queste rotte risiederanno direttamente nel kernel.
  577. 5.3.1 Groupnode: one entity
  578. Per avere il qspn effettivo dei groupnode la storia cambia un po'.
  579. La differenza tra un groupnode ed un nodo singolo risiede nel fatto che il
  580. nodo e' un'unica entita' che gestisce i suoi link direttamente da se', il
  581. groupnode, invece, e' un nodo composto da piu' nodi e i suoi link sono
  582. gestisti da altri nodi che sono i border node. Per rendere il groupnode
  583. un'unica entita' che si comporti esattamente come un nodo singolo basta che
  584. tutti i bnode del groupnode comunichino tra loro. Quindi, quando un bnode
  585. riceve un qspn_close da un altro groupnode, chiudera' il suo link e quando
  586. avra' tutti i suoi link con gli altri gnode chiusi, lo comunichera' agli
  587. altri bnode del suo groupnode. Lo stesso faranno gli altri. In questo modo
  588. il qspn_open sara' mandato solamente quando tutti i bnode avranno tutti i
  589. loro link esterni chiusi.
  590. Quando parliamo di groupnode di alti livelli allora un bnode non e' piu' un
  591. singolo nodo, ma e' a sua volta un gnode. Il procedimento resta invariato:
  592. questo bnode-gnode e' rappresentato da tutti i suoi bnodes interni.
  593. Ma come fanno i bnode a comunicare fra loro?
  594. Ovviamente in modo passivo: quando un bnode chiude tutti i suoi link esterni
  595. dopo aver ricevuto un qspn_close, setta nel tracer_pkt che sta per
  596. forwardare la flag BNODE_CLOSED, in questo modo gli altri bnode, vedendo
  597. questa flag, incrementeranno il loro contatore di bnodes chiusi. Quando i
  598. numero di bnode chiusi e' pari a quello dei bnode presenti nel gnode, allora
  599. verra' mandato il qspn_open.
  600. Un ultimo accorgimento: quando un bnode riceve un qspn_close mandato da un
  601. bnode del suo stesso gnode, allora, anche lui si considerera' un
  602. QSPN_STARTER e forwardera' il pkt senza aggiungere la sua entry, questo
  603. perche' il gnode deve essere come un unico nodo; inoltre, i bnode chiudono
  604. ed aprono solo i link esterni, cioe' quelli che li collegano ai bnode dei
  605. gnode confinanti.
  606. Tutto questo discorso vale anche per il qspn_open.
  607. 5.3.2 Gnode fusion
  608. Quando un nodo crea un nuovo group_node, ne sceglie uno completamente random,
  609. usando quindi un IP random. Se due gnode, dapprima isolati, per disgrazia
  610. hanno lo stesso groupnode id (e quindi lo stesso intervallo di IP), uno
  611. di loro due deve cambiare; questo significa cambiare l'IP di tutti i nodi
  612. del gnode.
  613. La soluzione e' descritta nell'NTK_RFC 0001:
  614. http://lab.dyne.org/Ntk_gnodes_contiguity
  615. 6. Broadcast: There can be only one!
  616. Quando vengono mandati dei pkt in broadcast si deve fare in modo che non
  617. vaghino in eterno in Netsukuku. Ogni nodo mantiene una cache composta
  618. da un numero di slot pari a MAXGROUPNODE. (La cache e' all'interno della
  619. mappa interna). Ogni slot corrisponde ad un nodo del g_node. Questo slot
  620. contiene il pkt_id dell'ultimo pkt broadcast mandato da quel nodo.
  621. Quindi:
  622. u_int brdcast; /*Pkt_id of the last brdcast_pkt sent by this node*/
  623. Un nodo quando riceve un pkt broadcast lo analizza:
  624. se vede che il pkt_id e' <= a quello memorizzato nella cache lo rigetta,
  625. perche' e' sicuramente un pkt vecchio che non deve piu' diffondersi.
  626. Ovviamente i pkt_id vengono incrementati ogni volta dal src_node.
  627. Se il pkt supera questo check allora il nodo esegue l'azione che il pkt
  628. richiede e forwarda il pkt a tutti i suoi r_node, escludendo quelli che gli
  629. hanno spedito il pkt. Se si vuole che il broadcast sia delimitato entro
  630. un'area di raggio prefissato, basta settare il ttl al numero di hop di questo
  631. raggio.
  632. 6.1 Tracer pkt: one flood, one route
  633. Il tracer pkt non e' altro che il modo per trovare la rotta migliore
  634. con il broadcast. Se il pkt che viene mandato in broadcast avra' la flag
  635. "tracer_pkt" settata allora ogni nodo che attraversera', aggiungera' in coda
  636. al pkt il suo IP. Quindi l'intera rotta che il pkt compie viene memorizzata
  637. nel pacchetto stesso. Il primo pacchetto che arrivera' a destinazione sara'
  638. sicuramente quello che avra' percorso la rotta migliore, percio' il dst_node
  639. non fara' altro che settare la rotta memorizzata nel pacchetto ed avviare
  640. la connessione. Il tracer_pkt introduce anche un altro subdolo vantaggio,
  641. infatti, il tracer_pkt non solo trasporta la rotta migliore per il src_node,
  642. ma anche quella per i nodi che fanno parte della rotta perche' se questo pkt
  643. ha davvero percorso la rotta migliore significa che ha anche percorso _TUTTE_
  644. le rotte migliori per gli hop intermediari.
  645. Concludendo, con un tracer pkt possiamo conoscere la rotta migliore per
  646. raggiungere il src_node (il nodo che ha spedito il pkt), e conseguentemente
  647. le rotte per raggiungere tutti i nodi intermediari.
  648. I border_node quando aggiungono la loro entry in un tracer_pkt settano la
  649. flag b_node ed aggiungono in coda l'id del gnode con cui confinano, ma
  650. solamente se quel gnode appartiene al livello superiore a quello in cui il
  651. tracer_pkt si sta propagando.
  652. Con questo sistema tutti riceveranno tutte le rotte migliori per raggiungere
  653. tutti i nodi del g_node e tutti i g_node confinanti.
  654. Per ottimizzare al massimo lo spazio utilizzato in un tracer_pkt,
  655. gli IP vengono scritti nel formato IP2MAP, che corrisponde all'id dei nodi
  656. nel gnode di livello zero. Con questo formato e' richiesto solamente un
  657. u_char (1 byte invece di 20).
  658. 7. ANDNA: Abnormal Netsukuku Domain Name Anarchy
  659. ANDNA e' il sistema distribuito, non gerarchico e decentralizzato, di
  660. gestione di hostname in Netsukuku. Sostituisce il DNS.
  661. Il database dell'ANDNA e' sparso in tutto Netsukuku e nel peggiore dei casi
  662. ogni nodo dovra' usare circa 355Kb di memoria.
  663. Il funzionamento base di ANDNA si articola nel seguente modo:
  664. per risolvere un hostname basta calcolarsi il suo hash.
  665. L'hash non e' nient'altro che un numero e questo numero noi lo consideriamo
  666. come un IP. Il nodo che corrisponde a questo IP lo chiamiamo
  667. andna_hash_node. In pratica l'hash_node manterra' un piccolo database che
  668. associa gli hostname, che corrispondono a lui, con l'IP del nodo che ha
  669. registrato quello stesso hostname.
  670. Nodo X
  671. IP: 123.123.123.123
  672. hash( hostname: "andna.acus" ) == 11.22.33.44
  673. ||
  674. ||
  675. Nodo Y
  676. IP: 11.22.33.44
  677. { [ Database andna del nodo Y ] }
  678. {hash_11.22.33.44 ---> 123.123.123.123}
  679. Le richieste di revoca non esistono, l'hostname viene cancellato
  680. automaticamente se non viene aggiornato.
  681. 7.1 ANDNA Metalloid elements: registration recipe
  682. In realta', non e' detto che l'hash_node esista nella rete, perche' puo'
  683. essere un IP a caso tra i 2^32 IP disponibili, ed ammesso che esista puo'
  684. sempre morire e uscire dalla rete. Quindi, per garantire la funzionalita'
  685. effettiva di ANDNA, ed anche un minimo di backup, gli hostname non vengono
  686. gestiti da singoli nodi, ma da interi gnode. Il gnode che corrisponde
  687. all'hash e' l'hash_gnode, all'interno ci sara' anche l'hash_node.
  688. Poiche' gli hash_gnode possono anche non esistere al momento, viene adottata
  689. una strategia di approsimazione: viene usato il gnode che piu' si avvicina
  690. all'hash_gnode, che viene chiamato, rounded_hash_gnode, o in forma breve
  691. rounded_gnode. Ad esempio, se l'hash gnode e' il 210, il piu' vicino a lui
  692. sara' il 211 e il 209.
  693. In generale, quando si considera solamente il gnode che ha accettato una
  694. registrazione, non si fa differenza tra i due tipi e il gnode si chiama
  695. sempre hash_gnode.
  696. Per consentire un pronto recupero degli hostname quando un intero hash_gnode
  697. viene tagliato fuori da Netsukuku perdendo tutti i suoi link, o quando tutti
  698. i nodi che lo compongono muoiono, si usano dei rounded_gnode di backup.
  699. Un backup_gnode e' sempre un gnode rounded_gnode, ma mette a disposizione
  700. solo alcuni dei suoi nodi per mantenere l'informazione dell'hostname
  701. registrato.
  702. Il numero dei nodi che fanno da backup in un backup_gnode e' proporzionale
  703. al suo numero totale di nodi (seeds):
  704. if(seeds > 8) { backup_nodes = (seeds * 32) / MAXGROUPNODE ); }
  705. else { backup_nodes = seeds; }
  706. Il numero di backup_gnodes utilizzati per ogni hash_gnode e' pari a
  707. MAX_ANDNA_BACKUP_GNODES (2).
  708. 7.1.1 ANDNA hook
  709. Quando un nodo si aggancia a Netsukuku diventando parte di un hash_gnode,
  710. dovra' anche preoccuparsi di agganciarsi ad ANDNA con l'andna_hook.
  711. Con l'andna_hook si prendera' dai suoi rnode tutte le cache ed i database
  712. che i nodi di quel gnode posseggono. Ovviamente e' prima necessario che il
  713. nodo si agganci a Netsukuku.
  714. 7.1.2 Don't rob my hostname!
  715. Un nodo, prima di fare una richiesta ad ANDNA, genera una coppia di chiavi
  716. RSA, una pubblica (pub_key) ed una privata (priv_key). La dimensione della
  717. pub_key sara' limitata, per questioni di spazio.
  718. La richiesta di un hostname fatta ad ANDNA verra' firmata con la chiave
  719. privata e nella richiesta stessa sara' allegata la chiave pubblica.
  720. In questo modo il nodo potra' far certificare l'originalita' delle sue future
  721. richieste.
  722. 7.1.3 Count again
  723. Il numero massimo di hostnames che un nodo puo' registrare e' pari a 256,
  724. per prevenire la registrazione massiccia di hostnames formati da parole
  725. comuni da parte di spammer.
  726. L'unico problema in andna sarebbe quello di contare. Il sistema e'
  727. totalmente distribuito e, quindi, non si puo' tenere il conto di quanti
  728. hostname ha registrato un nodo. Esiste pero' una soluzione: introdurre un
  729. nuovo elemento, gli andna_counter_nodes.
  730. Un counter_node e' un nodo che ha un IP uguale all'hash della public key
  731. del nodo che registra gli hostname. Quindi esiste un counter_node per ogni
  732. register_node. Il counter_node si occupa di memorizzare il numero di
  733. hostname che ha registrato il register_node che gli corrisponde. Quindi,
  734. quando un hash_gnode riceve una richiesta di registrazione, prima di tutto
  735. contatta il relativo counter_node, che gli comunica quanti hostname sono
  736. gia' stati registrati dal register_node: se il nodo non ha sforato il
  737. proprio limite, allora il counter node incrementa il contatore e
  738. l'hash_gnode registra effettivamente l'hostname.
  739. L'attivazione di un counter_node avviene con la richiesta di controllo da
  740. parte dell'hash_gnode e viene mantenuta dalle successive richieste.
  741. Il meccanismo e' identico a quello dell'andna, e pertanto il register_node si
  742. deve anche preoccupare di mantenere il suo counter_node attivo seguendo le
  743. stesse regole dell'ibernazione (vedi sotto).
  744. In pratica, se il counter_node non riceve piu' richieste di controllo da
  745. parte degli hash_gnode, si disattiva, e tutti gli hostname registrati non
  746. sono piu' validi (non si possono piu' aggiornare).
  747. La stessa regola degli hash_gnode viene applicata anche al counter_node: non
  748. esistera' piu' un singolo counter_node, ma un intero gnode di counter_node,
  749. chiamato appunto counter_gnode.
  750. 7.1.4 Registration step by step
  751. Il nodo x, che vuole registrare il suo hostname, trova il gnode piu' vicino
  752. all'hash_gnode (o l'hash_gnode stesso), contatta un nodo a caso (il nodo y)
  753. di quel gnode e gli manda la richiesta.
  754. La richiesta include una public key della sua coppia di chiavi RSA che
  755. rimane valida per tutte le future richieste. Il pkt viene anche firmato con
  756. la priv_key.
  757. Il nodo y controlla di essere effettivamente nel gnode piu' vicino
  758. all'hash_node, in caso contrario rigetta la richiesta. Viene controllata
  759. anche la validita' della firma apposta nella richiesta.
  760. Il nodo y contatta il counter_gnode e gli manda l'IP, l'hostname del
  761. register_node e la copia della richiesta.
  762. Il counter verifica i dati e controlla che la firma apposta sulla richiesta
  763. sia valida, e da' l'ok.
  764. Il nodo y, dopo l'ok, accetta la richiesta, crea l'entry nel suo db
  765. annotando la data di registrazione, e manda in broadcast, all'interno del
  766. gnode, la richiesta.
  767. Gli altri nodi dell'hash_gnode che ricevono la richiesta controllano la sua
  768. validita' e la memorizzano in un'entry del loro db.
  769. A questo punto il nodo x deve solo preoccuparsi di mandare la richiesta ai
  770. backup_gnode. Quando i nodi dei backup_gnode ricevono la richiesta,
  771. controllano di essere nel range dei gnode piu' vicini, e riapplicano la
  772. stessa procedura.
  773. 7.1.5 Endless rest and rebirth
  774. Gli hash_gnode mantengono gli hostname in uno stato di ibernazione per circa
  775. 3 giorni dal momento della loro registrazione od aggiornamento.
  776. Il tempo di decadimento e' volutamente molto alto per mantenere i domini
  777. stabili. In questo modo, anche se qualcuno attacca un nodo per appropriarsi
  778. del suo dominio, dovra' aspettare 3 giorni.
  779. Quando il tempo di ibernazione si e' esaurito allora tutti gli hostname
  780. scaduti vengono cancellati e vengono sostituiti dagli altri hostname in
  781. coda.
  782. Un nodo deve mandare una richiesta di aggiornamento dei suoi hostname ogni
  783. qualvolta il suo IP cambia e in ogni caso prima dello scadere del tempo di
  784. ibernazione, in questo modo il suo hostname non sara' cancellato.
  785. Il pacchetto della richiesta di aggiornamento ha un id che indica il numero
  786. di aggiornamenti gia' mandati. Il pacchetto viene anche firmato con la
  787. chiave privata del nodo, per garantire l'autenticita' della richiesta.
  788. Il pkt viene mandato ad un nodo qualsiasi dell'hash_gnode. Quest'ultimo nodo
  789. contattera' il counter_node, mandando anche una copia della richiesta, per
  790. aggiornare le sue entry e per verificare che sia ancora attivo e che l'entry
  791. relativa all'hostname da aggiornare sia presente. In caso contrario, la
  792. richiesta di aggiornamento viene rigettata.
  793. Se tutto va bene, il nodo dell'hash_gnode manda in broadcast la richiesta
  794. di aggiornamento all'interno del suo gnode.
  795. Il register_node deve poi mandare la richiesta di aggiornamento anche ai
  796. backup_gnode.
  797. Se la richiesta di aggiornamento viene mandata troppo presto (nel primo
  798. giorno) verra' considerata invalida e sara' ignorata.
  799. 7.1.6 Hash_gnodes mutation
  800. Se un generico rounded_gnode viene scavalcato da un nuovo gnode che e' piu'
  801. vicino all'hash_gnode deve lasciargli il posto, quindi avviene un
  802. trasferimento dal vecchio rounded_gnode al nuovo.
  803. La transizione, pero', avviene in maniera semi-passiva: quando il
  804. register_node fara' l'aggiornamento dell'hostname, si rivolgera'
  805. direttamente al nuovo rounded_gnode. L'hostname presente nel vecchio
  806. rounded_gnode, non essendo piu' aggiornato, decadera'.
  807. Nel frattempo, quando ancora l'hostname non e' stato aggiornato, tutti i
  808. nodi che vogliono risolverlo troveranno il nuovo rounded_gnode come gnode
  809. piu' vicino all'hash_gnode, quindi manderanno le richieste al nuovo gnode.
  810. Il nuovo rounded_gnode, non avendo ancora il db, chiedera' al vecchio
  811. hash_gnode di dargli la sua andna_cache relativa all'hostname da risolvere.
  812. Una volta ricevuta, rispondera' al nodo che ha chiesto la risoluzione
  813. dell'hname e nel frattempo mandera' in broadcast, all'intero del suo gnode,
  814. l'andna_cache appena ottenuta. In questo modo la registrazione di
  815. quell'hostname viene automaticamente trasferita nel nuovo gnode.
  816. Per evitare che un nodo sottragga l'hostname al leggittimo proprietario
  817. prima che il trasferimento dell'andna_cache avvenga, tutti i nodi del nuovo
  818. hash_gnode, per accettare una richiesta di registrazione, controllano se
  819. quell'hostname esiste gia' in un hash_gnode vecchio: se questa condizione
  820. e' verificata avvieranno il trasferimento dell'andna_cache ed aggiungeranno
  821. il nodo che vuole registrare l'hostname nella coda.
  822. 7.1.7 Yaq: Yet another queue
  823. Ogni nodo ha la liberta' di scegliersi un qualsiasi nome host, ed anche se
  824. l'hostname e' gia' stato preso da un altro nodo, puo' sempre decidere di
  825. proseguire nella registrazione. Proseguendo, il nodo manda una richiesta al
  826. gnode che conservera' l'hostname, la richiesta viene accettata, e
  827. viene aggiunta in coda, dove massimo possono esserci MAX_ANDNA_QUEUE (5)
  828. hostname. Nell'hash_gnode il nodo viene associato al nome host che ha
  829. richiesto e viene memorizzata anche la data di richiesta.
  830. Quando l'hostname, che sta' in cima alla coda, scade, verra' sostituito
  831. automaticamente dal secondo, e cosi' via.
  832. Un nodo che vuole risolvere l'hostame, puo' anche richiedere la lista dei
  833. nodi presenti nella andna_queue. In questo modo se il primo nodo non e'
  834. raggiungibile, potra' provare a contattare gli altri.
  835. 7.8 Hostname resolution
  836. Per risolvere un hostname il nodo X deve semplicemente trovare l'hash_gnode
  837. relativo all'hostname e mandare ad un nodo a caso di quel gnode la richiesta
  838. di risoluzione.
  839. 7.8.1 Distributed cache for hostname resolution
  840. Per incrementare l'efficienza di risoluzione di hostname, si adotta una
  841. piccola strategia: un nodo, ogni volta che risolve un hostname, memorizza
  842. il risultato in una cache. Per ogni risoluzione successiva dello stesso
  843. hostname, il nodo avra' gia' il risultato nella sua cache.
  844. Poiche' nei pacchetti di risoluzione degli hostname e' indicato il tempo
  845. dell'ultima volta in cui sono stati registrati o aggiornati, un'entry nella
  846. cache scade esattamente quando l'hostname non e' piu' valido in ANDNA e deve
  847. essere aggiornato.
  848. La resolved_hnames cache e' accessibile a qualunque nodo.
  849. Un nodo X, sfruttando questa proprieta', se non ha l'hostname da risolvere
  850. nella sua cache, puo' decidere di chiedere ad un qualsiasi bnode Y scelto a
  851. caso del suo stesso gnode di risolvere per lui l'hostname desiderato.
  852. Il bnode Y, cerchera' nella sua resolved cache l'hostname e in caso di esito
  853. negativo, risolvera' l'hostname in modo standard facendo mandare la risposta
  854. al nodo X.
  855. Questo sistema previene l'overload degli hash_gnode che mantengono hostname
  856. molto famosi.
  857. 7.8.2 noituloser emantsoh esreveR
  858. Se un nodo vuole conoscere gli hostname associati a un IP, contatta
  859. direttamente il nodo che ha quell'IP.
  860. 7.9 dns wrapper
  861. Un wrapper di richieste DNS si occupera' di mandare al demone di ANDNA gli
  862. hostname da risolvere e di restituire gli IP associati ad essi.
  863. Grazie al wrapper sara' possibile usare ANDNA senza modificare alcun
  864. programma esistente: bastera' usare come server DNS il proprio computer.
  865. 8. Heavy Load: flood your ass!
  866. Le rotte settate da Netsukuku sono create col supporto nexthop, che permette
  867. ad un nodo di raggiungere un altro nodo usando piu' rotte simultaneamente
  868. (multipath), garantendo uno smistamento equo del traffico dei pkts.
  869. Lo scudo anti-flood e' una conseguenza dell'avere delle rotte
  870. multipath, ed essere collegati a piu' rnodes. Infatti, anche quando un
  871. nodo e' bombardato da un flusso di dati continuo e sostenuto, riceve
  872. quel flusso diviso in differenti rotte e differenti link, e quindi puo'
  873. sempre comunicare con altri nodi.
  874. 9. Spoof the Wired: happy kiddies
  875. Se un nodo si aggancia a Netsukuku falsificando un IP, non concludera' nulla
  876. semplicemente perche' nessun nodo sapra' come raggiungerlo, avendo gia' la
  877. rotta esatta per raggiungere il nodo originale.
  878. In secondo luogo, gli rnode non permettono un aggancio di un IP che e' gia'
  879. presente nelle mappe.
  880. 10. /dev/accessibility
  881. Il mezzo ideale per connettere i nodi tra loro e', ovviamente, il wifi, ma
  882. qualunque tipo di link che connette due nodi serve allo scopo.
  883. I cellulari sono un ottimo dispositivo, su cui far girare Netsukuku.
  884. Alcuni dei nuovi modelli usano Linux come kernel.
  885. 11. Internet compatibility
  886. Netsukuku non puo' diffondersi instantaneamente, ed e' impossibile pensare
  887. di poter migrare da Internet a Netsukuku immediatamente.
  888. Bisogna, quindi, che durante la sua iniziale diffusione, rimanga compatibile
  889. con il vecchio Internet e l'unico modo e' quello di limitare temporaneamente
  890. l'espandibilita' di Netsukuku.
  891. Un nodo che usa Netsukuku non puo' uscire su Internet perche', quando
  892. ntkd viene avviato, come default gw viene settato lo stesso indirizzo
  893. IP assegnato all'interfaccia di rete, in questo modo le classi di IP non
  894. esistono piu', e qualsiasi nodo puo' prendersi qualsiasi IP random; inoltre,
  895. dato che gli IP vengono scelti in maniera random, possono accadere molte
  896. collisioni con gli attuali IP di Internet.
  897. Per mantenere la compabilita' con Internet, Netsukuku deve essere ristretto
  898. ad una sotto classe di IP, in modo da non interferire con il default gw che
  899. esce su Internet. Allora, per non interferire in nessun modo con Internet,
  900. usiamo la classe A degli indirizzi privati per l'IPv4, e la classe
  901. Site-Local per l'IPv6.
  902. Il passaggio dal Netsukuku ristretto al Netsukuku completo e' semplice:
  903. nel momento stesso in cui un utente decide di abbandonare Internet, riavvia
  904. NetsukukuD senza l'opzione di restrizione.
  905. Ovviamente le altre classi private di IP non vengono toccate, per lasciare la
  906. possibilita' di creare una LAN con un solo gw/nodo netsukuku.
  907. 12. Implementation: let's code
  908. Il protocollo di Netsukuku non e' low-level, perche' tutto quello che deve
  909. fare e' settare le rotte nella tabella di routing del kernel, percio' il
  910. demone NetsukukuD gira in userspace.
  911. Tutto il sistema viene quindi gestito dal demone che gira su ogni nodo.
  912. NetsukukuD comunica con gli altri nodi attraverso l'udp e il tcp e setta le
  913. rotte nella tabella del kernel.
  914. Tutto il codice e' scritto in C ed e' commentato, quindi non dovrebbe essere
  915. difficile seguire il flusso del programma, in ogni caso, prima di leggere un
  916. .c e' consigliato sbirciare il relativo .h .
  917. Netsukuku.c si occupa di lanciare i thread principali.
  918. Ogni porta su cui ascolta NetsukukuD e' gestita da un demone che viene
  919. lanciato come un singolo thread. Le porte usate sono le 269-udp, 269-tcp,
  920. 271-udp, 277-udp e 277-tcp.
  921. Tutti i pacchetti ricevuti dai demoni vengono filtrati da accept.c e da
  922. request.c che grazie ad una piccola tabella prevengono eventuali attacchi
  923. di flood (accept.c e' lo stesso codice usato per patchare la vulnerabita'
  924. user-level-denial-of-service di OpenSSH). In secondo luogo vengono passati
  925. a pkts.c/pkt_exec().
  926. Quando tutti i demoni sono attivi, viene lanciato hook.c/netsukuku_hook(),
  927. il codice che gestisce l'hook alla rete.
  928. Hook.c avviera' per la prima volta il primo radar scan con
  929. radar.c/radar_scan(). Tutti i pacchetti ricevuti relativi al radar sono
  930. gestiti da radar.c/radard() e da radar.c/radar_recv_reply().
  931. Dopo l'aggancio alla rete, verra' avviato il radar_scan thread che non fara'
  932. altro che eseguire in eterno la funzione radar.c/radar_daemon(), la quale
  933. lancia un radar_scan() ogni MAX_RADAR_WAIT secondi. Quando il
  934. radar_update_map() si accorge di un cambiamento nei suoi rnode spedisce un
  935. nuovo qspn_close con qspn.c/qspn_send().
  936. Tutto il codice relativo al qspn e ai tracer_pkt si trova in qspn.c e in
  937. tracer.c.
  938. Il codice di ANDNA e' diviso in andna_cache.c, che contiene tutte le
  939. funzioni usate per gestire le relative cache e in andna.c dove risiede il
  940. codice che si occupa dei pkt del protocollo ANDNA.
  941. I socket, sockaddr, le connect, i recv(), i send, etc... sono tutte in
  942. inet.c, e vengono utilizzate da pkts.c.
  943. pkts.c si occupa di ricevere le richieste con pkt_exec() e mandarne con
  944. send_rq(), un front-end utilizzato per impacchettare e spedire la grande
  945. maggioranza delle richieste.
  946. ipv6-gmp.c usa la libreria GMP (GNU multiple precision arithmetic library)
  947. per poter manipolare i 16 byte di un IPv6 come se fossero un unico grande
  948. numero, questo e' essenziale per alcune formule che agiscono direttamente
  949. sull'IP per poter ricavare molte informazioni, infatti, in Netsukuku un IP
  950. e' un numero a tutti gli effetti.
  951. Il codice che si interfaccia al kernel per settare le rotte nella route
  952. table e per configurare un'interfaccia di rete si trova in:
  953. krnl_route.c, if.c, ll_map.c, krnl_rule.c, libnetlink.c.
  954. Route.c fa da intermediario tra il codice che gestisce il protocollo di
  955. netsukuku e tra le funzioni che comunicano con il kernel.
  956. Per quanto riguarda le mappe tutto si basa su map.c, il sorgente che
  957. si occupa di prendersi cura della mappa interna. Tutte le altre mappe si
  958. appogiano su map.c, e sono:
  959. bmap.c per la border node map, gmap.c per le mappe esterne.
  960. Per compilare il codice di Netsukuku non e' necessario usare autoconf,
  961. automake e famiglia, ma basta usare il comodo scons (http://www.scons.org).
  962. L'ultima versione del codice e' sempre disponibile sul cvs degli
  963. hinezumilabs:
  964. cvs -d :pserver:anoncvs@hinezumilabs.org:/home/cvsroot login
  965. oppure date un'occhiata da qui:
  966. http://hinezumilabs.org/cgi-bin/viewcvs.cgi/netsukuku/
  967. 13. What to do
  968. - Testare su larga scala Netsukuku ed ANDNA.
  969. - Completare i src/TODO.
  970. - Codare, codare, codare.
  971. - Varie ed eventuali.
  972. Chi vuole imbarcarsi faccia un fischio.
  973. 14. The smoked ones who made Netsukuku
  974. Andrea Lo Pumo aka AlpT <alpt@freaknet.org>
  975. Special thanks to:
  976. Valvoline the non-existent entity for the implementation advices,
  977. Newmark, the hibernated guy who helped in some ANDNA problems,
  978. Crash aka "il nipponico bionico" who takes BSD, breathes the 2.4Ghz and
  979. worship the great Disagio,
  980. Tomak aka "il magnanimo" who watches everything with his crypto eyes and
  981. talks in the unrandomish slang,
  982. Asbesto aka "l'iniziatore" who lives to destroy the old to build the new,
  983. Nirvana who exists everywhere to bring peace in your data,
  984. Ram aka "il maledetto poeta" who builds streams of null filled with the
  985. infinite,
  986. Quest who taught me to look in the Code,
  987. Martin, the immortal coder and our beloved father,
  988. Elibus, the eternal packet present in your lines,
  989. Pallotron, the biatomic super AI used to build stream of consciousness,
  990. Entropika, the Great Mother of Enea,
  991. Uscinziatu, the attentive,
  992. Shezzan, the holy bard of the two worlds,
  993. Katolaz,
  994. Gamel,
  995. ...
  996. the list goes on...
  997. V C G R A N Q E M P N E T S U K
  998. and finally thanks to all the
  999. Freaknet Medialab <www.freaknet.org>
  1000. whose we are all part, and the poetry
  1001. Poetry Hacklab <poetry.freaknet.org - poetry.homelinux.org>
  1002. --
  1003. This file is part of Netsukuku.
  1004. This text is free documentation; you can redistribute it and/or modify it
  1005. under the terms of the GNU General Public License as published by the Free
  1006. Software Foundation; either version 2 of the License, or (at your option) any
  1007. later version. For more information read the COPYING file.