Alpt | 11 Jan 00:49 2007

Re: netsukuku info

On Wed, Jan 10, 2007 at 03:52:17PM +0100, <Alessandro Ordine>:
~> Sto preparando una presentazione in inglese che tira le somme delle nostre
~> conversazioni, appena e' pronta te la mando cosi', se e' ok, la posso
~> estendere e si puo' inserire nella documentazione ufficiale.

perfetto.

~> Viphilama non e' pensata per bilanciare il carico su i link fisici ma e'
~> pensata per estendere supplire all'assenza di nodi di netsuku fisicamente
~> vicini.

si

~> Quello che mi piacerebbe fare (non mi chiedere come ;-P ) e' invece
~> costruire una rete virtuale sopra netsukuku in modo da ottimizzarla in
~> situazioni simili a quella che risolvete col "Multi-barycenter". Forse e'
~> una cazzata ma ci voglio pensare... che dici?

Capito.
Non e' un'idea malvagia, pero' devi introdurre qualche meccanismo di overlay
che sia cosciente delle rotte e della situazione della rete su cui si appoggia
l'overlay (i.e Internet).
Viphilama non credo che possa aiutare, proprio perche' cerca di essere
trasparente a Netsukuku, senza entrare nei dettagli della rete su cui si
poggia, ma sfruttando solo le coordinate fisiche.

Non so, ma si potrebbe approfondire.

Se ti interessa lavorare su problemi teorici e sul load balancing, dai anche
un'occhiata al Caustic Routing:
(Continue reading)

Alpt | 16 Jan 17:09 2007

News section added in the homepage

As the subject says ;)

http://netsukuku.freaknet.org/

--

-- 
:wq!
"I don't know nothing" The One Who reached the Thinking Matter   '.'

[ Alpt --- Freaknet Medialab ]
[ GPG Key ID 441CF0EE ]
[ Key fingerprint = 8B02 26E8 831A 7BB9 81A9  5277 BFF8 037E 441C F0EE ]
_______________________________________________
Netsukuku mailing list
Netsukuku@...
http://lists.dyne.org/mailman/listinfo/netsukuku

Andrea Imparato | 16 Jan 17:32 2007
Picon

Re: News section added in the homepage

cool :)

On 1/16/07, Alpt <alpt-6BmP915+9Ldg9hUCZPvPmw@public.gmane.org> wrote:
As the subject says ;)

http://netsukuku.freaknet.org/

--
:wq!
"I don't know nothing" The One Who reached the Thinking Matter   '.'

[ Alpt --- Freaknet Medialab ]
[ GPG Key ID 441CF0EE ]
[ Key fingerprint = 8B02 26E8 831A 7BB9 81A9  5277 BFF8 037E 441C F0EE ]
_______________________________________________
Netsukuku mailing list
Netsukuku-pma9X3FYtpzZ+VzJOa5vwg@public.gmane.org
http://lists.dyne.org/mailman/listinfo/netsukuku

_______________________________________________
Netsukuku mailing list
Netsukuku@...
http://lists.dyne.org/mailman/listinfo/netsukuku
Alpt | 12 Jan 14:23 2007

Re: numero messaggi di broadcast

On Fri, Jan 12, 2007 at 12:19:03PM +0100, <Alessandro Ordine>:
~> Andrea, non sono molto convinto di questi conti... soprattutto quella
~> moltiplicazione per 4.

Allora (mi limito a quello della moltiplicazione per 4):

Credo che sia chiaro che 32Kb e' il carico per nodo, per una discovery a
livello 0, in questa situazione.
(256 * 128 byte = 32Kb)

Ora, cosi' come e' spiegato in topology.pdf, quando passa un TP attraverso
un gnode di level 1, ogni nodo che ci sta' all'interno lo ricevera' al piu'
una volta (potrebbe ricevere una copia, che pero' scarta subito, quindi
possiamo semplicemente considerare che ogni nodo ne forwarda solo una copia.
Vedi sempre topology.pdf).

