Development News

**
****  Theory improvements
**

The Netsukuku theory has been improved and simplified.

ChangeLog of the qspn document:
http://netsukuku.freaknet.org/2html/documentation/main_documentation/qspn.pdf

	1. The ETP has been simplified: all the cases are now just a minor adaptation
	   of a single case.
	2. Usage of the tpmask has been abolished.
	3. A simplified and distributed method to identify non disjoint routes
	   has been developed.

ChangeLog of the topology document:
http://netsukuku.freaknet.org/2html/documentation/main_documentation/topology.pdf

	1. Internal and external map structure redesigned.
	2. The bnode map is no more necessary.
	3. Flat levels simplified.
	4. The hooking procedure has been fused with the rehooking procedure.

**
****  P2P over Netsukuku
**

Netsukuku is a distributed, collaborative network of nodes. For this reason, the
development of P2P applications over Netsukuku is rather easy.

Re: Development News

* Alpt <alpt@...> [2007-08-10 01:52:24 +0200]:

> In order to ease the development of such applications, a "ntkp2p"
> library will be developed.

Thats one of the greatest idea for manipulating netsukuku and exploit
its potential. Would it be in a form of python bindings/modules? C?

> We've begun the ntkd implementation of the second version of the Netsukuku theory.

Yet more exciting news.

> This time we're working with Python, because:
> [snip...]
> 	4) we're going to use our own stripped version of Python, in this way
> 	   it will be possible to use Netsukuku in embedded devices.
> 	   See for example: http://www.areasx.com/index.php?D=1&id=8173

Would you like to elaborate a bit more about this? the page is in
italian and i can hardly gasp it.

--

-- 
Ricardo Lanziano
1DB1 3F01 E0E5 CB77 A4AC  46C2 9C9A 789B 1431 E275
UNIX is user friendly, it's just picky about who its friends are.

_______________________________________________
Netsukuku mailing list
Netsukuku@...

Re: Development News

I'm glad to hear the netsukuku project is still alive and kicking. I 
will look into the proposed goals in time.

Alpt wrote:
> 	5) the C language will be used to implement low level code.
> 

Since code in C tends to get very platform depended, it would be nice if 
you could clearly separate the architecture specific code from the 
architecture independed code right from the start of the implementation.
  IMO, portability would be a major plus for netsukuku.

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

Re: Development News

On 8/10/07, Constantine Kousoulos <wuwei@...> wrote:
> I'm glad to hear the netsukuku project is still alive and kicking. I
> will look into the proposed goals in time.
>
> Alpt wrote:
> >       5) the C language will be used to implement low level code.
> >
>
> Since code in C tends to get very platform depended,

Since when?

I disagree with this point. Anyway, for stability and rapidity purposes,
I welcome the choice of python.

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

Re: Development News

Ricardo Lanziano <ricardo.lanziano@...> scrisse:

> > http://www.areasx.com/index.php?D=1&id=8173
> 
> Would you like to elaborate a bit more about this? the page is in
> italian and i can hardly gasp it.

there are English version!

http://www.areasx.com/index.php?D=1&id=8173&lang_switch=ENG

--

-- 
Mancausoft

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

Mobile Devices

-English version at bottom-

:::::::::::::::::::::::::::ITALIAN:::::::::::::::::::::::::::::::::::::

Ciao a tutti, vi seguo da un po' ma non mi sono mai fatto vivo :p
Siccome Netsukuku è pensato per nodi "statici", quindi non del genere cellulari, ho pensato ad una
possibile implementazione per dispositivi mobili che riporto qui sotto...

-Si suddivide tutta la rete Netsukuku in 2 grossi gruppi: Nodi Statici (NS)e Nodi Mobili. (NM)*
-I NS sono normali nodi.
-I NM contengono SOLO le seguenti informazioni:
1- Nodi raggiungibili direttamente (ad 1 hop)
2- Contengono le classiche "mappe interne" del nodo a cui sono assocati. ** -vedi fondo-

-Associazione del NM (solo a NS):
-Ricerca dei punti di associazione disponibili e scelta del migliore per rapporto Banda/Latenza o
qualcosa di simile, magari considerando anche il numero di NM che un NS ha già associati... La ricerca
viene eseguita ogni secondo se non vengono trovati nodi disponibili o se ne trova uno solo, ogni 2-3
secondi se i nodi disponibili sono 2, ogni 5 sec se i nodi sono 3 e per più di 3 nodi aumentiamo a 10 secondi.
Nel caso si usino le mappe interne dei NS associati si può aumentare un pochino i tempi magari.
-Viene mandato un normale CTP che girerà la rete. questo CTP anzichè essere della forma:
IPM1---IPS2---IPS3--IPS4

