

				    Netsukuku
			
			- Close the world, txEn eht nepO -



--								

 -1. Preface

  0. The old wired

  1. The Pure Wired
  
  2. The Netsukuku wired
  
  	2.1  No name, no identity
	2.2  Gandhi
	2.3  Self Control
	2.4  So, WTF is it?
	2.5  Other implementations
  	2.6  The born
  
  3. Netukuku Protocol v7: the seventh son of Ipv7

	3.1  #define Npv7
	
  4. Npv7_II: Laser Broadcast
  
  5. Npv7 Hybrid Theory: the final way
  
  	5.1  QSPN: Quantum Shortest Path Netsukuku
  		5.1.1  QSPN screenshot
	  	5.1.2  Continual qspn starters
		5.1.3  The Qspn sickness: RequestForRoute
		5.1.4  Qspn round
		
	5.2  Npv7_HT Hook & Unhook
		5.2.1  Qspn Hook & Unhook
		
	5.3  The truly Gnode^n for n<=INFINITE
		5.3.1  Groupnode: one entity
		5.3.2  Gnode fusion
	
  6. Broadcast: There can be only one!
  
	6.1  Tracer pkt: one flood, one route
	
  7. ANDNA: Abnormal Netsukuku Domain Name Anarchy
 
 	7.1  ANDNA Metalloid elements: registration recipe
  		7.1.1  ANDNA hook
		7.1.2  Don't rob my hostname!
		7.1.3  Count again
		7.1.4  Registration step by step
		7.1.5  Endless rest and rebirth
		7.1.6  Hash_gnodes mutation
		7.1.7  Yaq: Yet another queue
		
  	7.8  Hostname resolution
		7.8.1  Distributed cache for hostname resolution
		7.8.2  noituloser emantsoh esreveR
		
	7.9  dns wrapper
	  
  8. Heavy Load: flood your ass!
  
  9. Spoof the Wired: happy kiddies
  
  10. /dev/Accessibility
  
  11. Internet compatibility
  
  12. Implementation: let's code
  
  13. What to do
  
  14. The smoked ones who made Netsukuku
  