Se il livello uno, e' combinato allo stesso modo (grafo completo), allora
Phi_m sara' sempre = 256. Quindi ogni gnode riceve 256 TP, durante la
discovery. Il carico imposto ai singoli nodi e' sempre quello di un singolo
TP, quindi un singolo nodo riceve sempre 256 singoli TP e quindi 32Kb.
Questo accade anche per gli altri livelli, quindi:

  LVL 0			LVL 1		LVL 2		LVL 3
256 * 128 byte  +  256 * 128 byte +  256 * 128 byte + 256 * 128 byte =
	
	= (256 * 128) byte * 4 = 131072 byte ~= 128 Kb

~> Per quanto riguarda il caustic routing, in allegato puoi trovare un extended
~> abstract che abbiamo pubblicato ad uno student workshop in Portogallo a
~> dicembre... Si tratta sempre di alberi, bisogna vedere come vengono creati e
~> utilizzati... Fammi sapere che ne pensi

Per ora non ho molto tempo di dedicarmi alla teoria. In questa fase vorrei
solo concentrarmi nell'implementazione, quindi cerco di minimizzare il tempo
usato per altre attivita'.
Appena posso ti faccio sapere.

--

-- 
:wq!
"I don't know nothing" The One Who reached the Thinking Matter   '.'

[ Alpt --- Freaknet Medialab ]
[ GPG Key ID 441CF0EE ]
[ Key fingerprint = 8B02 26E8 831A 7BB9 81A9  5277 BFF8 037E 441C F0EE ]
_______________________________________________
Netsukuku mailing list
Netsukuku@...
http://lists.dyne.org/mailman/listinfo/netsukuku

Alpt | 11 Jan 00:43 2007

Re: numero messaggi di broadcast

On Wed, Jan 10, 2007 at 05:56:10PM +0100, <Alessandro Ordine>:
~> stavo riflettendo mentre studiavo i grafici delle simulazioni che avete
~> fatto per QSPNv2.
~> In ogni gnode, nel caso peggiore ci sono in media circa 256 pacchetti di
~> broadcast per starter node.

Consideriamo un gnode con k=256 nodi.
Nel caso peggiore, cioe' un grafo completo in cui tutti i nodi sono degli
starter node, si ha Phi_m = k.
Phi_m non indica i broadcast, ma la quantita' media di TP che passano da ciascun
nodo. Cioe', in questo caso, da ogni nodo passano in media circa 256 TP.

Un TP non e' affatto un normale broadcast, anzi non si puo' proprio chiamare
broadcast.

Se esageriamo, e facciamo si' che un singolo TP sia di 128 byte, includendo
chiavi pubbliche e tutto quello che e' possibile includere, vediamo che da
ogni nodo dovranno passare 32Kb di dati.

~> Quindi nel caso peggiore ci sono
~> 256^4=4294967296 pacchetti di broadcast nell'intera rete!!! Una caciara come
~> diciamo a Roma :-)

Non proprio. Un TP e' limitato dentro un livello,
(adesso, aggiungendo i livelli, supponiamo che le discovery vengano effettuate
contemporaneamente in tutta la rete, per la prima volta),
quindi il calcolo e' un po' piu' complicato:

	i pkt generati in un g1:
		g1=256*256	# da ogni nodo, 256 TP
	i pkt generati in tutti i g1 di tutta la rete:
	(supponendo che la rete sia di 2^32)
		gt1=g1*256^3

	poi dobbiamo considerare che in ogni livello avviene una cosa simile.
	Ma qual'e' il layout dei gnode? Usiamo un grafo completo anche in ogni
	livello. Questo sarebbe il caso peggiore.
	Quindi Phi_m sarebbe sempre 256, ma nel lvl 2, quando un TP passa
	attraverso un gnode, raggiunge tutti i nodi al piu' una volta, quindi
		g1=256*256*256
		gt1=g1*256^2
		
		g2=256*256*256*256
		gt2=g2*256

		g3=256*256*256*256*256
		gt3=g3
	
	In totale:
		gt3+gt2+gt1 == 3298534883328 ~= 3.29 * 10^12