dove IPS: ip di un nodo Statico e IPM: ip di un nodo mobile

sarà nella forma:
IPM1:IPS2---IPS3---IPS4

In modo che sia chiaro che per raggiungere IPM bisogna dirigersi verso IPS.
Questo aumenterà sensibilmente le dimensioni della mappa interna/esterna ma credo sia il metodo migliore.

Re: Development News

On Thu, Aug 09, 2007 at 09:38:34PM -0500, <Ricardo Lanziano>:
~> > In order to ease the development of such applications, a "ntkp2p"
~> > library will be developed.
~> 
~> Thats one of the greatest idea for manipulating netsukuku and exploit
~> its potential. Would it be in a form of python bindings/modules? C?

The module/plugin architecture has not been completely defined yet.
Generally speaking, ntkp2p will be a module/plugin of ntkd.
An application wanting to use it will be loaded as a module/plugin of ntkp2p.
--

-- 
: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

Re: Mobile Devices

On Sun, Aug 12, 2007 at 05:44:50PM +0200, <xclxljowlgur@...>:
~> Waiting a reply,

There are some problems with solution:
	1) It is implicitly assumed that a Static network is available. For
	this reason, a net composed by only mobile nodes cannot be created.
	
	2) If a MN overpass a gnode, it must change IP!

Probably point (1) cannot be easily solved, since a real mobile protocol
requires a route exploration for each bouquet of outgoing packets.

Some ideas to be further explored:
	1) Use olsr, or something equivalent, to let mobile nodes talk each
	other. Then, NAT each "mobile group"/swarm into a single node.

	2) A single, internally connected, swarm won't assume any IP.
	   Suppose a node N sends a packet directed to a Static Node D.
	   The pkt will be routed by the swarm to the nearest static gw G.
	   G will route the packet to D, but will change the pkt's src IP with
	   its own IP, i.e. it is applying the NAT rule.
	   D will then reply to G.
	   If the swarm is still in contact with G, then the pkt will be
	   simply routed back to N.
	   Otherwise, suppose the swarm is now in contact with N', and not
	   anymore with N.
	   N' tells N that it is the new SG of the swarm:
	   	when the swarm meets N', it will send to N, and to all the
		previous SG, a pkt that lists all the new SG (in this case, N'
		will be in the list)[1]

15+16.9 Wireless Community Weekend Graz

hi,

this is an open invitation for:

https://wiki.graz.funkfeuer.at/WirelessCommunityWeekend

Free Network Initiatives from different parts of Europe meet to share
expieriences and to discuss about collective projects and visions.
Another focus will be recent developements in mesh routing protocolls.
Developers of several Projects will report about the latest research
findings and encourage discussion. 15th - 16th September 2007, 14-22h

scheduled Program (WIP!)

Fr, 14.9

    * day of arrival, informal evening round, Accomodations

Sa, 15.9

    * 14h: Opening, overview of programm + ressources
    * 15h: presentation of initiatives
    * 16h: authenticating IP addresses, IPSec-AH (otti/friedl/equinox?)
    * 17-21h: Routing Protocolls
          o o BATMAN: Axel Neumann
          o o OLSR: Aaron Kaplan, Hannes Gredler
          o o ?NETSUKUKU: Freaknet (tbc!!)?
    * 21:30h: Lecture/Discussion Armin Medosch
          o o 100 years wireless hacking

Re: Mobile Devices

 Alpt wrote:
> There are some problems with solution:
> 	1) It is implicitly assumed that a Static network is available. For
> 	this reason, a net composed by only mobile nodes cannot be created.
well, yes... but a net composed only by mobiles would mean more bandwith/cpu usage...
if this is not a real problem then i think it's not impossible for netsukuku to get there...
> 	
> 	2) If a MN overpass a gnode, it must change IP!
>   
Right, my fault.
>
> Some ideas to be further explored:
> [...]
>   

My idea was not really NAT. the LTP idea works like this: (let's stay in the same gnode for now)
-node 1, connected to node 2, moves onto node 3.
-node 1 send a TP that lasts 5 hops and remains in the same gnode of node 2. this TP contains just the info "node 1
moved to node 3"
now when node 4 want to contact node 1, he looks at his map and sees that node1 is at node2 (he didn't receive the LTP).
-node 4 sends a packet to node1.
-the nodes in the pkt-route route the pkt towards node2.
-when the pkt arrives at 5 hops from node2, the nodes are aware that node1 is now at node3, not node2, so they
route it towards node3.
-packet arrives.
So, more hops in the LTP means more efficent routes and more reliability, but more bandwith used.
This differs from nat because nat involves a single node: what if the node goes down? also, nat  has some
problems with incoming connections...

What if something like this is done: