kytv/I2P_Website
1
0
Fork 0
forked from I2P_Developers/i2p.www
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Fix typos

Browse Source
This commit is contained in:
duck
2010-07-30 21:01:19 +00:00
parent 12d23e36f1
commit b405a810df
12 changed files with 39 additions and 39 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
www.i2p2/pages/common_structures_spec.html
View File

@ -9,7 +9,7 @@
<h2 id="type_Integer">Integer</h2>
<h4>Description</h4>
<p>
Represents a nonnegative integer.
Represents a non-negative integer.
</p>
<h4>Contents</h4>
<p>
@ -53,7 +53,7 @@ Deprecated - unused
<h2 id="type_PublicKey">PublicKey</h2>
<h4>Description</h4>
<p>
This structure is used in ElGamal encryption, representing only the exponent, not the primes, which are constant and defined in the appropiate spec.
This structure is used in ElGamal encryption, representing only the exponent, not the primes, which are constant and defined in the appropriate spec.
</p>
<h4>Contents</h4>
<p>
@ -65,7 +65,7 @@ Deprecated - unused
<h2 id="type_PrivateKey">PrivateKey</h2>
<h4>Description</h4>
<p>
This structure is used in ElGama decryption, representing only the exponent, not the primes which are constant and defined in the appropiate spec.
This structure is used in ElGamal decryption, representing only the exponent, not the primes which are constant and defined in the appropriate spec.
</p>
<h4>Contents</h4>
<p>
@ -423,7 +423,7 @@ signature :: Signature
</pre>
<h4>Notes</h4>
The signing_key is currently unused. It was intendend for LeaseSet revocation, which is unimplemented.
The signing_key is currently unused. It was intended for LeaseSet revocation, which is unimplemented.
<h4><a href="http://docs.i2p2.de/core/net/i2p/data/LeaseSet.html">Javadoc</a></h4>
@ -547,7 +547,7 @@ options :: Mapping
<h4>Notes</h4>
The peer_size Integer may be followed by a list of that many router hashes.
This is currently unused. It was intendend for a form of restricted routes, which is unimplemented.
This is currently unused. It was intended for a form of restricted routes, which is unimplemented.
<h4><a href="http://docs.i2p2.de/core/net/i2p/data/RouterInfo.html">Javadoc</a></h4>

2
www.i2p2/pages/contact.html
View File

@ -49,7 +49,7 @@ Channel list:
<h1>NNTP</h1>
<p>
You don't like mailing lists? Then this is for you.. All mailing lists are available via nntp as well.
You don't like mailing lists? Then this is for you.. All mailing lists are available via NNTP as well.
</p>
<pre>
{% filter escape %}

24
www.i2p2/pages/how_networkdatabase.html
View File