Ora pero', pensandoci un altro po', ci accorgiamo che questi conti sono
totalmente inutili. Infatti:

	1) I TP vengono scambiati "localmente". 3298534883328 non e' il numero
	   di pkt scambiati tra tutti i nodi, ma e' il numero di pkt
	   generati/creati.
	   E' come se ogni nodo parlasse con il suo vicino e noi stessimo
	   contando il numero di pkt che si generano totalemente nella rete.
	   Ovviamente e' un numero enorme, perche' i nodi sono molti, pero'
	   il carico imposto a ogni nodo e' irrisorio: ogni nodo sta'
	   semplicemente parlando con il suo vicino.

	   In sostanza, e' sbagliato considerare i TP come pkt
	   broadcast/multicast.

	   Sempre in questo caso apocalittico, il conto che bisognerebbe fare
	   e' quello di vedere il carico imposto a ogni nodo:

	   	Prima abbiamo visto che era 32Kb per un nodo di un gnode. Ora
		consideriamo i livelli (sempre nella situazione di grafo
		completo a ogni livello).

		Da ogni gnode, passano 256 TP. Quello che importa qui e che da
		ogni nodo del gnode, ne passano pure solamente 256. Quindi il
		conto e' facile:

			32*4Kb == 128 Kb

		Quindi il carico imposto a ogni nodo, durante questa discovery
		gigante e' di 128Kb!
	
	2) Ora vediamo un po' alcune considerazioni pratiche:
	   
	   a) E' quasi impossibile che si arrivi in uno stato in cui 2^32 nodi
	      sono gia' connessi tra loro, non hanno mai fatto una discovery,
	      e tutti contemporaneamente iniziano a farla.

	      La rete, invece, cresce discretamente: prima un piccolo core,
	      poi vari nodi si agganciano, e cosi' via. L'andamento potrebbe
	      essere anche esponenziale, ma non importa.

	   b) La probabilita' che 2^32 nodi si dispongano come un grafo
	      completo (e per di piu' a ogni livello), e' quasi pari a zero ;)

a dopo
--

-- 
:wq!
"I don't know nothing" The One Who reached the Thinking Matter   '.'

[ Alpt --- Freaknet Medialab ]
[ GPG Key ID 441CF0EE ]
[ Key fingerprint = 8B02 26E8 831A 7BB9 81A9  5277 BFF8 037E 441C F0EE ]
_______________________________________________
Netsukuku mailing list
Netsukuku@...
http://lists.dyne.org/mailman/listinfo/netsukuku

Alpt | 18 Jan 13:41 2007

Re: Caustic routing

On Wed, Jan 17, 2007 at 03:33:27PM +0100, <Syst3m Crash3r 480>:
~> Spiegami come hai in mente di aumentare il throughput quando serve molta
~> banda...

il concetto di base e' uguale a quello del multipath:
usi piu' rotte, contemporaneamente, per una stessa connessione.

La differenza dal multipath sta' solo nel fatto di come le rotte vengono
scelte: il caustic routing cerca di massimizzare  l'uso di rotte disgiunte.
Due rotte sono disgiunte quando non hanno hop in comune.

Chiaramente, nel multipath normale, se usi 3 rotte che condividono molti hop,
non ottieni molti vantaggi.

Tutto deriva da questo, poi l'RFC entra nei dettagli di come queste rotte
disgiunte possono essere trovate.

Non e' una cosa nuova eh, vedi ad esempio:
http://www.hpl.hp.com/personal/Sung-Ju_Lee/abstracts/papers/icc2001b.pdf

La particolarita' del Caustic Routing e' che le rotte vengono scelte creando
un albero, ma anche questo non e' del tutto nuovo.
Ci sono molti paper a riguardo.

A dopo
--

-- 
:wq!
"I don't know nothing" The One Who reached the Thinking Matter   '.'

[ Alpt --- Freaknet Medialab ]
[ GPG Key ID 441CF0EE ]
[ Key fingerprint = 8B02 26E8 831A 7BB9 81A9  5277 BFF8 037E 441C F0EE ]
_______________________________________________
Netsukuku mailing list
Netsukuku@...
http://lists.dyne.org/mailman/listinfo/netsukuku

Alpt | 20 Jan 18:12 2007

Re: pippe mentali su netsukuku

On Fri, Jan 19, 2007 at 05:37:30PM +0100, <Alessandro Ordine>:
~> 1)Per quanto riguarda la mobilita' io penso che il trend attuale sia di
~> infischiarsene e gestirla in qualche modo a livelli piu' alti del livello 3.
~> Questo lo dico un po' per esperienza personale, un po' per articoli vari che
~> sto leggendo in questo periodo.

Si, ad esempio, si puo' usare OLSRD sopra ntk, e robe simili.

~> 2)Per quanto riguarda la gnode contiguity penso che una maniera per
~> ottimizzare la faccenda potrebbe essere cercare di assegnare gli id dei
~> gnode (del piu' alto livello) in maniera centralizzata (evitando cosi'
~> collisioni) e caso mai utilizzando forme di aggregazione. Lo so che non ti
~> piace l'idea della centralizzazione ma penso che sia solo un problema
~> filosofico perche' non credo ci siano questioni ne' dal punto di vista
~> dell'affidabilita' ne' dal punto di vista del traffico. Infatti solamente i
~> bnode dei gnode di livello 3 (se pensiamo a ipv4) dovrebbero interrgoare
~> questo(i) server.

brrr

Non e' solo una questione filosofica.
La centralizzazione non e' mai la soluzione piu' efficiente, anche se e' la
soluzione piu' semplice!
(si potrebbe anche cercare di dimostrare questo fatto. Una prima prova
intuitiva: scrivere un algoritmo distribuito e' piu' difficile rispetto allo
stesso centralizzato. Dovrebbero in qualche modo valere sempre queste
condizioni:
Kc=complessita' dell'algoritmo centralizzato
Kd=complessita' dell'algoritmo distribuito
Ec=efficienza dell'algoritmo centralizzato
Ed=efficienza dell'algoritmo distribuito

K=c*E	(L'efficienza di un algoritmo e' proporzionale alla sua complessita')

Kc < Kd,  Ec < Ed

Ovviamente non e' facile dimostrare una cosa del genere, dovresti considerare
Kolmogorov, la complessita' algoritmica (vedi Algorithimc Information Theory),
e via dicendo...
)

Cmq intuitivamente si vede subito. Un algoritmo centralizzato ti crea molti piu'
problemi a livello di efficienza.

Netsukuku deve rimanere distribuito. Se cominciamo ad aggiungere server qua e
la', si snaturalizza completamente.

Gli unici server che per ora vengono usati sono gli Entry Server (vedi
viphilama). Questi sono necessari, e svolgono un lavoro minimo.

Nota anche che Viphilama fa gia' quello che faresti con dei server
centralizzati: Viphilama permette di evitare che si creino collisioni, perche'
crea gia' una rete uniforme.

~> 3)Quando un node fa l'hooking e trova il gnode pieno abbiamo detto che crea
~> un nuovo gnode. Intendi un nuovo gnode di livello 3 uno nuovo di livello 2 e
~> cosi' via...

Si, ma non esattamente.

n cerca di hookare a g1:12 (gnode lvl 1, ID 12).
g1:12 e' pieno. 
Se pero' n confina anche con g1:16, e g1:16 e' libero, allora ovviamente hooka
con lui. In ogni caso n ha preso la mappa esterna da g1:16 e da g1:12.
Se, invece, tutti i suoi g1 confinanti fossero pieni, allora cercherebbe un g1
vuoto (guardando nella mappa esterna al livello 2).
Se tutti i g1 fossero pieni cercherebbe un g2 libero. E cosi' via...

Se non trova mai nulla di libero da lvl 1 a 2, allora quasi sicuramente troverebbe
un g3 non pieno. Se tutti i g3 fossero pieni, vorrebbe dire che l'intera rete
e' diventata satura.

