Changeset 1437

Show
Ignore:
Timestamp:
08/20/08 07:58:33 (3 months ago)
Author:
alpt
Message:

Ticket #4

Files:

Legend:

Unmodified
Added
Removed
Modified
Copied
Moved
  • netsukuku/trunk/proto/doc/andna/andna.tex

    r1423 r1437  
    133133 
    134134For this reasons, the registration of a hostname will be kept by all the nodes 
    135 of a single gnodes. This ensures the distribution and the redundancy of the 
     135of a single gnode. This ensures the distribution and the redundancy of the 
    136136database. The gnode associated to $H(h)$ is the \emph{hash gnode}, and it is 
    137137simply the gnode of level 1 of the hash node $H(h)$. We will denote the former 
     
    160160Before making a request to ANDNA, a node generates a couple of RSA keys, 
    161161i.e. a public one (\emph{pub key}) and a private (\emph{priv key}). The size of the 
    162 pub key will be limited due to reasons of space. 
     162public key will be limited due to reasons of space. 
    163163The request of a hostname made to ANDNA will be signed with the private key 
    164164and in the same request the public key will be attached. 
     
    168168\subsection{Hostnames limit} 
    169169 
    170 The maximum number of hostnames, which can be registered is 256. 
     170The maximum number of hostnames which can be registered is 256. 
    171171This limit is necessary to prevent the massive registration of hostnames, 
    172172which may lead to a overload of the ANDNA system. One its side effect is to 
    173 slow down the action of spammers, which registers thousands of common words to 
     173slow down the action of spammers, which register thousands of common words to 
    174174resell them. 
    175175 
     
    211211                The signature validity is also checked. 
    212212        \item The node $y$ contacts the counter gnode $cr(n)$ and sends to it 
    213                 the IP, the hash of th hostname to be registered and a copy of 
     213                the IP, the hash of the hostname to be registered and a copy of 
    214214                the registration request itself. 
    215215        \item $cr(n)$ checks the data and gives its ok. 
     
    219219        \item $y$ forwards to its gnode the registration request. 
    220220        \item The nodes, which receive the forwarded request, will check its 
    221                 validity and store the entry in their db
     221                validity and store the entry in their database
    222222\end{enumerate} 
    223223   
     
    233233substituted with the others in queue.\\ 
    234234A node has to send an update request for each of its hostnames, each time it 
    235 changes ip and before the hibernation time expires, in this way it'
     235changes ip and before the hibernation time expires, in this way it
    236236hostname won't be deleted. 
    237237 
     
    281281\subsection{Distributed cache for hostname resolution} 
    282282 
    283 In order to optimise the resolution of a hostname, a simple strategy is 
     283In order to optimize the resolution of a hostname, a simple strategy is 
    284284used: a node, each time it resolves a hostname, stores the result in a 
    285285cache. For each next resolution of the same hostname, the node has already 
     
    414414The register node can also choose to use an optional SNSD feature to be sure 
    415415that a SNSD hostname is always associated to its trusted machine. In this 
    416 case, the register node needs the ANDNA pubkey of the SNSD node to send a 
     416case, the register node needs the ANDNA public key of the SNSD node to send a 
    417417periodical challenge to the node. 
    418418If the node fails to reply, the register node will send to ANDNA a delete