--

 -1.  Preface

  This document and the relative source code are available on:
  http://netsukuku.freaknet.org


  0.  The old wired
  
  Internet is a hierarchic network managed by multinational companies and 
  organizations supported by governments. Each bit of Internet traffic passes
  through their backbones and routers.
  The well-deserving Internet Service Providers give the connectivity to all of
  the poor humans, who are in the lowest rank of this hierarchic pyramid,
  warranting, in this way, the global shared ownership of Internet and its
  free access, obviously, in accordance with the rightful and wise principle
  of equality. They ask, in exchange, a "small" money fee to obtain the right to
  join this network. Beside that, the information, the knowledge and
  the communication don't surely grow as spontaneous fruits on the trees.
  Thank to their generous service, about 600 million of people can be
  connected to the great, free and anonymous network.
  To the remaining 5 billion and 400 million of people, who cannot allow
  themself to this luxury, they say to try in another time, when there will be
  no more wars and the peace will rule.

  Going back to the multinationals: what will happen if one
  of them or an ISP decides to no more supply the service? The answer is
  simple: entire nations will be immediately cut out of the Internet.
  Paradoxally Internet was born with the intent of warranting a secure
  communication, unattackable between the various nodes of the network.
  And what will happen if one of these multinationals will stipulate a secret or
  public agreement with some governments to control the data traffic and trace
  back real or presumed "terrorists"? The traffic will be traced back,
  analysed and the potential "terrorists" submitted, without any restrictions,
  to unlimited controls.

  The centralised and hierarchical structure of Internet creates, as a
  consequence, other identical systems, which are based on it, i.e. the DNS
  The servers of the Domain Name Servers are managed by different ISP, as
  well, and the domains are literally sold out and the  of a centralised
  system remain unmutated.
  This kind of structure allows, in a very simple and efficient way, to
  physically localise any computers, which are connected to Internet, in a
  very short time and without any particular efforts.
  In China, the whole net is constantly watched by several computers which
  filter the Internet traffic: a Chinese will never be able to see or came to
  know about a site which contains some keywords censored by the government.
  And if he'll try to express his own ideas on the net, in spite of what the
  policy or the government is, he will risk the death penality.
  
  Internet was born to satisfy the military needs of security for the
  administration of the American defence. And during the time its basic
  structure never changed and never will change.
  Freedom of communication and information on Internet will always be denied:
  in order to communicate each other we'll always be obliged to ask the
  permission of the central authority and ask for the support of big
  multinationals, and in this way they'll continue to expand their own
  kingdom.
  If the destiny of all the efforts to make Internet the exclusive medium of
  communication is to fail, then there is no any other solution than change
  it.
  How?
  With a distributed, decentralised and fully efficient net, which will never
  be under control of any governments.
  
  1.   The Pure Wired
  
  A neural net, a web, a social network, a fishing net, are pure nets.
  The nature itself is, indeed, the universe in its whole, from the
  infinitely small to the infinitely big, are pure nets.
  
  In all the nets that can be found in nature no any centre of sorting of the
  net traffic exist. 'cause they are useless.
  The power and efficiency of this kind of nets is such because of their
  simplicity, therefore no any complications can be found in them.
  
  In a pure net every node has the function of router and then there aren't
  dedicated routers, indispensable, on the contrary, to the other hierarchic
  nets.
 
  The necessary and sufficient condition in order to consider a node belonging
  to a pure net is the connection to at least another node.
  In this way all the nodes of the net be connected to each other.
  If, for example, the node (A) (see the picture below) is sending a message
  to the node (Y), before it will send it to (C), the node (C) will send it to
  (E), then to (F) and at the end it will reach (Y).
  Let's recap: (A)-->(C)-->(E)-->(F)-->(Y).


				         (L)
				          |
				          |
			(A)----(B)-------(H)
			 |			     (T)
			 |			      |
	  (G)----(E)----(C)----(D)-------------------(S)
	          |		|
   	          |		|				  (L1)
	         (F)---(Y)--(1)	|				   |	
		 		|				   |
				|				   |
		       (R)-----(M)---------(Q)		  (Z)----(76)	
			      / | \			   |	
			    /	|   \			   |	
		       (P)/	|     \(O)----------------(U)----(V)
			  	|	|			  |
     (5)---------------------- (N)	|			  |
      |					|			  |
      |		       (9)     		|			 (X)
      |			|	       (20)
     (3)---------------(4)-----(8)
     
 				-| A possible portion of a pure net |-


  2.   The Netsukuku wired
  
  Netsukuku is a pure net which exploits the chaos, it generates and sustains
  itself autonomously, having the shape of a fractal.
  The fusion of pure net with fractals and chaos is the characteristic which
  allows to Netsukuku to be a diffused and distributed, not centralized,
  anonymous, anarchical, not controlled and autonomous net.

  2.1  No name, no identity
  
  Inside Netsukuku everyone, in any place, at any moment, ca ook immediately
  to the net without coming trough thousands bureaucratical obstacles, which
  cannot be overpassed.
  Moreover, every elements of the net is extremely dynamic and it's never the
  same. The ip address which identify a computer is chosen randomly,
  therefore it's impossible to associate it to a particular physical place,
  and the routes themselves, been composed by a huge number of node, show the
  tendence to have such a high complexity and density to make the trace of a
  node a titanic task.
  Since there isn't any contract with any organizations, the speed of the data
  transfer is uniquely limitated by the actual tecnology of the network cards.


  2.2  Gandhi

  Netsukuku is anarchical. It generates itself and can stand alone.
  A node hooks to Netsukuku, the net automatically rewrites itself and all the
  other nodes known which are the fastest and more efficient routes to
  communicate with the new arrived.
  The nodes don't have privileges or limitation, when compared with other
  nodes, they are part of the net and give their contribution to its expansion
  and efficiency.
  The more they increase in number the more the net grows and becomes perfect.
  In Netsukuku there is no any differences among private and public nets and
  talking about LAN became meaningless.

	
  2.3  Self Control

  Netsukuku can be neither controlled nor destroyed because it is totally
  decentralized and distributed. The only way to control or demolish
  Netsukuku is knocking physically down each single node which is part of it.

  Being Netsukuku a distributed and not centralised net, it is possible to
  implement real distributed systems on it, e.g. the Abnormal Netsukuku Domain
  Name Anarchy (ANDNA) which will replace the actual hierarchic and
  centralized system of DNS.
  
  2.4  So, WTF is it?
  
  Netsukuku is a mesh network or a p2p net composed by a net protocol for
  dynamic routing called Npv7_HT.
  Actually there is wide number of protocols and algorithms for the dynamic
  routing, but they differ from the Npv7_HT, 'cause they are solely utilized
  to  create small and medium nets. The routers of Internet are also managed
  by different protocols as the OSPF, the RIP, or the BGP, based on different
  classical algorithms, able to find out the best path to reach a node in the
  net.
  These protocols require a very high waste of cpu and memory, this is the
  reason why the Internet routers are computers specifically dedicated to
  this purpose. It would be impossible to implement one these protocols in
  order to create and maintain such a net as Netsukuku is, where every each
  node is a router by itself, because the map of all the routes would require
  a space, on each pc connected to the net, of about 1 hundred Gb.
  
  The Npv7 structures the entire net as a fractal and, in order to calculate
  all the needed routes which are necessary to connect a node to all the other
  nodes, it makes use of a particular algorithm called
  Quantum Shortest Path Netsukuku (QSPN).
  A fractal is a mathematical structure which can be compressed up to the
  infinite, because inside it, every part itself is composed by the same
  fractal. Thus there is a high compression of a structure which can be
  infinitely expanded. This means that we need just a few Kb to keep the whole
  Netsukuku map.
  On the other hand, the QSPN is a meta-algorithm in the sense that it
  doesn't follow any predefined mathematical instructions but exploits the
  chance and the chaos, which both don't need any computation. In other words,
  also a simple calculator can work using the QSPN to be connected to
  Netsukuku.

  2.5  Other implementations

  Netsukuku is not restricted solely to the creation of a net of computers, it
  is a protocol which implements a pure net, and alike every net protocol can
  be used in all the situations in which it's necessary to connect different
  nodes to each other.
 
  Let's take in exam the case of mobile phones. Also the mobile phone net is a
  hierarchic and centralised net. Thousands of nodes hook to a same cell,
  which will sort the traffic to the other cells and these, finally, will send
  the data to the destinator-nodes. Well, Netsukuku can be used also by
  mobile phones, making pointless the existence of all the mobile
  telecommunication companies.

  This can be applied to all the systems of communication which are used
  nowadays. 
  
  2.6  The born


  The story of how the idea of Netsukuku was born is quite a long and
  complicated story.
  In the far 2003, a crew of crazy freaks started to think about Ipv7: a net
  in which all the packets was sent in broadcasted, compressed with the zlib7,
  an algorithm which could compress all the existent Internet into just
  32 byte. In Ipv7 the nodes were devoid of an ip address. 
  In this way we could obtain an extremely decentralised and totally free net.
  Those people were really happy after the first draft of the RFC.
  One year later, the project is lost in the infinite forks of time, but after
  some time, the dust is shaked off the great Ipv7 book.
  We started to delineate the idea of the implementation of a pure net. Month
  by month the net became more and more refined, and the project became
  something concrete.
  <<But it has also to support a sort of anti-flood and anti-spoofing>>.
  <<Yep! And the main target is to make the routes always different from each
  other >>.
  <<Yea, yea, and why don't we make found out a way to abolish all the central
  servers?>>.
  Other three months passed by and after many mystical meditations, the
  theoretical kernel was ready. The algorithms were defined.
  We started to code. The curse of the protocols coders of Pharaon
  Mortedelprimogenito invaded the Netsukuku code. The delirium is the right
  reward to all those who dare to create protocols of pure nets. 
  In spite of all, exactly after one year and after fourteen thousand lines of
  code, Netsukuku Beta version was ready and immediately presented at the
  National Hackmeeting 2005 in Naples. The ANDNA was completed and
  documented. 
  What's left sleeps in our minds and still have to become.

  3.   Netsukukuku protocol v7

  Netsukuku uses its own protocol, the Npv7 (Netsukuku protocol version 7),
  which derives from three different previous versions.
  The first one was quite similar to the actual dynamic routing protocols:
  the network was in fact divided into several groups of nodes, and every
  single node had a distinct map of the entire network.
  This system, absolutely not optimal, cannot be employed by Netsukuku 'cause
  it needs continuous and subsequent updates of the early map, and each update
  will bring an overload in the net.
  Moreover, each time the map changes, it's necessary to recalculate all the
  routes.

  3.1  #define Npv7

  The basic definitions used in Netsukuku are: 

  src_node: Source node. It is the node who send a packet to the dst_node.
  dst_node: Destination node. It is the node which receives the packet from
	    the src_node.
  
  r_node: Remote node, given a node X, it is any other node directly linked to
	  X.
  g_node: Group node, a group of nodes, or a group of a group of nodes, and so
  	  on.
  b_node: Border node, a node connected to rnodes of different gnode.
  h_node: Hooking node, a node hooking to Netsukuku.
  
  int_map: Internal map. The internal map of the node X contains the
	   informations about the gnode, which the node X belongs to.
  ext_map: External map. The external map contains the informations about the
	   gnodes.
  bmap / bnode_map: Border node map. It's the map which keeps the list of
		    border_nodes.

  quadro_group: A node or a groupnode located at any level, disassembled in
	        its essential parts. 


  4.   Npv7_II: Laser Broadcast

  Npv7_II is the second version of the Npv7.
  Netsukuku is divided into many smaller groupnodes, which contains up to six
  hundred nodes each and every node will solely have an external map.
  All the groupnodes are grouped into multi-groupnodes, calle quadro
  groupnodes.
  In order to create a new route and connect to a given dst_node, the
  src_node, using the external map, firstly tries to find out the best path to
  reach the destination gnode, which the dst_node belongs to.
  In this way the founded route is stored in the pkt broadcasted inside the
  gnode, which the src_node belongs to.
  The border_nodes of the gnode of the src_node receive the pkt and check if
  the next gnode, to which the pkt has to be broadcasted, is the proper
  neighbor gnode. If the condition is true, the border_nodes broadcast the pkt
  to that same neighbor gnode. Otherwise the pkt is dropped.
  And so on...
  In this way the packet will reach the destination gnode.
  When the dst_node receives the pkt it has just to set an inverse route, using
  the route already stored in the pkt.
  The Npv7_II and its previous version are not utilised, but they are just the
  theoretical base of the Npv7_HT, the actual version of the Netsukuku
  protocol.

  5.   Npv7 Hybrid Theory: the final way

  From the union of the Npv7 and Npv7_II 
  Npv7 Hybrid Theory was born from the union of the Npv7 and Npv7_II.
  This new version, exploits the advantages of both the internal map and the
  laser broadcast and in this way it can overpass their limits.
  In Npv7_HT the maximum number of nodes, present in a group node
  (MAXGROUPNODE) is equal to 2^8, thus the groupnodes are relatively small.
  The main change in Npv7_HT is about its own essence, in fact, it's based on a
  algorithm appositely created for Netsukuku, which is called
  Quantum Shortest Path Netsukuku, which allows to obtain at once all the
  informations related to the complete situation of the gnode, all the best
  routes, the reduction of the load of the gnode, an efficient
  management of high dynamic gnodes and moreover it's not even necessary to
  authenticate each node.
  
  5.1   QSPN: Quantum Shortest Path Netsukuku


  In Netsukuku, as well as in Nature, there is no any need of using
  mathematical schemes, created by the limitated human logic.
  Netsukuku exploits the chaos.
  The use of a map, for a protocol of dynamic nets, can create a lot of
  troubles, since it has to be continuosly updated. The solution is simple: to
  avoid totally the use of maps and make every broadcasted request a
  tracer_pkt (See 6.1 Tracer pkt).
  In this way every node, which will receive the pkt, will known the best
  route to reach the src_node and all the nodes which are at the middle of the
  route itself, it will record these informations inside its internal map, it
  will add its own entry inside the tracer_pkt and will continue to broadcast
  the pkt.
  The left problem is: in order to obtain all the routes for all the nodes
  it's necessary that all the nodes broadcast a tracer_pkt. Actually this
  problem doesn't exist at all. In fact, with the tracer_pkt we can obtain
  also the routes for the middle-nodes: that means we need a smaller number
  of n packets, where n is the number of nodes.

  If every time a node receives a tracer_pkt, it sends it back to the
  src_node, in this way we are sure that all the nodes can receive all the
  possible routes. By using this system we obtain the same result achieved by
  making every node send a tracer_pkt.

  Those who already know the physic of waves, can easily understand how the
  qspn works. If we throw a pebble at a mirror of water, contained in a
  basin, circular waves begin to propagate themself from the point of impact.
  Each wave generates a child wave that continues to spread and to generate
  child waves, as well, which generate childs, and so on...
  When a wave hits the borders of the basin, it is reflected and goes back to
  the start point. The same happens if the wave meets an obstacle.
  The qspn_starter is the pebble thrown inside the groupnode and each wave is a
  tracer_pkt. Each child wave carries with itself the information of the
  parent wave. When the wave arrives at an extreme_node (an obstacle or a dead
  road), the qspn_open (the reflected wave) starts.
  
  The QSPN is based on this principle. To begin the tracing of the gnode, any
  node sends a qspn_pkt called qspn_close and then this node becomes a
  qspn_starter.
  A qspn_pkt is a normal tracer_pkt, but its broadcasting method is lightly
  different from the normal one.
  Each node, which receives a qspn_close "closes" the link the pkt was
  received and sends the pkt to all its other links. All the following
  qspn_close pkts, which will arrive to the node, will be sent to all the
  links, which have not been already closed.
  When the qspn_close is totally diffused, some nodes will have all their
  links closed. These nodes will be the extreme_nodes, which will send another
  qspn_pkt (called qspn_open) in order to reply. The qspn_open contains all
  the information already stored in the last qspn_close receveid. The
  extreme_nodes will send the qspn_open to all their links, except the one
  from which they have received the last qspn_close and to which they'll send
  an empty qspn_open.
  The qspn_open is a normal qspn_pkt, so it "opens" all the links in the same
  way of the qpsn_close. The nodes, which will have all their links opened
  will do absolutely nothing, in this way the end of the qspn_close is
  warranted.
  A qspn_open pkt has also a sub_id, a number that identifies, in the internal
  map, the extreme node, which has generated the qspn_open pkt itself. The
  sub_id, which remains unmodified in all the child qspn_open pkts, generated
  from the first packet, is used to manage simultaneusly more qspn_pkts, since
  each extreme_node generates one qspn_open and each of them has to be
  independent from the others.
  Indeed all the nodes, which have only one link, are surely e_nodes (extreme
  nodes), in fact, when they receive a qspn_close they are already closed.

  A node, after sending a qspn_open, cannot reply anymore to any qspn_pkts that
  it is going to receive and so it will send no more qspn_pkts.
  The qspn_starter, the node which has triggered the qspn, acts as a normal
  node but will not send qspn_opens, since it already sent the very first
  qspn_close. Moreover, in order to update its own map, it will use all the
  qspn_closes which are going to be received, excepting those which have been
  already sent by the qspn_starter and those which already crossed more than
  one hop. In this way, even if there is more than one qspn_starter, the
  stability is maintained. 
  The in-depth description of the qspn_starter is in the following paragraph
  5.1.1.

  At the end, the total number of packets, which are sent in broadcast are equal
  to the number of e_nodes, exactly 2 per cyclic net segment and 1 per single
  non-cyclic segment.

  Every time a tracer_pkt goes trough the net, the information about the
  crossed routes, which it carries, are stored by all the nodes which receive
  the tracer_pkt.
  A node will probably receive different routes to reach the same node, but it
  will memorize only the best MAXROUTES (10) routes. 
  
  The qspn_pkt id, which is stored in the pkt itself, is at the beginning set
  as 1 and is incremented by 1 every time a new qspn_pkt is sent by any nodes.
  Because of that, all the nodes know the current qspn_pkt id. Each time a
  node desires to globally update the internal or external map, it sends a
  qspn_close, but only if it hasn't received, in the previous QSPN_WAIT
  seconds, another qspn_close yet.
  If two nodes send, at the same time, a qspn_close, they will use the same
  pkt id 'cause they don't know that another qspn_close, with the same id, was
  already sent; in this case the way of working of the qspn doesn't change, in
  fact, if the two qspn_pkt were sent from very distant places, the qspn_pkt
  will spread more rapidly.

  When a node downloads the internal map from another node, it has to restore
  the map before making use of it. To do that the node has to just to insert the
  r_node, from which it has downloaded the map, to the beginning of all the
  routes. If the node downloads the map from more than one rnode, it will have
  to compare all the routes and choose the best one. The resulting map will
  have all the best routes.
  
  The routes of the internal and external maps will be always copied in the
  kernel routing table. In this way, it will not be necessary to create every
  time different routes to reach different destination nodes.
  
  5.1.1  QSPN screenshot
    
        (A)-----(B)
      /  | \     |  \
   (E)   |   \   |  (F)
      \  |     \ |  /
        (C)-----(D)
  
  Let's recap, then! All the extreme nodes shall send a tracer_pkt, but we
  cannot know which are they. In the above picture it's easy to point them
  out, because, indeed, they are drawn in a map, but in reality (inside the
  Netsukuku code) a topologic map doesn't exist at all, so we cannot know
  where a group of nodes begins and where it ends.
  
  This is what will happen, in a theoretical simulation, if the node E sends a
  qspn_close:
  E has sent the first qspn_close of a new qspn_round, so it is now a
  qspn_starter.
  Let's consider the case when the node A receives before C the qspn_close.
  A closes the link E and sends the pkt to B, C and D.
  C receives the pkt, closes the link E and sends it to A and D.
  C receives the pkt from A and closes the link.

  B e D have received the pkt and close the respective links.
  Let's consider the case when B sends the pkt before F.
  D, immediately, sends it to F, but at the same time F sends it to D.
  D receives the pkt from B, too.
  D and F have all the links closed.
  They send a qspn_open.
  The qspn_open propagates itself in the opposite sense.
  The qspn_open ends.
  Each node has the routes to reach all the other nodes.

  In general, the basic topology of a map for the qspn is a rhomb with the
  nodes at the vertexes, then, to have a more complex topology it's possible
  to add other rhombs united each other from the vertexes.

  5.1.2  Continual qspn starters

  If more qspn_starters, which launch a qspn, are contiguous among them, so
  the way of working of the qspn is slightly different.
  A group of qspn_starter nodes is contiguous when all its nodes are linked to
  other nodes, which are qspn_starters, as well. In this scenary the
  qspn_starters continue to mutually forward solely the qspn_closes sent by
  the qspn_starters; in fact, they acts as normal nodes, but whenever they
  receive pkts coming from outside of the contiguous group of qspn_starters,
  they follow again their basic instructions. So, if A sends a qspn_close and
  B has already sent a qspn_close, as well, when B receives the qspn_close of
  A, B forwards it as a normal tracer_pkt with the BCAST_TRACER_STARTERS flag,
  which will spread only among the other starters.
  The reason why all this happens is that in the contiguous group of nodes,
  every single node send a tracer_pkt, therefore, the qspn_pkts are
  declassified as normal tracer_pkts.

  5.1.3  The Qspn sickness: RequestForRoute
  
  /* To code, and maybe not really necessary */
  The only big hole in the qspn is the impossibility of having a vast number
  of routes in order to reach the same node. With the qspn we are sure to
  obtain just the best routes, but actually qspn can also generate uncountable
  routes, all what we need is to let the broadcast working forever, without
  interruption. Surely, it's unthinkable to wait for the eternity, that's why
  we use the RequestForRoute! The RFR will be used all the time a node gets
  connected to another node.
  This is what happens:
  the node sends to all its rnodes a RFR request for a specific route. This
  request contains also the number of sub-requests (total_routes), which the
  rnodes have to send to their rnodes. Practically, the node decides how many
  routes wants to receive and calculates the number of sub-requests, which its
  rnode will send: subrfr=(total_routes-r_node.links)/r_node.links.
  After that it sends the rfr request. After having sent the route, used to
  reach the dst_node specified inside the rfr_pkt, its rnodes sends, in the
  same way, an rfr with the number of total_routes equal to the number of
  subrfr. The rnodes of the rnodes will execute the same procedure and will
  directly answer to the requester node.
  
  5.1.4  Qspn round

  If a node finds a change around itself, e.g. one of its rnodes is dead, or
  the rtt, between it and its rnode, has considerably changed, then it will
  send a qspn. In order to avoid to continuously generate qspns the node must
  firstly verify that QSPN_WAIT_ROUND (60 seconds) has expired. The
  QSPN_WAIT_ROUND expires at the same moment for all the nodes belonging to
  the same gnode. In order to make the nodes which hook to the gnode
  synchronised to the nodes of the gnode itself, the rnodes give to the
  hooking nodes the number of seconds passed since the previous qspn, in this
  way all the nodes will know when the next deadline will be, i.e. it will be
  after (current_time-prev_qspn_round)+QSPN_WAIT_ROUND seconds.
  When a qspn_starter sends a new qspn_pkt, it increases by 1 the id of the
  qspn_round.
  If a node receiving a qspn_pkt notices that its id is greater than the
  previous already recorded qspn_round id, it means that it has received a new
  qspn_round. In this case it will update its local id and its qspn_time (the
  variable, which indicates when the last qspn has been received or sent).
  For updating the qspn_tim, it has to set it on
  current_time - sum_of_the_rtt_contained_in_the_tracer_pkt.

  5.2  Npv7_HT Hook & Unhook
 
  In order to make a node join Netsukuku, it has to be hooked to its rnodes. 
  Hook in Netsukuku doesn't refer to a physical hooking to the net, 'cause we
  assume that a node has been already physically linked to other (r)_nodes.
  The hooking of a node is the way the node communicate to its nearest rnodes,
  if it doesn't receive any answer it will choose another rnode. Practically
  during the hooking, the node gains the internal map, the external one, the
  border node map and chooses a free ip. Now it is officially a member of the
  net, therefore it sends a normal tracer_pkt and its rnodes will send, later,
  a qspn.
  
  This is in details what really happens:
  The node chooses an ip included in 10.0.0.1 <= x <= 10.0.0.1+256,
  removes the loopback nets from the routing table and sets as default gateway
  the choosen ip.
  The step number one is to launch the first radar to see what its rnodes are.
  If there are no rnodes, it creates a new gnode and the hooking ends here.
  Then it asks to nearest rnode the list of all the available free nodes
  (free_nodes) presents inside the gnode of the rnode. If the rnode rejects
  the request (the gnode might be full), the node asks for the list of another
  rnode. 
  It chooses an ip from all the received free_nodes and sets it on the network
  interface, modifying the default gw.
  The step number two is to ask the external map to the same rnode from which
  it obtained the list of free nodes. Using this list it checks if it has to
  create a new gnode. If it found it unnecessary it downloads the int_map from
  every rnode.
  Then, it joins all the received int_map into a unique map, in this way it
  knows all the routes. At the end, it gets the bnode_map.
  If everything has worked properly, it re-launch a second radar, sends a
  simple tracer_pkt and updates its routing table. Fin.
  
  5.2.1  Qspn Hook & Unhook

  After having been hooked to a gnode, what the node has to do is to send a
  tracer_pkt. In this way all the nodes will already have an exact route to
  reach it, so they will update some routes and they will be happy. Then for
  what the secondary routes may concern the match will be played at the next
  qspn round.
  When a node dies or un-hooks itself from Netsukuku, doesn't warn anyone.
  When its rnodes notice its death, they will send a new qspn round.

  5.3  The truly Gnode^n for n<=INFINITE

  In the world there are 6*10^9 people and if we colonize other planets they
  will increase to about (6*10^9)^n, where n is a random number > 0.
  It is also true that they will extinguish themself with one of the usual
  stupid war. Practically, Netsukuku has to manage a HUGE number of nodes and
  for this reason, as you already are aware, the gnodes are used.
  But they are not enough, 'cause, even using them, it would be still
  necessary to have an external and internal map of 300Mb. How can the problem
  be solved then?
  The gnodes are divided in further groups, which doesn't contain normal nodes
  but, on the contrary, whole gnodes. The contained gnodes are considered as
  single nodes... Continuing recursively with groups of groups, Netsukuku can
  contain about an infinite number of nodes with a small effort.
  The way of working of all the Netsukuku system remains unchanged.
  In order to implement the fractal gnodes we use more than one extern map,
  which will contain information about these groups of groups. A "group of
  group" is still called "groupnode".
  Every map of groupnodes belong to a specific level, thus the basic
  groupnode, which includes the single nodes, is in level 0. The map of
  the first groupnodes of groupnodes of nodes is located in level 1 and the map
  of the groupnodes of groupnodes of groupnoes is in the second level, and so
  on.
  
  A node, in order to reach any other node it must only have its internal map,
  which is the map of level 0 and all the maps of all the upper levels where
  it belongs to.
  With simple calculations, it's easy to know that to use all the IPs of the
  ipv4, the total number of levels is 3 (considering a group composed by
  MAXGROUPNODE of members). In the ipv6, instead, there are a huge number of
  IPs, therefore the number of levels if 16. A simple estimation tells us
  that, in the ipv4, all the maps needs 144K of memory, while in the ipv6
  1996K are required. 
  
  As usual, the QSPN is utilised to find all the routes, which connects the
  groupnodes. The QSPN will be restricted and started in each level, in this
  way, for example, it will find all the routes which links the gnodes
  belonging to the second level.
  The use of the levels isn't so complicated, just think about the way of
  working of the internal map, then apply it recursively to the external maps.
  Just consider every groupnode a single node.
  In order to use a route to reach a gnode, we store in the routing table
  range of ips (i.e. from ip x to ip y), instead of a single ip. In this way,
  the total number of routes necessary to reach all the nodes of Netsukuku is
  about is about MAXGROUPNODE*(levels+1). Let's take in exam the case of the
  ipv4 which has 3 levels. First of all, a node must have all the routes to
  reach every node of its groupnode at level 0, thus we have MAXGROUPNODE
  routes, then we have to add all the routes to reach the groupnodes of its
  upper level, so we add other MAXGROUPNODE routes. Continuing we arrive at
  the last level and we finally have MAXGROUPNODE*(3+1) routes. In the end we
  have 1024 routes for the ipv4 and 4352 for the ipv6. All of them are kept in
  the routing table of the kernel.
  
  5.3.1 Groupnode: one entity
  
  The real QSPN of groupnodes changes a bit.
  The difference between a groupnode and a single node is subtle: the node is
  a single entity, which maintains its links directly by itself, the
  groupnode, instead, is a node composed by more nodes and its links are
  managed by other nodes, which are the border nodes.
  In order to transform the gnode in a single entity the bnodes of the
  gnode have to communicate each other. When a bnode receives a qspn_close
  from another gnode, it closes its links, then it will communicate to the
  other bnode of the same gnode when all its links to the external gnodes are
  closed. The other bnodes, of that gnode, will do the same. In this way, the
  qspn_open will be sent only when _all_ the bnodes have all their external
  links closed.
  The situation changes again when we consider gnode of high level, because
  the bnode aren't anymore a single node but a complete gnode. The procedure
  remains the same: the bnode-gnode is formed by all its internal bnodes.
  How is possible for the bnode to communicate each other?
  Obviously they talk passively: when a bnode closes all its external links,
  having received a qspn_close, it sets in the tracer_pkt, which is going to be
  forwarded, the BNODE_CLOSED flag, in this way all the other bnodes, noticing
  that flag, will increment their counter of closed bnodes. When the number of
  closed bnodes is equal to the that of the total bnodes, which are in the same
  gnode, then the bnodes will send the qspn_open.
  One last trick: when a bnode receives a qspn_close sent from a bnode of its
  same gnode, then, it considers itself a QSPN_STARTER and forwards the
  tracer_pkt without adding its entry, that's because the gnode has to appear
  as a single node. Moreover, the bnodes close and open only the external
  links, which connect them to the bnodes of the bording gnodes.
  All this strategy is also valid for the qspn_open.

  5.3.2  Gnode fusion

  When a node creates a new group_node, it will chose it completely randomly,
  using a random ip. If two gnode, originally isolated, unfortunately have the
  same groupnode id, (and also the same range of IPs), one of them must
  change, that means to change the IPs of all the nodes of the gnode. When the
  gnode belongs to a higher level, it's a kind of disaster.
  In order to avoid all this stuff, we just need to keep the random ip unique
  all over the globe!
  The solution is simple: we use hash of time, which will be our "random" ip.
  And since we consider also the micro seconds, we'll never find two identical
  IPs.
  Every node has to maintain their clocks syncronised.

  6.   Broadcast: There can be only one!
  
  The broadcasted packet, generally, are not sent to being forwarded forever
  in Netsukuku ;). Each node keeps a cache with MAXGROUPNODE members, which is
  stored in the internal map. Each member is associated to a node of the
  gnode and it contains the pkt_id of the last pkt broadcasted from that node
  itself.
  When a broadcast pkt is received by a node, first of all, it is analysed:
  if the pkt_id is less or equal to that memorised in the cache, it will be
  dropped, because it is surely an old pkt.
  It's useless to say that the pkt_id of the broadcast pkt being sent are
  incremented by one each time. If the pkt passes the test, the node executes
  the action requested by it and forwards it to all its rnode, excluding the
  one from which it has received the pkt.
  The number of hops the broadcast pkt has to cross can also be choosen with
  the ttl (time to live) of the pkt.

  6.1  Tracer pkt: one flood, one route

  The tracer_pkt is just the way to find the best route using the broadcast.
  If the broadcasted pkt uses the "tracer_pkt" flag, then each crossed node
  will append in the pkt its ip. In this way the entire route crossed by the
  pkt is memorised in the pkt itself. The first pkt, which will arrive at
  destination, will be surely the pkt which has passed through the best route,
  therefore the dst_node will set the memorised route and it connects to the
  src_node. 
  The first tracer_pkt has also another subtle benefit, in fact, the
  tracer_pkt carries the route to reach all the nodes which are part of the
  memorised route. That is because, if the pkt has really gone through the
  best route it has also crossed _all_ the best routes for the middle hops.
  The conclusion is that a tracer_pkt can memorise the best route to reach the
  src_node, and thus all the routes to reach all the middle nodes, which have
  been crossed.
  The border_node, in order to append their ip in a tracer_pkt, set the
  "b_node" flag and adds the id of the bording gnode, but only if that gnode
  belongs to a level higher than the one where the tracer_pkt is spreading.

  In order to optimise the utilised space in a tracer_pkt, the IPs of the
  nodes are stored in the IP2MAP format, which is equivalent to the IDs of the
  nodes in the gnode of level 0. With this format only a u_char (one byte) is
  required, instead of 20.
  
  
  7.   ANDNA: Abnormal Netsukuku Domain Name Anarchy

  ANDNA is the distributed, non hierarchical and decentralised system of
  hostname management in Netsukuku. It substitutes the DNS.
  The ANDNA database is scattered inside all the Netsukuku and the worst of
  cases every node will have to use about 355 Kb of memory.
  
  ANDNA works basically in the following way:
  in order to resolve a hostname we just have to calculate its hash.
  The hash is nothing more than a number and we consider this number as an ip
  and the node related to that ip is called andna_hash_node.
  Practically the hash_node will keep a small database, which associates all
  the hostnames related to it with the ip of the node, which has registered
  the same hostnames.
  
            
	    Node X
      ip: 123.123.123.123
      hash( hostname: "andna.acus" ) == 11.22.33.44
					   ||
					   ||
					 Node Y
				     ip: 11.22.33.44
			   {	[ Andna database of the node Y ]    }
			   {hash_11.22.33.44 ---> 123.123.123.123}


  The revocation requests don't exist, the hostname is automagically deleted
  when it isn't updated.
 
  7.1  ANDNA Metalloid elements: registration recipe
  
  It is very probable that the hash_node doesn't exist at all in the net,
  'cause it can be one ip among the available 2^32 ips, and even if it is up,
  it can also die soon and exist from the net. The adopted solution to this
  ugly problem is to let the hostnames be kept by whole gnodes, in this way
  the working of the ANDNA and a minum of hostnames backup is warranted.
  The gnodes related to the hash of the hostname is the hash_gnode. Inside the
  hash_gnode there is the hash_node too.
 
  Since even the hash_gnodes cannot exist, a approximation strategy is
  utilised: the nearest gnode to the hash_gnode is the rounded_hash_gnode and
  it is consider as a normal hash_gnode. For example, if the hash_gnode is the
  210, the nearest gnode to it will be the 211 or the 209. Generally, when we
  are referring to the gnode, which has accepted a registration, there is no
  difference between the two kind of gnodes, they are always called
  hash_gnode.
  
  There are also gnodes, which backup the hash_gnode when it dies. A
  backup_gnode is always a rounded_gnode, but the number of its nodes, which
  backup the data is proportional to the total number of its nodes (seeds):
  	if(seeds > 8) { backup_nodes = (seeds * 32) / MAXGROUPNODE ); }
		else    { backup_nodes = seeds; }
  The maximum number of backup_gnodes per hostname is about
  MAX_ANDNA_BACKUP_GNODES (2). 

  7.1.1	 ANDNA hook

  When a node hooks to Netsukuku becoming automatically part of a ash_gnode,
  it will also wonder about hooking to ANDNA through the andna_hook.
  With the andna_hook it will get from its rnodes all the caches and
  databases, which are  already inside the nodes of that gnode.
  Obviously it is first necesarry the hooking of the node to Netsukuku.

  7.1.2  Don't rob my hostname!
  
  Before making a request to ANDNA, a node generates a couple of RSA keys,
  i.e. a public one (pub_key) and a private (priv_key). The size of the
  pub_key will be limitated due to reasons of space.
  The request of a ostname made to ANDNA will be signed with the private key
  and in the same request the public key will be attached.
  In this way, the node will be able to certify the true identity of its
  future requests.

  7.1.3  Count again

  The maximum number of hostnames, which can be registered is 256, in order to
  prevent the massive registration of hostnames, formed by common keyword, by
  spammers.
  The problem in ANDNA is to count. The system is completely distributed,
  therefore is cannot know how many hostnames a node has registered. However a
  there is a solution: a new element will be added, the andna_counter_node.
  A counter_node is a node with an ip equal to the hash of the public key of
  the node, which registers its hostnames, in this way there is always a
  counter_node for each register_node.
  The counter_node keeps the number of hostnames registered by the
  register_node related to it. 
  When a hash_gnode receives a registration request, it contacts the relative
  counter_node, which reply by telling how many hostnames have been registered
  by the register_node. If the register_node has not exceeded its limit, the
  counter_node will increments its counter and the hash_gnode finally register
  the hostname.
  A counter_node is activated by the check request the hash_gnode sends. The
  register_node has to keep the counter_node active following the same rules
  of the hibernation (see the chapter below). Practically, if the counter_node
  receives no more chech requests, it will deactivate itself, and all the
  registered hostnames become invalid and cannot be updated anymore.
  The same hack of the hash_gnode is used for the counter_node: there will be
  a whole gnode of counter_nodes, which is called, indeed, counter_gnode.
  
  
  7.1.4  Registration step by step

  Let's see the hostname registration step by step:
  The node x, which wants to register its hostname, finds the nearest gnode to
  the hash_gnode, contacts a random node belonging to that gnode (say the node
  y) and sends it the request.
  The request includes a public key of its key pair. which is valid for all
  the future requests. The pkt is also signed with its private key.
  The node y verifies to be effectively the nearest gnode to the hash_gnode,
  on the contrary it rejects the request. The signature validity is also
  checked. The node y contacts the counter_gnode and sends to it the ip, the
  hostname to be registered and a copy of the registration request itself.
  The counter_gnode checks the data and gives its ok.
  The node y, after the affermative reply, accepts the registration request
  and adds the entry in its database, storing the date of registration.
  Finally it forwards in broadcast, inside the its gnode, the request.
  The other nodes of the hash_gnode, which receive the forwarded request, will
  check its validity and store the entry in their db.
  At this point the node x sends the request to the backup_gnodes with the
  same procedure.
  
  7.1.5  Endless rest and rebirth

  The hash_gnode keeps the hostname in an hibernated state for about 3 days
  since the moment of their registration or update.
  The expiration time is very long to stabilise the domains. In this way, even
  if someone attacks a node to steal its domain, it will have to wait 3 days
  to fully have it.
  When the expiration time runs out, all the expired hostnames are deleted and
  substituted with the other in queue.
  A node has to send an update request for each of its hostnames, each time it
  changes ip and before the hibernation time expires, in this way it's
  hostname won't be deleted.
  The packet of the update request has an id, which is equal to the number of
  updates already sent. The pkt is also signed with the private key of the
  node to warrant the true identity of the request.
  The pkt is sent to any node of the hash_gnode, which will send a copy of the
  request to the counter_gnode, in order to verify if it is still active and
  that the entry related to the hostname being updated exists. On the
  contrary, the update request is rejected.
  If all it's ok, the node of the hash_gnode broadcasts the update request
  inside its gnode.
  The register_node has to send the update request to the backup_gnodes too.
  If the update request is sent too early it will be considered invalid and
  will be ignored.

  7.1.6  Hash_gnodes mutation
 
  If a generical rounded_gnode is overpassed by a new gnode, which is nearer
  to the hash_gnode, it will exchange its rule with that of the second one,
  and so the old rounded_gnode is transformed into the new one.
  This transition takes place passively: when the register_node will update
  its hostname, will directly contact the new rounded_gnode and since the
  hostname stored inside the old rounded_gnode is not up to date, they'll be
  dropped.
  In the while, when the hostname has not been updated, all the nodes trying
  to resolve it, will find the new rounded_gnode as the gnode nearest to the
  hash_gnode and so they'll send the requests to the new gnode.
  Since the new rounded_gnode doesn't have the database yet, it will ask to
  the old hash_gnode to let it get its andna_cache related to the hostname to
  resolve. Once it receives the cache, it will answer the node and in the
  while it will broadcast, inside its gnode, the just obtained andna_cache.
  In this way, the registration of that hostname is automatically transfered
  into the new gnode.
  In order to avoid a node to take the hostname away from the legitimate owner
  before the starting of the transfer, all the nodes of the new hash_gnode,
  will double check a registration request. In this way, they will come to
  know if that hostname already exists. In case of positive response, they
  will start the transfer of the andna_cache and they'll add the node asking for
  the hname registration in queue.
 

  7.1.7  Yaq: Yet another queue
  
  Every node is free to choose any hostname and even if the hostname has been
  already chosen by another node, by the way, it can still decide to continue
  the registration. Then, the node sends a request to the gnode which will
  keep the hostname, the request is accepted and it is added in the queue,
  which can be composed of a maximum of MAX_ANDNA_QUEUE (5) elements. 
  The node is associated to the registered hostname and with that also the
  date is kept inside the hash_gnode, 
  When a node has to resolve a hostname, contacts the hash_gnode. The node can
  also decide to utilise the other queueing IPs associated to the same
  hostname.
  
  7.8	Hostname resolution

  In order to resolve a hostname the X node has to simply find the hash_gnode
  related to the hostname itself and randomly send to any node of that gnode
  the resolution request.
  
  7.8.1  Distributed cache for hostname resolution

  In order to optimise the resolution of a hostname, a simple strategy is
  used: a node, each time it resolves a hostname, stores the result in a
  cache. For each next resolution of the same hostname, the node has already
  the result in its cache. Since in the resolution packet is written the last
  time when the hostname has been registered or updated, an entry in the cache
  expires exactly when that hostname is not valid anymore in ANDNA and has to
  be updated.
  The resolved_hnames cache is readable by any node.
  A node X, exploiting this feature, can ask to any bnode Y randomly choosen
  insied its same gnode to resolve for itself the given hostname.
  The bnode Y, will search in its resoved cache the hostname and on negative
  result the bnode will resolve it in the standard way, sending the result to
  the node X.
  These tricks avoid the overload of the hash_gnodes, which keep very famous
  hostnames.
  
  7.8.2  noituloser emantsoh esreveR

  If a node wants to know all the related hostnames associated to an ip, it
  will directly contact the node which possides that ip.

  7.9  dns wrapper

  The work of a DNS requests wrapper will be to send to the ANDNA daemon the
  hostnames to resolve and to return the IPs associated to them.
  Thanks to the wrapper it will be possible to use the ANDNA without modifying
  any preexistent programs: it will be enough to use its own computer as a dns
  server.
 
  8.   Heavy Load: flood your ass!

  The routes set by Netsukuku are created with the nexthop support, which
  allows a node to reach another node using more than one route simultaneusly
  (multipath), warranting a balanced sorting of the pkts traffic.
  The anti-flood shield is a consequence of this multipath routes system, in
  fact, also when a node is bombed by a continuous and consistent flux of
  data, it receives that flux subdivided into different routes and links,
  therefore it is always be able to communicate with other nodes.
  
  9.   Spoof the Wired: happy kiddies

  If a node hooks Netsukuku spoofing an ip, it will obtain nothing simply
  because no nodes will know how to reach it, as the exact route to reach the
  true node is already known.
  Moreover, the rnodes will not allow a hooking an ip which was already
  present inside the maps.
  
  10.  /dev/accessibility
  
  The best medium to make the nodes linked each other is, obviously, the wifi,
  but any kind of links, which connects two nodes can be used for the same
  purpose.
  The mobile phones are a great device, where Netsukuku can run.
  Some of the newest models use Linux as kernel.
  
  11.  Internet compatibility

  Netsukuku cannot instantaneusly spread and it's impossibile to imagine to
  move from the Internet to Netsukuku immediately.
  Actually, during its early phase of diffusion, we need to make it compatible
  with the old Internet and the only way is to temporarily limitate the
  growing of Netsukuku.

  A node which uses Netsukuku cannot enter inside Internet because when
  netsukuku_d is launched, the same ip address set to the network interface is
  set as default gateway, as well. In this way, all the classes of ip don't
  exist anymore and any node can take any random ip, moreover, since the are
  chosen randomly many collisions with the current Internet ip addresses may
  happen.
  
  In order to keep the compatibility with the Internet, Netsukuku has to be
  restricted to a subclass of ip, so that it doesn't interfere with the
  normal default gw for the Internet. Then we use the private A class of ip
  for the ipv4 and the Site-Local class for the ipv6.
  
  The passage from the restricted Netsukuku to the complete one is easy:
  at the same moment the user decides to abandon the Internet, he will
  restart NetsukukuD without any options of restriction.
  
  Obviously all the other private classes are not influenced, to let the user
  create a LAN with just one gw/node Netsukuku.
  
  12.  Implementation: let's code
  
  The Netsukuku protocol isn't low-level, 'cause all it has to do is to set
  the routes in the routing table of the kernel, therefore the daemon
  NetsukukuD runs in userspace.
  All the system is, in fact, maintained by the daemon, which runs on every
  node. NetsukukuD communicates with the other nodes using the tcp and the udp
  ad sets the routes in the kernel table.

  All the code is written in C and is well commented, thus it should be easy
  to follow the flux of the program, but, before reading a .c is adviced to
  peep the relative .h.
  
  The code in netsukuku.c launches the main threads.
  Every port listened by NetsukukuD is owned by a daemon, which runs as a
  single thread. The used ports are the 269-udp , 269-tcp, 271-udp, 277-udp,
  277-tcp.
  All the packets received by the daemons are filtered by accept.c and
  request.c, which avoid flood attacks using a small table. (accept.c is the
  same code used to patch the user-level-denial-of-service OpenSSH
  vulnerability). Secondly, the packets are given to pkts.c/pkt_exec().
  When all the daemons are up and running, hook.c/netsukuku_hook(), which is
  the code used to hook at Netsukuku, is called.
  
  Hook.c will launch the first radar scan calling radar.c/radar_scan().
  The radar_scan thread will then launch a radar scan every MAX_RADAR_WAIT
  seconds. When radar_update_map() notices a change in its rnodes, it sends a
  new qspn_close with qspn.c/qspn_send().
  All the code relative to the qspn and the tracer_pkts is in qspn.c and
  tracer.c

  The ANDNA code was subdivided in andna_cache.c. which contains all the
  functions used to manage the caches and in andna.c, where the code for the
  ANDNA packets is written.
  
  The sockets, sockaddr, connect,  recv(), send, etc... are all in inet.c and
  are mainly utilsed by pkts.c.
  Pkts.c is the code which receives the requests with pkt_exec() and sends
  them with send_rq(), a front end used to packet and send the majority of
  requests.
  Ipv6-gmp.c makes use of GMP (GNU multiple precision arithmetic library) in
  order to manipulate the 16 bytes of the ipv6, considering them as a unique
  big number. That is essential for some formulas, which modify directly the
  ip to know many information, in fact, in Netsukuku, an ip is truly a number.
  
  The code for the kernel interface, used to set the routes in the routing
  table and to configure a network interface is in:
  krnl_route.c, if.c, ll_map.c, krnl_rule.c, libnetlink.c.
  Route.c is the middleman between the code of the Netsukuku protocol and the
  functions which communicates with the kernel.

  The cares of the internal map are up to map.c. All the other maps are based
  on it and they are:
  bmap.c for the border node map. gmap.c for the external maps.
  
  In order to compile the Netsukuku code, it isn't necessary to use autoconf,
  automake and the others, but it's just needed the handy scons
  (http://www.scons.org).

  The latest version of the code is always available on the hinezumilabs cvs:

  cvs -d :pserver:anoncvs@hinezumilabs.org:/home/cvsroot login
  
  or give a look on the online web cvs:
  
  http://hinezumilabs.org/cgi-bin/viewcvs.cgi/netsukuku/
  
  
  13.  What to do

  - Testing on large Netsukuku and ANDNA.
  - Complete what is in src/TODO.
  - Code, code and code.
  - Something else is always necessary.

  If you wants to get on board, just blow a whistle.

  
  14.  The smoked ones who made Netsukuku

  Andrea Lo Pumo   aka   AlpT				<alpt@freaknet.org>

  
  Special thanks to:
  
  Valvoline the non-existent entity for the implementation advices,
  Newmark, the hibernated guy who helped in some ANDNA problems,
  Crash aka "il nipponico bionico" who takes BSD, breathes the 2.4Ghz and
        worship the great Disagio,
  Tomak aka "il magnanimo" who watches everything with his crypto eyes and
        talks in the unrandomish slang,
  Asbesto aka "l'iniziatore" who lives to destroy the old to build the new,
  Nirvana who exists everywhere to bring peace in your data,
  Ram aka "il maledetto poeta" who builds streams of null filled with the
	infinite,
  Quest who taught me to look in the Code,
  Martin, the immortal coder and our beloved father,
  Elibus, the eternal packet present in your lines,
  Pallotron, the biatomic super AI used to build stream of consciousness,
  Entropika, the Great Mother of Enea,
  Uscinziatu, the attentive,
  Shezzan, the holy bard of the two worlds,
  Katolaz,
  Gamel,
  ...
  the list goes on...
  V C G R A N Q E M P N E T S U K

  and finally thanks to all the
  
  Freaknet  Medialab      <www.freaknet.org>
  
  whose we are all part, and the poetry

  Poetry Hacklab          <poetry.freaknet.org - poetry.homelinux.org>
  
  
  About the translator of this document, you have to thank this great guy:
  
  Salahuddin, the hurd-nipponese old british one, which is always joyful.
  
--
This file is part of Netsukuku.
This text is free documentation; you can redistribute it and/or modify it
under the terms of the GNU General Public License as published by the Free
Software Foundation; either version 2 of the License, or (at your option) any
later version. For more information read the COPYING file.