~> 4)Avete mai pensato alla "local latency"? Se la procedura descritta nella
~> slide e' corretta avete mai pensato a quantificare il tempo che ciascun nodo
~> impiega a trovare il next-hop per la destinazione?? E' se questa fase di
~> lookup viene eseguita su tutti i nodi che collegano sorgente e destinazione
~> non ci mette troppo? Se introduci dei meccanismi per cui all'interno del
~> gnode i nodi intermedi cercano di raggiungere solo il bnode e non ogni volta
~> la destinazione finale semplifichi la lookup phase nei nodi intermedi, devi
~> portarti dietro pero' un informazione in piu' (l'ID del bnode!)

Intendi l' O() dell'algoritmo di lookup?
Per questo non c'e' problema. E' quasi costante, perche' c'e' gia' tutto nella
mappa:
	nella mappa posseduta da n, nella struttura di ogni (g)node D e' presente
	il gw (del livello in questione) che n deve usare per raggiungere D
	stesso.
Quindi, sono proprio pochissimi passaggi.
O meglio, e' legato al numero di livelli l, quindi sara' qualcosa del tipo O(l).

Cmq di questo non mi preoccuperei proprio.

~> 5)pensavo che ci saranno piu' o meno sparsi ovunque nodi molto
~> congestionati. Voi risolvete il problema del bilanciamento del carico
~> (usando il Caustic Routing) sostanzialmente bilanciando con il multipath il
~> carico lontano dalla destinazione. Se un nodo riceve molto carico i suoi
~> link resteranno comunque il collo di bottiglia. Infatti gli alberi che
~> costruisci col multipath convergono a D!!!

