Changeset 1437
- Timestamp:
- 08/20/08 07:58:33 (3 months ago)
- Files:
-
- netsukuku/trunk/proto/doc/andna/andna.tex (modified) (8 diffs)
Legend:
- Unmodified
- Added
- Removed
- Modified
- Copied
- Moved
netsukuku/trunk/proto/doc/andna/andna.tex
r1423 r1437 133 133 134 134 For this reasons, the registration of a hostname will be kept by all the nodes 135 of a single gnode s. This ensures the distribution and the redundancy of the135 of a single gnode. This ensures the distribution and the redundancy of the 136 136 database. The gnode associated to $H(h)$ is the \emph{hash gnode}, and it is 137 137 simply the gnode of level 1 of the hash node $H(h)$. We will denote the former … … 160 160 Before making a request to ANDNA, a node generates a couple of RSA keys, 161 161 i.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.162 public key will be limited due to reasons of space. 163 163 The request of a hostname made to ANDNA will be signed with the private key 164 164 and in the same request the public key will be attached. … … 168 168 \subsection{Hostnames limit} 169 169 170 The maximum number of hostnames ,which can be registered is 256.170 The maximum number of hostnames which can be registered is 256. 171 171 This limit is necessary to prevent the massive registration of hostnames, 172 172 which may lead to a overload of the ANDNA system. One its side effect is to 173 slow down the action of spammers, which register sthousands of common words to173 slow down the action of spammers, which register thousands of common words to 174 174 resell them. 175 175 … … 211 211 The signature validity is also checked. 212 212 \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 of213 the IP, the hash of the hostname to be registered and a copy of 214 214 the registration request itself. 215 215 \item $cr(n)$ checks the data and gives its ok. … … 219 219 \item $y$ forwards to its gnode the registration request. 220 220 \item The nodes, which receive the forwarded request, will check its 221 validity and store the entry in their d b.221 validity and store the entry in their database. 222 222 \end{enumerate} 223 223 … … 233 233 substituted with the others in queue.\\ 234 234 A 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 's235 changes ip and before the hibernation time expires, in this way its 236 236 hostname won't be deleted. 237 237 … … 281 281 \subsection{Distributed cache for hostname resolution} 282 282 283 In order to optimi se the resolution of a hostname, a simple strategy is283 In order to optimize the resolution of a hostname, a simple strategy is 284 284 used: a node, each time it resolves a hostname, stores the result in a 285 285 cache. For each next resolution of the same hostname, the node has already … … 414 414 The register node can also choose to use an optional SNSD feature to be sure 415 415 that a SNSD hostname is always associated to its trusted machine. In this 416 case, the register node needs the ANDNA pub key of the SNSD node to send a416 case, the register node needs the ANDNA public key of the SNSD node to send a 417 417 periodical challenge to the node. 418 418 If the node fails to reply, the register node will send to ANDNA a delete