@ -79,7 +79,7 @@
</p>
<ul>
<li>1 hour average bandwidth (average of outbound and inbound bandwidth)
<li>Client and exporatory tunnel build success, reject, and timeout rates
<li>Client and exploratory tunnel build success, reject, and timeout rates
<li>1 hour average number of participating tunnels
</ul>
@ -106,7 +106,7 @@
In the current implementation, there are the following general policies:
</p>
<ul>
<li>There is no expiration during the first hour of uptime, as the perstistent stored data may be old.
<li>There is no expiration during the first hour of uptime, as the persistent stored data may be old.
<li>As the number of local RouterInfos grows, the expiration time shrinks, in an attempt to maintain
a reasonable number RouterInfos.
<li>RouterInfos containing <a href="udp.html">SSU</a> introducers expire in about an hour, as
@ -139,7 +139,7 @@
signing key, and certificate) and an additional signing and
encryption public keys. The additional encryption public key is used for end-to-end encryption of
garlic messages.
The additional signing publc key was intended for LeaseSet revocation but is currently unused.
The additional signing public key was intended for LeaseSet revocation but is currently unused.
</p>
<p>
@ -166,7 +166,7 @@
<h3 id="revoked">Revoked LeaseSets</h3>
<p>
A LeaseSet may be <i>revoked</i> by publishing a new LeaseSet with zero leases.
Revocations must be signed by the additional signing key in the leaseset.
Revocations must be signed by the additional signing key in the LeaseSet.
Revocations are not fully implemented, and it is unclear if they have any practical use.
This is the only planned use for the that signing key, so it is currently unused.
</p>
@ -178,7 +178,7 @@
by those with the key.
There is no flag or other direct indication that the LeaseSet is encrypted.
Encrypted LeaseSets are not widely used, and it is a topic for future work to
research whether the user interface and implementation of encrypted leasesets could be improved.
research whether the user interface and implementation of encrypted LeaseSets could be improved.
</p>
<h3>LeaseSet Expiration</h3>
@ -279,9 +279,9 @@
<h2 id="kad">Kademlia Closeness Metric</h2>
<p>
The netDb uses a simple Kademlia-style XOR metric to determine closeness.
The SHA256 Hash of the key being looked up or stored is XORed with
The SHA256 Hash of the key being looked up or stored is XOR-ed with
the hash of the router in question to determine closeness
(there is an additional daily keyspace rotation to increase the costs of sybil attacks,
(there is an additional daily keyspace rotation to increase the costs of Sybil attacks,
as <a href="#sybil-partial">explained below).
</p>
@ -486,7 +486,7 @@
<p>
A hostile user may attempt to harm the network by
creating one or more floodfill routers and crafting them to offer
bad, slow, or no reponses.
bad, slow, or no responses.
Some scenarios are discussed below.
</p>
@ -555,7 +555,7 @@
metrics described above, this is a difficult scenario to handle.
Tor's response can be much more nimble in the relay case, as the suspicious relays
can be manually removed from the consensus.
Some possible reponses in the I2P case, none of them satisfactory:
Some possible responses in the I2P case, none of them satisfactory:
</p>
<ul>
<li>Compile a list of bad router hashes or IPs, and announce the list through various means
@ -633,7 +633,7 @@ This attack becomes more difficult as the network size grows.
Several defenses are possible, and most of these are planned:
</p>
<ul>
<li>Switching from http to https for reseeding, with SSL certificate verification
<li>Switching from HTTP to HTTPS for reseeding, with SSL certificate verification
<li>Changing the reseed task to fetch a subset of RouterInfos from
each of several reseed sites rather than using only a single site
<li>Creating an out-of-network reseed monitoring service that
@ -664,7 +664,7 @@ This attack becomes more difficult as the network size grows.
response to a lookup,
these references are not immediately followed.
The requesting router does not trust that the references are
closer to the key (i.e. they are <i>verifiably correct</i>, and the references are not immediately queried.
closer to the key (i.e. they are <i>verifiable correct</i>, and the references are not immediately queried.
In other words, the Kademlia lookup is not iterative.
This means the query capture attack described in
<a href="http://www-users.cs.umn.edu/~hopper/hashing_it_out.pdf">Hashing it out in Public</a>
@ -685,7 +685,7 @@ This attack becomes more difficult as the network size grows.
<h2 id="history">History</h2>
<p>
<a href="netdb_discussion.html">Moved to the netdb disussion page</a>.
<a href="netdb_discussion.html">Moved to the netdb discussion page</a>.
</p>
<h2 id="future">Future Work</h2>

8
www.i2p2/pages/how_peerselection.html
View File

@ -10,7 +10,7 @@ Updated July 2010 for release 0.8
<p><b>Peer profiling</b> is the process of collecting data based on the <b>observed</b> performance
of other routers or peers, and classifying those peers into groups.
Profling does <b>not</b> use any claimed performance data published by the peer itself
Profiling does <b>not</b> use any claimed performance data published by the peer itself
in the <a href="how_networkdatabase.html">network database</a>.
<p>
@ -135,7 +135,7 @@ The size of the groups may be limited.
<li>The fast group is limited to 30 peers.
If there would be more, only the ones with the highest speed rating are placed in the group.
<li>The high capacity group is limited to 75 peers (including the fast group)
If there would be more, only the ones with the highest capactiy rating are placed in the group.
If there would be more, only the ones with the highest capacity rating are placed in the group.
<li>The standard group has no fixed limit, but is somewhat smaller than the number of RouterInfos
stored in the local network database.
On an active router in today's network, there may be about 1000 RouterInfos and 500 peer profiles
@ -163,7 +163,7 @@ The router selects peers from the above groups to build tunnels through.
Client tunnels are used for application traffic, such as for HTTP proxies and web servers.
<p>
To reduce the susceptibililty to <a href="http://blog.torproject.org/blog/one-cell-enough">some attacks</a>,
To reduce the susceptibility to <a href="http://blog.torproject.org/blog/one-cell-enough">some attacks</a>,
and increase performance,
peers for building client tunnels are chosen randomly from the smallest group, which is the "fast" group.
There is no bias toward selecting peers that were previously participants in a tunnel for the same client.
@ -180,7 +180,7 @@ These tunnels are usually low-bandwidth.
Peers for building exploratory tunnels are generally chosen randomly from the standard group.
If the success rate of these build attempts is low compared to the client tunnel build success rate,
the router will select a weighted average of peers randomly from the high capacity group instead.
This helps maintain a satisfactory build success rate even when network performace is poor.
This helps maintain a satisfactory build success rate even when network performance is poor.
There is no bias toward selecting peers that were previously participants in an exploratory tunnel.
<p>
As the standard group includes a very large subset of all peers the router knows about,

2
www.i2p2/pages/netdb_discussion.html
View File

@ -2,7 +2,7 @@
{% block title %}Network Database Discussion{% endblock %}
{% block content %}
<p>
NOTE: The following is a discussion of the history of netdb implmenetation and is not current information.
NOTE: The following is a discussion of the history of netdb implementation and is not current information.
See <a href="how_networkdatabase.html">the main netdb page</a> for current documentation</a>.
<h2><a name="status">History</a></h2>

12
www.i2p2/pages/plugin_spec.html
View File

@ -10,7 +10,7 @@ Page last updated July 2010, current as of router version 0.8.
<h3>Overview</h3>
<p>
This document specifies
a .xpi2p file format (like the firefox .xpi), but with a simple
a .xpi2p file format (like the Firefox .xpi), but with a simple
plugin.config description file instead of an XML install.rdf file.
This file format is used for both initial plugin installs and plugin updates.
<p>
@ -89,7 +89,7 @@ foo.xpi2p is a sud file containing the following:
author (yourname@mail.i2p recommended)
websiteURL (http://foo.i2p/)
updateURL (http://foo.i2p/foo.xpi2p)
The update checker will check bytes 41-56 at this url
The update checker will check bytes 41-56 at this URL
to determine whether a newer version is available
( Should the checker fetch with ?currentVersion=1.2.3?...
No. If the dev wants to have the URL contain the current version, just
@ -225,7 +225,7 @@ foo.xpi2p is a sud file containing the following:
<li>
stop existing plugin
<li>
verify install dir doesnt exist if update=false, or ask
verify install dir doesn't exist if update=false, or ask
<li>
verify install dir does exist if update=true, or ask
<li>
@ -304,7 +304,7 @@ Client start/stop notes
<p>
The router has no way to monitor the state of clients started via clients.config.
The plugin author should handle multiple start or stop calls gracefully, if at all possible,
by keeping a static state table, or using pid files, etc.
by keeping a static state table, or using PID files, etc.
Avoid logging or exceptions on multiple starts or stops.
This also goes for a stop call without a previous start.
As of router version 0.7.12-3, plugins will be stopped at router shutdown,
@ -318,7 +318,7 @@ Shell script and external program notes
<p>
To run shell scripts or other external programs, see <a href="http://zzz.i2p/topics/141">zzz.i2p</a>
<p>
To work on both windows and linux, write a small Java class that checks the OS type, then
To work on both Windows and Linux, write a small Java class that checks the OS type, then
runs ShellCommand on either the .bat or a .sh file you provide.
<p>
External programs won't be stopped when the router stops, and a second copy will
@ -367,7 +367,7 @@ context API in i2p.jar.
<li>
To run in a separate JVM, use ShellCommand with java -cp foo:bar:baz my.main.class arg1 arg2 arg3.
Of course, it will be a lot harder to stop the plugin then...
But with some trickery with pid files it should be possible.
But with some trickery with PID files it should be possible.
<li>
As an alternative to stopargs in clients.config,
a Java client may register a shutdown hook with I2PAppContext.addShutdownTask().

2
www.i2p2/pages/plugins.html
View File

@ -40,7 +40,7 @@ Benefits to i2p users and app developers:
<li>
Automatic integration and startup of webapps into console Jetty instance
<li>
Factilitate creation of 'app stores'
Facilitate creation of 'app stores'
<li>
One-click uninstall
<li>

2
www.i2p2/pages/transport.html
View File

@ -20,7 +20,7 @@ There are two transports currently implemented:
</ol>
Each provides a "connection" paradigm, with authentication,
flow control, acknowledgements and retransmission.
flow control, acknowledgments and retransmission.
<h2>Transport Services</h2>

6
www.i2p2/pages/tunnel-alt.html
View File

@ -190,7 +190,7 @@ is to find underutilized high capacity peers so that they can be promoted for
use in client tunnels.</p>
<p>
Exporatory peer selection is disucssed further on the
Exploratory peer selection is discussed further on the
<a href="how_peerselection.html">Peer Profiling and Selection page</a>.
@ -203,7 +203,7 @@ However, there are several important details beyond that basic selection that
should be adhered to, depending upon the client's anonymity needs.</p>
<p>
Client peer selection is disucssed further on the
Client peer selection is discussed further on the
<a href="how_peerselection.html">Peer Profiling and Selection page</a>.
<h4><a name="ordering">Peer Ordering within Tunnels</a></h4>
@ -212,7 +212,7 @@ Peers are ordered within tunnels to
to deal with the <a href="http://prisms.cs.umass.edu/brian/pubs/wright-tissec.pdf">predecessor
attack</a> <a href="http://prisms.cs.umass.edu/brian/pubs/wright.tissec.2008.pdf">(2008
update)</a>.
<p>To frustrate the predecgessor
<p>To frustrate the predecessor
attack, the tunnel selection keeps the peers selected in a strict order -
if A, B, and C are in a tunnel for a particular tunnel pool, the hop after A is always B, and the hop after
B is always C.

2
www.i2p2/pages/tunnel_message_spec.html
View File

@ -214,7 +214,7 @@ To Hash:
Optional, present if delivery type is DESTINATION, ROUTER, or TUNNEL
If DESTINATION, the SHA256 Hash of the destination
If ROUTER, the SHA256 Hash of the router
If TUNNEL, the SHA256 Hash of the gatweay router
If TUNNEL, the SHA256 Hash of the gateway router
Delay:
1 bytes

6
www.i2p2/pages/udp.html
View File

@ -102,7 +102,7 @@ the publicly knowable introKey is used for the MAC and encryption.</p>
<p>When using the introKey, both the initial message and any subsequent
reply use the introKey of the responder (Bob) - the responder does
not need to know the introKey of the requestor (Alice). The DSA
not need to know the introKey of the requester (Alice). The DSA
signing key used by Bob should already be known to Alice when she
contacts him, though Alice's DSA key may not already be known by
Bob.</p>
@ -165,7 +165,7 @@ packet to Charlie including Alice's public IP and port number, then sends
Alice back a RelayResponse packet containing Charlie's public IP and port
number. When Charlie receives the RelayIntro packet, he sends off a small
random packet to Alice's IP and port (poking a hole in his NAT/firewall),
and when Alice receive's Bob's RelayResponse packet, she begins a new
and when Alice receives Bob's RelayResponse packet, she begins a new
full direction session establishment with the specified IP and port.</p>
<!--
@ -341,7 +341,7 @@ Analysis of current SSU performance, including assessment of window size adjustm
and other parameters, and adjustment of the protocol implementation to improve
performance, is a topic for future work.
<p>
The current implementation repeatedly sends acknowledgements for the same packets,
The current implementation repeatedly sends acknowledgments for the same packets,
which unnecessarily increases overhead.
<p>
The Session Destroyed message is not currently implemented and is scheduled for release 0.8.1.

2
www.i2p2/pages/udp_spec.html
View File

@ -308,7 +308,7 @@ Currently unimplemented, scheduled for implementation in version 0.8.1.
<li>1 byte challenge size</li>
<li>that many bytes to be relayed to Charlie in the intro</li>
<li>Alice's intro key (so Bob can reply with Charlie's info)</li>
<li>4 byte nonce of alice's relay request</li>
<li>4 byte nonce of Alice's relay request</li>
<li>N bytes, currently uninterpreted</li>
</ul></td></tr>
<tr><td align="right" valign="top"><b>Key used:</b></td>