Si e' vero. Ma
	Se riceve molto carico esterno (che non genera lui e a cui non e' interessato), 
		allora il valore della qualita' del suo link cambiera',
		e quindi al prossimo update i nodi non lo considereranno come un link buono.
		Quindi i nodi non cercheranno piu' di usarlo come gw, 
		e quindi ricevera' meno carico.
	se invece il traffico e' interno
		allora gli altri nodi non lo useranno come gw,
		e potra' usare i suoi link solo per se stesso.

Ovviamente se e' in un punto cruciale (unico link tra europa-america), non
c'e' molto da fare...
--

-- 
:wq!
"I don't know nothing" The One Who reached the Thinking Matter   '.'

[ Alpt --- Freaknet Medialab ]
[ GPG Key ID 441CF0EE ]
[ Key fingerprint = 8B02 26E8 831A 7BB9 81A9  5277 BFF8 037E 441C F0EE ]
_______________________________________________
Netsukuku mailing list
Netsukuku@...
http://lists.dyne.org/mailman/listinfo/netsukuku

Alpt | 24 Jan 23:27 2007

FAQ translated in italian

CLazop has done a good job translating the FAQ in italian:

http://netsukuku.freaknet.org/index.php?pag=documentation&dir=lang/italian/faq
http://netsukuku.freaknet.org/2html/documentation/lang/italian/faq/FAQ.pdf
http://netsukuku.freaknet.org/index.php?pag=documentation&file=lang/italian/faq/FAQ

0;
--

-- 
:wq!
"I don't know nothing" The One Who reached the Thinking Matter   '.'

[ Alpt --- Freaknet Medialab ]
[ GPG Key ID 441CF0EE ]
[ Key fingerprint = 8B02 26E8 831A 7BB9 81A9  5277 BFF8 037E 441C F0EE ]
_______________________________________________
Netsukuku mailing list
Netsukuku@...
http://lists.dyne.org/mailman/listinfo/netsukuku

coЯe | 24 Jan 20:48 2007
Picon

Traduzione commenti in e if.c

Salve a tutti,
volevo dare un piccolissimo contributo iniziando a tradurre parte del 
codice commentato di netsukuku.
Ho tradotto il file "if.c" in italiano, non ho aggiunto commenti dove 
non ve ne erano.
Vi allego un file contente solo i commenti con indicato a quale funzione 
appartengono, in modo che possiate decidere voi se cestinare o 
modificare i sorgenti sul CVS. Non avendo mai partecipato ad un progetto 
open source  non so esattamente come ci si comporti, per tanto spero 
presto di contribuire sempre in maniera più utile a questa comunità.

Un saluto core
/* IT:
 * ifs_find_idx: restituisce un puntatore alla struttura dell'interfaccia
 * del dispositivo che ha indice uguale a  'dev_idx'.
 * 'ifs' è un array che mantiene la lista d'interfaccia e ha 'ifs_n' elementi.
 * EN:
 * ifs_find_idx: returns the pointer to the interface struct of the 
 * device which has the index equal to `dev_idx'.
 * `ifs' is the array which keeps the interface list and has `ifs_n' elements.
 */
interface *ifs_find_idx(interface *ifs, int ifs_n, int dev_idx)

/* IT:
 * ifs_del: rimuove dall'array 'ifs' il dispositivo che è nella posizione di
 * 'if_pos'. '*ifs_n" viene poi decrementato.
 * EN:
 * ifs_del: removes from the `ifs' array the device which is at the
 * `if_pos'th position. `*ifs_n' is then decremented.
 */
void ifs_del(interface *ifs, int *ifs_n, int if_pos)

/* IT:
 * ifs_del_byname: rimuove dal'array 'ifs' il dispositivo il quale nome
 * corrisponde a 'dev_name'
 * EN:
 * ifs_del_byname: deletes from the `ifs' array the device whose name is equal
 * to `dev_name'
 */
void ifs_del_byname(interface *ifs, int *ifs_n, char *dev_name)

/* IT:
 * ifs_del_all_name: rimuove dall'array 'ifs' tutte i dispositivi che hanno
 * un nome dispositivo che inizia con 'dev_name'. Esempio:
 * ifs_del_all_name(ifs, ifs_n, "tun") rimuove tutti i tunnel iifs
 * EN:
 * ifs_del_all_name: deleted from the `ifs' array all the device which have a
 * device name that begins with `dev_name'. For example, 
 * ifs_del_all_name(ifs, ifs_n, "tun") deletes all the tunnel iifs
 */
void ifs_del_all_name(interface *ifs, int *ifs_n, char *dev_name)

/* IT:
 * ifs_get_pos: questa stupida funzione restituisce la posizione della
 * struttura nell'array 'ifs' che ha l'elemento del dev_idx uguale al 
 * 'dev'->dev_idx. L'array 'ifs' ha 'ifs_n' membri.
 * Restituisce -1 in caso di mancata corrispondenza
 * EN:
 * ifs_get_pos: this is a stupid functions which returns the position of the
 * struct in the `ifs' array which has the dev_idx element equal to
 * `dev'->dev_idx. The `ifs' array has `ifs_n' members.
 * If it is not found -1 is returned.
 */
int ifs_get_pos(interface *ifs, int ifs_n, interface *dev)

/* IT:
 * 
 * EN:
 * get_dev: It returs the first dev it finds up and sets `*dev_ids' to the
 * device's index. On error NULL is returned.
 */
const char *get_dev(int *dev_idx) 

/* IT:
 * get_all_ifs: riempie l'array 'ifs' con tutte le interfacce di rete
 * trovate attive. L'array 'ifs' ha 'ifs_n'# membri
 * Restituisce il numero di interfacce inserite.
 * EN:
 * get_all_ifs: It fills the `ifs' array with all the network interfaces it
 * finds up. The `ifs' array has `ifs_n'# members.
 * It returns the number of filled interfaces.
 */
int get_all_up_ifs(interface *ifs, int ifs_n)

/* IT:
 * set_all_ifs: per tutte le 'ifs_n' interfacce persentu nell'array 'ifs',
 * chiama le funzioni 'set_func', passando come argomento ifs[i].dev_name.
 * (Tutte le suddette funzioni set_* possono essere usate come 'set_func').
 * Esso ritorna la somma di tutti i codici di ritorno di set_func, se il
 * valore ritornato è un valore negativo, allora alcune 'set_func' hanno dato
 * errore.
 * EN:
 * set_all_ifs: for all the `ifs_n' interfaces present in the `ifs' array, it
 * calls the `set_func' functions, passing as argument ifs[i].dev_name.
 * (All the above set_* functions can be used as `set_func').
 * It returns the sum of all each return code, of set_func, therefore if it
 * returns a negative value, some `set_func' gave an error.
 */
int set_all_ifs(interface *ifs, int ifs_n, int (*set_func)(char *dev))

/* IT:
 * if_init_all: Inizializza tutte le interfacce 'ifs_n'# presenti nell'array
 * 'ifs'. Se 'if_n' è zero restiuisce e preleva tutte le interfacce
 * correntemente attive e le immagazzina in 'new_ifs', aggiornando anche il contatore
 * 'new_ifs_n'. Inizialiazza successivamente poi questi. 
 * Nell'array 'new_ifs', che deve essere delle stesse dimensioni dell'array
 * 'ids', immagazzina tutte le interfacce, aggiornando il contatore
 * 'new_ifs_n'.
 * In caso di errore viene restituito -1.
 * EN:
 * if_init_all: it initializes all the `ifs_n'# interfaces present in the
 * `ifs' array. If `ifs_n' is zero it gets all the current up interfaces and
 * stores them in `new_ifs', updating the `new_ifs_n' counter too. Then it
 * initializes them.
 * In the `new_ifs' array, which must be at least big as the `ids' array, it
 * stores all the initialized interfaces, updating the `new_ifs_n' counter.
 * On error -1 is returned.
 */
int if_init_all(char *ifs_name[MAX_INTERFACES], int ifs_n, 

/* IT:
 * set_dev_ip: Assegna l'ip' dato all'interfaccia chiamata 'dev'
 * In caso di successo restituisce 0, altimenti -1
 * EN:
 * set_dev_ip: Assign the given `ip' to the interface named `dev'
 * On success 0 is returned, -1 otherwise.
 */
int set_dev_ip(inet_prefix ip, char *dev)

/* IT:
 * set_all_dev_ip: setta l'ip' ritornato su tutte le 'if_n'# interfacce 
 * presenti dell'array 'ifn'.
 * In caso di errore restituisce -1.
 * EN:
 * set_all_dev_ip: it sets the given `ip' to all the `ifs_n'# interfaces
 * present in the `ifs' array.
 * On error -1 is returned.
 */
int set_all_dev_ip(inet_prefix ip, interface *ifs, int ifs_n)

/* IT:
 * get_dev_ip: riceve l'ip correntemente assegnato dell'interfaccia chiamata
 * 'dev' e l'immagazzina dentro 'ip'.
 * In caso di successo è restituito 0, altrimenti -1.
 * EN:
 * get_dev_ip: fetches the ip currently assigned to the interface named `dev'
 * and stores it to `ip'.
 * On success 0 is returned, -1 otherwise.
 */
int get_dev_ip(inet_prefix *ip, int family, char *dev)

/* IT: Tutto il codice riportato qua sotto è stato rippato da
 * iproute2/iproute.c.
 * Scritto da Alexey Kuznetsov. <kuznet <at> ms2.inr.ac.ru>.
 * 
 * Leggermente modificato
 * EN:
 * All the code below this point is ripped from iproute2/iproute.c
 * written by Alexey Kuznetsov, <kuznet <at> ms2.inr.ac.ru>.
 *
 * Modified lightly
 */
static int flush_update(void)
_______________________________________________
Netsukuku mailing list
Netsukuku@...
http://lists.dyne.org/mailman/listinfo/netsukuku
Jolly Roger | 25 Jan 15:03 2007
Picon

Re: FAQ translated in italian

ciao
ragazzi controllate tutti i caratteri accentati delle faq sul sito, e sostituiteli con i relativi tag html, perchè sulla mia Ubuntu non si vedono...
Meglio renderli standard con html

Cmq bel lavoro ;)

_______________________________________________
Netsukuku mailing list
Netsukuku@...
http://lists.dyne.org/mailman/listinfo/netsukuku

Gmane