I2P_Developers/i2p.www
3
0
Fork 5
Code Issues 27 Pull Requests Actions 1 Packages Projects Releases Wiki Activity

merge of '7b832dcf53a4af35d42c8fba4cd39ff3dffd5349'

Browse Source 
and '92f2e25b6565275877be8f416e37dd17ef4133ab'
This commit is contained in:
HungryHobo
2010-09-20 04:20:02 +00:00
parent 6b547f0245 8871eb126b
commit 0af16e569f
78 changed files with 8921 additions and 1641 deletions
Download Patch File Download Diff File Expand all files Collapse all files

732
www.i2p2/image_design/i2ptunnel_peertopeer.svg Normal file
View File

@ -0,0 +1,732 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<svg
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:cc="http://creativecommons.org/ns#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:svg="http://www.w3.org/2000/svg"
xmlns="http://www.w3.org/2000/svg"
xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
width="7cm"
height="7cm"
viewBox="102 159 129 139"
id="svg3091"
version="1.1"
inkscape:version="0.47pre4 r22446"
sodipodi:docname="i2ptunnel_peertopeer.svg"
inkscape:export-filename="/home/mathias/Documents/I2P/i2p.www/www.i2p2/static/images/i2ptunnel_peertopeer.png"
inkscape:export-xdpi="49.999134"
inkscape:export-ydpi="49.999134">
<metadata
id="metadata3257">
<rdf:RDF>
<cc:Work
rdf:about="">
<dc:format>image/svg+xml</dc:format>
<dc:type
rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
<dc:title></dc:title>
</cc:Work>
</rdf:RDF>
</metadata>
<defs
id="defs3255">
<marker
inkscape:stockid="Arrow1Lend"
orient="auto"
refY="0.0"
refX="0.0"
id="Arrow1Lend"
style="overflow:visible;">
<path
id="path4394"
d="M 0.0,0.0 L 5.0,-5.0 L -12.5,0.0 L 5.0,5.0 L 0.0,0.0 z "
style="fill-rule:evenodd;stroke:#000000;stroke-width:1.0pt;marker-start:none;"
transform="scale(0.8) rotate(180) translate(12.5,0)" />
</marker>
<inkscape:perspective
sodipodi:type="inkscape:persp3d"
inkscape:vp_x="0 : 124.01575 : 1"
inkscape:vp_y="0 : 1000 : 0"
inkscape:vp_z="248.03149 : 124.01575 : 1"
inkscape:persp3d-origin="124.01575 : 82.677165 : 1"
id="perspective3259" />
<inkscape:perspective
id="perspective3524"
inkscape:persp3d-origin="0.5 : 0.33333333 : 1"
inkscape:vp_z="1 : 0.5 : 1"
inkscape:vp_y="0 : 1000 : 0"
inkscape:vp_x="0 : 0.5 : 1"
sodipodi:type="inkscape:persp3d" />
<inkscape:perspective
id="perspective3597"
inkscape:persp3d-origin="0.5 : 0.33333333 : 1"
inkscape:vp_z="1 : 0.5 : 1"
inkscape:vp_y="0 : 1000 : 0"
inkscape:vp_x="0 : 0.5 : 1"
sodipodi:type="inkscape:persp3d" />
<inkscape:perspective
id="perspective2900"
inkscape:persp3d-origin="0.5 : 0.33333333 : 1"
inkscape:vp_z="1 : 0.5 : 1"
inkscape:vp_y="0 : 1000 : 0"
inkscape:vp_x="0 : 0.5 : 1"
sodipodi:type="inkscape:persp3d" />
<inkscape:perspective
id="perspective2900-5"
inkscape:persp3d-origin="0.5 : 0.33333333 : 1"
inkscape:vp_z="1 : 0.5 : 1"
inkscape:vp_y="0 : 1000 : 0"
inkscape:vp_x="0 : 0.5 : 1"
sodipodi:type="inkscape:persp3d" />
<inkscape:perspective
id="perspective3011"
inkscape:persp3d-origin="0.5 : 0.33333333 : 1"
inkscape:vp_z="1 : 0.5 : 1"
inkscape:vp_y="0 : 1000 : 0"
inkscape:vp_x="0 : 0.5 : 1"
sodipodi:type="inkscape:persp3d" />
<inkscape:perspective
id="perspective3036"
inkscape:persp3d-origin="0.5 : 0.33333333 : 1"
inkscape:vp_z="1 : 0.5 : 1"
inkscape:vp_y="0 : 1000 : 0"
inkscape:vp_x="0 : 0.5 : 1"
sodipodi:type="inkscape:persp3d" />
<inkscape:perspective
id="perspective3036-4"
inkscape:persp3d-origin="0.5 : 0.33333333 : 1"
inkscape:vp_z="1 : 0.5 : 1"
inkscape:vp_y="0 : 1000 : 0"
inkscape:vp_x="0 : 0.5 : 1"
sodipodi:type="inkscape:persp3d" />
<inkscape:perspective
id="perspective5025"
inkscape:persp3d-origin="0.5 : 0.33333333 : 1"
inkscape:vp_z="1 : 0.5 : 1"
inkscape:vp_y="0 : 1000 : 0"
inkscape:vp_x="0 : 0.5 : 1"
sodipodi:type="inkscape:persp3d" />
</defs>
<sodipodi:namedview
pagecolor="#ffffff"
bordercolor="#666666"
borderopacity="1"
objecttolerance="10"
gridtolerance="10"
guidetolerance="10"
inkscape:pageopacity="0"
inkscape:pageshadow="2"
inkscape:window-width="1280"
inkscape:window-height="726"
id="namedview3253"
showgrid="false"
inkscape:zoom="0.95149207"
inkscape:cx="-64.635323"
inkscape:cy="179.6227"
inkscape:window-x="0"
inkscape:window-y="25"
inkscape:window-maximized="1"
inkscape:current-layer="svg3091" />
<g
id="g3093"
transform="translate(-124.27542,48.29661)">
<path
style="fill:#b7b79d"
d="m 170.897,186.814 39.968,0 0,7.386 -39.968,0 0,-7.386 z"
id="path3095" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 170.897,186.814 39.968,0 0,7.386 -39.968,0 0,-7.386"
id="path3097" />
<path
style="fill:#c9c9b6"
d="m 170.897,186.814 4.238,-4.018 39.968,0 -4.238,4.018 -39.968,0 z"
id="path3099" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 170.897,186.814 4.238,-4.018 39.968,0 -4.238,4.018 -39.968,0"
id="path3101" />
<path
style="fill:none;stroke:#000000;stroke-width:2.11999989"
d="m 208.63,190.176 -9.591,0"
id="path3103" />
<path
style="fill:#7a7a5a"
d="m 210.865,194.2 4.238,-4.25 0,-7.154 -4.238,4.018 0,7.386 z"
id="path3105" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 210.865,194.2 4.238,-4.25 0,-7.154 -4.238,4.018 0,7.386"
id="path3107" />
<path
style="fill:#c9c9b6"
d="m 171.123,198.885 4.459,-5.585 30.819,0 -4.459,5.585 -30.819,0 z"
id="path3109" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 171.123,198.885 4.459,-5.585 30.819,0 -4.459,5.585 -30.819,0"
id="path3111" />
<path
style="fill:#7a7a5a"
d="m 201.942,200 4.459,-4.685 0,-2.015 -4.459,5.585 0,1.115 z"
id="path3113" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 201.942,200 4.459,-4.685 0,-2.015 -4.459,5.585 0,1.115"
id="path3115" />
<path
style="fill:#b7b79d"
d="m 171.123,198.885 30.819,0 0,1.115 -30.819,0 0,-1.115 z"
id="path3117" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 171.123,198.885 30.819,0 0,1.115 -30.819,0 0,-1.115"
id="path3119" />
<path
style="fill:#000000"
d="m 176.923,185.926 3.357,-3.13 28.35,0 -3.117,3.13 -28.59,0 z"
id="path3121" />
<path
style="fill:none;stroke:#000000;stroke-width:0.02"
d="m 176.923,185.926 3.357,-3.13 28.35,0 -3.117,3.13 -28.59,0"
id="path3123" />
<path
style="fill:#c9c9b6"
d="m 176.696,162.903 3.136,-2.903 28.363,0 -3.136,2.903 -28.363,0 z"
id="path3125" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 176.696,162.903 3.136,-2.903 28.363,0 -3.136,2.903 -28.363,0"
id="path3127" />
<path
style="fill:#b7b79d"
d="m 176.696,162.903 28.59,0 0,22.569 -28.59,0 0,-22.569 z"
id="path3129" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 176.696,162.903 28.577,0 0,22.563 -28.577,0 0,-22.563"
id="path3131" />
<path
style="fill:#ffffff"
d="m 179.152,165.8 23.672,0 0,17.437 -23.672,0 0,-17.437 z"
id="path3133" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 179.152,165.8 23.672,0 0,17.43 -23.672,0 0,-17.43"
id="path3135" />
<path
style="fill:#7a7a5a"
d="m 205.059,185.258 3.136,-3.13 0,-22.128 -3.136,2.903 0,22.355 z"
id="path3137" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 205.059,185.258 3.136,-3.13 0,-22.128 -3.136,2.903 0,22.355"
id="path3139" />
</g>
<g
id="g3219"
transform="translate(134.87712,28.099763)">
<path
style="fill:#b7b79d"
d="m 139.83,178.978 0,37.022 21.882,0 0,-37.022 -21.882,0 z"
id="path3221" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 139.83,178.978 0,37.022 21.882,0 0,-37.022 -21.882,0"
id="path3223" />
<path
style="fill:#c9c9b6"
d="m 139.83,178.978 2.965,-2.978 21.875,0 -2.958,2.978 -21.882,0 z"
id="path3225" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 139.83,178.978 2.965,-2.978 21.731,0"
id="path3227" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 164.526,176.151 -2.814,2.827 -21.882,0"
id="path3229" />
<path
style="fill:#c9c9b6"
d="m 141.178,181.132 9.995,0 0,4.857 -9.995,0 0,-4.857 z"
id="path3231" />
<path
style="fill:none;stroke:#626248;stroke-width:0.02"
d="m 141.178,181.132 9.989,0 0,4.85 -9.989,0 0,-4.85"
id="path3233" />
<path
style="fill:none;stroke:#ecece7;stroke-width:0.60000002"
d="m 142.527,183.567 7.01,0"
id="path3235" />
<path
style="fill:#7a7a5a"
d="m 161.712,216 2.958,-2.985 0,-37.015 -2.958,2.978 0,37.022 z"
id="path3237" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 161.712,216 2.814,-2.834"
id="path3239" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 164.526,176.151 -2.814,2.827 0,37.022"
id="path3241" />
<path
style="fill:none;stroke:#ecece7;stroke-width:0.60000002"
d="m 140.105,213.559 21.6,0"
id="path3243" />
<path
style="fill:none;stroke:#000000;stroke-width:0.60000002"
d="m 140.105,193.837 21.6,0"
id="path3245" />
<path
style="fill:none;stroke:#494936;stroke-width:0.60000002"
d="m 139.83,213.29 21.855,0"
id="path3247" />
<path
style="fill:none;stroke:#000000;stroke-width:0.60000002"
d="m 139.83,193.562 21.855,0"
id="path3249" />
<path
style="fill:none;stroke:#ecece7;stroke-width:0.02"
d="m 141.178,185.727 0,-4.595 9.72,0"
id="path3251" />
</g>
<text
xml:space="preserve"
style="font-size:6.16453981px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans"
x="52.2197"
y="266.53781"
id="text3232"><tspan
sodipodi:role="line"
id="tspan3234"
x="52.2197"
y="266.53781"
style="font-size:11.20825386px">Client</tspan></text>
<text
xml:space="preserve"
style="font-size:16.81238174px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans"
x="268.38885"
y="267.14429"
id="text3236"><tspan
sodipodi:role="line"
id="tspan3238"
x="268.38885"
y="267.14429"
style="font-size:11.20825386px">Peers</tspan></text>
<g
transform="matrix(0.75311128,0,0,0.75311128,66.977055,17.740053)"
id="g3183">
<path
style="fill:#0078aa"
d="m 171.824,286.241 -0.049,-0.589 -0.13,-0.599 -0.22,-0.589 -0.309,-0.579 -0.4,-0.589 -0.479,-0.579 -0.569,-0.559 -0.639,-0.549 -0.738,-0.539 -0.809,-0.519 -0.888,-0.52 -0.969,-0.499 -1.038,-0.479 -1.108,-0.469 -1.178,-0.439 -1.228,-0.42 -1.297,-0.399 -1.368,-0.369 -1.408,-0.37 -1.457,-0.309 -1.507,-0.309 -1.558,-0.27 -1.587,-0.26 -1.637,-0.219 -1.647,-0.19 -1.697,-0.16 -1.707,-0.139 -1.717,-0.11 -1.737,-0.08 -1.747,-0.03 -1.767,-0.03 0,0 -1.747,0.03 -1.737,0.03 -1.737,0.08 -1.717,0.11 -1.707,0.139 -1.697,0.16 -1.647,0.19 -1.637,0.219 -1.587,0.26 -1.558,0.27 -1.517,0.309 -1.447,0.309 -1.408,0.37 -1.368,0.369 -1.297,0.399 -1.228,0.42 -1.178,0.439 -1.108,0.469 -1.038,0.479 -0.979,0.499 -0.878,0.52 -0.819,0.519 -0.728,0.539 -0.639,0.549 -0.569,0.559 -0.479,0.579 -0.4,0.589 -0.309,0.579 -0.23,0.589 -0.12,0.599 -0.049,0.589 0,0 0.049,0.609 0.12,0.588 0.23,0.589 0.309,0.589 0.4,0.579 0.479,0.579 0.569,0.559 0.639,0.549 0.728,0.54 0.819,0.529 0.878,0.499 0.979,0.519 1.038,0.479 1.108,0.459 1.178,0.429 1.228,0.43 1.297,0.399 1.368,0.379 1.408,0.35 1.447,0.329 1.517,0.3 1.558,0.269 1.587,0.26 1.637,0.219 1.647,0.19 1.697,0.17 1.707,0.119 1.717,0.11 1.737,0.08 1.737,0.05 1.747,0.01 0,0 1.767,-0.01 1.747,-0.05 1.737,-0.08 1.717,-0.11 1.707,-0.119 1.697,-0.17 1.647,-0.19 1.637,-0.219 1.587,-0.26 1.558,-0.269 1.507,-0.3 1.457,-0.329 1.408,-0.35 1.368,-0.379 1.297,-0.399 1.228,-0.43 1.178,-0.429 1.108,-0.459 1.038,-0.479 0.969,-0.519 0.888,-0.499 0.809,-0.529 0.738,-0.54 0.639,-0.549 0.569,-0.559 0.479,-0.579 0.4,-0.579 0.309,-0.589 0.22,-0.589 0.13,-0.588 0.049,-0.609 z"
id="path3185" />
<path
style="fill:none;stroke:#aae6ff;stroke-width:0.02"
d="m 171.425,286.061 -0.05,-0.599 -0.129,-0.569 -0.22,-0.589 -0.3,-0.569 -0.399,-0.579 -0.489,-0.559 -0.539,-0.549 -0.659,-0.549 -0.729,-0.529 -0.808,-0.529 -0.879,-0.489 -0.968,-0.49 -1.018,-0.489 -1.098,-0.449 -1.178,-0.439 -1.238,-0.399 -1.288,-0.4 -1.347,-0.369 -1.388,-0.34 -1.467,-0.329 -1.508,-0.289 -1.527,-0.27 -1.587,-0.25 -1.618,-0.219 -1.647,-0.19 -1.687,-0.16 -1.687,-0.139 -1.707,-0.08 -1.737,-0.09 -1.737,-0.05 -1.747,0 0,0 -1.737,0 -1.747,0.05 -1.727,0.09 -1.707,0.08 -1.697,0.139 -1.677,0.16 -1.647,0.19 -1.627,0.219 -1.577,0.25 -1.527,0.27 -1.518,0.289 -1.447,0.329 -1.388,0.34 -1.357,0.369 -1.308,0.4 -1.238,0.399 -1.158,0.439 -1.108,0.449 -1.028,0.489 -0.949,0.49 -0.868,0.489 -0.819,0.529 -0.738,0.529 -0.639,0.549 -0.559,0.549 -0.499,0.559 -0.37,0.579 -0.319,0.569 -0.22,0.589 -0.12,0.569 -0.049,0.599 0,0 0.049,0.589 0.12,0.579 0.22,0.579 0.319,0.569 0.37,0.579 0.499,0.559 0.559,0.549 0.639,0.529 0.738,0.549 0.819,0.529 0.868,0.499 0.949,0.479 1.028,0.48 1.108,0.459 1.158,0.429 1.238,0.409 1.308,0.38 1.357,0.389 1.388,0.339 1.447,0.32 1.518,0.309 1.527,0.26 1.577,0.239 1.627,0.23 1.647,0.18 1.677,0.149 1.697,0.15 1.707,0.09 1.727,0.08 1.747,0.04 1.737,0.02 0,0 1.747,-0.02 1.737,-0.04 1.737,-0.08 1.707,-0.09 1.687,-0.15 1.687,-0.149 1.647,-0.18 1.618,-0.23 1.587,-0.239 1.527,-0.26 1.508,-0.309 1.467,-0.32 1.388,-0.339 1.347,-0.389 1.288,-0.38 1.238,-0.409 1.178,-0.429 1.098,-0.459 1.018,-0.48 0.968,-0.479 0.879,-0.499 0.808,-0.529 0.729,-0.549 0.659,-0.529 0.539,-0.549 0.489,-0.559 0.399,-0.579 0.3,-0.569 0.22,-0.579 0.129,-0.579 0.05,-0.589"
id="path3187" />
<path
style="fill:#0078aa"
d="m 102.676,269.969 0,16.491 68.749,0 0,-16.491 -68.749,0 z"
id="path3189" />
<path
style="fill:#00b4ff"
d="m 171.824,269.739 -0.049,-0.579 -0.13,-0.598 -0.22,-0.589 -0.309,-0.589 -0.4,-0.589 -0.479,-0.569 -0.569,-0.559 -0.639,-0.559 -0.738,-0.53 -0.809,-0.529 -0.888,-0.509 -0.969,-0.519 -1.038,-0.469 -1.108,-0.469 -1.178,-0.439 -1.228,-0.41 -1.297,-0.399 -1.368,-0.379 -1.408,-0.35 -1.457,-0.329 -1.507,-0.31 -1.558,-0.259 -1.587,-0.27 -1.637,-0.219 -1.647,-0.19 -1.697,-0.16 -1.707,-0.119 -1.717,-0.11 -1.737,-0.08 -1.747,-0.06 -1.767,0 0,0 -1.747,0 -1.737,0.06 -1.737,0.08 -1.717,0.11 -1.707,0.119 -1.697,0.16 -1.647,0.19 -1.637,0.219 -1.587,0.27 -1.558,0.259 -1.517,0.31 -1.447,0.329 -1.408,0.35 -1.368,0.379 -1.297,0.399 -1.228,0.41 -1.178,0.439 -1.108,0.469 -1.038,0.469 -0.979,0.519 -0.878,0.509 -0.819,0.529 -0.728,0.53 -0.639,0.559 -0.569,0.559 -0.479,0.569 -0.4,0.589 -0.309,0.589 -0.23,0.589 -0.12,0.598 -0.049,0.579 0,0 0.049,0.609 0.12,0.599 0.23,0.589 0.309,0.579 0.4,0.589 0.479,0.559 0.569,0.579 0.639,0.549 0.728,0.539 0.819,0.529 0.878,0.51 0.979,0.509 1.038,0.479 1.108,0.439 1.178,0.459 1.228,0.42 1.297,0.399 1.368,0.379 1.408,0.35 1.447,0.319 1.517,0.309 1.558,0.27 1.587,0.26 1.637,0.219 1.647,0.19 1.697,0.16 1.707,0.119 1.717,0.11 1.737,0.09 1.737,0.05 1.747,0 0,0 1.767,0 1.747,-0.05 1.737,-0.09 1.717,-0.11 1.707,-0.119 1.697,-0.16 1.647,-0.19 1.637,-0.219 1.587,-0.26 1.558,-0.27 1.507,-0.309 1.457,-0.319 1.408,-0.35 1.368,-0.379 1.297,-0.399 1.228,-0.42 1.178,-0.459 1.108,-0.439 1.038,-0.479 0.969,-0.509 0.888,-0.51 0.809,-0.529 0.738,-0.539 0.639,-0.549 0.569,-0.579 0.479,-0.559 0.4,-0.589 0.309,-0.579 0.22,-0.589 0.13,-0.599 0.049,-0.609 z"
id="path3191" />
<path
style="fill:none;stroke:#aae6ff;stroke-width:0.02"
d="m 171.425,269.57 -0.05,-0.599 -0.129,-0.589 -0.22,-0.559 -0.3,-0.589 -0.399,-0.569 -0.489,-0.559 -0.539,-0.539 -0.659,-0.559 -0.729,-0.519 -0.808,-0.539 -0.879,-0.5 -0.968,-0.499 -1.018,-0.469 -1.098,-0.439 -1.178,-0.459 -1.238,-0.4 -1.288,-0.389 -1.347,-0.369 -1.388,-0.34 -1.467,-0.339 -1.508,-0.29 -1.527,-0.269 -1.587,-0.25 -1.618,-0.219 -1.647,-0.19 -1.687,-0.14 -1.687,-0.139 -1.707,-0.1 -1.737,-0.09 -1.737,-0.04 -1.747,-0.02 0,0 -1.737,0.02 -1.747,0.04 -1.727,0.09 -1.707,0.1 -1.697,0.139 -1.677,0.14 -1.647,0.19 -1.627,0.219 -1.577,0.25 -1.527,0.269 -1.518,0.29 -1.447,0.339 -1.388,0.34 -1.357,0.369 -1.308,0.389 -1.238,0.4 -1.158,0.459 -1.108,0.439 -1.028,0.469 -0.949,0.499 -0.868,0.5 -0.819,0.539 -0.738,0.519 -0.639,0.559 -0.559,0.539 -0.499,0.559 -0.37,0.569 -0.319,0.589 -0.22,0.559 -0.12,0.589 -0.049,0.599 0,0 0.049,0.579 0.12,0.589 0.22,0.559 0.319,0.579 0.37,0.579 0.499,0.559 0.559,0.559 0.639,0.549 0.738,0.529 0.819,0.519 0.868,0.509 0.949,0.469 1.028,0.489 1.108,0.45 1.158,0.439 1.238,0.409 1.308,0.389 1.357,0.37 1.388,0.339 1.447,0.33 1.518,0.309 1.527,0.25 1.577,0.259 1.627,0.21 1.647,0.189 1.677,0.17 1.697,0.14 1.707,0.08 1.727,0.08 1.747,0.05 1.737,0.01 0,0 1.747,-0.01 1.737,-0.05 1.737,-0.08 1.707,-0.08 1.687,-0.14 1.687,-0.17 1.647,-0.189 1.618,-0.21 1.587,-0.259 1.527,-0.25 1.508,-0.309 1.467,-0.33 1.388,-0.339 1.347,-0.37 1.288,-0.389 1.238,-0.409 1.178,-0.439 1.098,-0.45 1.018,-0.489 0.968,-0.469 0.879,-0.509 0.808,-0.519 0.729,-0.529 0.659,-0.549 0.539,-0.559 0.489,-0.559 0.399,-0.579 0.3,-0.579 0.22,-0.559 0.129,-0.589 0.05,-0.579"
id="path3193" />
<path
style="fill:#000000"
d="m 137.874,267.074 5.041,1.657 12.169,-4.961 5.44,1.657 -2.955,-4.123 -14.225,0 5.85,1.248 -11.32,4.522 z"
id="path3195" />
<path
style="fill:#000000"
d="m 135.768,271.626 -5.002,-1.657 -11.749,4.961 -5.86,-1.667 2.935,4.542 14.674,0 -6.299,-1.657 11.301,-4.522 z"
id="path3197" />
<path
style="fill:#000000"
d="m 114.405,262.552 5.031,-1.657 12.149,4.532 5.46,-1.228 -2.925,4.113 -14.265,0 5.86,-1.238 -11.31,-4.522 z"
id="path3199" />
<path
style="fill:#000000"
d="m 159.676,276.568 -5.021,1.647 -11.74,-4.952 -5.87,1.667 2.935,-4.132 14.675,0 -6.299,1.217 11.32,4.553 z"
id="path3201" />
<path
style="fill:#ffffff"
d="m 138.293,267.483 5.051,1.648 12.149,-4.932 5.451,1.657 -2.935,-4.142 -14.265,0 5.879,1.237 -11.33,4.532 z"
id="path3203" />
<path
style="fill:#ffffff"
d="m 136.217,272.015 -5.051,-1.637 -11.73,4.952 -5.87,-1.657 2.935,4.542 14.665,0 -6.269,-1.647 11.32,-4.553 z"
id="path3205" />
<path
style="fill:#ffffff"
d="m 114.834,262.951 5.021,-1.647 12.159,4.552 5.451,-1.258 -2.935,4.133 -14.255,0 5.879,-1.248 -11.32,-4.532 z"
id="path3207" />
<path
style="fill:#ffffff"
d="m 160.105,276.977 -5.021,1.657 -11.74,-4.961 -5.879,1.657 2.925,-4.113 14.694,0 -6.289,1.228 11.31,4.532 z"
id="path3209" />
<path
style="fill:none;stroke:#aae6ff;stroke-width:0.02"
d="m 102.676,269.57 0,16.471"
id="path3211" />
<path
style="fill:none;stroke:#aae6ff;stroke-width:0.02"
d="m 171.425,269.57 0,16.471"
id="path3213" />
<path
style="fill:#000000"
d="m 124.467,283.995 7.547,0 4.612,3.713 4.602,-3.713 7.128,0 0,-1.648 5.041,2.456 -5.041,2.486 0,-1.647 -6.279,0 -4.203,2.885 4.203,3.284 6.279,0 0,-2.037 5.041,2.875 -5.041,2.486 0,-1.667 -7.128,0 -4.602,-3.694 -4.612,3.694 -7.547,0 0,1.667 -5.031,-2.486 5.031,-2.875 0,2.037 6.699,0 4.202,-2.875 -4.202,-3.294 -6.699,0 0,1.647 -5.031,-2.486 5.031,-2.456 0,1.648 z"
id="path3215" />
<path
style="fill:#ffffff"
d="m 124.897,284.394 7.536,0 4.612,3.703 4.602,-3.703 7.148,0 0,-1.647 5.011,2.485 -5.011,2.476 0,-1.647 -6.299,0 -4.203,2.875 4.203,3.294 6.299,0 0,-2.056 5.011,2.885 -5.011,2.475 0,-1.657 -7.148,0 -4.602,-3.703 -4.612,3.703 -7.536,0 0,1.657 -5.042,-2.475 5.042,-2.885 0,2.056 6.688,0 4.183,-2.885 -4.183,-3.284 -6.688,0 0,1.647 -5.042,-2.476 5.042,-2.485 0,1.647 z"
id="path3217" />
</g>
<text
xml:space="preserve"
style="font-size:6.16453981px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans"
x="143.47925"
y="266.56204"
id="text3232-1"><tspan
sodipodi:role="line"
id="tspan3234-7"
x="143.47925"
y="266.56204"
style="font-size:11.20825386px">I2PTunnel</tspan></text>
<path
style="fill:none;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-end:url(#Arrow1Lend)"
d="m -23.12158,114.55692 106.149072,0"
id="path3614"
transform="matrix(0.5604127,0,0,0.5604127,97,159)" />
<path
style="fill:none;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-end:url(#Arrow1Lend)"
d="m 176.56479,114.55692 140.83144,0"
id="path4836"
transform="matrix(0.5604127,0,0,0.5604127,97,159)" />
<g
id="g3219-0"
transform="translate(134.85585,-107.12416)">
<path
style="fill:#b7b79d"
d="m 139.83,178.978 0,37.022 21.882,0 0,-37.022 -21.882,0 z"
id="path3221-3" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 139.83,178.978 0,37.022 21.882,0 0,-37.022 -21.882,0"
id="path3223-4" />
<path
style="fill:#c9c9b6"
d="m 139.83,178.978 2.965,-2.978 21.875,0 -2.958,2.978 -21.882,0 z"
id="path3225-0" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 139.83,178.978 2.965,-2.978 21.731,0"
id="path3227-3" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 164.526,176.151 -2.814,2.827 -21.882,0"
id="path3229-9" />
<path
style="fill:#c9c9b6"
d="m 141.178,181.132 9.995,0 0,4.857 -9.995,0 0,-4.857 z"
id="path3231-1" />
<path
style="fill:none;stroke:#626248;stroke-width:0.02"
d="m 141.178,181.132 9.989,0 0,4.85 -9.989,0 0,-4.85"
id="path3233-9" />
<path
style="fill:none;stroke:#ecece7;stroke-width:0.60000002"
d="m 142.527,183.567 7.01,0"
id="path3235-6" />
<path
style="fill:#7a7a5a"
d="m 161.712,216 2.958,-2.985 0,-37.015 -2.958,2.978 0,37.022 z"
id="path3237-9" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 161.712,216 2.814,-2.834"
id="path3239-3" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 164.526,176.151 -2.814,2.827 0,37.022"
id="path3241-3" />
<path
style="fill:none;stroke:#ecece7;stroke-width:0.60000002"
d="m 140.105,213.559 21.6,0"
id="path3243-8" />
<path
style="fill:none;stroke:#000000;stroke-width:0.60000002"
d="m 140.105,193.837 21.6,0"
id="path3245-0" />
<path
style="fill:none;stroke:#494936;stroke-width:0.60000002"
d="m 139.83,213.29 21.855,0"
id="path3247-5" />
<path
style="fill:none;stroke:#000000;stroke-width:0.60000002"
d="m 139.83,193.562 21.855,0"
id="path3249-6" />
<path
style="fill:none;stroke:#ecece7;stroke-width:0.02"
d="m 141.178,185.727 0,-4.595 9.72,0"
id="path3251-6" />
</g>
<g
id="g3219-6"
transform="translate(134.38113,-56.133163)">
<path
style="fill:#b7b79d"
d="m 139.83,178.978 0,37.022 21.882,0 0,-37.022 -21.882,0 z"
id="path3221-9" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 139.83,178.978 0,37.022 21.882,0 0,-37.022 -21.882,0"
id="path3223-8" />
<path
style="fill:#c9c9b6"
d="m 139.83,178.978 2.965,-2.978 21.875,0 -2.958,2.978 -21.882,0 z"
id="path3225-7" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 139.83,178.978 2.965,-2.978 21.731,0"
id="path3227-2" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 164.526,176.151 -2.814,2.827 -21.882,0"
id="path3229-8" />
<path
style="fill:#c9c9b6"
d="m 141.178,181.132 9.995,0 0,4.857 -9.995,0 0,-4.857 z"
id="path3231-2" />
<path
style="fill:none;stroke:#626248;stroke-width:0.02"
d="m 141.178,181.132 9.989,0 0,4.85 -9.989,0 0,-4.85"
id="path3233-99" />
<path
style="fill:none;stroke:#ecece7;stroke-width:0.60000002"
d="m 142.527,183.567 7.01,0"
id="path3235-60" />
<path
style="fill:#7a7a5a"
d="m 161.712,216 2.958,-2.985 0,-37.015 -2.958,2.978 0,37.022 z"
id="path3237-2" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 161.712,216 2.814,-2.834"
id="path3239-7" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 164.526,176.151 -2.814,2.827 0,37.022"
id="path3241-6" />
<path
style="fill:none;stroke:#ecece7;stroke-width:0.60000002"
d="m 140.105,213.559 21.6,0"
id="path3243-1" />
<path
style="fill:none;stroke:#000000;stroke-width:0.60000002"
d="m 140.105,193.837 21.6,0"
id="path3245-3" />
<path
style="fill:none;stroke:#494936;stroke-width:0.60000002"
d="m 139.83,213.29 21.855,0"
id="path3247-2" />
<path
style="fill:none;stroke:#000000;stroke-width:0.60000002"
d="m 139.83,193.562 21.855,0"
id="path3249-1" />
<path
style="fill:none;stroke:#ecece7;stroke-width:0.02"
d="m 141.178,185.727 0,-4.595 9.72,0"
id="path3251-5" />
</g>
<text
xml:space="preserve"
style="font-size:6.16453981px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans"
x="280.74731"
y="181.24799"
id="text3232-2"><tspan
sodipodi:role="line"
id="tspan3234-0"
x="280.74731"
y="181.24799"
style="font-size:11.20825386px">...</tspan></text>
<g
transform="matrix(0.75311128,0,0,0.75311128,66.155046,-65.60384)"
id="g3183-0">
<path
style="fill:#0078aa"
d="m 171.824,286.241 -0.049,-0.589 -0.13,-0.599 -0.22,-0.589 -0.309,-0.579 -0.4,-0.589 -0.479,-0.579 -0.569,-0.559 -0.639,-0.549 -0.738,-0.539 -0.809,-0.519 -0.888,-0.52 -0.969,-0.499 -1.038,-0.479 -1.108,-0.469 -1.178,-0.439 -1.228,-0.42 -1.297,-0.399 -1.368,-0.369 -1.408,-0.37 -1.457,-0.309 -1.507,-0.309 -1.558,-0.27 -1.587,-0.26 -1.637,-0.219 -1.647,-0.19 -1.697,-0.16 -1.707,-0.139 -1.717,-0.11 -1.737,-0.08 -1.747,-0.03 -1.767,-0.03 0,0 -1.747,0.03 -1.737,0.03 -1.737,0.08 -1.717,0.11 -1.707,0.139 -1.697,0.16 -1.647,0.19 -1.637,0.219 -1.587,0.26 -1.558,0.27 -1.517,0.309 -1.447,0.309 -1.408,0.37 -1.368,0.369 -1.297,0.399 -1.228,0.42 -1.178,0.439 -1.108,0.469 -1.038,0.479 -0.979,0.499 -0.878,0.52 -0.819,0.519 -0.728,0.539 -0.639,0.549 -0.569,0.559 -0.479,0.579 -0.4,0.589 -0.309,0.579 -0.23,0.589 -0.12,0.599 -0.049,0.589 0,0 0.049,0.609 0.12,0.588 0.23,0.589 0.309,0.589 0.4,0.579 0.479,0.579 0.569,0.559 0.639,0.549 0.728,0.54 0.819,0.529 0.878,0.499 0.979,0.519 1.038,0.479 1.108,0.459 1.178,0.429 1.228,0.43 1.297,0.399 1.368,0.379 1.408,0.35 1.447,0.329 1.517,0.3 1.558,0.269 1.587,0.26 1.637,0.219 1.647,0.19 1.697,0.17 1.707,0.119 1.717,0.11 1.737,0.08 1.737,0.05 1.747,0.01 0,0 1.767,-0.01 1.747,-0.05 1.737,-0.08 1.717,-0.11 1.707,-0.119 1.697,-0.17 1.647,-0.19 1.637,-0.219 1.587,-0.26 1.558,-0.269 1.507,-0.3 1.457,-0.329 1.408,-0.35 1.368,-0.379 1.297,-0.399 1.228,-0.43 1.178,-0.429 1.108,-0.459 1.038,-0.479 0.969,-0.519 0.888,-0.499 0.809,-0.529 0.738,-0.54 0.639,-0.549 0.569,-0.559 0.479,-0.579 0.4,-0.579 0.309,-0.589 0.22,-0.589 0.13,-0.588 0.049,-0.609 z"
id="path3185-2" />
<path
style="fill:none;stroke:#aae6ff;stroke-width:0.02"
d="m 171.425,286.061 -0.05,-0.599 -0.129,-0.569 -0.22,-0.589 -0.3,-0.569 -0.399,-0.579 -0.489,-0.559 -0.539,-0.549 -0.659,-0.549 -0.729,-0.529 -0.808,-0.529 -0.879,-0.489 -0.968,-0.49 -1.018,-0.489 -1.098,-0.449 -1.178,-0.439 -1.238,-0.399 -1.288,-0.4 -1.347,-0.369 -1.388,-0.34 -1.467,-0.329 -1.508,-0.289 -1.527,-0.27 -1.587,-0.25 -1.618,-0.219 -1.647,-0.19 -1.687,-0.16 -1.687,-0.139 -1.707,-0.08 -1.737,-0.09 -1.737,-0.05 -1.747,0 0,0 -1.737,0 -1.747,0.05 -1.727,0.09 -1.707,0.08 -1.697,0.139 -1.677,0.16 -1.647,0.19 -1.627,0.219 -1.577,0.25 -1.527,0.27 -1.518,0.289 -1.447,0.329 -1.388,0.34 -1.357,0.369 -1.308,0.4 -1.238,0.399 -1.158,0.439 -1.108,0.449 -1.028,0.489 -0.949,0.49 -0.868,0.489 -0.819,0.529 -0.738,0.529 -0.639,0.549 -0.559,0.549 -0.499,0.559 -0.37,0.579 -0.319,0.569 -0.22,0.589 -0.12,0.569 -0.049,0.599 0,0 0.049,0.589 0.12,0.579 0.22,0.579 0.319,0.569 0.37,0.579 0.499,0.559 0.559,0.549 0.639,0.529 0.738,0.549 0.819,0.529 0.868,0.499 0.949,0.479 1.028,0.48 1.108,0.459 1.158,0.429 1.238,0.409 1.308,0.38 1.357,0.389 1.388,0.339 1.447,0.32 1.518,0.309 1.527,0.26 1.577,0.239 1.627,0.23 1.647,0.18 1.677,0.149 1.697,0.15 1.707,0.09 1.727,0.08 1.747,0.04 1.737,0.02 0,0 1.747,-0.02 1.737,-0.04 1.737,-0.08 1.707,-0.09 1.687,-0.15 1.687,-0.149 1.647,-0.18 1.618,-0.23 1.587,-0.239 1.527,-0.26 1.508,-0.309 1.467,-0.32 1.388,-0.339 1.347,-0.389 1.288,-0.38 1.238,-0.409 1.178,-0.429 1.098,-0.459 1.018,-0.48 0.968,-0.479 0.879,-0.499 0.808,-0.529 0.729,-0.549 0.659,-0.529 0.539,-0.549 0.489,-0.559 0.399,-0.579 0.3,-0.569 0.22,-0.579 0.129,-0.579 0.05,-0.589"
id="path3187-9" />
<path
style="fill:#0078aa"
d="m 102.676,269.969 0,16.491 68.749,0 0,-16.491 -68.749,0 z"
id="path3189-4" />
<path
style="fill:#00b4ff"
d="m 171.824,269.739 -0.049,-0.579 -0.13,-0.598 -0.22,-0.589 -0.309,-0.589 -0.4,-0.589 -0.479,-0.569 -0.569,-0.559 -0.639,-0.559 -0.738,-0.53 -0.809,-0.529 -0.888,-0.509 -0.969,-0.519 -1.038,-0.469 -1.108,-0.469 -1.178,-0.439 -1.228,-0.41 -1.297,-0.399 -1.368,-0.379 -1.408,-0.35 -1.457,-0.329 -1.507,-0.31 -1.558,-0.259 -1.587,-0.27 -1.637,-0.219 -1.647,-0.19 -1.697,-0.16 -1.707,-0.119 -1.717,-0.11 -1.737,-0.08 -1.747,-0.06 -1.767,0 0,0 -1.747,0 -1.737,0.06 -1.737,0.08 -1.717,0.11 -1.707,0.119 -1.697,0.16 -1.647,0.19 -1.637,0.219 -1.587,0.27 -1.558,0.259 -1.517,0.31 -1.447,0.329 -1.408,0.35 -1.368,0.379 -1.297,0.399 -1.228,0.41 -1.178,0.439 -1.108,0.469 -1.038,0.469 -0.979,0.519 -0.878,0.509 -0.819,0.529 -0.728,0.53 -0.639,0.559 -0.569,0.559 -0.479,0.569 -0.4,0.589 -0.309,0.589 -0.23,0.589 -0.12,0.598 -0.049,0.579 0,0 0.049,0.609 0.12,0.599 0.23,0.589 0.309,0.579 0.4,0.589 0.479,0.559 0.569,0.579 0.639,0.549 0.728,0.539 0.819,0.529 0.878,0.51 0.979,0.509 1.038,0.479 1.108,0.439 1.178,0.459 1.228,0.42 1.297,0.399 1.368,0.379 1.408,0.35 1.447,0.319 1.517,0.309 1.558,0.27 1.587,0.26 1.637,0.219 1.647,0.19 1.697,0.16 1.707,0.119 1.717,0.11 1.737,0.09 1.737,0.05 1.747,0 0,0 1.767,0 1.747,-0.05 1.737,-0.09 1.717,-0.11 1.707,-0.119 1.697,-0.16 1.647,-0.19 1.637,-0.219 1.587,-0.26 1.558,-0.27 1.507,-0.309 1.457,-0.319 1.408,-0.35 1.368,-0.379 1.297,-0.399 1.228,-0.42 1.178,-0.459 1.108,-0.439 1.038,-0.479 0.969,-0.509 0.888,-0.51 0.809,-0.529 0.738,-0.539 0.639,-0.549 0.569,-0.579 0.479,-0.559 0.4,-0.589 0.309,-0.579 0.22,-0.589 0.13,-0.599 0.049,-0.609 z"
id="path3191-3" />
<path
style="fill:none;stroke:#aae6ff;stroke-width:0.02"
d="m 171.425,269.57 -0.05,-0.599 -0.129,-0.589 -0.22,-0.559 -0.3,-0.589 -0.399,-0.569 -0.489,-0.559 -0.539,-0.539 -0.659,-0.559 -0.729,-0.519 -0.808,-0.539 -0.879,-0.5 -0.968,-0.499 -1.018,-0.469 -1.098,-0.439 -1.178,-0.459 -1.238,-0.4 -1.288,-0.389 -1.347,-0.369 -1.388,-0.34 -1.467,-0.339 -1.508,-0.29 -1.527,-0.269 -1.587,-0.25 -1.618,-0.219 -1.647,-0.19 -1.687,-0.14 -1.687,-0.139 -1.707,-0.1 -1.737,-0.09 -1.737,-0.04 -1.747,-0.02 0,0 -1.737,0.02 -1.747,0.04 -1.727,0.09 -1.707,0.1 -1.697,0.139 -1.677,0.14 -1.647,0.19 -1.627,0.219 -1.577,0.25 -1.527,0.269 -1.518,0.29 -1.447,0.339 -1.388,0.34 -1.357,0.369 -1.308,0.389 -1.238,0.4 -1.158,0.459 -1.108,0.439 -1.028,0.469 -0.949,0.499 -0.868,0.5 -0.819,0.539 -0.738,0.519 -0.639,0.559 -0.559,0.539 -0.499,0.559 -0.37,0.569 -0.319,0.589 -0.22,0.559 -0.12,0.589 -0.049,0.599 0,0 0.049,0.579 0.12,0.589 0.22,0.559 0.319,0.579 0.37,0.579 0.499,0.559 0.559,0.559 0.639,0.549 0.738,0.529 0.819,0.519 0.868,0.509 0.949,0.469 1.028,0.489 1.108,0.45 1.158,0.439 1.238,0.409 1.308,0.389 1.357,0.37 1.388,0.339 1.447,0.33 1.518,0.309 1.527,0.25 1.577,0.259 1.627,0.21 1.647,0.189 1.677,0.17 1.697,0.14 1.707,0.08 1.727,0.08 1.747,0.05 1.737,0.01 0,0 1.747,-0.01 1.737,-0.05 1.737,-0.08 1.707,-0.08 1.687,-0.14 1.687,-0.17 1.647,-0.189 1.618,-0.21 1.587,-0.259 1.527,-0.25 1.508,-0.309 1.467,-0.33 1.388,-0.339 1.347,-0.37 1.288,-0.389 1.238,-0.409 1.178,-0.439 1.098,-0.45 1.018,-0.489 0.968,-0.469 0.879,-0.509 0.808,-0.519 0.729,-0.529 0.659,-0.549 0.539,-0.559 0.489,-0.559 0.399,-0.579 0.3,-0.579 0.22,-0.559 0.129,-0.589 0.05,-0.579"
id="path3193-5" />
<path
style="fill:#000000"
d="m 137.874,267.074 5.041,1.657 12.169,-4.961 5.44,1.657 -2.955,-4.123 -14.225,0 5.85,1.248 -11.32,4.522 z"
id="path3195-1" />
<path
style="fill:#000000"
d="m 135.768,271.626 -5.002,-1.657 -11.749,4.961 -5.86,-1.667 2.935,4.542 14.674,0 -6.299,-1.657 11.301,-4.522 z"
id="path3197-7" />
<path
style="fill:#000000"
d="m 114.405,262.552 5.031,-1.657 12.149,4.532 5.46,-1.228 -2.925,4.113 -14.265,0 5.86,-1.238 -11.31,-4.522 z"
id="path3199-4" />
<path
style="fill:#000000"
d="m 159.676,276.568 -5.021,1.647 -11.74,-4.952 -5.87,1.667 2.935,-4.132 14.675,0 -6.299,1.217 11.32,4.553 z"
id="path3201-3" />
<path
style="fill:#ffffff"
d="m 138.293,267.483 5.051,1.648 12.149,-4.932 5.451,1.657 -2.935,-4.142 -14.265,0 5.879,1.237 -11.33,4.532 z"
id="path3203-1" />
<path
style="fill:#ffffff"
d="m 136.217,272.015 -5.051,-1.637 -11.73,4.952 -5.87,-1.657 2.935,4.542 14.665,0 -6.269,-1.647 11.32,-4.553 z"
id="path3205-4" />
<path
style="fill:#ffffff"
d="m 114.834,262.951 5.021,-1.647 12.159,4.552 5.451,-1.258 -2.935,4.133 -14.255,0 5.879,-1.248 -11.32,-4.532 z"
id="path3207-6" />
<path
style="fill:#ffffff"
d="m 160.105,276.977 -5.021,1.657 -11.74,-4.961 -5.879,1.657 2.925,-4.113 14.694,0 -6.289,1.228 11.31,4.532 z"
id="path3209-9" />
<path
style="fill:none;stroke:#aae6ff;stroke-width:0.02"
d="m 102.676,269.57 0,16.471"
id="path3211-4" />
<path
style="fill:none;stroke:#aae6ff;stroke-width:0.02"
d="m 171.425,269.57 0,16.471"
id="path3213-2" />
<path
style="fill:#000000"
d="m 124.467,283.995 7.547,0 4.612,3.713 4.602,-3.713 7.128,0 0,-1.648 5.041,2.456 -5.041,2.486 0,-1.647 -6.279,0 -4.203,2.885 4.203,3.284 6.279,0 0,-2.037 5.041,2.875 -5.041,2.486 0,-1.667 -7.128,0 -4.602,-3.694 -4.612,3.694 -7.547,0 0,1.667 -5.031,-2.486 5.031,-2.875 0,2.037 6.699,0 4.202,-2.875 -4.202,-3.294 -6.699,0 0,1.647 -5.031,-2.486 5.031,-2.456 0,1.648 z"
id="path3215-2" />
<path
style="fill:#ffffff"
d="m 124.897,284.394 7.536,0 4.612,3.703 4.602,-3.703 7.148,0 0,-1.647 5.011,2.485 -5.011,2.476 0,-1.647 -6.299,0 -4.203,2.875 4.203,3.294 6.299,0 0,-2.056 5.011,2.885 -5.011,2.475 0,-1.657 -7.148,0 -4.602,-3.703 -4.612,3.703 -7.536,0 0,1.657 -5.042,-2.475 5.042,-2.885 0,2.056 6.688,0 4.183,-2.885 -4.183,-3.284 -6.688,0 0,1.647 -5.042,-2.476 5.042,-2.485 0,1.647 z"
id="path3217-6" />
</g>
<g
transform="matrix(0.75311128,0,0,0.75311128,66.040764,-121.3287)"
id="g3183-1">
<path
style="fill:#0078aa"
d="m 171.824,286.241 -0.049,-0.589 -0.13,-0.599 -0.22,-0.589 -0.309,-0.579 -0.4,-0.589 -0.479,-0.579 -0.569,-0.559 -0.639,-0.549 -0.738,-0.539 -0.809,-0.519 -0.888,-0.52 -0.969,-0.499 -1.038,-0.479 -1.108,-0.469 -1.178,-0.439 -1.228,-0.42 -1.297,-0.399 -1.368,-0.369 -1.408,-0.37 -1.457,-0.309 -1.507,-0.309 -1.558,-0.27 -1.587,-0.26 -1.637,-0.219 -1.647,-0.19 -1.697,-0.16 -1.707,-0.139 -1.717,-0.11 -1.737,-0.08 -1.747,-0.03 -1.767,-0.03 0,0 -1.747,0.03 -1.737,0.03 -1.737,0.08 -1.717,0.11 -1.707,0.139 -1.697,0.16 -1.647,0.19 -1.637,0.219 -1.587,0.26 -1.558,0.27 -1.517,0.309 -1.447,0.309 -1.408,0.37 -1.368,0.369 -1.297,0.399 -1.228,0.42 -1.178,0.439 -1.108,0.469 -1.038,0.479 -0.979,0.499 -0.878,0.52 -0.819,0.519 -0.728,0.539 -0.639,0.549 -0.569,0.559 -0.479,0.579 -0.4,0.589 -0.309,0.579 -0.23,0.589 -0.12,0.599 -0.049,0.589 0,0 0.049,0.609 0.12,0.588 0.23,0.589 0.309,0.589 0.4,0.579 0.479,0.579 0.569,0.559 0.639,0.549 0.728,0.54 0.819,0.529 0.878,0.499 0.979,0.519 1.038,0.479 1.108,0.459 1.178,0.429 1.228,0.43 1.297,0.399 1.368,0.379 1.408,0.35 1.447,0.329 1.517,0.3 1.558,0.269 1.587,0.26 1.637,0.219 1.647,0.19 1.697,0.17 1.707,0.119 1.717,0.11 1.737,0.08 1.737,0.05 1.747,0.01 0,0 1.767,-0.01 1.747,-0.05 1.737,-0.08 1.717,-0.11 1.707,-0.119 1.697,-0.17 1.647,-0.19 1.637,-0.219 1.587,-0.26 1.558,-0.269 1.507,-0.3 1.457,-0.329 1.408,-0.35 1.368,-0.379 1.297,-0.399 1.228,-0.43 1.178,-0.429 1.108,-0.459 1.038,-0.479 0.969,-0.519 0.888,-0.499 0.809,-0.529 0.738,-0.54 0.639,-0.549 0.569,-0.559 0.479,-0.579 0.4,-0.579 0.309,-0.589 0.22,-0.589 0.13,-0.588 0.049,-0.609 z"
id="path3185-28" />
<path
style="fill:none;stroke:#aae6ff;stroke-width:0.02"
d="m 171.425,286.061 -0.05,-0.599 -0.129,-0.569 -0.22,-0.589 -0.3,-0.569 -0.399,-0.579 -0.489,-0.559 -0.539,-0.549 -0.659,-0.549 -0.729,-0.529 -0.808,-0.529 -0.879,-0.489 -0.968,-0.49 -1.018,-0.489 -1.098,-0.449 -1.178,-0.439 -1.238,-0.399 -1.288,-0.4 -1.347,-0.369 -1.388,-0.34 -1.467,-0.329 -1.508,-0.289 -1.527,-0.27 -1.587,-0.25 -1.618,-0.219 -1.647,-0.19 -1.687,-0.16 -1.687,-0.139 -1.707,-0.08 -1.737,-0.09 -1.737,-0.05 -1.747,0 0,0 -1.737,0 -1.747,0.05 -1.727,0.09 -1.707,0.08 -1.697,0.139 -1.677,0.16 -1.647,0.19 -1.627,0.219 -1.577,0.25 -1.527,0.27 -1.518,0.289 -1.447,0.329 -1.388,0.34 -1.357,0.369 -1.308,0.4 -1.238,0.399 -1.158,0.439 -1.108,0.449 -1.028,0.489 -0.949,0.49 -0.868,0.489 -0.819,0.529 -0.738,0.529 -0.639,0.549 -0.559,0.549 -0.499,0.559 -0.37,0.579 -0.319,0.569 -0.22,0.589 -0.12,0.569 -0.049,0.599 0,0 0.049,0.589 0.12,0.579 0.22,0.579 0.319,0.569 0.37,0.579 0.499,0.559 0.559,0.549 0.639,0.529 0.738,0.549 0.819,0.529 0.868,0.499 0.949,0.479 1.028,0.48 1.108,0.459 1.158,0.429 1.238,0.409 1.308,0.38 1.357,0.389 1.388,0.339 1.447,0.32 1.518,0.309 1.527,0.26 1.577,0.239 1.627,0.23 1.647,0.18 1.677,0.149 1.697,0.15 1.707,0.09 1.727,0.08 1.747,0.04 1.737,0.02 0,0 1.747,-0.02 1.737,-0.04 1.737,-0.08 1.707,-0.09 1.687,-0.15 1.687,-0.149 1.647,-0.18 1.618,-0.23 1.587,-0.239 1.527,-0.26 1.508,-0.309 1.467,-0.32 1.388,-0.339 1.347,-0.389 1.288,-0.38 1.238,-0.409 1.178,-0.429 1.098,-0.459 1.018,-0.48 0.968,-0.479 0.879,-0.499 0.808,-0.529 0.729,-0.549 0.659,-0.529 0.539,-0.549 0.489,-0.559 0.399,-0.579 0.3,-0.569 0.22,-0.579 0.129,-0.579 0.05,-0.589"
id="path3187-8" />
<path
style="fill:#0078aa"
d="m 102.676,269.969 0,16.491 68.749,0 0,-16.491 -68.749,0 z"
id="path3189-9" />
<path
style="fill:#00b4ff"
d="m 171.824,269.739 -0.049,-0.579 -0.13,-0.598 -0.22,-0.589 -0.309,-0.589 -0.4,-0.589 -0.479,-0.569 -0.569,-0.559 -0.639,-0.559 -0.738,-0.53 -0.809,-0.529 -0.888,-0.509 -0.969,-0.519 -1.038,-0.469 -1.108,-0.469 -1.178,-0.439 -1.228,-0.41 -1.297,-0.399 -1.368,-0.379 -1.408,-0.35 -1.457,-0.329 -1.507,-0.31 -1.558,-0.259 -1.587,-0.27 -1.637,-0.219 -1.647,-0.19 -1.697,-0.16 -1.707,-0.119 -1.717,-0.11 -1.737,-0.08 -1.747,-0.06 -1.767,0 0,0 -1.747,0 -1.737,0.06 -1.737,0.08 -1.717,0.11 -1.707,0.119 -1.697,0.16 -1.647,0.19 -1.637,0.219 -1.587,0.27 -1.558,0.259 -1.517,0.31 -1.447,0.329 -1.408,0.35 -1.368,0.379 -1.297,0.399 -1.228,0.41 -1.178,0.439 -1.108,0.469 -1.038,0.469 -0.979,0.519 -0.878,0.509 -0.819,0.529 -0.728,0.53 -0.639,0.559 -0.569,0.559 -0.479,0.569 -0.4,0.589 -0.309,0.589 -0.23,0.589 -0.12,0.598 -0.049,0.579 0,0 0.049,0.609 0.12,0.599 0.23,0.589 0.309,0.579 0.4,0.589 0.479,0.559 0.569,0.579 0.639,0.549 0.728,0.539 0.819,0.529 0.878,0.51 0.979,0.509 1.038,0.479 1.108,0.439 1.178,0.459 1.228,0.42 1.297,0.399 1.368,0.379 1.408,0.35 1.447,0.319 1.517,0.309 1.558,0.27 1.587,0.26 1.637,0.219 1.647,0.19 1.697,0.16 1.707,0.119 1.717,0.11 1.737,0.09 1.737,0.05 1.747,0 0,0 1.767,0 1.747,-0.05 1.737,-0.09 1.717,-0.11 1.707,-0.119 1.697,-0.16 1.647,-0.19 1.637,-0.219 1.587,-0.26 1.558,-0.27 1.507,-0.309 1.457,-0.319 1.408,-0.35 1.368,-0.379 1.297,-0.399 1.228,-0.42 1.178,-0.459 1.108,-0.439 1.038,-0.479 0.969,-0.509 0.888,-0.51 0.809,-0.529 0.738,-0.539 0.639,-0.549 0.569,-0.579 0.479,-0.559 0.4,-0.589 0.309,-0.579 0.22,-0.589 0.13,-0.599 0.049,-0.609 z"
id="path3191-2" />
<path
style="fill:none;stroke:#aae6ff;stroke-width:0.02"
d="m 171.425,269.57 -0.05,-0.599 -0.129,-0.589 -0.22,-0.559 -0.3,-0.589 -0.399,-0.569 -0.489,-0.559 -0.539,-0.539 -0.659,-0.559 -0.729,-0.519 -0.808,-0.539 -0.879,-0.5 -0.968,-0.499 -1.018,-0.469 -1.098,-0.439 -1.178,-0.459 -1.238,-0.4 -1.288,-0.389 -1.347,-0.369 -1.388,-0.34 -1.467,-0.339 -1.508,-0.29 -1.527,-0.269 -1.587,-0.25 -1.618,-0.219 -1.647,-0.19 -1.687,-0.14 -1.687,-0.139 -1.707,-0.1 -1.737,-0.09 -1.737,-0.04 -1.747,-0.02 0,0 -1.737,0.02 -1.747,0.04 -1.727,0.09 -1.707,0.1 -1.697,0.139 -1.677,0.14 -1.647,0.19 -1.627,0.219 -1.577,0.25 -1.527,0.269 -1.518,0.29 -1.447,0.339 -1.388,0.34 -1.357,0.369 -1.308,0.389 -1.238,0.4 -1.158,0.459 -1.108,0.439 -1.028,0.469 -0.949,0.499 -0.868,0.5 -0.819,0.539 -0.738,0.519 -0.639,0.559 -0.559,0.539 -0.499,0.559 -0.37,0.569 -0.319,0.589 -0.22,0.559 -0.12,0.589 -0.049,0.599 0,0 0.049,0.579 0.12,0.589 0.22,0.559 0.319,0.579 0.37,0.579 0.499,0.559 0.559,0.559 0.639,0.549 0.738,0.529 0.819,0.519 0.868,0.509 0.949,0.469 1.028,0.489 1.108,0.45 1.158,0.439 1.238,0.409 1.308,0.389 1.357,0.37 1.388,0.339 1.447,0.33 1.518,0.309 1.527,0.25 1.577,0.259 1.627,0.21 1.647,0.189 1.677,0.17 1.697,0.14 1.707,0.08 1.727,0.08 1.747,0.05 1.737,0.01 0,0 1.747,-0.01 1.737,-0.05 1.737,-0.08 1.707,-0.08 1.687,-0.14 1.687,-0.17 1.647,-0.189 1.618,-0.21 1.587,-0.259 1.527,-0.25 1.508,-0.309 1.467,-0.33 1.388,-0.339 1.347,-0.37 1.288,-0.389 1.238,-0.409 1.178,-0.439 1.098,-0.45 1.018,-0.489 0.968,-0.469 0.879,-0.509 0.808,-0.519 0.729,-0.529 0.659,-0.549 0.539,-0.559 0.489,-0.559 0.399,-0.579 0.3,-0.579 0.22,-0.559 0.129,-0.589 0.05,-0.579"
id="path3193-8" />
<path
style="fill:#000000"
d="m 137.874,267.074 5.041,1.657 12.169,-4.961 5.44,1.657 -2.955,-4.123 -14.225,0 5.85,1.248 -11.32,4.522 z"
id="path3195-8" />
<path
style="fill:#000000"
d="m 135.768,271.626 -5.002,-1.657 -11.749,4.961 -5.86,-1.667 2.935,4.542 14.674,0 -6.299,-1.657 11.301,-4.522 z"
id="path3197-8" />
<path
style="fill:#000000"
d="m 114.405,262.552 5.031,-1.657 12.149,4.532 5.46,-1.228 -2.925,4.113 -14.265,0 5.86,-1.238 -11.31,-4.522 z"
id="path3199-6" />
<path
style="fill:#000000"
d="m 159.676,276.568 -5.021,1.647 -11.74,-4.952 -5.87,1.667 2.935,-4.132 14.675,0 -6.299,1.217 11.32,4.553 z"
id="path3201-8" />
<path
style="fill:#ffffff"
d="m 138.293,267.483 5.051,1.648 12.149,-4.932 5.451,1.657 -2.935,-4.142 -14.265,0 5.879,1.237 -11.33,4.532 z"
id="path3203-3" />
<path
style="fill:#ffffff"
d="m 136.217,272.015 -5.051,-1.637 -11.73,4.952 -5.87,-1.657 2.935,4.542 14.665,0 -6.269,-1.647 11.32,-4.553 z"
id="path3205-8" />
<path
style="fill:#ffffff"
d="m 114.834,262.951 5.021,-1.647 12.159,4.552 5.451,-1.258 -2.935,4.133 -14.255,0 5.879,-1.248 -11.32,-4.532 z"
id="path3207-3" />
<path
style="fill:#ffffff"
d="m 160.105,276.977 -5.021,1.657 -11.74,-4.961 -5.879,1.657 2.925,-4.113 14.694,0 -6.289,1.228 11.31,4.532 z"
id="path3209-3" />
<path
style="fill:none;stroke:#aae6ff;stroke-width:0.02"
d="m 102.676,269.57 0,16.471"
id="path3211-3" />
<path
style="fill:none;stroke:#aae6ff;stroke-width:0.02"
d="m 171.425,269.57 0,16.471"
id="path3213-8" />
<path
style="fill:#000000"
d="m 124.467,283.995 7.547,0 4.612,3.713 4.602,-3.713 7.128,0 0,-1.648 5.041,2.456 -5.041,2.486 0,-1.647 -6.279,0 -4.203,2.885 4.203,3.284 6.279,0 0,-2.037 5.041,2.875 -5.041,2.486 0,-1.667 -7.128,0 -4.602,-3.694 -4.612,3.694 -7.547,0 0,1.667 -5.031,-2.486 5.031,-2.875 0,2.037 6.699,0 4.202,-2.875 -4.202,-3.294 -6.699,0 0,1.647 -5.031,-2.486 5.031,-2.456 0,1.648 z"
id="path3215-0" />
<path
style="fill:#ffffff"
d="m 124.897,284.394 7.536,0 4.612,3.703 4.602,-3.703 7.148,0 0,-1.647 5.011,2.485 -5.011,2.476 0,-1.647 -6.299,0 -4.203,2.875 4.203,3.294 6.299,0 0,-2.056 5.011,2.885 -5.011,2.475 0,-1.657 -7.148,0 -4.602,-3.703 -4.612,3.703 -7.536,0 0,1.657 -5.042,-2.475 5.042,-2.885 0,2.056 6.688,0 4.183,-2.885 -4.183,-3.284 -6.688,0 0,1.647 -5.042,-2.476 5.042,-2.485 0,1.647 z"
id="path3217-4" />
</g>
<path
style="fill:none;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-end:url(#Arrow1Lend)"
d="M -24.172561,102.99613 83.027492,-13.662752"
id="path3144"
transform="matrix(0.5604127,0,0,0.5604127,97,159)" />
<path
style="fill:none;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-end:url(#Arrow1Lend)"
d="M -35.733351,87.231415 81.976511,-112.45496"
id="path3146"
transform="matrix(0.5604127,0,0,0.5604127,97,159)" />
<path
style="fill:none;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-end:url(#Arrow1Lend)"
d="m 175.51381,-125.06673 139.78046,0"
id="path3148"
transform="matrix(0.5604127,0,0,0.5604127,97,159)" />
<path
style="fill:none;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-end:url(#Arrow1Lend)"
d="m 173.41185,-27.325504 141.88242,0"
id="path3150"
transform="matrix(0.5604127,0,0,0.5604127,97,159)" />
<text
xml:space="preserve"
style="font-size:6.16453981px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans"
x="165.27502"
y="181.54456"
id="text3232-2-6"><tspan
sodipodi:role="line"
id="tspan3234-0-7"
x="165.27502"
y="181.54456"
style="font-size:11.20825386px">...</tspan></text>
</svg>
Side by Side

After

Width:  |  Height:  |  Size: 46 KiB

368
www.i2p2/image_design/i2ptunnel_serverclient.svg Normal file
View File

@ -0,0 +1,368 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<svg
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:cc="http://creativecommons.org/ns#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:svg="http://www.w3.org/2000/svg"
xmlns="http://www.w3.org/2000/svg"
xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
width="7cm"
height="7cm"
viewBox="102 159 129 139"
id="svg3091"
version="1.1"
inkscape:version="0.47pre4 r22446"
sodipodi:docname="i2ptunnel_serverclient.svg"
inkscape:export-filename="/home/mathias/Documents/I2P/i2p.www/www.i2p2/static/images/i2ptunnel_serverclient.png"
inkscape:export-xdpi="49.999134"
inkscape:export-ydpi="49.999134">
<metadata
id="metadata3257">
<rdf:RDF>
<cc:Work
rdf:about="">
<dc:format>image/svg+xml</dc:format>
<dc:type
rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
<dc:title></dc:title>
</cc:Work>
</rdf:RDF>
</metadata>
<defs
id="defs3255">
<marker
inkscape:stockid="Arrow1Lend"
orient="auto"
refY="0.0"
refX="0.0"
id="Arrow1Lend"
style="overflow:visible;">
<path
id="path4394"
d="M 0.0,0.0 L 5.0,-5.0 L -12.5,0.0 L 5.0,5.0 L 0.0,0.0 z "
style="fill-rule:evenodd;stroke:#000000;stroke-width:1.0pt;marker-start:none;"
transform="scale(0.8) rotate(180) translate(12.5,0)" />
</marker>
<inkscape:perspective
sodipodi:type="inkscape:persp3d"
inkscape:vp_x="0 : 124.01575 : 1"
inkscape:vp_y="0 : 1000 : 0"
inkscape:vp_z="248.03149 : 124.01575 : 1"
inkscape:persp3d-origin="124.01575 : 82.677165 : 1"
id="perspective3259" />
<inkscape:perspective
id="perspective3524"
inkscape:persp3d-origin="0.5 : 0.33333333 : 1"
inkscape:vp_z="1 : 0.5 : 1"
inkscape:vp_y="0 : 1000 : 0"
inkscape:vp_x="0 : 0.5 : 1"
sodipodi:type="inkscape:persp3d" />
<inkscape:perspective
id="perspective3597"
inkscape:persp3d-origin="0.5 : 0.33333333 : 1"
inkscape:vp_z="1 : 0.5 : 1"
inkscape:vp_y="0 : 1000 : 0"
inkscape:vp_x="0 : 0.5 : 1"
sodipodi:type="inkscape:persp3d" />
</defs>
<sodipodi:namedview
pagecolor="#ffffff"
bordercolor="#666666"
borderopacity="1"
objecttolerance="10"
gridtolerance="10"
guidetolerance="10"
inkscape:pageopacity="0"
inkscape:pageshadow="2"
inkscape:window-width="1280"
inkscape:window-height="726"
id="namedview3253"
showgrid="false"
inkscape:zoom="0.95149207"
inkscape:cx="124.01575"
inkscape:cy="124.01575"
inkscape:window-x="0"
inkscape:window-y="25"
inkscape:window-maximized="1"
inkscape:current-layer="svg3091" />
<g
id="g3093"
transform="translate(-124.27542,48.29661)">
<path
style="fill:#b7b79d"
d="m 170.897,186.814 39.968,0 0,7.386 -39.968,0 0,-7.386 z"
id="path3095" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 170.897,186.814 39.968,0 0,7.386 -39.968,0 0,-7.386"
id="path3097" />
<path
style="fill:#c9c9b6"
d="m 170.897,186.814 4.238,-4.018 39.968,0 -4.238,4.018 -39.968,0 z"
id="path3099" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 170.897,186.814 4.238,-4.018 39.968,0 -4.238,4.018 -39.968,0"
id="path3101" />
<path
style="fill:none;stroke:#000000;stroke-width:2.11999989"
d="m 208.63,190.176 -9.591,0"
id="path3103" />
<path
style="fill:#7a7a5a"
d="m 210.865,194.2 4.238,-4.25 0,-7.154 -4.238,4.018 0,7.386 z"
id="path3105" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 210.865,194.2 4.238,-4.25 0,-7.154 -4.238,4.018 0,7.386"
id="path3107" />
<path
style="fill:#c9c9b6"
d="m 171.123,198.885 4.459,-5.585 30.819,0 -4.459,5.585 -30.819,0 z"
id="path3109" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 171.123,198.885 4.459,-5.585 30.819,0 -4.459,5.585 -30.819,0"
id="path3111" />
<path
style="fill:#7a7a5a"
d="m 201.942,200 4.459,-4.685 0,-2.015 -4.459,5.585 0,1.115 z"
id="path3113" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 201.942,200 4.459,-4.685 0,-2.015 -4.459,5.585 0,1.115"
id="path3115" />
<path
style="fill:#b7b79d"
d="m 171.123,198.885 30.819,0 0,1.115 -30.819,0 0,-1.115 z"
id="path3117" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 171.123,198.885 30.819,0 0,1.115 -30.819,0 0,-1.115"
id="path3119" />
<path
style="fill:#000000"
d="m 176.923,185.926 3.357,-3.13 28.35,0 -3.117,3.13 -28.59,0 z"
id="path3121" />
<path
style="fill:none;stroke:#000000;stroke-width:0.02"
d="m 176.923,185.926 3.357,-3.13 28.35,0 -3.117,3.13 -28.59,0"
id="path3123" />
<path
style="fill:#c9c9b6"
d="m 176.696,162.903 3.136,-2.903 28.363,0 -3.136,2.903 -28.363,0 z"
id="path3125" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 176.696,162.903 3.136,-2.903 28.363,0 -3.136,2.903 -28.363,0"
id="path3127" />
<path
style="fill:#b7b79d"
d="m 176.696,162.903 28.59,0 0,22.569 -28.59,0 0,-22.569 z"
id="path3129" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 176.696,162.903 28.577,0 0,22.563 -28.577,0 0,-22.563"
id="path3131" />
<path
style="fill:#ffffff"
d="m 179.152,165.8 23.672,0 0,17.437 -23.672,0 0,-17.437 z"
id="path3133" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 179.152,165.8 23.672,0 0,17.43 -23.672,0 0,-17.43"
id="path3135" />
<path
style="fill:#7a7a5a"
d="m 205.059,185.258 3.136,-3.13 0,-22.128 -3.136,2.903 0,22.355 z"
id="path3137" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 205.059,185.258 3.136,-3.13 0,-22.128 -3.136,2.903 0,22.355"
id="path3139" />
</g>
<g
id="g3219"
transform="translate(134.87712,28.099763)">
<path
style="fill:#b7b79d"
d="m 139.83,178.978 0,37.022 21.882,0 0,-37.022 -21.882,0 z"
id="path3221" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 139.83,178.978 0,37.022 21.882,0 0,-37.022 -21.882,0"
id="path3223" />
<path
style="fill:#c9c9b6"
d="m 139.83,178.978 2.965,-2.978 21.875,0 -2.958,2.978 -21.882,0 z"
id="path3225" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 139.83,178.978 2.965,-2.978 21.731,0"
id="path3227" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 164.526,176.151 -2.814,2.827 -21.882,0"
id="path3229" />
<path
style="fill:#c9c9b6"
d="m 141.178,181.132 9.995,0 0,4.857 -9.995,0 0,-4.857 z"
id="path3231" />
<path
style="fill:none;stroke:#626248;stroke-width:0.02"
d="m 141.178,181.132 9.989,0 0,4.85 -9.989,0 0,-4.85"
id="path3233" />
<path
style="fill:none;stroke:#ecece7;stroke-width:0.60000002"
d="m 142.527,183.567 7.01,0"
id="path3235" />
<path
style="fill:#7a7a5a"
d="m 161.712,216 2.958,-2.985 0,-37.015 -2.958,2.978 0,37.022 z"
id="path3237" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 161.712,216 2.814,-2.834"
id="path3239" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 164.526,176.151 -2.814,2.827 0,37.022"
id="path3241" />
<path
style="fill:none;stroke:#ecece7;stroke-width:0.60000002"
d="m 140.105,213.559 21.6,0"
id="path3243" />
<path
style="fill:none;stroke:#000000;stroke-width:0.60000002"
d="m 140.105,193.837 21.6,0"
id="path3245" />
<path
style="fill:none;stroke:#494936;stroke-width:0.60000002"
d="m 139.83,213.29 21.855,0"
id="path3247" />
<path
style="fill:none;stroke:#000000;stroke-width:0.60000002"
d="m 139.83,193.562 21.855,0"
id="path3249" />
<path
style="fill:none;stroke:#ecece7;stroke-width:0.02"
d="m 141.178,185.727 0,-4.595 9.72,0"
id="path3251" />
</g>
<text
xml:space="preserve"
style="font-size:6.16453981px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans"
x="52.2197"
y="266.53781"
id="text3232"><tspan
sodipodi:role="line"
id="tspan3234"
x="52.2197"
y="266.53781"
style="font-size:11.20825386px">Client</tspan></text>
<text
xml:space="preserve"
style="font-size:16.81238174px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans"
x="268.38885"
y="267.14429"
id="text3236"><tspan
sodipodi:role="line"
id="tspan3238"
x="268.38885"
y="267.14429"
style="font-size:11.20825386px">Server</tspan></text>
<g
transform="matrix(0.75311128,0,0,0.75311128,66.977055,17.740053)"
id="g3183">
<path
style="fill:#0078aa"
d="m 171.824,286.241 -0.049,-0.589 -0.13,-0.599 -0.22,-0.589 -0.309,-0.579 -0.4,-0.589 -0.479,-0.579 -0.569,-0.559 -0.639,-0.549 -0.738,-0.539 -0.809,-0.519 -0.888,-0.52 -0.969,-0.499 -1.038,-0.479 -1.108,-0.469 -1.178,-0.439 -1.228,-0.42 -1.297,-0.399 -1.368,-0.369 -1.408,-0.37 -1.457,-0.309 -1.507,-0.309 -1.558,-0.27 -1.587,-0.26 -1.637,-0.219 -1.647,-0.19 -1.697,-0.16 -1.707,-0.139 -1.717,-0.11 -1.737,-0.08 -1.747,-0.03 -1.767,-0.03 0,0 -1.747,0.03 -1.737,0.03 -1.737,0.08 -1.717,0.11 -1.707,0.139 -1.697,0.16 -1.647,0.19 -1.637,0.219 -1.587,0.26 -1.558,0.27 -1.517,0.309 -1.447,0.309 -1.408,0.37 -1.368,0.369 -1.297,0.399 -1.228,0.42 -1.178,0.439 -1.108,0.469 -1.038,0.479 -0.979,0.499 -0.878,0.52 -0.819,0.519 -0.728,0.539 -0.639,0.549 -0.569,0.559 -0.479,0.579 -0.4,0.589 -0.309,0.579 -0.23,0.589 -0.12,0.599 -0.049,0.589 0,0 0.049,0.609 0.12,0.588 0.23,0.589 0.309,0.589 0.4,0.579 0.479,0.579 0.569,0.559 0.639,0.549 0.728,0.54 0.819,0.529 0.878,0.499 0.979,0.519 1.038,0.479 1.108,0.459 1.178,0.429 1.228,0.43 1.297,0.399 1.368,0.379 1.408,0.35 1.447,0.329 1.517,0.3 1.558,0.269 1.587,0.26 1.637,0.219 1.647,0.19 1.697,0.17 1.707,0.119 1.717,0.11 1.737,0.08 1.737,0.05 1.747,0.01 0,0 1.767,-0.01 1.747,-0.05 1.737,-0.08 1.717,-0.11 1.707,-0.119 1.697,-0.17 1.647,-0.19 1.637,-0.219 1.587,-0.26 1.558,-0.269 1.507,-0.3 1.457,-0.329 1.408,-0.35 1.368,-0.379 1.297,-0.399 1.228,-0.43 1.178,-0.429 1.108,-0.459 1.038,-0.479 0.969,-0.519 0.888,-0.499 0.809,-0.529 0.738,-0.54 0.639,-0.549 0.569,-0.559 0.479,-0.579 0.4,-0.579 0.309,-0.589 0.22,-0.589 0.13,-0.588 0.049,-0.609 z"
id="path3185" />
<path
style="fill:none;stroke:#aae6ff;stroke-width:0.02"
d="m 171.425,286.061 -0.05,-0.599 -0.129,-0.569 -0.22,-0.589 -0.3,-0.569 -0.399,-0.579 -0.489,-0.559 -0.539,-0.549 -0.659,-0.549 -0.729,-0.529 -0.808,-0.529 -0.879,-0.489 -0.968,-0.49 -1.018,-0.489 -1.098,-0.449 -1.178,-0.439 -1.238,-0.399 -1.288,-0.4 -1.347,-0.369 -1.388,-0.34 -1.467,-0.329 -1.508,-0.289 -1.527,-0.27 -1.587,-0.25 -1.618,-0.219 -1.647,-0.19 -1.687,-0.16 -1.687,-0.139 -1.707,-0.08 -1.737,-0.09 -1.737,-0.05 -1.747,0 0,0 -1.737,0 -1.747,0.05 -1.727,0.09 -1.707,0.08 -1.697,0.139 -1.677,0.16 -1.647,0.19 -1.627,0.219 -1.577,0.25 -1.527,0.27 -1.518,0.289 -1.447,0.329 -1.388,0.34 -1.357,0.369 -1.308,0.4 -1.238,0.399 -1.158,0.439 -1.108,0.449 -1.028,0.489 -0.949,0.49 -0.868,0.489 -0.819,0.529 -0.738,0.529 -0.639,0.549 -0.559,0.549 -0.499,0.559 -0.37,0.579 -0.319,0.569 -0.22,0.589 -0.12,0.569 -0.049,0.599 0,0 0.049,0.589 0.12,0.579 0.22,0.579 0.319,0.569 0.37,0.579 0.499,0.559 0.559,0.549 0.639,0.529 0.738,0.549 0.819,0.529 0.868,0.499 0.949,0.479 1.028,0.48 1.108,0.459 1.158,0.429 1.238,0.409 1.308,0.38 1.357,0.389 1.388,0.339 1.447,0.32 1.518,0.309 1.527,0.26 1.577,0.239 1.627,0.23 1.647,0.18 1.677,0.149 1.697,0.15 1.707,0.09 1.727,0.08 1.747,0.04 1.737,0.02 0,0 1.747,-0.02 1.737,-0.04 1.737,-0.08 1.707,-0.09 1.687,-0.15 1.687,-0.149 1.647,-0.18 1.618,-0.23 1.587,-0.239 1.527,-0.26 1.508,-0.309 1.467,-0.32 1.388,-0.339 1.347,-0.389 1.288,-0.38 1.238,-0.409 1.178,-0.429 1.098,-0.459 1.018,-0.48 0.968,-0.479 0.879,-0.499 0.808,-0.529 0.729,-0.549 0.659,-0.529 0.539,-0.549 0.489,-0.559 0.399,-0.579 0.3,-0.569 0.22,-0.579 0.129,-0.579 0.05,-0.589"
id="path3187" />
<path
style="fill:#0078aa"
d="m 102.676,269.969 0,16.491 68.749,0 0,-16.491 -68.749,0 z"
id="path3189" />
<path
style="fill:#00b4ff"
d="m 171.824,269.739 -0.049,-0.579 -0.13,-0.598 -0.22,-0.589 -0.309,-0.589 -0.4,-0.589 -0.479,-0.569 -0.569,-0.559 -0.639,-0.559 -0.738,-0.53 -0.809,-0.529 -0.888,-0.509 -0.969,-0.519 -1.038,-0.469 -1.108,-0.469 -1.178,-0.439 -1.228,-0.41 -1.297,-0.399 -1.368,-0.379 -1.408,-0.35 -1.457,-0.329 -1.507,-0.31 -1.558,-0.259 -1.587,-0.27 -1.637,-0.219 -1.647,-0.19 -1.697,-0.16 -1.707,-0.119 -1.717,-0.11 -1.737,-0.08 -1.747,-0.06 -1.767,0 0,0 -1.747,0 -1.737,0.06 -1.737,0.08 -1.717,0.11 -1.707,0.119 -1.697,0.16 -1.647,0.19 -1.637,0.219 -1.587,0.27 -1.558,0.259 -1.517,0.31 -1.447,0.329 -1.408,0.35 -1.368,0.379 -1.297,0.399 -1.228,0.41 -1.178,0.439 -1.108,0.469 -1.038,0.469 -0.979,0.519 -0.878,0.509 -0.819,0.529 -0.728,0.53 -0.639,0.559 -0.569,0.559 -0.479,0.569 -0.4,0.589 -0.309,0.589 -0.23,0.589 -0.12,0.598 -0.049,0.579 0,0 0.049,0.609 0.12,0.599 0.23,0.589 0.309,0.579 0.4,0.589 0.479,0.559 0.569,0.579 0.639,0.549 0.728,0.539 0.819,0.529 0.878,0.51 0.979,0.509 1.038,0.479 1.108,0.439 1.178,0.459 1.228,0.42 1.297,0.399 1.368,0.379 1.408,0.35 1.447,0.319 1.517,0.309 1.558,0.27 1.587,0.26 1.637,0.219 1.647,0.19 1.697,0.16 1.707,0.119 1.717,0.11 1.737,0.09 1.737,0.05 1.747,0 0,0 1.767,0 1.747,-0.05 1.737,-0.09 1.717,-0.11 1.707,-0.119 1.697,-0.16 1.647,-0.19 1.637,-0.219 1.587,-0.26 1.558,-0.27 1.507,-0.309 1.457,-0.319 1.408,-0.35 1.368,-0.379 1.297,-0.399 1.228,-0.42 1.178,-0.459 1.108,-0.439 1.038,-0.479 0.969,-0.509 0.888,-0.51 0.809,-0.529 0.738,-0.539 0.639,-0.549 0.569,-0.579 0.479,-0.559 0.4,-0.589 0.309,-0.579 0.22,-0.589 0.13,-0.599 0.049,-0.609 z"
id="path3191" />
<path
style="fill:none;stroke:#aae6ff;stroke-width:0.02"
d="m 171.425,269.57 -0.05,-0.599 -0.129,-0.589 -0.22,-0.559 -0.3,-0.589 -0.399,-0.569 -0.489,-0.559 -0.539,-0.539 -0.659,-0.559 -0.729,-0.519 -0.808,-0.539 -0.879,-0.5 -0.968,-0.499 -1.018,-0.469 -1.098,-0.439 -1.178,-0.459 -1.238,-0.4 -1.288,-0.389 -1.347,-0.369 -1.388,-0.34 -1.467,-0.339 -1.508,-0.29 -1.527,-0.269 -1.587,-0.25 -1.618,-0.219 -1.647,-0.19 -1.687,-0.14 -1.687,-0.139 -1.707,-0.1 -1.737,-0.09 -1.737,-0.04 -1.747,-0.02 0,0 -1.737,0.02 -1.747,0.04 -1.727,0.09 -1.707,0.1 -1.697,0.139 -1.677,0.14 -1.647,0.19 -1.627,0.219 -1.577,0.25 -1.527,0.269 -1.518,0.29 -1.447,0.339 -1.388,0.34 -1.357,0.369 -1.308,0.389 -1.238,0.4 -1.158,0.459 -1.108,0.439 -1.028,0.469 -0.949,0.499 -0.868,0.5 -0.819,0.539 -0.738,0.519 -0.639,0.559 -0.559,0.539 -0.499,0.559 -0.37,0.569 -0.319,0.589 -0.22,0.559 -0.12,0.589 -0.049,0.599 0,0 0.049,0.579 0.12,0.589 0.22,0.559 0.319,0.579 0.37,0.579 0.499,0.559 0.559,0.559 0.639,0.549 0.738,0.529 0.819,0.519 0.868,0.509 0.949,0.469 1.028,0.489 1.108,0.45 1.158,0.439 1.238,0.409 1.308,0.389 1.357,0.37 1.388,0.339 1.447,0.33 1.518,0.309 1.527,0.25 1.577,0.259 1.627,0.21 1.647,0.189 1.677,0.17 1.697,0.14 1.707,0.08 1.727,0.08 1.747,0.05 1.737,0.01 0,0 1.747,-0.01 1.737,-0.05 1.737,-0.08 1.707,-0.08 1.687,-0.14 1.687,-0.17 1.647,-0.189 1.618,-0.21 1.587,-0.259 1.527,-0.25 1.508,-0.309 1.467,-0.33 1.388,-0.339 1.347,-0.37 1.288,-0.389 1.238,-0.409 1.178,-0.439 1.098,-0.45 1.018,-0.489 0.968,-0.469 0.879,-0.509 0.808,-0.519 0.729,-0.529 0.659,-0.549 0.539,-0.559 0.489,-0.559 0.399,-0.579 0.3,-0.579 0.22,-0.559 0.129,-0.589 0.05,-0.579"
id="path3193" />
<path
style="fill:#000000"
d="m 137.874,267.074 5.041,1.657 12.169,-4.961 5.44,1.657 -2.955,-4.123 -14.225,0 5.85,1.248 -11.32,4.522 z"
id="path3195" />
<path
style="fill:#000000"
d="m 135.768,271.626 -5.002,-1.657 -11.749,4.961 -5.86,-1.667 2.935,4.542 14.674,0 -6.299,-1.657 11.301,-4.522 z"
id="path3197" />
<path
style="fill:#000000"
d="m 114.405,262.552 5.031,-1.657 12.149,4.532 5.46,-1.228 -2.925,4.113 -14.265,0 5.86,-1.238 -11.31,-4.522 z"
id="path3199" />
<path
style="fill:#000000"
d="m 159.676,276.568 -5.021,1.647 -11.74,-4.952 -5.87,1.667 2.935,-4.132 14.675,0 -6.299,1.217 11.32,4.553 z"
id="path3201" />
<path
style="fill:#ffffff"
d="m 138.293,267.483 5.051,1.648 12.149,-4.932 5.451,1.657 -2.935,-4.142 -14.265,0 5.879,1.237 -11.33,4.532 z"
id="path3203" />
<path
style="fill:#ffffff"
d="m 136.217,272.015 -5.051,-1.637 -11.73,4.952 -5.87,-1.657 2.935,4.542 14.665,0 -6.269,-1.647 11.32,-4.553 z"
id="path3205" />
<path
style="fill:#ffffff"
d="m 114.834,262.951 5.021,-1.647 12.159,4.552 5.451,-1.258 -2.935,4.133 -14.255,0 5.879,-1.248 -11.32,-4.532 z"
id="path3207" />
<path
style="fill:#ffffff"
d="m 160.105,276.977 -5.021,1.657 -11.74,-4.961 -5.879,1.657 2.925,-4.113 14.694,0 -6.289,1.228 11.31,4.532 z"
id="path3209" />
<path
style="fill:none;stroke:#aae6ff;stroke-width:0.02"
d="m 102.676,269.57 0,16.471"
id="path3211" />
<path
style="fill:none;stroke:#aae6ff;stroke-width:0.02"
d="m 171.425,269.57 0,16.471"
id="path3213" />
<path
style="fill:#000000"
d="m 124.467,283.995 7.547,0 4.612,3.713 4.602,-3.713 7.128,0 0,-1.648 5.041,2.456 -5.041,2.486 0,-1.647 -6.279,0 -4.203,2.885 4.203,3.284 6.279,0 0,-2.037 5.041,2.875 -5.041,2.486 0,-1.667 -7.128,0 -4.602,-3.694 -4.612,3.694 -7.547,0 0,1.667 -5.031,-2.486 5.031,-2.875 0,2.037 6.699,0 4.202,-2.875 -4.202,-3.294 -6.699,0 0,1.647 -5.031,-2.486 5.031,-2.456 0,1.648 z"
id="path3215" />
<path
style="fill:#ffffff"
d="m 124.897,284.394 7.536,0 4.612,3.703 4.602,-3.703 7.148,0 0,-1.647 5.011,2.485 -5.011,2.476 0,-1.647 -6.299,0 -4.203,2.875 4.203,3.294 6.299,0 0,-2.056 5.011,2.885 -5.011,2.475 0,-1.657 -7.148,0 -4.602,-3.703 -4.612,3.703 -7.536,0 0,1.657 -5.042,-2.475 5.042,-2.885 0,2.056 6.688,0 4.183,-2.885 -4.183,-3.284 -6.688,0 0,1.647 -5.042,-2.476 5.042,-2.485 0,1.647 z"
id="path3217" />
</g>
<text
xml:space="preserve"
style="font-size:6.16453981px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans"
x="143.47925"
y="266.56204"
id="text3232-1"><tspan
sodipodi:role="line"
id="tspan3234-7"
x="143.47925"
y="266.56204"
style="font-size:11.20825386px">I2PTunnel</tspan></text>
<path
style="fill:none;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-end:url(#Arrow1Lend)"
d="m -23.12158,114.55692 106.149072,0"
id="path3614"
transform="matrix(0.5604127,0,0,0.5604127,97,159)" />
<path
style="fill:none;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-end:url(#Arrow1Lend)"
d="m 176.56479,114.55692 140.83144,0"
id="path4836"
transform="matrix(0.5604127,0,0,0.5604127,97,159)" />
</svg>
Side by Side

After

Width:  |  Height:  |  Size: 19 KiB

952
www.i2p2/image_design/netdb_get_leaseset.svg Normal file
View File

@ -0,0 +1,952 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<svg
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:cc="http://creativecommons.org/ns#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:svg="http://www.w3.org/2000/svg"
xmlns="http://www.w3.org/2000/svg"
xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
width="7cm"
height="7cm"
viewBox="102 159 129 139"
id="svg3091"
version="1.1"
inkscape:version="0.47pre4 r22446"
sodipodi:docname="netdb_get_leaseset.svg"
inkscape:export-filename="/home/mathias/Documents/I2P/i2p.www/www.i2p2/image_design/netdb_get_leaseset.png"
inkscape:export-xdpi="49.999134"
inkscape:export-ydpi="49.999134">
<metadata
id="metadata3257">
<rdf:RDF>
<cc:Work
rdf:about="">
<dc:format>image/svg+xml</dc:format>
<dc:type
rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
<dc:title></dc:title>
</cc:Work>
</rdf:RDF>
</metadata>
<defs
id="defs3255">
<marker
inkscape:stockid="Arrow1Lend"
orient="auto"
refY="0.0"
refX="0.0"
id="Arrow1Lend"
style="overflow:visible;">
<path
id="path4855"
d="M 0.0,0.0 L 5.0,-5.0 L -12.5,0.0 L 5.0,5.0 L 0.0,0.0 z "
style="fill-rule:evenodd;stroke:#000000;stroke-width:1.0pt;marker-start:none;"
transform="scale(0.8) rotate(180) translate(12.5,0)" />
</marker>
<linearGradient
id="linearGradient4351">
<stop
style="stop-color:#cacaff;stop-opacity:1;"
offset="0"
id="stop4353" />
<stop
style="stop-color:#cacaff;stop-opacity:0;"
offset="1"
id="stop4355" />
</linearGradient>
<inkscape:perspective
sodipodi:type="inkscape:persp3d"
inkscape:vp_x="0 : 124.01575 : 1"
inkscape:vp_y="0 : 1000 : 0"
inkscape:vp_z="248.03149 : 124.01575 : 1"
inkscape:persp3d-origin="124.01575 : 82.677165 : 1"
id="perspective3259" />
<inkscape:perspective
id="perspective3365"
inkscape:persp3d-origin="0.5 : 0.33333333 : 1"
inkscape:vp_z="1 : 0.5 : 1"
inkscape:vp_y="0 : 1000 : 0"
inkscape:vp_x="0 : 0.5 : 1"
sodipodi:type="inkscape:persp3d" />
<inkscape:perspective
id="perspective3456"
inkscape:persp3d-origin="0.5 : 0.33333333 : 1"
inkscape:vp_z="1 : 0.5 : 1"
inkscape:vp_y="0 : 1000 : 0"
inkscape:vp_x="0 : 0.5 : 1"
sodipodi:type="inkscape:persp3d" />
<inkscape:perspective
id="perspective5313"
inkscape:persp3d-origin="0.5 : 0.33333333 : 1"
inkscape:vp_z="1 : 0.5 : 1"
inkscape:vp_y="0 : 1000 : 0"
inkscape:vp_x="0 : 0.5 : 1"
sodipodi:type="inkscape:persp3d" />
<inkscape:perspective
id="perspective5313-8"
inkscape:persp3d-origin="0.5 : 0.33333333 : 1"
inkscape:vp_z="1 : 0.5 : 1"
inkscape:vp_y="0 : 1000 : 0"
inkscape:vp_x="0 : 0.5 : 1"
sodipodi:type="inkscape:persp3d" />
<inkscape:perspective
id="perspective5535"
inkscape:persp3d-origin="0.5 : 0.33333333 : 1"
inkscape:vp_z="1 : 0.5 : 1"
inkscape:vp_y="0 : 1000 : 0"
inkscape:vp_x="0 : 0.5 : 1"
sodipodi:type="inkscape:persp3d" />
<inkscape:perspective
id="perspective6324"
inkscape:persp3d-origin="0.5 : 0.33333333 : 1"
inkscape:vp_z="1 : 0.5 : 1"
inkscape:vp_y="0 : 1000 : 0"
inkscape:vp_x="0 : 0.5 : 1"
sodipodi:type="inkscape:persp3d" />
<inkscape:perspective
id="perspective6580"
inkscape:persp3d-origin="0.5 : 0.33333333 : 1"
inkscape:vp_z="1 : 0.5 : 1"
inkscape:vp_y="0 : 1000 : 0"
inkscape:vp_x="0 : 0.5 : 1"
sodipodi:type="inkscape:persp3d" />
<marker
inkscape:stockid="Arrow1Lend"
orient="auto"
refY="0"
refX="0"
id="Arrow1Lend-7"
style="overflow:visible">
<path
id="path4855-9"
d="M 0,0 5,-5 -12.5,0 5,5 0,0 z"
style="fill-rule:evenodd;stroke:#000000;stroke-width:1pt;marker-start:none"
transform="matrix(-0.8,0,0,-0.8,-10,0)" />
</marker>
<marker
inkscape:stockid="Arrow1Lend"
orient="auto"
refY="0"
refX="0"
id="marker6586"
style="overflow:visible">
<path
id="path6588"
d="M 0,0 5,-5 -12.5,0 5,5 0,0 z"
style="fill-rule:evenodd;stroke:#000000;stroke-width:1pt;marker-start:none"
transform="matrix(-0.8,0,0,-0.8,-10,0)" />
</marker>
<inkscape:perspective
id="perspective6874"
inkscape:persp3d-origin="0.5 : 0.33333333 : 1"
inkscape:vp_z="1 : 0.5 : 1"
inkscape:vp_y="0 : 1000 : 0"
inkscape:vp_x="0 : 0.5 : 1"
sodipodi:type="inkscape:persp3d" />
<marker
inkscape:stockid="Arrow1Lend"
orient="auto"
refY="0"
refX="0"
id="Arrow1Lend-5"
style="overflow:visible">
<path
id="path4855-3"
d="M 0,0 5,-5 -12.5,0 5,5 0,0 z"
style="fill-rule:evenodd;stroke:#000000;stroke-width:1pt;marker-start:none"
transform="matrix(-0.8,0,0,-0.8,-10,0)" />
</marker>
<marker
inkscape:stockid="Arrow1Lend"
orient="auto"
refY="0"
refX="0"
id="marker6880"
style="overflow:visible">
<path
id="path6882"
d="M 0,0 5,-5 -12.5,0 5,5 0,0 z"
style="fill-rule:evenodd;stroke:#000000;stroke-width:1pt;marker-start:none"
transform="matrix(-0.8,0,0,-0.8,-10,0)" />
</marker>
<inkscape:perspective
id="perspective6932"
inkscape:persp3d-origin="0.5 : 0.33333333 : 1"
inkscape:vp_z="1 : 0.5 : 1"
inkscape:vp_y="0 : 1000 : 0"
inkscape:vp_x="0 : 0.5 : 1"
sodipodi:type="inkscape:persp3d" />
</defs>
<sodipodi:namedview
pagecolor="#ffffff"
bordercolor="#666666"
borderopacity="1"
objecttolerance="10"
gridtolerance="10"
guidetolerance="10"
inkscape:pageopacity="0"
inkscape:pageshadow="2"
inkscape:window-width="1280"
inkscape:window-height="726"
id="namedview3253"
showgrid="false"
inkscape:zoom="0.95149207"
inkscape:cx="251.92816"
inkscape:cy="112.51086"
inkscape:window-x="0"
inkscape:window-y="25"
inkscape:window-maximized="1"
inkscape:current-layer="layer1" />
<g
inkscape:groupmode="layer"
id="layer2"
inkscape:label="Pictures">
<g
style="display:inline"
id="g3093"
transform="translate(-185.52966,11.190679)">
<path
style="fill:#b7b79d"
d="m 170.897,186.814 39.968,0 0,7.386 -39.968,0 0,-7.386 z"
id="path3095" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 170.897,186.814 39.968,0 0,7.386 -39.968,0 0,-7.386"
id="path3097" />
<path
style="fill:#c9c9b6"
d="m 170.897,186.814 4.238,-4.018 39.968,0 -4.238,4.018 -39.968,0 z"
id="path3099" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 170.897,186.814 4.238,-4.018 39.968,0 -4.238,4.018 -39.968,0"
id="path3101" />
<path
style="fill:none;stroke:#000000;stroke-width:2.11999989"
d="m 208.63,190.176 -9.591,0"
id="path3103" />
<path
style="fill:#7a7a5a"
d="m 210.865,194.2 4.238,-4.25 0,-7.154 -4.238,4.018 0,7.386 z"
id="path3105" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 210.865,194.2 4.238,-4.25 0,-7.154 -4.238,4.018 0,7.386"
id="path3107" />
<path
style="fill:#c9c9b6"
d="m 171.123,198.885 4.459,-5.585 30.819,0 -4.459,5.585 -30.819,0 z"
id="path3109" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 171.123,198.885 4.459,-5.585 30.819,0 -4.459,5.585 -30.819,0"
id="path3111" />
<path
style="fill:#7a7a5a"
d="m 201.942,200 4.459,-4.685 0,-2.015 -4.459,5.585 0,1.115 z"
id="path3113" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 201.942,200 4.459,-4.685 0,-2.015 -4.459,5.585 0,1.115"
id="path3115" />
<path
style="fill:#b7b79d"
d="m 171.123,198.885 30.819,0 0,1.115 -30.819,0 0,-1.115 z"
id="path3117" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 171.123,198.885 30.819,0 0,1.115 -30.819,0 0,-1.115"
id="path3119" />
<path
style="fill:#000000"
d="m 176.923,185.926 3.357,-3.13 28.35,0 -3.117,3.13 -28.59,0 z"
id="path3121" />
<path
style="fill:none;stroke:#000000;stroke-width:0.02"
d="m 176.923,185.926 3.357,-3.13 28.35,0 -3.117,3.13 -28.59,0"
id="path3123" />
<path
style="fill:#c9c9b6"
d="m 176.696,162.903 3.136,-2.903 28.363,0 -3.136,2.903 -28.363,0 z"
id="path3125" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 176.696,162.903 3.136,-2.903 28.363,0 -3.136,2.903 -28.363,0"
id="path3127" />
<path
style="fill:#b7b79d"
d="m 176.696,162.903 28.59,0 0,22.569 -28.59,0 0,-22.569 z"
id="path3129" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 176.696,162.903 28.577,0 0,22.563 -28.577,0 0,-22.563"
id="path3131" />
<path
style="fill:#ffffff"
d="m 179.152,165.8 23.672,0 0,17.437 -23.672,0 0,-17.437 z"
id="path3133" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 179.152,165.8 23.672,0 0,17.43 -23.672,0 0,-17.43"
id="path3135" />
<path
style="fill:#7a7a5a"
d="m 205.059,185.258 3.136,-3.13 0,-22.128 -3.136,2.903 0,22.355 z"
id="path3137" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 205.059,185.258 3.136,-3.13 0,-22.128 -3.136,2.903 0,22.355"
id="path3139" />
</g>
<g
style="display:inline"
id="g3093-1"
transform="translate(-80.220357,10.805087)">
<path
style="fill:#b7b79d"
d="m 170.897,186.814 39.968,0 0,7.386 -39.968,0 0,-7.386 z"
id="path3095-1" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 170.897,186.814 39.968,0 0,7.386 -39.968,0 0,-7.386"
id="path3097-9" />
<path
style="fill:#c9c9b6"
d="m 170.897,186.814 4.238,-4.018 39.968,0 -4.238,4.018 -39.968,0 z"
id="path3099-0" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 170.897,186.814 4.238,-4.018 39.968,0 -4.238,4.018 -39.968,0"
id="path3101-5" />
<path
style="fill:none;stroke:#000000;stroke-width:2.11999989"
d="m 208.63,190.176 -9.591,0"
id="path3103-6" />
<path
style="fill:#7a7a5a"
d="m 210.865,194.2 4.238,-4.25 0,-7.154 -4.238,4.018 0,7.386 z"
id="path3105-7" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 210.865,194.2 4.238,-4.25 0,-7.154 -4.238,4.018 0,7.386"
id="path3107-7" />
<path
style="fill:#c9c9b6"
d="m 171.123,198.885 4.459,-5.585 30.819,0 -4.459,5.585 -30.819,0 z"
id="path3109-4" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 171.123,198.885 4.459,-5.585 30.819,0 -4.459,5.585 -30.819,0"
id="path3111-0" />
<path
style="fill:#7a7a5a"
d="m 201.942,200 4.459,-4.685 0,-2.015 -4.459,5.585 0,1.115 z"
id="path3113-6" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 201.942,200 4.459,-4.685 0,-2.015 -4.459,5.585 0,1.115"
id="path3115-4" />
<path
style="fill:#b7b79d"
d="m 171.123,198.885 30.819,0 0,1.115 -30.819,0 0,-1.115 z"
id="path3117-7" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 171.123,198.885 30.819,0 0,1.115 -30.819,0 0,-1.115"
id="path3119-4" />
<path
style="fill:#000000"
d="m 176.923,185.926 3.357,-3.13 28.35,0 -3.117,3.13 -28.59,0 z"
id="path3121-8" />
<path
style="fill:none;stroke:#000000;stroke-width:0.02"
d="m 176.923,185.926 3.357,-3.13 28.35,0 -3.117,3.13 -28.59,0"
id="path3123-5" />
<path
style="fill:#c9c9b6"
d="m 176.696,162.903 3.136,-2.903 28.363,0 -3.136,2.903 -28.363,0 z"
id="path3125-8" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 176.696,162.903 3.136,-2.903 28.363,0 -3.136,2.903 -28.363,0"
id="path3127-2" />
<path
style="fill:#b7b79d"
d="m 176.696,162.903 28.59,0 0,22.569 -28.59,0 0,-22.569 z"
id="path3129-6" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 176.696,162.903 28.577,0 0,22.563 -28.577,0 0,-22.563"
id="path3131-0" />
<path
style="fill:#ffffff"
d="m 179.152,165.8 23.672,0 0,17.437 -23.672,0 0,-17.437 z"
id="path3133-6" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 179.152,165.8 23.672,0 0,17.43 -23.672,0 0,-17.43"
id="path3135-6" />
<path
style="fill:#7a7a5a"
d="m 205.059,185.258 3.136,-3.13 0,-22.128 -3.136,2.903 0,22.355 z"
id="path3137-4" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 205.059,185.258 3.136,-3.13 0,-22.128 -3.136,2.903 0,22.355"
id="path3139-6" />
</g>
<g
style="display:inline"
id="g3093-1-3"
transform="translate(38.710001,10.805087)">
<path
style="fill:#b7b79d"
d="m 170.897,186.814 39.968,0 0,7.386 -39.968,0 0,-7.386 z"
id="path3095-1-7" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 170.897,186.814 39.968,0 0,7.386 -39.968,0 0,-7.386"
id="path3097-9-7" />
<path
style="fill:#c9c9b6"
d="m 170.897,186.814 4.238,-4.018 39.968,0 -4.238,4.018 -39.968,0 z"
id="path3099-0-2" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 170.897,186.814 4.238,-4.018 39.968,0 -4.238,4.018 -39.968,0"
id="path3101-5-6" />
<path
style="fill:none;stroke:#000000;stroke-width:2.11999989"
d="m 208.63,190.176 -9.591,0"
id="path3103-6-4" />
<path
style="fill:#7a7a5a"
d="m 210.865,194.2 4.238,-4.25 0,-7.154 -4.238,4.018 0,7.386 z"
id="path3105-7-5" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 210.865,194.2 4.238,-4.25 0,-7.154 -4.238,4.018 0,7.386"
id="path3107-7-2" />
<path
style="fill:#c9c9b6"
d="m 171.123,198.885 4.459,-5.585 30.819,0 -4.459,5.585 -30.819,0 z"
id="path3109-4-0" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 171.123,198.885 4.459,-5.585 30.819,0 -4.459,5.585 -30.819,0"
id="path3111-0-2" />
<path
style="fill:#7a7a5a"
d="m 201.942,200 4.459,-4.685 0,-2.015 -4.459,5.585 0,1.115 z"
id="path3113-6-9" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 201.942,200 4.459,-4.685 0,-2.015 -4.459,5.585 0,1.115"
id="path3115-4-0" />
<path
style="fill:#b7b79d"
d="m 171.123,198.885 30.819,0 0,1.115 -30.819,0 0,-1.115 z"
id="path3117-7-9" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 171.123,198.885 30.819,0 0,1.115 -30.819,0 0,-1.115"
id="path3119-4-9" />
<path
style="fill:#000000"
d="m 176.923,185.926 3.357,-3.13 28.35,0 -3.117,3.13 -28.59,0 z"
id="path3121-8-4" />
<path
style="fill:none;stroke:#000000;stroke-width:0.02"
d="m 176.923,185.926 3.357,-3.13 28.35,0 -3.117,3.13 -28.59,0"
id="path3123-5-5" />
<path
style="fill:#c9c9b6"
d="m 176.696,162.903 3.136,-2.903 28.363,0 -3.136,2.903 -28.363,0 z"
id="path3125-8-1" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 176.696,162.903 3.136,-2.903 28.363,0 -3.136,2.903 -28.363,0"
id="path3127-2-0" />
<path
style="fill:#b7b79d"
d="m 176.696,162.903 28.59,0 0,22.569 -28.59,0 0,-22.569 z"
id="path3129-6-3" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 176.696,162.903 28.577,0 0,22.563 -28.577,0 0,-22.563"
id="path3131-0-7" />
<path
style="fill:#ffffff"
d="m 179.152,165.8 23.672,0 0,17.437 -23.672,0 0,-17.437 z"
id="path3133-6-8" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 179.152,165.8 23.672,0 0,17.43 -23.672,0 0,-17.43"
id="path3135-6-8" />
<path
style="fill:#7a7a5a"
d="m 205.059,185.258 3.136,-3.13 0,-22.128 -3.136,2.903 0,22.355 z"
id="path3137-4-6" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 205.059,185.258 3.136,-3.13 0,-22.128 -3.136,2.903 0,22.355"
id="path3139-6-0" />
</g>
<path
style="fill:#cacaff;fill-opacity:1;fill-rule:nonzero;stroke:none;display:inline"
d="m 210.96287,244.40394 c -46.36835,0 -85.38274,19.53789 -96.93388,46.09394 -10.69963,-2.73694 -22.659031,-4.27314 -35.288491,-4.27314 -45.540086,0 -82.4507158,19.90612 -82.4507158,44.46524 0,9.70624 5.765251,18.67753 15.5514528,25.98914 -12.20321684,6.15369 -19.6844958,14.41016 -19.6844958,23.4848 0,19.02925 32.8283478,34.44786 73.3264988,34.44786 27.54066,0 51.544801,-7.12071 64.079691,-17.67051 15.34489,5.5421 34.71109,8.84401 55.77858,8.84401 49.76881,0 90.12136,-18.45531 90.12136,-41.22536 0,-3.0279 -0.72988,-5.98433 -2.08403,-8.8265 23.15405,-11.43708 38.00298,-29.08221 38.00298,-48.896 0,-34.48036 -44.95762,-62.43348 -100.41895,-62.43348 z"
id="path5558" />
</g>
<g
inkscape:groupmode="layer"
id="layer1"
inkscape:label="Text"
style="display:inline">
<text
xml:space="preserve"
style="font-size:11.20825386px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans"
x="101.22408"
y="339.98462"
id="text4359"><tspan
sodipodi:role="line"
id="tspan4361"
x="101.22408"
y="339.98462">Network database</tspan></text>
<text
transform="translate(-2.1705283e-6,-6.1137644e-7)"
xml:space="preserve"
style="font-size:11.20825385999999924px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans"
x="-5.6149035"
y="162.89429"
id="text5301"><tspan
sodipodi:role="line"
id="tspan5303"
x="-5.6149035"
y="162.89429">Alice</tspan></text>
<text
transform="translate(-2.1705283e-6,-6.1137644e-7)"
xml:space="preserve"
style="font-size:11.20825385999999924px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans"
x="99.99514"
y="162.76093"
id="text5301-0"><tspan
sodipodi:role="line"
id="tspan5303-7"
x="99.99514"
y="162.76093">John</tspan></text>
<text
transform="translate(-2.1705283e-6,-6.1137644e-7)"
xml:space="preserve"
style="font-size:11.20825385999999924px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans"
x="217.44405"
y="161.75439"
id="text5301-6"><tspan
sodipodi:role="line"
id="tspan5303-6"
x="217.44405"
y="161.75439">Peter</tspan></text>
<path
style="fill:none;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-end:url(#Arrow1Lend)"
d="m -132.42359,48.345122 131.3726091,0"
id="path5942"
transform="matrix(0.5604127,0,0,0.5604127,97,159)" />
<path
style="fill:none;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-end:url(#Arrow1Lend)"
d="m 55.701988,48.345122 155.545172,0"
id="path6128"
transform="matrix(0.5604127,0,0,0.5604127,97,159)" />
<path
style="fill:none;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
d="m -352.0786,-3.152943 0,0 z"
id="path6314"
transform="matrix(0.5604127,0,0,0.5604127,97,159)" />
<g
style="display:inline"
id="g3093-0"
transform="translate(152.79493,11.156386)">
<path
style="fill:#b7b79d"
d="m 170.897,186.814 39.968,0 0,7.386 -39.968,0 0,-7.386 z"
id="path3095-8" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 170.897,186.814 39.968,0 0,7.386 -39.968,0 0,-7.386"
id="path3097-5" />
<path
style="fill:#c9c9b6"
d="m 170.897,186.814 4.238,-4.018 39.968,0 -4.238,4.018 -39.968,0 z"
id="path3099-9" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 170.897,186.814 4.238,-4.018 39.968,0 -4.238,4.018 -39.968,0"
id="path3101-4" />
<path
style="fill:none;stroke:#000000;stroke-width:2.11999989"
d="m 208.63,190.176 -9.591,0"
id="path3103-4" />
<path
style="fill:#7a7a5a"
d="m 210.865,194.2 4.238,-4.25 0,-7.154 -4.238,4.018 0,7.386 z"
id="path3105-6" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 210.865,194.2 4.238,-4.25 0,-7.154 -4.238,4.018 0,7.386"
id="path3107-6" />
<path
style="fill:#c9c9b6"
d="m 171.123,198.885 4.459,-5.585 30.819,0 -4.459,5.585 -30.819,0 z"
id="path3109-9" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 171.123,198.885 4.459,-5.585 30.819,0 -4.459,5.585 -30.819,0"
id="path3111-8" />
<path
style="fill:#7a7a5a"
d="m 201.942,200 4.459,-4.685 0,-2.015 -4.459,5.585 0,1.115 z"
id="path3113-7" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 201.942,200 4.459,-4.685 0,-2.015 -4.459,5.585 0,1.115"
id="path3115-44" />
<path
style="fill:#b7b79d"
d="m 171.123,198.885 30.819,0 0,1.115 -30.819,0 0,-1.115 z"
id="path3117-6" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 171.123,198.885 30.819,0 0,1.115 -30.819,0 0,-1.115"
id="path3119-1" />
<path
style="fill:#000000"
d="m 176.923,185.926 3.357,-3.13 28.35,0 -3.117,3.13 -28.59,0 z"
id="path3121-1" />
<path
style="fill:none;stroke:#000000;stroke-width:0.02"
d="m 176.923,185.926 3.357,-3.13 28.35,0 -3.117,3.13 -28.59,0"
id="path3123-1" />
<path
style="fill:#c9c9b6"
d="m 176.696,162.903 3.136,-2.903 28.363,0 -3.136,2.903 -28.363,0 z"
id="path3125-3" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 176.696,162.903 3.136,-2.903 28.363,0 -3.136,2.903 -28.363,0"
id="path3127-4" />
<path
style="fill:#b7b79d"
d="m 176.696,162.903 28.59,0 0,22.569 -28.59,0 0,-22.569 z"
id="path3129-8" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 176.696,162.903 28.577,0 0,22.563 -28.577,0 0,-22.563"
id="path3131-7" />
<path
style="fill:#ffffff"
d="m 179.152,165.8 23.672,0 0,17.437 -23.672,0 0,-17.437 z"
id="path3133-3" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 179.152,165.8 23.672,0 0,17.43 -23.672,0 0,-17.43"
id="path3135-2" />
<path
style="fill:#7a7a5a"
d="m 205.059,185.258 3.136,-3.13 0,-22.128 -3.136,2.903 0,22.355 z"
id="path3137-7" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 205.059,185.258 3.136,-3.13 0,-22.128 -3.136,2.903 0,22.355"
id="path3139-5" />
</g>
<g
style="display:inline"
id="g3093-1-2"
transform="translate(258.10434,10.770794)">
<path
style="fill:#b7b79d"
d="m 170.897,186.814 39.968,0 0,7.386 -39.968,0 0,-7.386 z"
id="path3095-1-2" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 170.897,186.814 39.968,0 0,7.386 -39.968,0 0,-7.386"
id="path3097-9-0" />
<path
style="fill:#c9c9b6"
d="m 170.897,186.814 4.238,-4.018 39.968,0 -4.238,4.018 -39.968,0 z"
id="path3099-0-1" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 170.897,186.814 4.238,-4.018 39.968,0 -4.238,4.018 -39.968,0"
id="path3101-5-9" />
<path
style="fill:none;stroke:#000000;stroke-width:2.11999989"
d="m 208.63,190.176 -9.591,0"
id="path3103-6-2" />
<path
style="fill:#7a7a5a"
d="m 210.865,194.2 4.238,-4.25 0,-7.154 -4.238,4.018 0,7.386 z"
id="path3105-7-1" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 210.865,194.2 4.238,-4.25 0,-7.154 -4.238,4.018 0,7.386"
id="path3107-7-9" />
<path
style="fill:#c9c9b6"
d="m 171.123,198.885 4.459,-5.585 30.819,0 -4.459,5.585 -30.819,0 z"
id="path3109-4-7" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 171.123,198.885 4.459,-5.585 30.819,0 -4.459,5.585 -30.819,0"
id="path3111-0-0" />
<path
style="fill:#7a7a5a"
d="m 201.942,200 4.459,-4.685 0,-2.015 -4.459,5.585 0,1.115 z"
id="path3113-6-6" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 201.942,200 4.459,-4.685 0,-2.015 -4.459,5.585 0,1.115"
id="path3115-4-3" />
<path
style="fill:#b7b79d"
d="m 171.123,198.885 30.819,0 0,1.115 -30.819,0 0,-1.115 z"
id="path3117-7-8" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 171.123,198.885 30.819,0 0,1.115 -30.819,0 0,-1.115"
id="path3119-4-2" />
<path
style="fill:#000000"
d="m 176.923,185.926 3.357,-3.13 28.35,0 -3.117,3.13 -28.59,0 z"
id="path3121-8-2" />
<path
style="fill:none;stroke:#000000;stroke-width:0.02"
d="m 176.923,185.926 3.357,-3.13 28.35,0 -3.117,3.13 -28.59,0"
id="path3123-5-9" />
<path
style="fill:#c9c9b6"
d="m 176.696,162.903 3.136,-2.903 28.363,0 -3.136,2.903 -28.363,0 z"
id="path3125-8-0" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 176.696,162.903 3.136,-2.903 28.363,0 -3.136,2.903 -28.363,0"
id="path3127-2-7" />
<path
style="fill:#b7b79d"
d="m 176.696,162.903 28.59,0 0,22.569 -28.59,0 0,-22.569 z"
id="path3129-6-36" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 176.696,162.903 28.577,0 0,22.563 -28.577,0 0,-22.563"
id="path3131-0-0" />
<path
style="fill:#ffffff"
d="m 179.152,165.8 23.672,0 0,17.437 -23.672,0 0,-17.437 z"
id="path3133-6-6" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 179.152,165.8 23.672,0 0,17.43 -23.672,0 0,-17.43"
id="path3135-6-9" />
<path
style="fill:#7a7a5a"
d="m 205.059,185.258 3.136,-3.13 0,-22.128 -3.136,2.903 0,22.355 z"
id="path3137-4-4" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 205.059,185.258 3.136,-3.13 0,-22.128 -3.136,2.903 0,22.355"
id="path3139-6-2" />
</g>
<g
style="display:inline"
id="g3093-1-3-7"
transform="translate(377.0347,10.770794)">
<path
style="fill:#b7b79d"
d="m 170.897,186.814 39.968,0 0,7.386 -39.968,0 0,-7.386 z"
id="path3095-1-7-1" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 170.897,186.814 39.968,0 0,7.386 -39.968,0 0,-7.386"
id="path3097-9-7-5" />
<path
style="fill:#c9c9b6"
d="m 170.897,186.814 4.238,-4.018 39.968,0 -4.238,4.018 -39.968,0 z"
id="path3099-0-2-0" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 170.897,186.814 4.238,-4.018 39.968,0 -4.238,4.018 -39.968,0"
id="path3101-5-6-8" />
<path
style="fill:none;stroke:#000000;stroke-width:2.11999989"
d="m 208.63,190.176 -9.591,0"
id="path3103-6-4-2" />
<path
style="fill:#7a7a5a"
d="m 210.865,194.2 4.238,-4.25 0,-7.154 -4.238,4.018 0,7.386 z"
id="path3105-7-5-4" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 210.865,194.2 4.238,-4.25 0,-7.154 -4.238,4.018 0,7.386"
id="path3107-7-2-1" />
<path
style="fill:#c9c9b6"
d="m 171.123,198.885 4.459,-5.585 30.819,0 -4.459,5.585 -30.819,0 z"
id="path3109-4-0-5" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 171.123,198.885 4.459,-5.585 30.819,0 -4.459,5.585 -30.819,0"
id="path3111-0-2-5" />
<path
style="fill:#7a7a5a"
d="m 201.942,200 4.459,-4.685 0,-2.015 -4.459,5.585 0,1.115 z"
id="path3113-6-9-2" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 201.942,200 4.459,-4.685 0,-2.015 -4.459,5.585 0,1.115"
id="path3115-4-0-7" />
<path
style="fill:#b7b79d"
d="m 171.123,198.885 30.819,0 0,1.115 -30.819,0 0,-1.115 z"
id="path3117-7-9-7" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 171.123,198.885 30.819,0 0,1.115 -30.819,0 0,-1.115"
id="path3119-4-9-4" />
<path
style="fill:#000000"
d="m 176.923,185.926 3.357,-3.13 28.35,0 -3.117,3.13 -28.59,0 z"
id="path3121-8-4-4" />
<path
style="fill:none;stroke:#000000;stroke-width:0.02"
d="m 176.923,185.926 3.357,-3.13 28.35,0 -3.117,3.13 -28.59,0"
id="path3123-5-5-9" />
<path
style="fill:#c9c9b6"
d="m 176.696,162.903 3.136,-2.903 28.363,0 -3.136,2.903 -28.363,0 z"
id="path3125-8-1-0" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 176.696,162.903 3.136,-2.903 28.363,0 -3.136,2.903 -28.363,0"
id="path3127-2-0-9" />
<path
style="fill:#b7b79d"
d="m 176.696,162.903 28.59,0 0,22.569 -28.59,0 0,-22.569 z"
id="path3129-6-3-8" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 176.696,162.903 28.577,0 0,22.563 -28.577,0 0,-22.563"
id="path3131-0-7-2" />
<path
style="fill:#ffffff"
d="m 179.152,165.8 23.672,0 0,17.437 -23.672,0 0,-17.437 z"
id="path3133-6-8-4" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 179.152,165.8 23.672,0 0,17.43 -23.672,0 0,-17.43"
id="path3135-6-8-9" />
<path
style="fill:#7a7a5a"
d="m 205.059,185.258 3.136,-3.13 0,-22.128 -3.136,2.903 0,22.355 z"
id="path3137-4-6-2" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 205.059,185.258 3.136,-3.13 0,-22.128 -3.136,2.903 0,22.355"
id="path3139-6-0-1" />
</g>
<text
xml:space="preserve"
style="font-size:11.20825386px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;display:inline;font-family:Bitstream Vera Sans"
x="332.70944"
y="162.86003"
id="text5301-4"><tspan
sodipodi:role="line"
id="tspan5303-0"
x="332.70944"
y="162.86003">Cloë</tspan></text>
<text
xml:space="preserve"
style="font-size:11.20825386px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;display:inline;font-family:Bitstream Vera Sans"
x="439.4404"
y="162.72667"
id="text5301-0-3"><tspan
sodipodi:role="line"
id="tspan5303-7-0"
x="439.4404"
y="162.72667">Dan</tspan></text>
<text
xml:space="preserve"
style="font-size:11.20825386px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;display:inline;font-family:Bitstream Vera Sans"
x="559.13147"
y="161.72014"
id="text5301-6-0"><tspan
sodipodi:role="line"
id="tspan5303-6-7"
x="559.13147"
y="161.72014">Bob</tspan></text>
<path
style="fill:none;stroke:#000000;stroke-width:0.5604127px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-end:url(#Arrow1Lend);display:inline"
d="m 361.11284,186.05889 73.62288,0"
id="path5942-2" />
<path
style="fill:none;stroke:#000000;stroke-width:0.5604127px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-end:url(#Arrow1Lend);display:inline"
d="m 466.5408,186.05889 87.16949,0"
id="path6128-9" />
<path
style="fill:none;stroke:#000000;stroke-width:0.5604127px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-end:url(#Arrow1Lend);display:inline"
d="m 6.716754,211.95133 21.792366,83.6356"
id="path4847" />
<text
xml:space="preserve"
style="font-size:6.16453981px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;display:inline;font-family:Bitstream Vera Sans"
x="208.88512"
y="63.842232"
id="text5297"
transform="matrix(0.26559506,0.96408468,-0.96408468,0.26559506,0,0)"><tspan
sodipodi:role="line"
id="tspan5299"
x="208.88512"
y="63.842232"
style="font-size:11.20825386px">GET leaseSet</tspan></text>
<text
xml:space="preserve"
style="font-size:6.16453981px;font-style:normal;font-weight:normal;text-align:start;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;display:inline;font-family:Bitstream Vera Sans"
x="223.43687"
y="3.2048521"
id="text5297-6"
transform="matrix(0.22245257,0.97494351,-0.97494351,0.22245257,0,0)"><tspan
sodipodi:role="line"
x="223.43687"
y="3.2048521"
style="font-size:11.20825386px;text-align:start;text-anchor:start"
id="tspan5556">leaseSet</tspan><tspan
sodipodi:role="line"
x="223.43687"
y="17.21517"
style="font-size:11.20825386px;text-align:start;text-anchor:start"
id="tspan6922">to Bob</tspan></text>
<path
style="fill:none;stroke:#000000;stroke-width:0.5604127px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-end:url(#Arrow1Lend);display:inline"
d="M 41.46675,291.46405 20.26336,208.41744"
id="path5735" />
<text
xml:space="preserve"
style="font-size:6.16453981px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans"
x="261.72629"
y="166.1996"
id="text7150"><tspan
sodipodi:role="line"
id="tspan7152"
x="261.72629"
y="166.1996"
style="font-size:11.20825386px">CONNECT</tspan><tspan
sodipodi:role="line"
x="261.72629"
y="180.20992"
id="tspan7154"
style="font-size:11.20825386px">tunnels</tspan></text>
<path
style="fill:none;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-end:url(#marker6880)"
d="m 268.00013,47.294141 147.13733,0"
id="path7156"
transform="matrix(0.5604127,0,0,0.5604127,97,159)" />
</g>
</svg>
Side by Side

After

Width:  |  Height:  |  Size: 36 KiB

509
www.i2p2/image_design/netdb_get_routerinfo_1.svg Normal file
View File

@ -0,0 +1,509 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<svg
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:cc="http://creativecommons.org/ns#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:svg="http://www.w3.org/2000/svg"
xmlns="http://www.w3.org/2000/svg"
xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
width="7cm"
height="7cm"
viewBox="102 159 129 139"
id="svg3091"
version="1.1"
inkscape:version="0.47pre4 r22446"
sodipodi:docname="netdb_get_routerinfo_1.svg"
inkscape:export-filename="/home/mathias/Documents/I2P/i2p.www/www.i2p2/image_design/netdb_get_routerinfo_1.png"
inkscape:export-xdpi="49.999134"
inkscape:export-ydpi="49.999134">
<metadata
id="metadata3257">
<rdf:RDF>
<cc:Work
rdf:about="">
<dc:format>image/svg+xml</dc:format>
<dc:type
rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
<dc:title></dc:title>
</cc:Work>
</rdf:RDF>
</metadata>
<defs
id="defs3255">
<marker
inkscape:stockid="Arrow1Lend"
orient="auto"
refY="0.0"
refX="0.0"
id="Arrow1Lend"
style="overflow:visible;">
<path
id="path4855"
d="M 0.0,0.0 L 5.0,-5.0 L -12.5,0.0 L 5.0,5.0 L 0.0,0.0 z "
style="fill-rule:evenodd;stroke:#000000;stroke-width:1.0pt;marker-start:none;"
transform="scale(0.8) rotate(180) translate(12.5,0)" />
</marker>
<linearGradient
id="linearGradient4351">
<stop
style="stop-color:#cacaff;stop-opacity:1;"
offset="0"
id="stop4353" />
<stop
style="stop-color:#cacaff;stop-opacity:0;"
offset="1"
id="stop4355" />
</linearGradient>
<inkscape:perspective
sodipodi:type="inkscape:persp3d"
inkscape:vp_x="0 : 124.01575 : 1"
inkscape:vp_y="0 : 1000 : 0"
inkscape:vp_z="248.03149 : 124.01575 : 1"
inkscape:persp3d-origin="124.01575 : 82.677165 : 1"
id="perspective3259" />
<inkscape:perspective
id="perspective3365"
inkscape:persp3d-origin="0.5 : 0.33333333 : 1"
inkscape:vp_z="1 : 0.5 : 1"
inkscape:vp_y="0 : 1000 : 0"
inkscape:vp_x="0 : 0.5 : 1"
sodipodi:type="inkscape:persp3d" />
<inkscape:perspective
id="perspective3456"
inkscape:persp3d-origin="0.5 : 0.33333333 : 1"
inkscape:vp_z="1 : 0.5 : 1"
inkscape:vp_y="0 : 1000 : 0"
inkscape:vp_x="0 : 0.5 : 1"
sodipodi:type="inkscape:persp3d" />
<inkscape:perspective
id="perspective5313"
inkscape:persp3d-origin="0.5 : 0.33333333 : 1"
inkscape:vp_z="1 : 0.5 : 1"
inkscape:vp_y="0 : 1000 : 0"
inkscape:vp_x="0 : 0.5 : 1"
sodipodi:type="inkscape:persp3d" />
<inkscape:perspective
id="perspective5313-8"
inkscape:persp3d-origin="0.5 : 0.33333333 : 1"
inkscape:vp_z="1 : 0.5 : 1"
inkscape:vp_y="0 : 1000 : 0"
inkscape:vp_x="0 : 0.5 : 1"
sodipodi:type="inkscape:persp3d" />
<inkscape:perspective
id="perspective5535"
inkscape:persp3d-origin="0.5 : 0.33333333 : 1"
inkscape:vp_z="1 : 0.5 : 1"
inkscape:vp_y="0 : 1000 : 0"
inkscape:vp_x="0 : 0.5 : 1"
sodipodi:type="inkscape:persp3d" />
</defs>
<sodipodi:namedview
pagecolor="#ffffff"
bordercolor="#666666"
borderopacity="1"
objecttolerance="10"
gridtolerance="10"
guidetolerance="10"
inkscape:pageopacity="0"
inkscape:pageshadow="2"
inkscape:window-width="1280"
inkscape:window-height="726"
id="namedview3253"
showgrid="false"
inkscape:zoom="0.95149207"
inkscape:cx="30.351733"
inkscape:cy="64.573832"
inkscape:window-x="0"
inkscape:window-y="25"
inkscape:window-maximized="1"
inkscape:current-layer="layer1" />
<g
inkscape:groupmode="layer"
id="layer2"
inkscape:label="Pictures">
<g
style="display:inline"
id="g3093"
transform="translate(-185.52966,11.190679)">
<path
style="fill:#b7b79d"
d="m 170.897,186.814 39.968,0 0,7.386 -39.968,0 0,-7.386 z"
id="path3095" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 170.897,186.814 39.968,0 0,7.386 -39.968,0 0,-7.386"
id="path3097" />
<path
style="fill:#c9c9b6"
d="m 170.897,186.814 4.238,-4.018 39.968,0 -4.238,4.018 -39.968,0 z"
id="path3099" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 170.897,186.814 4.238,-4.018 39.968,0 -4.238,4.018 -39.968,0"
id="path3101" />
<path
style="fill:none;stroke:#000000;stroke-width:2.11999989"
d="m 208.63,190.176 -9.591,0"
id="path3103" />
<path
style="fill:#7a7a5a"
d="m 210.865,194.2 4.238,-4.25 0,-7.154 -4.238,4.018 0,7.386 z"
id="path3105" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 210.865,194.2 4.238,-4.25 0,-7.154 -4.238,4.018 0,7.386"
id="path3107" />
<path
style="fill:#c9c9b6"
d="m 171.123,198.885 4.459,-5.585 30.819,0 -4.459,5.585 -30.819,0 z"
id="path3109" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 171.123,198.885 4.459,-5.585 30.819,0 -4.459,5.585 -30.819,0"
id="path3111" />
<path
style="fill:#7a7a5a"
d="m 201.942,200 4.459,-4.685 0,-2.015 -4.459,5.585 0,1.115 z"
id="path3113" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 201.942,200 4.459,-4.685 0,-2.015 -4.459,5.585 0,1.115"
id="path3115" />
<path
style="fill:#b7b79d"
d="m 171.123,198.885 30.819,0 0,1.115 -30.819,0 0,-1.115 z"
id="path3117" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 171.123,198.885 30.819,0 0,1.115 -30.819,0 0,-1.115"
id="path3119" />
<path
style="fill:#000000"
d="m 176.923,185.926 3.357,-3.13 28.35,0 -3.117,3.13 -28.59,0 z"
id="path3121" />
<path
style="fill:none;stroke:#000000;stroke-width:0.02"
d="m 176.923,185.926 3.357,-3.13 28.35,0 -3.117,3.13 -28.59,0"
id="path3123" />
<path
style="fill:#c9c9b6"
d="m 176.696,162.903 3.136,-2.903 28.363,0 -3.136,2.903 -28.363,0 z"
id="path3125" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 176.696,162.903 3.136,-2.903 28.363,0 -3.136,2.903 -28.363,0"
id="path3127" />
<path
style="fill:#b7b79d"
d="m 176.696,162.903 28.59,0 0,22.569 -28.59,0 0,-22.569 z"
id="path3129" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 176.696,162.903 28.577,0 0,22.563 -28.577,0 0,-22.563"
id="path3131" />
<path
style="fill:#ffffff"
d="m 179.152,165.8 23.672,0 0,17.437 -23.672,0 0,-17.437 z"
id="path3133" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 179.152,165.8 23.672,0 0,17.43 -23.672,0 0,-17.43"
id="path3135" />
<path
style="fill:#7a7a5a"
d="m 205.059,185.258 3.136,-3.13 0,-22.128 -3.136,2.903 0,22.355 z"
id="path3137" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 205.059,185.258 3.136,-3.13 0,-22.128 -3.136,2.903 0,22.355"
id="path3139" />
</g>
<g
style="display:inline"
id="g3093-1"
transform="translate(-80.220357,10.805087)">
<path
style="fill:#b7b79d"
d="m 170.897,186.814 39.968,0 0,7.386 -39.968,0 0,-7.386 z"
id="path3095-1" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 170.897,186.814 39.968,0 0,7.386 -39.968,0 0,-7.386"
id="path3097-9" />
<path
style="fill:#c9c9b6"
d="m 170.897,186.814 4.238,-4.018 39.968,0 -4.238,4.018 -39.968,0 z"
id="path3099-0" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 170.897,186.814 4.238,-4.018 39.968,0 -4.238,4.018 -39.968,0"
id="path3101-5" />
<path
style="fill:none;stroke:#000000;stroke-width:2.11999989"
d="m 208.63,190.176 -9.591,0"
id="path3103-6" />
<path
style="fill:#7a7a5a"
d="m 210.865,194.2 4.238,-4.25 0,-7.154 -4.238,4.018 0,7.386 z"
id="path3105-7" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 210.865,194.2 4.238,-4.25 0,-7.154 -4.238,4.018 0,7.386"
id="path3107-7" />
<path
style="fill:#c9c9b6"
d="m 171.123,198.885 4.459,-5.585 30.819,0 -4.459,5.585 -30.819,0 z"
id="path3109-4" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 171.123,198.885 4.459,-5.585 30.819,0 -4.459,5.585 -30.819,0"
id="path3111-0" />
<path
style="fill:#7a7a5a"
d="m 201.942,200 4.459,-4.685 0,-2.015 -4.459,5.585 0,1.115 z"
id="path3113-6" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 201.942,200 4.459,-4.685 0,-2.015 -4.459,5.585 0,1.115"
id="path3115-4" />
<path
style="fill:#b7b79d"
d="m 171.123,198.885 30.819,0 0,1.115 -30.819,0 0,-1.115 z"
id="path3117-7" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 171.123,198.885 30.819,0 0,1.115 -30.819,0 0,-1.115"
id="path3119-4" />
<path
style="fill:#000000"
d="m 176.923,185.926 3.357,-3.13 28.35,0 -3.117,3.13 -28.59,0 z"
id="path3121-8" />
<path
style="fill:none;stroke:#000000;stroke-width:0.02"
d="m 176.923,185.926 3.357,-3.13 28.35,0 -3.117,3.13 -28.59,0"
id="path3123-5" />
<path
style="fill:#c9c9b6"
d="m 176.696,162.903 3.136,-2.903 28.363,0 -3.136,2.903 -28.363,0 z"
id="path3125-8" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 176.696,162.903 3.136,-2.903 28.363,0 -3.136,2.903 -28.363,0"
id="path3127-2" />
<path
style="fill:#b7b79d"
d="m 176.696,162.903 28.59,0 0,22.569 -28.59,0 0,-22.569 z"
id="path3129-6" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 176.696,162.903 28.577,0 0,22.563 -28.577,0 0,-22.563"
id="path3131-0" />
<path
style="fill:#ffffff"
d="m 179.152,165.8 23.672,0 0,17.437 -23.672,0 0,-17.437 z"
id="path3133-6" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 179.152,165.8 23.672,0 0,17.43 -23.672,0 0,-17.43"
id="path3135-6" />
<path
style="fill:#7a7a5a"
d="m 205.059,185.258 3.136,-3.13 0,-22.128 -3.136,2.903 0,22.355 z"
id="path3137-4" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 205.059,185.258 3.136,-3.13 0,-22.128 -3.136,2.903 0,22.355"
id="path3139-6" />
</g>
<g
style="display:inline"
id="g3093-1-3"
transform="translate(38.710001,10.805087)">
<path
style="fill:#b7b79d"
d="m 170.897,186.814 39.968,0 0,7.386 -39.968,0 0,-7.386 z"
id="path3095-1-7" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 170.897,186.814 39.968,0 0,7.386 -39.968,0 0,-7.386"
id="path3097-9-7" />
<path
style="fill:#c9c9b6"
d="m 170.897,186.814 4.238,-4.018 39.968,0 -4.238,4.018 -39.968,0 z"
id="path3099-0-2" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 170.897,186.814 4.238,-4.018 39.968,0 -4.238,4.018 -39.968,0"
id="path3101-5-6" />
<path
style="fill:none;stroke:#000000;stroke-width:2.11999989"
d="m 208.63,190.176 -9.591,0"
id="path3103-6-4" />
<path
style="fill:#7a7a5a"
d="m 210.865,194.2 4.238,-4.25 0,-7.154 -4.238,4.018 0,7.386 z"
id="path3105-7-5" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 210.865,194.2 4.238,-4.25 0,-7.154 -4.238,4.018 0,7.386"
id="path3107-7-2" />
<path
style="fill:#c9c9b6"
d="m 171.123,198.885 4.459,-5.585 30.819,0 -4.459,5.585 -30.819,0 z"
id="path3109-4-0" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 171.123,198.885 4.459,-5.585 30.819,0 -4.459,5.585 -30.819,0"
id="path3111-0-2" />
<path
style="fill:#7a7a5a"
d="m 201.942,200 4.459,-4.685 0,-2.015 -4.459,5.585 0,1.115 z"
id="path3113-6-9" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 201.942,200 4.459,-4.685 0,-2.015 -4.459,5.585 0,1.115"
id="path3115-4-0" />
<path
style="fill:#b7b79d"
d="m 171.123,198.885 30.819,0 0,1.115 -30.819,0 0,-1.115 z"
id="path3117-7-9" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 171.123,198.885 30.819,0 0,1.115 -30.819,0 0,-1.115"
id="path3119-4-9" />
<path
style="fill:#000000"
d="m 176.923,185.926 3.357,-3.13 28.35,0 -3.117,3.13 -28.59,0 z"
id="path3121-8-4" />
<path
style="fill:none;stroke:#000000;stroke-width:0.02"
d="m 176.923,185.926 3.357,-3.13 28.35,0 -3.117,3.13 -28.59,0"
id="path3123-5-5" />
<path
style="fill:#c9c9b6"
d="m 176.696,162.903 3.136,-2.903 28.363,0 -3.136,2.903 -28.363,0 z"
id="path3125-8-1" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 176.696,162.903 3.136,-2.903 28.363,0 -3.136,2.903 -28.363,0"
id="path3127-2-0" />
<path
style="fill:#b7b79d"
d="m 176.696,162.903 28.59,0 0,22.569 -28.59,0 0,-22.569 z"
id="path3129-6-3" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 176.696,162.903 28.577,0 0,22.563 -28.577,0 0,-22.563"
id="path3131-0-7" />
<path
style="fill:#ffffff"
d="m 179.152,165.8 23.672,0 0,17.437 -23.672,0 0,-17.437 z"
id="path3133-6-8" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 179.152,165.8 23.672,0 0,17.43 -23.672,0 0,-17.43"
id="path3135-6-8" />
<path
style="fill:#7a7a5a"
d="m 205.059,185.258 3.136,-3.13 0,-22.128 -3.136,2.903 0,22.355 z"
id="path3137-4-6" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 205.059,185.258 3.136,-3.13 0,-22.128 -3.136,2.903 0,22.355"
id="path3139-6-0" />
</g>
<path
style="fill:#cacaff;fill-opacity:1;fill-rule:nonzero;stroke:none;display:inline"
d="m 210.96287,244.40394 c -46.36835,0 -85.38274,19.53789 -96.93388,46.09394 -10.69963,-2.73694 -22.659031,-4.27314 -35.288491,-4.27314 -45.540086,0 -82.4507158,19.90612 -82.4507158,44.46524 0,9.70624 5.765251,18.67753 15.5514528,25.98914 -12.20321684,6.15369 -19.6844958,14.41016 -19.6844958,23.4848 0,19.02925 32.8283478,34.44786 73.3264988,34.44786 27.54066,0 51.544801,-7.12071 64.079691,-17.67051 15.34489,5.5421 34.71109,8.84401 55.77858,8.84401 49.76881,0 90.12136,-18.45531 90.12136,-41.22536 0,-3.0279 -0.72988,-5.98433 -2.08403,-8.8265 23.15405,-11.43708 38.00298,-29.08221 38.00298,-48.896 0,-34.48036 -44.95762,-62.43348 -100.41895,-62.43348 z"
id="path5558" />
</g>
<g
inkscape:groupmode="layer"
id="layer1"
inkscape:label="Text"
style="display:inline">
<text
xml:space="preserve"
style="font-size:11.20825386px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans"
x="101.22408"
y="339.98462"
id="text4359"><tspan
sodipodi:role="line"
id="tspan4361"
x="101.22408"
y="339.98462">Network database</tspan></text>
<path
style="fill:none;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-end:url(#Arrow1Lend)"
d="m -161.85106,93.537301 38.88629,149.239289"
id="path4847"
transform="matrix(0.5604127,0,0,0.5604127,97,159)" />
<text
xml:space="preserve"
style="font-size:6.16453980999999995px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans"
x="206.88257"
y="64.888947"
id="text5297"
transform="matrix(0.26559507,0.9640847,-0.9640847,0.26559507,-2.1705283e-6,-6.1137644e-7)"><tspan
sodipodi:role="line"
id="tspan5299"
x="206.88257"
y="64.888947"
style="font-size:11.20825386px">GET routerInfo</tspan></text>
<text
transform="translate(-2.1705283e-6,-6.1137644e-7)"
xml:space="preserve"
style="font-size:11.20825385999999924px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans"
x="-5.6149035"
y="162.89429"
id="text5301"><tspan
sodipodi:role="line"
id="tspan5303"
x="-5.6149035"
y="162.89429">Alice</tspan></text>
<text
transform="translate(-2.1705283e-6,-6.1137644e-7)"
xml:space="preserve"
style="font-size:11.20825385999999924px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans"
x="99.99514"
y="162.76093"
id="text5301-0"><tspan
sodipodi:role="line"
id="tspan5303-7"
x="99.99514"
y="162.76093">John</tspan></text>
<text
transform="translate(-2.1705283e-6,-6.1137644e-7)"
xml:space="preserve"
style="font-size:11.20825385999999924px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans"
x="217.44405"
y="161.75439"
id="text5301-6"><tspan
sodipodi:role="line"
id="tspan5303-6"
x="217.44405"
y="161.75439">Peter</tspan></text>
<text
xml:space="preserve"
style="font-size:6.16453981px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;display:inline;font-family:Bitstream Vera Sans"
x="222.82492"
y="3.4961586"
id="text5297-6"
transform="matrix(0.22245258,0.97494351,-0.97494351,0.22245258,0,0)"><tspan
sodipodi:role="line"
x="222.82492"
y="3.4961586"
style="font-size:11.20825386px"
id="tspan5552">routerInfo</tspan><tspan
sodipodi:role="line"
x="222.82492"
y="17.506475"
style="font-size:11.20825386px"
id="tspan5556">John, Peter</tspan></text>
<path
style="fill:none;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-end:url(#Arrow1Lend)"
d="M -99.843186,235.41972 -137.6785,87.231415"
id="path5735"
transform="matrix(0.5604127,0,0,0.5604127,97,159)" />
</g>
</svg>
Side by Side

After

Width:  |  Height:  |  Size: 19 KiB

516
www.i2p2/image_design/netdb_get_routerinfo_2.svg Normal file
View File

@ -0,0 +1,516 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<svg
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:cc="http://creativecommons.org/ns#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:svg="http://www.w3.org/2000/svg"
xmlns="http://www.w3.org/2000/svg"
xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
width="7cm"
height="7cm"
viewBox="102 159 129 139"
id="svg3091"
version="1.1"
inkscape:version="0.47pre4 r22446"
sodipodi:docname="netdb_get_routerinfo_2.svg"
inkscape:export-filename="/home/mathias/Documents/I2P/i2p.www/www.i2p2/image_design/netdb_get_routerinfo_2.png"
inkscape:export-xdpi="49.999134"
inkscape:export-ydpi="49.999134">
<metadata
id="metadata3257">
<rdf:RDF>
<cc:Work
rdf:about="">
<dc:format>image/svg+xml</dc:format>
<dc:type
rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
<dc:title></dc:title>
</cc:Work>
</rdf:RDF>
</metadata>
<defs
id="defs3255">
<marker
inkscape:stockid="Arrow1Lend"
orient="auto"
refY="0.0"
refX="0.0"
id="Arrow1Lend"
style="overflow:visible;">
<path
id="path4855"
d="M 0.0,0.0 L 5.0,-5.0 L -12.5,0.0 L 5.0,5.0 L 0.0,0.0 z "
style="fill-rule:evenodd;stroke:#000000;stroke-width:1.0pt;marker-start:none;"
transform="scale(0.8) rotate(180) translate(12.5,0)" />
</marker>
<linearGradient
id="linearGradient4351">
<stop
style="stop-color:#cacaff;stop-opacity:1;"
offset="0"
id="stop4353" />
<stop
style="stop-color:#cacaff;stop-opacity:0;"
offset="1"
id="stop4355" />
</linearGradient>
<inkscape:perspective
sodipodi:type="inkscape:persp3d"
inkscape:vp_x="0 : 124.01575 : 1"
inkscape:vp_y="0 : 1000 : 0"
inkscape:vp_z="248.03149 : 124.01575 : 1"
inkscape:persp3d-origin="124.01575 : 82.677165 : 1"
id="perspective3259" />
<inkscape:perspective
id="perspective3365"
inkscape:persp3d-origin="0.5 : 0.33333333 : 1"
inkscape:vp_z="1 : 0.5 : 1"
inkscape:vp_y="0 : 1000 : 0"
inkscape:vp_x="0 : 0.5 : 1"
sodipodi:type="inkscape:persp3d" />
<inkscape:perspective
id="perspective3456"
inkscape:persp3d-origin="0.5 : 0.33333333 : 1"
inkscape:vp_z="1 : 0.5 : 1"
inkscape:vp_y="0 : 1000 : 0"
inkscape:vp_x="0 : 0.5 : 1"
sodipodi:type="inkscape:persp3d" />
<inkscape:perspective
id="perspective5313"
inkscape:persp3d-origin="0.5 : 0.33333333 : 1"
inkscape:vp_z="1 : 0.5 : 1"
inkscape:vp_y="0 : 1000 : 0"
inkscape:vp_x="0 : 0.5 : 1"
sodipodi:type="inkscape:persp3d" />
<inkscape:perspective
id="perspective5313-8"
inkscape:persp3d-origin="0.5 : 0.33333333 : 1"
inkscape:vp_z="1 : 0.5 : 1"
inkscape:vp_y="0 : 1000 : 0"
inkscape:vp_x="0 : 0.5 : 1"
sodipodi:type="inkscape:persp3d" />
<inkscape:perspective
id="perspective5535"
inkscape:persp3d-origin="0.5 : 0.33333333 : 1"
inkscape:vp_z="1 : 0.5 : 1"
inkscape:vp_y="0 : 1000 : 0"
inkscape:vp_x="0 : 0.5 : 1"
sodipodi:type="inkscape:persp3d" />
<inkscape:perspective
id="perspective6324"
inkscape:persp3d-origin="0.5 : 0.33333333 : 1"
inkscape:vp_z="1 : 0.5 : 1"
inkscape:vp_y="0 : 1000 : 0"
inkscape:vp_x="0 : 0.5 : 1"
sodipodi:type="inkscape:persp3d" />
</defs>
<sodipodi:namedview
pagecolor="#ffffff"
bordercolor="#666666"
borderopacity="1"
objecttolerance="10"
gridtolerance="10"
guidetolerance="10"
inkscape:pageopacity="0"
inkscape:pageshadow="2"
inkscape:window-width="1280"
inkscape:window-height="726"
id="namedview3253"
showgrid="false"
inkscape:zoom="0.95149207"
inkscape:cx="30.351733"
inkscape:cy="64.573832"
inkscape:window-x="0"
inkscape:window-y="25"
inkscape:window-maximized="1"
inkscape:current-layer="layer1" />
<g
inkscape:groupmode="layer"
id="layer2"
inkscape:label="Pictures">
<g
style="display:inline"
id="g3093"
transform="translate(-185.52966,11.190679)">
<path
style="fill:#b7b79d"
d="m 170.897,186.814 39.968,0 0,7.386 -39.968,0 0,-7.386 z"
id="path3095" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 170.897,186.814 39.968,0 0,7.386 -39.968,0 0,-7.386"
id="path3097" />
<path
style="fill:#c9c9b6"
d="m 170.897,186.814 4.238,-4.018 39.968,0 -4.238,4.018 -39.968,0 z"
id="path3099" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 170.897,186.814 4.238,-4.018 39.968,0 -4.238,4.018 -39.968,0"
id="path3101" />
<path
style="fill:none;stroke:#000000;stroke-width:2.11999989"
d="m 208.63,190.176 -9.591,0"
id="path3103" />
<path
style="fill:#7a7a5a"
d="m 210.865,194.2 4.238,-4.25 0,-7.154 -4.238,4.018 0,7.386 z"
id="path3105" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 210.865,194.2 4.238,-4.25 0,-7.154 -4.238,4.018 0,7.386"
id="path3107" />
<path
style="fill:#c9c9b6"
d="m 171.123,198.885 4.459,-5.585 30.819,0 -4.459,5.585 -30.819,0 z"
id="path3109" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 171.123,198.885 4.459,-5.585 30.819,0 -4.459,5.585 -30.819,0"
id="path3111" />
<path
style="fill:#7a7a5a"
d="m 201.942,200 4.459,-4.685 0,-2.015 -4.459,5.585 0,1.115 z"
id="path3113" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 201.942,200 4.459,-4.685 0,-2.015 -4.459,5.585 0,1.115"
id="path3115" />
<path
style="fill:#b7b79d"
d="m 171.123,198.885 30.819,0 0,1.115 -30.819,0 0,-1.115 z"
id="path3117" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 171.123,198.885 30.819,0 0,1.115 -30.819,0 0,-1.115"
id="path3119" />
<path
style="fill:#000000"
d="m 176.923,185.926 3.357,-3.13 28.35,0 -3.117,3.13 -28.59,0 z"
id="path3121" />
<path
style="fill:none;stroke:#000000;stroke-width:0.02"
d="m 176.923,185.926 3.357,-3.13 28.35,0 -3.117,3.13 -28.59,0"
id="path3123" />
<path
style="fill:#c9c9b6"
d="m 176.696,162.903 3.136,-2.903 28.363,0 -3.136,2.903 -28.363,0 z"
id="path3125" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 176.696,162.903 3.136,-2.903 28.363,0 -3.136,2.903 -28.363,0"
id="path3127" />
<path
style="fill:#b7b79d"
d="m 176.696,162.903 28.59,0 0,22.569 -28.59,0 0,-22.569 z"
id="path3129" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 176.696,162.903 28.577,0 0,22.563 -28.577,0 0,-22.563"
id="path3131" />
<path
style="fill:#ffffff"
d="m 179.152,165.8 23.672,0 0,17.437 -23.672,0 0,-17.437 z"
id="path3133" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 179.152,165.8 23.672,0 0,17.43 -23.672,0 0,-17.43"
id="path3135" />
<path
style="fill:#7a7a5a"
d="m 205.059,185.258 3.136,-3.13 0,-22.128 -3.136,2.903 0,22.355 z"
id="path3137" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 205.059,185.258 3.136,-3.13 0,-22.128 -3.136,2.903 0,22.355"
id="path3139" />
</g>
<g
style="display:inline"
id="g3093-1"
transform="translate(-80.220357,10.805087)">
<path
style="fill:#b7b79d"
d="m 170.897,186.814 39.968,0 0,7.386 -39.968,0 0,-7.386 z"
id="path3095-1" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 170.897,186.814 39.968,0 0,7.386 -39.968,0 0,-7.386"
id="path3097-9" />
<path
style="fill:#c9c9b6"
d="m 170.897,186.814 4.238,-4.018 39.968,0 -4.238,4.018 -39.968,0 z"
id="path3099-0" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 170.897,186.814 4.238,-4.018 39.968,0 -4.238,4.018 -39.968,0"
id="path3101-5" />
<path
style="fill:none;stroke:#000000;stroke-width:2.11999989"
d="m 208.63,190.176 -9.591,0"
id="path3103-6" />
<path
style="fill:#7a7a5a"
d="m 210.865,194.2 4.238,-4.25 0,-7.154 -4.238,4.018 0,7.386 z"
id="path3105-7" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 210.865,194.2 4.238,-4.25 0,-7.154 -4.238,4.018 0,7.386"
id="path3107-7" />
<path
style="fill:#c9c9b6"
d="m 171.123,198.885 4.459,-5.585 30.819,0 -4.459,5.585 -30.819,0 z"
id="path3109-4" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 171.123,198.885 4.459,-5.585 30.819,0 -4.459,5.585 -30.819,0"
id="path3111-0" />
<path
style="fill:#7a7a5a"
d="m 201.942,200 4.459,-4.685 0,-2.015 -4.459,5.585 0,1.115 z"
id="path3113-6" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 201.942,200 4.459,-4.685 0,-2.015 -4.459,5.585 0,1.115"
id="path3115-4" />
<path
style="fill:#b7b79d"
d="m 171.123,198.885 30.819,0 0,1.115 -30.819,0 0,-1.115 z"
id="path3117-7" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 171.123,198.885 30.819,0 0,1.115 -30.819,0 0,-1.115"
id="path3119-4" />
<path
style="fill:#000000"
d="m 176.923,185.926 3.357,-3.13 28.35,0 -3.117,3.13 -28.59,0 z"
id="path3121-8" />
<path
style="fill:none;stroke:#000000;stroke-width:0.02"
d="m 176.923,185.926 3.357,-3.13 28.35,0 -3.117,3.13 -28.59,0"
id="path3123-5" />
<path
style="fill:#c9c9b6"
d="m 176.696,162.903 3.136,-2.903 28.363,0 -3.136,2.903 -28.363,0 z"
id="path3125-8" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 176.696,162.903 3.136,-2.903 28.363,0 -3.136,2.903 -28.363,0"
id="path3127-2" />
<path
style="fill:#b7b79d"
d="m 176.696,162.903 28.59,0 0,22.569 -28.59,0 0,-22.569 z"
id="path3129-6" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 176.696,162.903 28.577,0 0,22.563 -28.577,0 0,-22.563"
id="path3131-0" />
<path
style="fill:#ffffff"
d="m 179.152,165.8 23.672,0 0,17.437 -23.672,0 0,-17.437 z"
id="path3133-6" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 179.152,165.8 23.672,0 0,17.43 -23.672,0 0,-17.43"
id="path3135-6" />
<path
style="fill:#7a7a5a"
d="m 205.059,185.258 3.136,-3.13 0,-22.128 -3.136,2.903 0,22.355 z"
id="path3137-4" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 205.059,185.258 3.136,-3.13 0,-22.128 -3.136,2.903 0,22.355"
id="path3139-6" />
</g>
<g
style="display:inline"
id="g3093-1-3"
transform="translate(38.710001,10.805087)">
<path
style="fill:#b7b79d"
d="m 170.897,186.814 39.968,0 0,7.386 -39.968,0 0,-7.386 z"
id="path3095-1-7" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 170.897,186.814 39.968,0 0,7.386 -39.968,0 0,-7.386"
id="path3097-9-7" />
<path
style="fill:#c9c9b6"
d="m 170.897,186.814 4.238,-4.018 39.968,0 -4.238,4.018 -39.968,0 z"
id="path3099-0-2" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 170.897,186.814 4.238,-4.018 39.968,0 -4.238,4.018 -39.968,0"
id="path3101-5-6" />
<path
style="fill:none;stroke:#000000;stroke-width:2.11999989"
d="m 208.63,190.176 -9.591,0"
id="path3103-6-4" />
<path
style="fill:#7a7a5a"
d="m 210.865,194.2 4.238,-4.25 0,-7.154 -4.238,4.018 0,7.386 z"
id="path3105-7-5" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 210.865,194.2 4.238,-4.25 0,-7.154 -4.238,4.018 0,7.386"
id="path3107-7-2" />
<path
style="fill:#c9c9b6"
d="m 171.123,198.885 4.459,-5.585 30.819,0 -4.459,5.585 -30.819,0 z"
id="path3109-4-0" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 171.123,198.885 4.459,-5.585 30.819,0 -4.459,5.585 -30.819,0"
id="path3111-0-2" />
<path
style="fill:#7a7a5a"
d="m 201.942,200 4.459,-4.685 0,-2.015 -4.459,5.585 0,1.115 z"
id="path3113-6-9" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 201.942,200 4.459,-4.685 0,-2.015 -4.459,5.585 0,1.115"
id="path3115-4-0" />
<path
style="fill:#b7b79d"
d="m 171.123,198.885 30.819,0 0,1.115 -30.819,0 0,-1.115 z"
id="path3117-7-9" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 171.123,198.885 30.819,0 0,1.115 -30.819,0 0,-1.115"
id="path3119-4-9" />
<path
style="fill:#000000"
d="m 176.923,185.926 3.357,-3.13 28.35,0 -3.117,3.13 -28.59,0 z"
id="path3121-8-4" />
<path
style="fill:none;stroke:#000000;stroke-width:0.02"
d="m 176.923,185.926 3.357,-3.13 28.35,0 -3.117,3.13 -28.59,0"
id="path3123-5-5" />
<path
style="fill:#c9c9b6"
d="m 176.696,162.903 3.136,-2.903 28.363,0 -3.136,2.903 -28.363,0 z"
id="path3125-8-1" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 176.696,162.903 3.136,-2.903 28.363,0 -3.136,2.903 -28.363,0"
id="path3127-2-0" />
<path
style="fill:#b7b79d"
d="m 176.696,162.903 28.59,0 0,22.569 -28.59,0 0,-22.569 z"
id="path3129-6-3" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 176.696,162.903 28.577,0 0,22.563 -28.577,0 0,-22.563"
id="path3131-0-7" />
<path
style="fill:#ffffff"
d="m 179.152,165.8 23.672,0 0,17.437 -23.672,0 0,-17.437 z"
id="path3133-6-8" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 179.152,165.8 23.672,0 0,17.43 -23.672,0 0,-17.43"
id="path3135-6-8" />
<path
style="fill:#7a7a5a"
d="m 205.059,185.258 3.136,-3.13 0,-22.128 -3.136,2.903 0,22.355 z"
id="path3137-4-6" />
<path
style="fill:none;stroke:#494936;stroke-width:0.02"
d="m 205.059,185.258 3.136,-3.13 0,-22.128 -3.136,2.903 0,22.355"
id="path3139-6-0" />
</g>
<path
style="fill:#cacaff;fill-opacity:1;fill-rule:nonzero;stroke:none;display:inline"
d="m 210.96287,244.40394 c -46.36835,0 -85.38274,19.53789 -96.93388,46.09394 -10.69963,-2.73694 -22.659031,-4.27314 -35.288491,-4.27314 -45.540086,0 -82.4507158,19.90612 -82.4507158,44.46524 0,9.70624 5.765251,18.67753 15.5514528,25.98914 -12.20321684,6.15369 -19.6844958,14.41016 -19.6844958,23.4848 0,19.02925 32.8283478,34.44786 73.3264988,34.44786 27.54066,0 51.544801,-7.12071 64.079691,-17.67051 15.34489,5.5421 34.71109,8.84401 55.77858,8.84401 49.76881,0 90.12136,-18.45531 90.12136,-41.22536 0,-3.0279 -0.72988,-5.98433 -2.08403,-8.8265 23.15405,-11.43708 38.00298,-29.08221 38.00298,-48.896 0,-34.48036 -44.95762,-62.43348 -100.41895,-62.43348 z"
id="path5558" />
</g>
<g
inkscape:groupmode="layer"
id="layer1"
inkscape:label="Text"
style="display:inline">
<text
xml:space="preserve"
style="font-size:11.20825386px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans"
x="101.22408"
y="339.98462"
id="text4359"><tspan
sodipodi:role="line"
id="tspan4361"
x="101.22408"
y="339.98462">Network database</tspan></text>
<text
xml:space="preserve"
style="font-size:6.16453981px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans"
x="25.080004"
y="181.51357"
id="text5297"
transform="matrix(0.99997535,-0.00702166,0.00702166,0.99997535,0,0)"><tspan
sodipodi:role="line"
id="tspan5299"
x="25.080004"
y="181.51357"
style="font-size:11.20825386px">build tunnel</tspan></text>
<text
transform="translate(-2.1705283e-6,-6.1137644e-7)"
xml:space="preserve"
style="font-size:11.20825385999999924px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans"
x="-5.6149035"
y="162.89429"
id="text5301"><tspan
sodipodi:role="line"
id="tspan5303"
x="-5.6149035"
y="162.89429">Alice</tspan></text>
<text
transform="translate(-2.1705283e-6,-6.1137644e-7)"
xml:space="preserve"
style="font-size:11.20825385999999924px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans"
x="99.99514"
y="162.76093"
id="text5301-0"><tspan
sodipodi:role="line"
id="tspan5303-7"
x="99.99514"
y="162.76093">John</tspan></text>
<text
transform="translate(-2.1705283e-6,-6.1137644e-7)"
xml:space="preserve"
style="font-size:11.20825385999999924px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans"
x="217.44405"
y="161.75439"
id="text5301-6"><tspan
sodipodi:role="line"
id="tspan5303-6"
x="217.44405"
y="161.75439">Peter</tspan></text>
<path
style="fill:none;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-end:url(#Arrow1Lend)"
d="m -132.42359,48.345122 131.3726091,0"
id="path5942"
transform="matrix(0.5604127,0,0,0.5604127,97,159)" />
<path
style="fill:none;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-end:url(#Arrow1Lend)"
d="m 55.701988,48.345122 155.545172,0"
id="path6128"
transform="matrix(0.5604127,0,0,0.5604127,97,159)" />
<path
style="fill:none;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
d="m -352.0786,-3.152943 0,0 z"
id="path6314"
transform="matrix(0.5604127,0,0,0.5604127,97,159)" />
<text
xml:space="preserve"
style="font-size:6.16453981px;font-style:normal;font-weight:normal;fill:#000000;fill-opacity:1;stroke:none;display:inline;font-family:Bitstream Vera Sans"
x="136.1862"
y="182.10078"
id="text5297-6"
transform="matrix(0.99997535,-0.00702166,0.00702166,0.99997535,0,0)"><tspan
sodipodi:role="line"
id="tspan5299-2"
x="136.1862"
y="182.10078"
style="font-size:11.20825386px">build tunnel</tspan></text>
</g>
</svg>
Side by Side

After

Width:  |  Height:  |  Size: 20 KiB

190
www.i2p2/image_design/protocol_stack.svg Normal file
View File

@ -0,0 +1,190 @@
<?xml version="1.0" encoding="UTF-8"?>
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" width="362pt" height="422pt" viewBox="0 0 362 422" version="1.1">
<defs>
<g>
<symbol overflow="visible" id="glyph0-0">
<path style="stroke:none;" d="M 0.84375 3 L 0.84375 -11.984375 L 9.34375 -11.984375 L 9.34375 3 L 0.84375 3 Z M 1.796875 2.0625 L 8.40625 2.0625 L 8.40625 -11.03125 L 1.796875 -11.03125 L 1.796875 2.0625 Z M 1.796875 2.0625 "/>
</symbol>
<symbol overflow="visible" id="glyph0-1">
<path style="stroke:none;" d="M 1.671875 -12.390625 L 3.34375 -12.390625 L 3.34375 0 L 1.671875 0 L 1.671875 -12.390625 Z M 1.671875 -12.390625 "/>
</symbol>
<symbol overflow="visible" id="glyph0-2">
<path style="stroke:none;" d="M 3.34375 -11.015625 L 3.34375 -6.359375 L 5.453125 -6.359375 C 6.234375 -6.359375 6.835938 -6.5625 7.265625 -6.96875 C 7.691406 -7.375 7.90625 -7.945312 7.90625 -8.6875 C 7.90625 -9.425781 7.691406 -10 7.265625 -10.40625 C 6.835938 -10.8125 6.234375 -11.015625 5.453125 -11.015625 L 3.34375 -11.015625 Z M 1.671875 -12.390625 L 5.453125 -12.390625 C 6.835938 -12.390625 7.882812 -12.078125 8.59375 -11.453125 C 9.3125 -10.828125 9.671875 -9.90625 9.671875 -8.6875 C 9.671875 -7.46875 9.3125 -6.546875 8.59375 -5.921875 C 7.882812 -5.296875 6.835938 -4.984375 5.453125 -4.984375 L 3.34375 -4.984375 L 3.34375 0 L 1.671875 0 L 1.671875 -12.390625 Z M 1.671875 -12.390625 "/>
</symbol>
<symbol overflow="visible" id="glyph0-3">
<path style="stroke:none;" d="M -0.046875 -12.390625 L 10.4375 -12.390625 L 10.4375 -10.984375 L 6.03125 -10.984375 L 6.03125 0 L 4.34375 0 L 4.34375 -10.984375 L -0.046875 -10.984375 L -0.046875 -12.390625 Z M -0.046875 -12.390625 "/>
</symbol>
<symbol overflow="visible" id="glyph0-4">
<path style="stroke:none;" d="M 10.953125 -11.4375 L 10.953125 -9.671875 C 10.390625 -10.191406 9.785156 -10.582031 9.140625 -10.84375 C 8.503906 -11.101562 7.828125 -11.234375 7.109375 -11.234375 C 5.691406 -11.234375 4.601562 -10.800781 3.84375 -9.9375 C 3.09375 -9.070312 2.71875 -7.820312 2.71875 -6.1875 C 2.71875 -4.550781 3.09375 -3.300781 3.84375 -2.4375 C 4.601562 -1.570312 5.691406 -1.140625 7.109375 -1.140625 C 7.828125 -1.140625 8.503906 -1.269531 9.140625 -1.53125 C 9.785156 -1.789062 10.390625 -2.179688 10.953125 -2.703125 L 10.953125 -0.953125 C 10.359375 -0.554688 9.734375 -0.257812 9.078125 -0.0625 C 8.429688 0.132812 7.738281 0.234375 7 0.234375 C 5.125 0.234375 3.644531 -0.335938 2.5625 -1.484375 C 1.488281 -2.628906 0.953125 -4.195312 0.953125 -6.1875 C 0.953125 -8.175781 1.488281 -9.742188 2.5625 -10.890625 C 3.644531 -12.046875 5.125 -12.625 7 -12.625 C 7.75 -12.625 8.445312 -12.523438 9.09375 -12.328125 C 9.75 -12.128906 10.367188 -11.832031 10.953125 -11.4375 Z M 10.953125 -11.4375 "/>
</symbol>
<symbol overflow="visible" id="glyph0-5">
<path style="stroke:none;" d="M 1.484375 -12.390625 L 3.15625 -12.390625 L 3.15625 -4.859375 C 3.15625 -3.535156 3.394531 -2.582031 3.875 -2 C 4.363281 -1.414062 5.144531 -1.125 6.21875 -1.125 C 7.300781 -1.125 8.082031 -1.414062 8.5625 -2 C 9.039062 -2.582031 9.28125 -3.535156 9.28125 -4.859375 L 9.28125 -12.390625 L 10.96875 -12.390625 L 10.96875 -4.65625 C 10.96875 -3.039062 10.566406 -1.820312 9.765625 -1 C 8.960938 -0.175781 7.78125 0.234375 6.21875 0.234375 C 4.65625 0.234375 3.472656 -0.175781 2.671875 -1 C 1.878906 -1.820312 1.484375 -3.039062 1.484375 -4.65625 L 1.484375 -12.390625 Z M 1.484375 -12.390625 "/>
</symbol>
<symbol overflow="visible" id="glyph0-6">
<path style="stroke:none;" d="M 3.34375 -11.015625 L 3.34375 -1.375 L 5.375 -1.375 C 7.082031 -1.375 8.332031 -1.757812 9.125 -2.53125 C 9.914062 -3.3125 10.3125 -4.535156 10.3125 -6.203125 C 10.3125 -7.867188 9.914062 -9.085938 9.125 -9.859375 C 8.332031 -10.628906 7.082031 -11.015625 5.375 -11.015625 L 3.34375 -11.015625 Z M 1.671875 -12.390625 L 5.109375 -12.390625 C 7.515625 -12.390625 9.28125 -11.890625 10.40625 -10.890625 C 11.53125 -9.890625 12.09375 -8.328125 12.09375 -6.203125 C 12.09375 -4.066406 11.523438 -2.5 10.390625 -1.5 C 9.265625 -0.5 7.503906 0 5.109375 0 L 1.671875 0 L 1.671875 -12.390625 Z M 1.671875 -12.390625 "/>
</symbol>
<symbol overflow="visible" id="glyph0-7">
<path style="stroke:none;" d="M 1.671875 -12.390625 L 3.921875 -12.390625 L 9.421875 -2.03125 L 9.421875 -12.390625 L 11.046875 -12.390625 L 11.046875 0 L 8.796875 0 L 3.296875 -10.375 L 3.296875 0 L 1.671875 0 L 1.671875 -12.390625 Z M 1.671875 -12.390625 "/>
</symbol>
<symbol overflow="visible" id="glyph0-8">
<path style="stroke:none;" d="M 9.09375 -11.984375 L 9.09375 -10.34375 C 8.457031 -10.65625 7.859375 -10.882812 7.296875 -11.03125 C 6.734375 -11.175781 6.1875 -11.25 5.65625 -11.25 C 4.75 -11.25 4.046875 -11.070312 3.546875 -10.71875 C 3.054688 -10.363281 2.8125 -9.863281 2.8125 -9.21875 C 2.8125 -8.664062 2.972656 -8.25 3.296875 -7.96875 C 3.628906 -7.6875 4.253906 -7.460938 5.171875 -7.296875 L 6.1875 -7.09375 C 7.4375 -6.851562 8.359375 -6.429688 8.953125 -5.828125 C 9.546875 -5.234375 9.84375 -4.429688 9.84375 -3.421875 C 9.84375 -2.222656 9.4375 -1.3125 8.625 -0.6875 C 7.820312 -0.0703125 6.644531 0.234375 5.09375 0.234375 C 4.507812 0.234375 3.882812 0.164062 3.21875 0.03125 C 2.5625 -0.09375 1.878906 -0.285156 1.171875 -0.546875 L 1.171875 -2.28125 C 1.847656 -1.894531 2.515625 -1.601562 3.171875 -1.40625 C 3.828125 -1.21875 4.46875 -1.125 5.09375 -1.125 C 6.050781 -1.125 6.789062 -1.3125 7.3125 -1.6875 C 7.832031 -2.0625 8.09375 -2.597656 8.09375 -3.296875 C 8.09375 -3.898438 7.90625 -4.375 7.53125 -4.71875 C 7.15625 -5.0625 6.539062 -5.320312 5.6875 -5.5 L 4.671875 -5.6875 C 3.421875 -5.9375 2.515625 -6.328125 1.953125 -6.859375 C 1.398438 -7.390625 1.125 -8.128906 1.125 -9.078125 C 1.125 -10.171875 1.507812 -11.035156 2.28125 -11.671875 C 3.050781 -12.304688 4.113281 -12.625 5.46875 -12.625 C 6.050781 -12.625 6.644531 -12.566406 7.25 -12.453125 C 7.851562 -12.347656 8.46875 -12.191406 9.09375 -11.984375 Z M 9.09375 -11.984375 "/>
</symbol>
<symbol overflow="visible" id="glyph0-9">
<path style="stroke:none;" d="M 1.4375 -3.671875 L 1.4375 -9.296875 L 2.96875 -9.296875 L 2.96875 -3.734375 C 2.96875 -2.847656 3.140625 -2.1875 3.484375 -1.75 C 3.828125 -1.3125 4.34375 -1.09375 5.03125 -1.09375 C 5.851562 -1.09375 6.503906 -1.351562 6.984375 -1.875 C 7.460938 -2.40625 7.703125 -3.125 7.703125 -4.03125 L 7.703125 -9.296875 L 9.234375 -9.296875 L 9.234375 0 L 7.703125 0 L 7.703125 -1.421875 C 7.328125 -0.859375 6.894531 -0.441406 6.40625 -0.171875 C 5.914062 0.0976562 5.347656 0.234375 4.703125 0.234375 C 3.640625 0.234375 2.828125 -0.09375 2.265625 -0.75 C 1.710938 -1.414062 1.4375 -2.390625 1.4375 -3.671875 Z M 5.28125 -9.515625 L 5.28125 -9.515625 Z M 5.28125 -9.515625 "/>
</symbol>
<symbol overflow="visible" id="glyph0-10">
<path style="stroke:none;" d="M 9.328125 -5.609375 L 9.328125 0 L 7.796875 0 L 7.796875 -5.5625 C 7.796875 -6.4375 7.625 -7.09375 7.28125 -7.53125 C 6.945312 -7.96875 6.4375 -8.1875 5.75 -8.1875 C 4.914062 -8.1875 4.257812 -7.921875 3.78125 -7.390625 C 3.3125 -6.867188 3.078125 -6.15625 3.078125 -5.25 L 3.078125 0 L 1.546875 0 L 1.546875 -9.296875 L 3.078125 -9.296875 L 3.078125 -7.859375 C 3.441406 -8.410156 3.867188 -8.820312 4.359375 -9.09375 C 4.859375 -9.375 5.429688 -9.515625 6.078125 -9.515625 C 7.148438 -9.515625 7.957031 -9.179688 8.5 -8.515625 C 9.050781 -7.859375 9.328125 -6.890625 9.328125 -5.609375 Z M 9.328125 -5.609375 "/>
</symbol>
<symbol overflow="visible" id="glyph0-11">
<path style="stroke:none;" d="M 9.546875 -5.03125 L 9.546875 -4.28125 L 2.53125 -4.28125 C 2.59375 -3.226562 2.90625 -2.425781 3.46875 -1.875 C 4.039062 -1.320312 4.835938 -1.046875 5.859375 -1.046875 C 6.441406 -1.046875 7.007812 -1.117188 7.5625 -1.265625 C 8.113281 -1.410156 8.660156 -1.628906 9.203125 -1.921875 L 9.203125 -0.46875 C 8.648438 -0.238281 8.085938 -0.0664062 7.515625 0.046875 C 6.941406 0.171875 6.359375 0.234375 5.765625 0.234375 C 4.273438 0.234375 3.097656 -0.191406 2.234375 -1.046875 C 1.367188 -1.910156 0.9375 -3.082031 0.9375 -4.5625 C 0.9375 -6.082031 1.347656 -7.285156 2.171875 -8.171875 C 2.992188 -9.066406 4.101562 -9.515625 5.5 -9.515625 C 6.75 -9.515625 7.734375 -9.113281 8.453125 -8.3125 C 9.179688 -7.507812 9.546875 -6.414062 9.546875 -5.03125 Z M 8.03125 -5.484375 C 8.019531 -6.316406 7.785156 -6.976562 7.328125 -7.46875 C 6.867188 -7.96875 6.265625 -8.21875 5.515625 -8.21875 C 4.660156 -8.21875 3.976562 -7.976562 3.46875 -7.5 C 2.957031 -7.019531 2.660156 -6.34375 2.578125 -5.46875 L 8.03125 -5.484375 Z M 8.03125 -5.484375 "/>
</symbol>
<symbol overflow="visible" id="glyph0-12">
<path style="stroke:none;" d="M 1.609375 -12.921875 L 3.125 -12.921875 L 3.125 0 L 1.609375 0 L 1.609375 -12.921875 Z M 1.609375 -12.921875 "/>
</symbol>
<symbol overflow="visible" id="glyph0-13">
<path style="stroke:none;" d=""/>
</symbol>
<symbol overflow="visible" id="glyph0-14">
<path style="stroke:none;" d="M 8.84375 -7.515625 C 9.21875 -8.203125 9.671875 -8.707031 10.203125 -9.03125 C 10.734375 -9.351562 11.363281 -9.515625 12.09375 -9.515625 C 13.050781 -9.515625 13.789062 -9.175781 14.3125 -8.5 C 14.84375 -7.820312 15.109375 -6.859375 15.109375 -5.609375 L 15.109375 0 L 13.578125 0 L 13.578125 -5.5625 C 13.578125 -6.445312 13.421875 -7.101562 13.109375 -7.53125 C 12.796875 -7.96875 12.3125 -8.1875 11.65625 -8.1875 C 10.863281 -8.1875 10.238281 -7.921875 9.78125 -7.390625 C 9.320312 -6.867188 9.09375 -6.15625 9.09375 -5.25 L 9.09375 0 L 7.5625 0 L 7.5625 -5.5625 C 7.5625 -6.457031 7.398438 -7.117188 7.078125 -7.546875 C 6.765625 -7.972656 6.28125 -8.1875 5.625 -8.1875 C 4.84375 -8.1875 4.222656 -7.921875 3.765625 -7.390625 C 3.304688 -6.867188 3.078125 -6.15625 3.078125 -5.25 L 3.078125 0 L 1.546875 0 L 1.546875 -9.296875 L 3.078125 -9.296875 L 3.078125 -7.859375 C 3.429688 -8.421875 3.847656 -8.835938 4.328125 -9.109375 C 4.816406 -9.378906 5.394531 -9.515625 6.0625 -9.515625 C 6.738281 -9.515625 7.3125 -9.34375 7.78125 -9 C 8.257812 -8.65625 8.613281 -8.160156 8.84375 -7.515625 Z M 8.84375 -7.515625 "/>
</symbol>
<symbol overflow="visible" id="glyph0-15">
<path style="stroke:none;" d="M 7.53125 -9.015625 L 7.53125 -7.578125 C 7.09375 -7.796875 6.640625 -7.960938 6.171875 -8.078125 C 5.710938 -8.191406 5.234375 -8.25 4.734375 -8.25 C 3.984375 -8.25 3.414062 -8.128906 3.03125 -7.890625 C 2.65625 -7.660156 2.46875 -7.3125 2.46875 -6.84375 C 2.46875 -6.488281 2.601562 -6.210938 2.875 -6.015625 C 3.144531 -5.816406 3.6875 -5.625 4.5 -5.4375 L 5.03125 -5.328125 C 6.113281 -5.085938 6.882812 -4.753906 7.34375 -4.328125 C 7.800781 -3.910156 8.03125 -3.320312 8.03125 -2.5625 C 8.03125 -1.695312 7.6875 -1.015625 7 -0.515625 C 6.320312 -0.015625 5.382812 0.234375 4.1875 0.234375 C 3.6875 0.234375 3.164062 0.1875 2.625 0.09375 C 2.082031 0 1.515625 -0.144531 0.921875 -0.34375 L 0.921875 -1.921875 C 1.484375 -1.628906 2.035156 -1.40625 2.578125 -1.25 C 3.128906 -1.101562 3.675781 -1.03125 4.21875 -1.03125 C 4.9375 -1.03125 5.488281 -1.15625 5.875 -1.40625 C 6.257812 -1.65625 6.453125 -2.003906 6.453125 -2.453125 C 6.453125 -2.867188 6.3125 -3.1875 6.03125 -3.40625 C 5.757812 -3.625 5.148438 -3.835938 4.203125 -4.046875 L 3.671875 -4.171875 C 2.722656 -4.367188 2.035156 -4.671875 1.609375 -5.078125 C 1.191406 -5.492188 0.984375 -6.0625 0.984375 -6.78125 C 0.984375 -7.65625 1.289062 -8.328125 1.90625 -8.796875 C 2.53125 -9.273438 3.414062 -9.515625 4.5625 -9.515625 C 5.125 -9.515625 5.648438 -9.472656 6.140625 -9.390625 C 6.640625 -9.304688 7.101562 -9.179688 7.53125 -9.015625 Z M 7.53125 -9.015625 "/>
</symbol>
<symbol overflow="visible" id="glyph0-16">
<path style="stroke:none;" d="M 5.828125 -4.671875 C 4.585938 -4.671875 3.726562 -4.53125 3.25 -4.25 C 2.78125 -3.96875 2.546875 -3.488281 2.546875 -2.8125 C 2.546875 -2.269531 2.722656 -1.835938 3.078125 -1.515625 C 3.441406 -1.191406 3.929688 -1.03125 4.546875 -1.03125 C 5.390625 -1.03125 6.066406 -1.332031 6.578125 -1.9375 C 7.085938 -2.539062 7.34375 -3.335938 7.34375 -4.328125 L 7.34375 -4.671875 L 5.828125 -4.671875 Z M 8.875 -5.296875 L 8.875 0 L 7.34375 0 L 7.34375 -1.40625 C 7 -0.84375 6.566406 -0.425781 6.046875 -0.15625 C 5.523438 0.101562 4.890625 0.234375 4.140625 0.234375 C 3.179688 0.234375 2.421875 -0.03125 1.859375 -0.5625 C 1.296875 -1.09375 1.015625 -1.804688 1.015625 -2.703125 C 1.015625 -3.753906 1.363281 -4.546875 2.0625 -5.078125 C 2.769531 -5.609375 3.816406 -5.875 5.203125 -5.875 L 7.34375 -5.875 L 7.34375 -6.015625 C 7.34375 -6.722656 7.109375 -7.265625 6.640625 -7.640625 C 6.179688 -8.023438 5.535156 -8.21875 4.703125 -8.21875 C 4.171875 -8.21875 3.65625 -8.15625 3.15625 -8.03125 C 2.65625 -7.90625 2.171875 -7.71875 1.703125 -7.46875 L 1.703125 -8.875 C 2.265625 -9.09375 2.804688 -9.253906 3.328125 -9.359375 C 3.859375 -9.460938 4.367188 -9.515625 4.859375 -9.515625 C 6.203125 -9.515625 7.207031 -9.164062 7.875 -8.46875 C 8.539062 -7.769531 8.875 -6.710938 8.875 -5.296875 Z M 8.875 -5.296875 "/>
</symbol>
<symbol overflow="visible" id="glyph0-17">
<path style="stroke:none;" d="M 7.71875 -4.75 C 7.71875 -5.863281 7.488281 -6.722656 7.03125 -7.328125 C 6.570312 -7.941406 5.929688 -8.25 5.109375 -8.25 C 4.296875 -8.25 3.660156 -7.941406 3.203125 -7.328125 C 2.742188 -6.722656 2.515625 -5.863281 2.515625 -4.75 C 2.515625 -3.65625 2.742188 -2.800781 3.203125 -2.1875 C 3.660156 -1.582031 4.296875 -1.28125 5.109375 -1.28125 C 5.929688 -1.28125 6.570312 -1.582031 7.03125 -2.1875 C 7.488281 -2.800781 7.71875 -3.65625 7.71875 -4.75 Z M 9.25 -1.15625 C 9.25 0.425781 8.894531 1.601562 8.1875 2.375 C 7.488281 3.144531 6.414062 3.53125 4.96875 3.53125 C 4.425781 3.53125 3.914062 3.488281 3.4375 3.40625 C 2.96875 3.332031 2.507812 3.210938 2.0625 3.046875 L 2.0625 1.5625 C 2.507812 1.800781 2.953125 1.976562 3.390625 2.09375 C 3.828125 2.21875 4.269531 2.28125 4.71875 2.28125 C 5.71875 2.28125 6.46875 2.015625 6.96875 1.484375 C 7.46875 0.960938 7.71875 0.175781 7.71875 -0.875 L 7.71875 -1.640625 C 7.40625 -1.085938 7 -0.675781 6.5 -0.40625 C 6.007812 -0.132812 5.421875 0 4.734375 0 C 3.597656 0 2.679688 -0.429688 1.984375 -1.296875 C 1.285156 -2.171875 0.9375 -3.320312 0.9375 -4.75 C 0.9375 -6.195312 1.285156 -7.351562 1.984375 -8.21875 C 2.679688 -9.082031 3.597656 -9.515625 4.734375 -9.515625 C 5.421875 -9.515625 6.007812 -9.378906 6.5 -9.109375 C 7 -8.835938 7.40625 -8.429688 7.71875 -7.890625 L 7.71875 -9.296875 L 9.25 -9.296875 L 9.25 -1.15625 Z M 9.25 -1.15625 "/>
</symbol>
<symbol overflow="visible" id="glyph0-18">
<path style="stroke:none;" d="M 10.125 -1.765625 L 10.125 -5.09375 L 7.375 -5.09375 L 7.375 -6.46875 L 11.78125 -6.46875 L 11.78125 -1.15625 C 11.132812 -0.695312 10.421875 -0.347656 9.640625 -0.109375 C 8.859375 0.117188 8.023438 0.234375 7.140625 0.234375 C 5.203125 0.234375 3.6875 -0.328125 2.59375 -1.453125 C 1.5 -2.585938 0.953125 -4.164062 0.953125 -6.1875 C 0.953125 -8.207031 1.5 -9.785156 2.59375 -10.921875 C 3.6875 -12.054688 5.203125 -12.625 7.140625 -12.625 C 7.941406 -12.625 8.707031 -12.519531 9.4375 -12.3125 C 10.164062 -12.113281 10.835938 -11.820312 11.453125 -11.4375 L 11.453125 -9.65625 C 10.835938 -10.175781 10.179688 -10.566406 9.484375 -10.828125 C 8.785156 -11.097656 8.050781 -11.234375 7.28125 -11.234375 C 5.757812 -11.234375 4.617188 -10.8125 3.859375 -9.96875 C 3.097656 -9.125 2.71875 -7.863281 2.71875 -6.1875 C 2.71875 -4.507812 3.097656 -3.25 3.859375 -2.40625 C 4.617188 -1.5625 5.757812 -1.140625 7.28125 -1.140625 C 7.875 -1.140625 8.398438 -1.1875 8.859375 -1.28125 C 9.328125 -1.382812 9.75 -1.546875 10.125 -1.765625 Z M 10.125 -1.765625 "/>
</symbol>
<symbol overflow="visible" id="glyph0-19">
<path style="stroke:none;" d="M 6.984375 -7.875 C 6.816406 -7.96875 6.628906 -8.035156 6.421875 -8.078125 C 6.222656 -8.128906 6.003906 -8.15625 5.765625 -8.15625 C 4.898438 -8.15625 4.234375 -7.875 3.765625 -7.3125 C 3.304688 -6.75 3.078125 -5.941406 3.078125 -4.890625 L 3.078125 0 L 1.546875 0 L 1.546875 -9.296875 L 3.078125 -9.296875 L 3.078125 -7.859375 C 3.398438 -8.421875 3.816406 -8.835938 4.328125 -9.109375 C 4.847656 -9.378906 5.472656 -9.515625 6.203125 -9.515625 C 6.304688 -9.515625 6.421875 -9.507812 6.546875 -9.5 C 6.679688 -9.488281 6.828125 -9.46875 6.984375 -9.4375 L 6.984375 -7.875 Z M 6.984375 -7.875 "/>
</symbol>
<symbol overflow="visible" id="glyph0-20">
<path style="stroke:none;" d="M 1.609375 -9.296875 L 3.125 -9.296875 L 3.125 0 L 1.609375 0 L 1.609375 -9.296875 Z M 1.609375 -12.921875 L 3.125 -12.921875 L 3.125 -10.984375 L 1.609375 -10.984375 L 1.609375 -12.921875 Z M 1.609375 -12.921875 "/>
</symbol>
<symbol overflow="visible" id="glyph0-21">
<path style="stroke:none;" d="M 8.296875 -8.9375 L 8.296875 -7.515625 C 7.859375 -7.753906 7.421875 -7.929688 6.984375 -8.046875 C 6.554688 -8.160156 6.117188 -8.21875 5.671875 -8.21875 C 4.679688 -8.21875 3.910156 -7.90625 3.359375 -7.28125 C 2.816406 -6.65625 2.546875 -5.773438 2.546875 -4.640625 C 2.546875 -3.503906 2.816406 -2.617188 3.359375 -1.984375 C 3.910156 -1.359375 4.679688 -1.046875 5.671875 -1.046875 C 6.117188 -1.046875 6.554688 -1.101562 6.984375 -1.21875 C 7.421875 -1.34375 7.859375 -1.523438 8.296875 -1.765625 L 8.296875 -0.359375 C 7.867188 -0.160156 7.425781 -0.015625 6.96875 0.078125 C 6.507812 0.179688 6.023438 0.234375 5.515625 0.234375 C 4.109375 0.234375 2.992188 -0.203125 2.171875 -1.078125 C 1.347656 -1.960938 0.9375 -3.148438 0.9375 -4.640625 C 0.9375 -6.160156 1.351562 -7.351562 2.1875 -8.21875 C 3.019531 -9.082031 4.160156 -9.515625 5.609375 -9.515625 C 6.078125 -9.515625 6.535156 -9.46875 6.984375 -9.375 C 7.429688 -9.28125 7.867188 -9.132812 8.296875 -8.9375 Z M 8.296875 -8.9375 "/>
</symbol>
<symbol overflow="visible" id="glyph0-22">
<path style="stroke:none;" d="M 5.46875 0.859375 C 5.039062 1.972656 4.617188 2.695312 4.203125 3.03125 C 3.796875 3.363281 3.25 3.53125 2.5625 3.53125 L 1.34375 3.53125 L 1.34375 2.265625 L 2.234375 2.265625 C 2.660156 2.265625 2.988281 2.160156 3.21875 1.953125 C 3.445312 1.753906 3.707031 1.285156 4 0.546875 L 4.265625 -0.15625 L 0.5 -9.296875 L 2.125 -9.296875 L 5.03125 -2.03125 L 7.9375 -9.296875 L 9.546875 -9.296875 L 5.46875 0.859375 Z M 5.46875 0.859375 "/>
</symbol>
<symbol overflow="visible" id="glyph0-23">
<path style="stroke:none;" d="M 3.078125 -1.390625 L 3.078125 3.53125 L 1.546875 3.53125 L 1.546875 -9.296875 L 3.078125 -9.296875 L 3.078125 -7.890625 C 3.398438 -8.441406 3.804688 -8.847656 4.296875 -9.109375 C 4.785156 -9.378906 5.367188 -9.515625 6.046875 -9.515625 C 7.179688 -9.515625 8.097656 -9.066406 8.796875 -8.171875 C 9.503906 -7.273438 9.859375 -6.097656 9.859375 -4.640625 C 9.859375 -3.179688 9.503906 -2.003906 8.796875 -1.109375 C 8.097656 -0.210938 7.179688 0.234375 6.046875 0.234375 C 5.367188 0.234375 4.785156 0.101562 4.296875 -0.15625 C 3.804688 -0.425781 3.398438 -0.835938 3.078125 -1.390625 Z M 8.28125 -4.640625 C 8.28125 -5.765625 8.046875 -6.644531 7.578125 -7.28125 C 7.117188 -7.925781 6.484375 -8.25 5.671875 -8.25 C 4.867188 -8.25 4.234375 -7.925781 3.765625 -7.28125 C 3.304688 -6.644531 3.078125 -5.765625 3.078125 -4.640625 C 3.078125 -3.515625 3.304688 -2.628906 3.765625 -1.984375 C 4.234375 -1.347656 4.867188 -1.03125 5.671875 -1.03125 C 6.484375 -1.03125 7.117188 -1.347656 7.578125 -1.984375 C 8.046875 -2.628906 8.28125 -3.515625 8.28125 -4.640625 Z M 8.28125 -4.640625 "/>
</symbol>
<symbol overflow="visible" id="glyph0-24">
<path style="stroke:none;" d="M 3.109375 -11.9375 L 3.109375 -9.296875 L 6.265625 -9.296875 L 6.265625 -8.109375 L 3.109375 -8.109375 L 3.109375 -3.0625 C 3.109375 -2.300781 3.210938 -1.8125 3.421875 -1.59375 C 3.628906 -1.382812 4.050781 -1.28125 4.6875 -1.28125 L 6.265625 -1.28125 L 6.265625 0 L 4.6875 0 C 3.507812 0 2.695312 -0.21875 2.25 -0.65625 C 1.800781 -1.09375 1.578125 -1.894531 1.578125 -3.0625 L 1.578125 -8.109375 L 0.453125 -8.109375 L 0.453125 -9.296875 L 1.578125 -9.296875 L 1.578125 -11.9375 L 3.109375 -11.9375 Z M 3.109375 -11.9375 "/>
</symbol>
<symbol overflow="visible" id="glyph0-25">
<path style="stroke:none;" d="M 5.203125 -8.21875 C 4.378906 -8.21875 3.726562 -7.898438 3.25 -7.265625 C 2.78125 -6.628906 2.546875 -5.753906 2.546875 -4.640625 C 2.546875 -3.523438 2.78125 -2.644531 3.25 -2 C 3.726562 -1.363281 4.378906 -1.046875 5.203125 -1.046875 C 6.015625 -1.046875 6.660156 -1.367188 7.140625 -2.015625 C 7.617188 -2.660156 7.859375 -3.535156 7.859375 -4.640625 C 7.859375 -5.742188 7.617188 -6.613281 7.140625 -7.25 C 6.660156 -7.894531 6.015625 -8.21875 5.203125 -8.21875 Z M 5.203125 -9.515625 C 6.535156 -9.515625 7.578125 -9.082031 8.328125 -8.21875 C 9.085938 -7.363281 9.46875 -6.171875 9.46875 -4.640625 C 9.46875 -3.117188 9.085938 -1.925781 8.328125 -1.0625 C 7.578125 -0.195312 6.535156 0.234375 5.203125 0.234375 C 3.867188 0.234375 2.820312 -0.195312 2.0625 -1.0625 C 1.3125 -1.925781 0.9375 -3.117188 0.9375 -4.640625 C 0.9375 -6.171875 1.3125 -7.363281 2.0625 -8.21875 C 2.820312 -9.082031 3.867188 -9.515625 5.203125 -9.515625 Z M 5.203125 -9.515625 "/>
</symbol>
<symbol overflow="visible" id="glyph0-26">
<path style="stroke:none;" d="M 3.265625 -1.40625 L 9.109375 -1.40625 L 9.109375 0 L 1.25 0 L 1.25 -1.40625 C 1.882812 -2.070312 2.75 -2.957031 3.84375 -4.0625 C 4.945312 -5.175781 5.640625 -5.890625 5.921875 -6.203125 C 6.453125 -6.804688 6.820312 -7.316406 7.03125 -7.734375 C 7.25 -8.160156 7.359375 -8.570312 7.359375 -8.96875 C 7.359375 -9.632812 7.128906 -10.171875 6.671875 -10.578125 C 6.210938 -10.992188 5.609375 -11.203125 4.859375 -11.203125 C 4.335938 -11.203125 3.785156 -11.109375 3.203125 -10.921875 C 2.617188 -10.742188 1.992188 -10.472656 1.328125 -10.109375 L 1.328125 -11.796875 C 2.003906 -12.066406 2.632812 -12.269531 3.21875 -12.40625 C 3.800781 -12.550781 4.335938 -12.625 4.828125 -12.625 C 6.109375 -12.625 7.128906 -12.300781 7.890625 -11.65625 C 8.660156 -11.007812 9.046875 -10.148438 9.046875 -9.078125 C 9.046875 -8.566406 8.945312 -8.082031 8.75 -7.625 C 8.5625 -7.175781 8.21875 -6.640625 7.71875 -6.015625 C 7.582031 -5.859375 7.140625 -5.394531 6.390625 -4.625 C 5.648438 -3.863281 4.609375 -2.789062 3.265625 -1.40625 Z M 3.265625 -1.40625 "/>
</symbol>
</g>
</defs>
<g id="surface0">
<path style=" stroke:none;fill-rule:nonzero;fill:rgb(100%,100%,100%);fill-opacity:1;" d="M 0 0 L 661 0 L 661 401 L 0 401 Z M 0 0 "/>
<path style="fill-rule:evenodd;fill:rgb(100%,100%,100%);fill-opacity:1;stroke-width:0.1;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(0%,0%,0%);stroke-opacity:1;stroke-miterlimit:10;" d="M 15 17 L 33 17 L 33 20 L 15 20 Z M 15 17 " transform="matrix(20,0,0,20,-299,21)"/>
<g style="fill:rgb(0%,0%,0%);fill-opacity:1;">
<use xlink:href="#glyph0-1" x="173.402344" y="396.875"/>
<use xlink:href="#glyph0-2" x="178.402344" y="396.875"/>
</g>
<path style="fill-rule:evenodd;fill:rgb(100%,100%,100%);fill-opacity:1;stroke-width:0.1;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(0%,0%,0%);stroke-opacity:1;stroke-miterlimit:10;" d="M 15 14 L 24 14 L 24 17 L 15 17 Z M 15 14 " transform="matrix(20,0,0,20,-299,21)"/>
<path style="fill-rule:evenodd;fill:rgb(100%,100%,100%);fill-opacity:1;stroke-width:0.1;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(0%,0%,0%);stroke-opacity:1;stroke-miterlimit:10;" d="M 24 14 L 33 14 L 33 17 L 24 17 Z M 24 14 " transform="matrix(20,0,0,20,-299,21)"/>
<g style="fill:rgb(0%,0%,0%);fill-opacity:1;">
<use xlink:href="#glyph0-3" x="84.671875" y="336.875"/>
<use xlink:href="#glyph0-4" x="84.671875" y="336.875"/>
<use xlink:href="#glyph0-2" x="96.488281" y="336.875"/>
</g>
<g style="fill:rgb(0%,0%,0%);fill-opacity:1;">
<use xlink:href="#glyph0-5" x="253.207031" y="336.875"/>
<use xlink:href="#glyph0-6" x="265.589844" y="336.875"/>
<use xlink:href="#glyph0-2" x="278.617188" y="336.875"/>
</g>
<path style="fill-rule:evenodd;fill:rgb(100%,100%,100%);fill-opacity:1;stroke-width:0.1;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(0%,0%,0%);stroke-opacity:1;stroke-miterlimit:10;" d="M 15 11 L 24 11 L 24 14 L 15 14 Z M 15 11 " transform="matrix(20,0,0,20,-299,21)"/>
<path style="fill-rule:evenodd;fill:rgb(100%,100%,100%);fill-opacity:1;stroke-width:0.1;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(0%,0%,0%);stroke-opacity:1;stroke-miterlimit:10;" d="M 24 11 L 33 11 L 33 14 L 24 14 Z M 24 11 " transform="matrix(20,0,0,20,-299,21)"/>
<g style="fill:rgb(0%,0%,0%);fill-opacity:1;">
<use xlink:href="#glyph0-7" x="68.988281" y="276.875"/>
<use xlink:href="#glyph0-3" x="91" y="276.875"/>
<use xlink:href="#glyph0-4" x="91" y="276.875"/>
<use xlink:href="#glyph0-2" x="102.816406" y="276.875"/>
</g>
<g style="fill:rgb(0%,0%,0%);fill-opacity:1;">
<use xlink:href="#glyph0-8" x="254.066406" y="276.875"/>
<use xlink:href="#glyph0-8" x="264.808594" y="276.875"/>
<use xlink:href="#glyph0-5" x="275.550781" y="276.875"/>
</g>
<path style="fill-rule:evenodd;fill:rgb(100%,100%,100%);fill-opacity:1;stroke-width:0.1;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(0%,0%,0%);stroke-opacity:1;stroke-miterlimit:10;" d="M 15 8 L 33 8 L 33 11 L 15 11 Z M 15 8 " transform="matrix(20,0,0,20,-299,21)"/>
<g style="fill:rgb(0%,0%,0%);fill-opacity:1;">
<use xlink:href="#glyph0-3" x="132.71875" y="216.875"/>
<use xlink:href="#glyph0-9" x="132.71875" y="216.875"/>
<use xlink:href="#glyph0-10" x="143.441406" y="216.875"/>
<use xlink:href="#glyph0-10" x="154.164062" y="216.875"/>
<use xlink:href="#glyph0-11" x="164.886719" y="216.875"/>
<use xlink:href="#glyph0-12" x="175.296875" y="216.875"/>
<use xlink:href="#glyph0-13" x="180.003906" y="216.875"/>
<use xlink:href="#glyph0-14" x="185.375" y="216.875"/>
<use xlink:href="#glyph0-11" x="201.859375" y="216.875"/>
<use xlink:href="#glyph0-15" x="212.269531" y="216.875"/>
<use xlink:href="#glyph0-15" x="221.078125" y="216.875"/>
<use xlink:href="#glyph0-16" x="229.886719" y="216.875"/>
<use xlink:href="#glyph0-17" x="240.257812" y="216.875"/>
<use xlink:href="#glyph0-11" x="251" y="216.875"/>
<use xlink:href="#glyph0-15" x="261.410156" y="216.875"/>
</g>
<path style="fill-rule:evenodd;fill:rgb(100%,100%,100%);fill-opacity:1;stroke-width:0.1;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(0%,0%,0%);stroke-opacity:1;stroke-miterlimit:10;" d="M 15 5 L 33 5 L 33 8 L 15 8 Z M 15 5 " transform="matrix(20,0,0,20,-299,21)"/>
<g style="fill:rgb(0%,0%,0%);fill-opacity:1;">
<use xlink:href="#glyph0-18" x="108.460938" y="156.875"/>
<use xlink:href="#glyph0-16" x="121.566406" y="156.875"/>
<use xlink:href="#glyph0-19" x="131.9375" y="156.875"/>
<use xlink:href="#glyph0-12" x="138.890625" y="156.875"/>
<use xlink:href="#glyph0-20" x="143.597656" y="156.875"/>
<use xlink:href="#glyph0-21" x="148.304688" y="156.875"/>
<use xlink:href="#glyph0-13" x="157.601562" y="156.875"/>
<use xlink:href="#glyph0-11" x="162.972656" y="156.875"/>
<use xlink:href="#glyph0-10" x="173.382812" y="156.875"/>
<use xlink:href="#glyph0-21" x="184.105469" y="156.875"/>
<use xlink:href="#glyph0-19" x="193.402344" y="156.875"/>
<use xlink:href="#glyph0-22" x="200.355469" y="156.875"/>
<use xlink:href="#glyph0-23" x="210.375" y="156.875"/>
<use xlink:href="#glyph0-24" x="221.117188" y="156.875"/>
<use xlink:href="#glyph0-20" x="227.757812" y="156.875"/>
<use xlink:href="#glyph0-25" x="232.464844" y="156.875"/>
<use xlink:href="#glyph0-10" x="242.816406" y="156.875"/>
</g>
<path style="fill-rule:evenodd;fill:rgb(100%,100%,100%);fill-opacity:1;stroke-width:0.1;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(0%,0%,0%);stroke-opacity:1;stroke-miterlimit:10;" d="M 15 2 L 33 2 L 33 5 L 15 5 Z M 15 2 " transform="matrix(20,0,0,20,-299,21)"/>
<g style="fill:rgb(0%,0%,0%);fill-opacity:1;">
<use xlink:href="#glyph0-1" x="162.113281" y="96.875"/>
<use xlink:href="#glyph0-26" x="167.113281" y="96.875"/>
<use xlink:href="#glyph0-4" x="177.875" y="96.875"/>
<use xlink:href="#glyph0-2" x="189.691406" y="96.875"/>
</g>
<path style="fill-rule:evenodd;fill:rgb(100%,100%,100%);fill-opacity:1;stroke-width:0.1;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(0%,0%,0%);stroke-opacity:1;stroke-miterlimit:10;" d="M 15 -1 L 24 -1 L 24 2 L 15 2 Z M 15 -1 " transform="matrix(20,0,0,20,-299,21)"/>
<path style="fill-rule:evenodd;fill:rgb(100%,100%,100%);fill-opacity:1;stroke-width:0.1;stroke-linecap:butt;stroke-linejoin:miter;stroke:rgb(0%,0%,0%);stroke-opacity:1;stroke-miterlimit:10;" d="M 24 -1 L 33 -1 L 33 2 L 24 2 Z M 24 -1 " transform="matrix(20,0,0,20,-299,21)"/>
<g style="fill:rgb(0%,0%,0%);fill-opacity:1;">
<use xlink:href="#glyph0-8" x="50.472656" y="36.875"/>
<use xlink:href="#glyph0-24" x="61.214844" y="36.875"/>
<use xlink:href="#glyph0-19" x="68.089844" y="36.875"/>
<use xlink:href="#glyph0-11" x="68.089844" y="36.875"/>
<use xlink:href="#glyph0-16" x="78.5" y="36.875"/>
<use xlink:href="#glyph0-14" x="88.871094" y="36.875"/>
<use xlink:href="#glyph0-20" x="105.355469" y="36.875"/>
<use xlink:href="#glyph0-10" x="110.0625" y="36.875"/>
<use xlink:href="#glyph0-17" x="120.785156" y="36.875"/>
</g>
<g style="fill:rgb(0%,0%,0%);fill-opacity:1;">
<use xlink:href="#glyph0-6" x="224.125" y="36.875"/>
<use xlink:href="#glyph0-16" x="237.152344" y="36.875"/>
<use xlink:href="#glyph0-24" x="247.523438" y="36.875"/>
<use xlink:href="#glyph0-16" x="254.164062" y="36.875"/>
<use xlink:href="#glyph0-17" x="264.535156" y="36.875"/>
<use xlink:href="#glyph0-19" x="275.277344" y="36.875"/>
<use xlink:href="#glyph0-16" x="282.230469" y="36.875"/>
<use xlink:href="#glyph0-14" x="292.601562" y="36.875"/>
<use xlink:href="#glyph0-15" x="309.085938" y="36.875"/>
</g>
</g>
</svg>
Side by Side

After

Width:  |  Height:  |  Size: 29 KiB

5
www.i2p2/image_design/tunnels.svg
View File

@ -13,7 +13,10 @@
id="svg3091"
version="1.1"
inkscape:version="0.47pre4 r22446"
sodipodi:docname="tunnels.svg">
sodipodi:docname="tunnels.svg"
inkscape:export-filename="/home/mathias/Documents/Programming/I2P/monotone/i2p.www/www.i2p2/static/images/tunnels.png"
inkscape:export-xdpi="59.290222"
inkscape:export-ydpi="59.290222">
<metadata
id="metadata3257">
<rdf:RDF>

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 31 KiB

After

Width:  |  Height:  |  Size: 32 KiB

28
www.i2p2/pages/_layout_cs.html Normal file
View File

@ -0,0 +1,28 @@
{% set lang = "cs" -%}
{% include "_urlify" -%}
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="cs" >
<head>
<title>{% filter capture('title') %}{% block title %}{% endblock %}{% endfilter %} - I2P</title>
<link rel="canonical" href="{{ domain }}/{{ path }}" />
<link rel="stylesheet" href="_static/styles/{{ theme }}.css" type="text/css" title="{{ theme }}" />
<link rel="shortcut icon" href="_static/favicon.ico" />
<link type="application/atom+xml" rel="alternate" href="http://code.google.com/feeds/p/i2p/downloads/basic" />
<meta name="robots" content="NOODP" />
</head>
<body>
<div class="hide"><a href="#main" title="Skip navigation" accesskey="2">Skip navigation</a></div>
<div class="logo">
<a href="index.html" class="fade"><img src="_static/images/i2plogo.png" alt="I2P Logo" title="Invisible Internet Project (I2P)" /></a>
</div>
<h1>{{ title }}</h1>
<div class="menu">
{% include "_menu.html" %}
</div>
<div class="main" id="main">
{% block content %}{% endblock %}
</div>
</body>
</html>

74
www.i2p2/pages/_menu.html
View File

@ -7,6 +7,7 @@
<a href="index_it.html" class="fade"><img src="_static/images/it.png" alt="Italiano" title="Italiano" class="lang" /></a>
<a href="index_nl.html" class="fade"><img src="_static/images/nl.png" alt="Nederlands" title="Nederlands" class="lang" /></a>
<a href="index_ru.html" class="fade"><img src="_static/images/ru.png" alt="Русский" title="Русский" class="lang" /></a>
<a href="index_cs.html" class="fade"><img src="_static/images/cz.png" alt="Čeština" title="Čeština" class="lang" /></a>
</div></div>
<div class="themebox"><center><a href="?theme=dark" class="fade"><img src="/_static/images/dark.png" alt="Dark" title="Dark theme" class="lang" /></a>&nbsp;
@ -36,9 +37,9 @@
<img src="/_static/images/sqbullet.png" />&nbsp;<a href="techintro_de.html">Tech-intro</a><br />
<img src="/_static/images/sqbullet.png" />&nbsp;<a href="applications_de.html">Anwendungen</a><br />
<br /><b>Entwickeln</b><br />
<img src="/_static/images/sqbullet.png" />&nbsp;<a href="api_de.html">API</a><br />
<img src="/_static/images/sqbullet.png" />&nbsp;<a href="http://docs.i2p2.de/javadoc/">API</a><br />
<img src="/_static/images/sqbullet.png" />&nbsp;<a href="licenses_de.html">Lizenzen</a><br />
<img src="/_static/images/sqbullet.png" />&nbsp;<a href="http://trac.i2p2.i2p/">Trac</a>
<img src="/_static/images/sqbullet.png" />&nbsp;<a href="http://trac.i2p2.de/">Trac</a>
<br /><br /><b><a href="http://syndie.i2p2.de/">Syndie</a></b><br />
<br /><b><a href="links.html">Links</a></b><br />
@ -73,9 +74,9 @@
<img src="/_static/images/sqbullet.png" />&nbsp;<a href="techintro.html">Introduzione Tecnica</a><br />
<img src="/_static/images/sqbullet.png" />&nbsp;<a href="applications.html">Applicazioni</a><br />
<br /><b>Sviluppo</b><br />
<img src="/_static/images/sqbullet.png" />&nbsp;<a href="api_it.html">API</a><br />
<img src="/_static/images/sqbullet.png" />&nbsp;<a href="http://docs.i2p2.de/javadoc/">API</a><br />
<img src="/_static/images/sqbullet.png" />&nbsp;<a href="licenses.html">Licenze</a><br />
<img src="/_static/images/sqbullet.png" />&nbsp;<a href="http://trac.i2p2.i2p/">Trac</a>
<img src="/_static/images/sqbullet.png" />&nbsp;<a href="http://trac.i2p2.de/">Trac</a>
<br /><br /><b><a href="http://syndie.i2p2.de/">Syndie</a></b><br />
<br /><b><a href="links.html">Links</a></b><br />
@ -107,11 +108,11 @@
<br /><b>Documentation</b><br />
<img src="/_static/images/sqbullet.png" />&nbsp;<a href="how.html">Hoe werkt het?</a><br />
<img src="/_static/images/sqbullet.png" />&nbsp;<a href="techintro.html">Tech intro</a><br />
<img src="/_static/images/sqbullet.png" />&nbsp;<a href="applications.html">Applicaties</a><br />
<img src="/_static/images/sqbullet.png" />&nbsp;<a href="applications.html">Apps ontwikkelen</a><br />
<br /><b>Development</b><br />
<img src="/_static/images/sqbullet.png" />&nbsp;<a href="api.html">API</a><br />
<img src="/_static/images/sqbullet.png" />&nbsp;<a href="http://docs.i2p2.de/javadoc/">API</a><br />
<img src="/_static/images/sqbullet.png" />&nbsp;<a href="licenses.html">Licenties</a><br />
<img src="/_static/images/sqbullet.png" />&nbsp;<a href="http://trac.i2p2.i2p/">Trac</a>
<img src="/_static/images/sqbullet.png" />&nbsp;<a href="http://trac.i2p2.de/">Trac</a>
<br /><br /><b><a href="http://syndie.i2p2.de/">Syndie</a></b><br />
<br /><b><a href="links.html">Links</a></b><br />
@ -149,9 +150,9 @@
<img src="/_static/images/sqbullet.png" />&nbsp;<a href="techintro.html">技术内幕</a><br />
<img src="/_static/images/sqbullet.png" />&nbsp;<a href="applications.html">程序开发</a><br />
<br /><b>开发</b><br />
<img src="/_static/images/sqbullet.png" />&nbsp;<a href="api.html">API</a><br />
<img src="/_static/images/sqbullet.png" />&nbsp;<a href="http://docs.i2p2.de/javadoc/">API</a><br />
<img src="/_static/images/sqbullet.png" />&nbsp;<a href="licenses.html">许可证</a><br />
<img src="/_static/images/sqbullet.png" />&nbsp;<a href="http://trac.i2p2.i2p/">Trac</a>
<img src="/_static/images/sqbullet.png" />&nbsp;<a href="http://trac.i2p2.de/">Trac</a>
<br /><br /><b><a href="http://syndie.i2p2.de/">Syndie</a></b><br />
<br /><b><a href="links_zh.html">链接</a></b><br />
@ -189,9 +190,9 @@
<img src="/_static/images/sqbullet.png" />&nbsp;<a href="techintro.html">Intro technique</a><br />
<img src="/_static/images/sqbullet.png" />&nbsp;<a href="applications.html">Applications pour I2P</a><br />
<br /><b>D&eacute;veloppement</b><br />
<img src="/_static/images/sqbullet.png" />&nbsp;<a href="api.html">API</a><br />
<img src="/_static/images/sqbullet.png" />&nbsp;<a href="http://docs.i2p2.de/javadoc/">API</a><br />
<img src="/_static/images/sqbullet.png" />&nbsp;<a href="licenses.html">Licences</a><br />
<img src="/_static/images/sqbullet.png" />&nbsp;<a href="http://trac.i2p2.i2p/">Trac</a>
<img src="/_static/images/sqbullet.png" />&nbsp;<a href="http://trac.i2p2.de/">Trac</a>
<br /><br /><b><a href="http://syndie.i2p2.de/">Syndie</a></b><br />
<br /><b><a href="links.html">Liens</a></b><br />
@ -230,9 +231,9 @@
<img src="/_static/images/sqbullet.png" />&nbsp;<a href="applications.html">Приложения</a><br />
<br /><b>Разработка</b><br />
<img src="/_static/images/sqbullet.png" />&nbsp;<a href="api.html">API</a><br />
<img src="/_static/images/sqbullet.png" />&nbsp;<a href="http://docs.i2p2.de/javadoc/">API</a><br />
<img src="/_static/images/sqbullet.png" />&nbsp;<a href="licenses.html">Лицензии</a><br />
<img src="/_static/images/sqbullet.png" />&nbsp;<a href="http://trac.i2p2.i2p/">Багтрекер</a>
<img src="/_static/images/sqbullet.png" />&nbsp;<a href="http://trac.i2p2.de/">Багтрекер</a>
<br /><br /><b><a href="http://syndie.i2p2.de/">Syndie</a></b><br />
<br /><b><a href="links.html">Ссылки</a></b><br />
@ -244,6 +245,47 @@
<br />
<br /><a href="impressum.html">Impressum</a><br />
{% elif lang == "cs" %}
<br /><b><a href="index.html">Vítejte v síti I2P</a></b><br />
<br /><b><a href="download_cs.html">Stáhnout</a></b><br />
<!-- <img src="/_static/images/sqbullet.png" />&nbsp;<a href="http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/history.txt?rev=HEAD">Latest changes</a><br /> -->
<br /><b>Novinky</b><br />
<img src="/_static/images/sqbullet.png" />&nbsp;<a href="announcements.html">Poznámky k vydání</a><br />
<!-- <img src="/_static/images/sqbullet.png" />&nbsp;<a href="http://dev.i2p.net/pipermail/i2p/">Mailinglist</a><br /> -->
<img src="/_static/images/sqbullet.png" />&nbsp;<a href="meetings.html">Projektové schůzky</a><br />
<img src="/_static/images/sqbullet.png" />&nbsp;<a href="roadmap.html">Plán rozvoje</a><br />
<img src="/_static/images/sqbullet.png" />&nbsp;<a href="todo.html">Seznam úkolů</a><br />
<br /><b><a href="intro.html">Co je I2P</a></b><br />
<img src="/_static/images/sqbullet.png" />&nbsp;<a href="faq.html">FAQ</a><br />
<img src="/_static/images/sqbullet.png" />&nbsp;<a href="http://forum.i2p2.de/">Diskuzní fóra</a><br />
<img src="/_static/images/sqbullet.png" />&nbsp;<a href="bounties.html">Projektové odměny</a><br />
<img src="/_static/images/sqbullet.png" />&nbsp;<a href="getinvolved.html">Zapojte se</a><br />
<img src="/_static/images/sqbullet.png" />&nbsp;<a href="donate.html">Dotace!</a><br />
<img src="/_static/images/sqbullet.png" />&nbsp;<a href="team.html">Tým I2P</a><br />
<img src="/_static/images/sqbullet.png" />&nbsp;<a href="halloffame.html">Síň slávy</a><br />
<br /><b>Dokumentace</b><br />
<img src="/_static/images/sqbullet.png" />&nbsp;<a href="how.html">Jak to funguje?</a><br />
<img src="/_static/images/sqbullet.png" />&nbsp;<a href="techintro.html">Technický úvod</a><br />
<img src="/_static/images/sqbullet.png" />&nbsp;<a href="applications.html">Aplikace</a><br />
<br /><b>Vývoj</b><br />
<img src="/_static/images/sqbullet.png" />&nbsp;<a href="http://docs.i2p2.de/javadoc/">API</a><br />
<img src="/_static/images/sqbullet.png" />&nbsp;<a href="licenses.html">Licence</a><br />
<img src="/_static/images/sqbullet.png" />&nbsp;<a href="http://trac.i2p2.de/">Trac</a>
<br /><br /><b><a href="http://syndie.i2p2.de/">Syndie</a></b><br />
<br /><b><a href="links.html">Odkazy</a></b><br />
<br /><b><a rel="nofollow" href="http://i2pproject.net/index_cz.html">Kopie</a></b>
<br /><b><a rel="nofollow" href="http://i2p.us/index_cz.html">Kopie 2</a></b>
<br /><b><a rel="nofollow" href="http://i2p-projekt.de/index_cz.html">Kopie 3</a></b>
<br /><b><a rel="nofollow" href="https://www.i2p2.de/index_cz.html">Bezpečné stránky</a></b>
<br /><b><a rel="nofollow" href="https://i2p.us/index_cz.html">Bezpečná kopie</a></b>
<br />
<br /><a href="impressum.html">Tiráž</a><br />
{% else %}
<br /><b><a href="index.html">Welcome to I2P</a></b><br />
@ -268,11 +310,11 @@
<br /><b>Documentation</b><br />
<img src="/_static/images/sqbullet.png" />&nbsp;<a href="how.html">How does it work?</a><br />
<img src="/_static/images/sqbullet.png" />&nbsp;<a href="techintro.html">Tech intro</a><br />
<img src="/_static/images/sqbullet.png" />&nbsp;<a href="applications.html">Applications</a><br />
<img src="/_static/images/sqbullet.png" />&nbsp;<a href="applications.html">App Dev</a><br />
<br /><b>Development</b><br />
<img src="/_static/images/sqbullet.png" />&nbsp;<a href="api.html">API</a><br />
<img src="/_static/images/sqbullet.png" />&nbsp;<a href="http://docs.i2p2.de/javadoc/">API</a><br />
<img src="/_static/images/sqbullet.png" />&nbsp;<a href="licenses.html">Licenses</a><br />
<img src="/_static/images/sqbullet.png" />&nbsp;<a href="http://trac.i2p2.i2p/">Trac</a>
<img src="/_static/images/sqbullet.png" />&nbsp;<a href="http://trac.i2p2.de/">Trac</a>
<br /><br /><b><a href="http://syndie.i2p2.de/">Syndie</a></b><br />
<br /><b><a href="links.html">Links</a></b><br />

4
www.i2p2/pages/api_de.html
View File

@ -6,8 +6,8 @@
Anwendungen</a> nach Ideen &uuml;ber die 4 Grundprotokolle durchlesen, um eine Idee zum Schreiben
einer Anwendung auf I2P zu bekommen:</p>
<ul class="helplist>
<li><a href="http://docs.i2p2.de/core/">Core I2P API Javadoc</a>
(<a href="http://docs.i2p2.i2p/core/">internal link</a>)</li>
<li><a href="http://docs.i2p2.de/javadoc/">Core I2P API Javadoc</a>
(<a href="http://docs.i2p2.de/javadoc/">internal link</a>)</li>
<li>BOB</li>
<li><a href="sam_de">SAM</a> und <a href="samv2_de.html">SAM V2</a></li>
<li><a href="ministreaming_de">ministreaming</a></li>

4
www.i2p2/pages/api_it.html
View File

@ -5,8 +5,8 @@
<p>Programmatori di applicazioni controllate prima di tutto la <a href="applications">guida su come creare un applicazione</a>
per farsi un idea dei quattro protocolli base per creare un applicazione che funzioni su I2P:</p>
<ul class="helplist">
<li><a href="http://docs.i2p2.de/core/">Core I2P API Javadoc</a>
(<a href="http://docs.i2p2.i2p/core/">Link Interni</a>)</li>
<li><a href="http://docs.i2p2.de/javadoc/">Core I2P API Javadoc</a>
(<a href="http://docs.i2p2.de/javadoc/">Link Interni</a>)</li>
<li>BOB</li>
<li><a href="sam">SAM</a>, <a href="samv2.html">SAM V2</a> and <a href="samv3.html">SAM V3</a></li>
<li><a href="ministreaming">Ministreaming</a></li>

413
www.i2p2/pages/applications.html
View File

@ -3,48 +3,43 @@
{% block content %}
<h1>Application Development Guide</h1>
<h2>Why write I2P specific code?</h2>
<h2>Contents</h2>
<ul>
<li><a href="#why">Why write I2P-specific code?</a></li>
<li><a href="#concepts">Important concepts</a></li>
<li><a href="#options">Development options</a></li>
<li><a href="#start"><b>Start developing - a simple guide</b></a></li>
</ul>
<p>Using mihi's <a href="i2ptunnel">I2PTunnel</a> application, you can hook up
application instances and have them talk to each other over standard TCP
sockets. In plain client-server scenarios, this is an effective technique for
many simple protocols, but for distributed systems where each peer may contact
a number of other peers (instead of just a single server), or for systems that
expose TCP or IP information within the communication protocols themselves,
there are problems.</p>
<h2 id="why">Why write I2P-specific code?</h2>
<p>With I2PTunnel, you need to explicitly instantiate an I2PTunnel for each peer
you want to contact - if you are building a distributed instant messenger
application, that means you need to have each peer create an I2PTunnel 'client'
pointing at each peer it wants to contact, plus a single I2PTunnel 'server' to
receive other peer's connections. This process can of course be automated, but
there are nontrivial overheads involved in running more than just a few I2PTunnel
instances. In addition, with many protocols you will need to force everyone to
<p>
There are multiple ways to use applications in I2P.
Using <a href="/i2ptunnel.html">I2PTunnel</a>,
you can use regular applications without needing to program explicit I2P support.
This is very effective for client-server scenario's,
where you need to connect to a single website.
You can simply create a tunnel using I2PTunnel to connect to that website, as shown in <a href="#tunnel.serverclient">Figure 1</a>.
</p>
<p>
If your application is distributed, it will require connections to a large amount of peers.
Using I2PTunnel, you will need to create a new tunnel for each peer you want to contact,
as shown in <a href="#tunnel.peertopeer">Figure 2</a>.
This process can of course be automated, but running a lot of I2PTunnel instances creates a large amount of overhead.
In addition, with many protocols you will need to force everyone to
use the same set of ports for all peers - e.g. if you want to reliably run DCC
chat, everyone needs to agree that port 10001 is Alice, port 10002 is Bob, port
10003 is Charlie, and so on, since the protocol includes TCP/IP specific information
(host and port).</p>
<p>Applications that are designed to work with I2P can take advantage of its
built in data security and optional pseudonymous authentication. All data sent
over the network is transparently end to end encrypted (not even the routers
get the cleartext), and any application using the streaming or datagram
functionality has all of that data authenticated by the sending destination's
public key. As an aside, environments where anonymity instead of pseudonymity
is required are trivially accommodated by either using the I2CP directly, SAM RAW
sessions, or by simply creating a new sending destination whenever needed).</p>
<p>Another important thing to remember is that I2P is simply a communication
system - what data is sent and what is done with that data is outside of its scope.
Applications that are used on top of I2P should be carefully sanitized of any
insecure or identifying data or protocols (hostnames, port numbers, time zone,
character set, etc). This in and of itself is often a daunting task, as
analyzing the safety of a system that has had anonymity and security strapped on to
it is no small feat, giving significant incentive to learn from the experiences of
the traditional application base, but design the application and its communication
protocols with I2P's anonymity and security in mind.</p>
<p>There are also efficiency considerations to review when determining how to
(host and port).
</p>
<p>
General network applications often send a lot of additional data that could be used to identify users.
Hostnames, port numbers, time zones, character sets, etc. are often sent without informing the user.
As such, designing the network protocol specifically with anonymity in mind
can avoid compromising user identities.
</p>
<p>
There are also efficiency considerations to review when determining how to
interact on top of I2P. The streaming library and things built on top of it
operate with handshakes similar to TCP, while the core I2P protocols (I2NP and I2CP)
are strictly message based (like UDP or in some instances raw IP). The important
@ -55,17 +50,37 @@ of any state and drop the latency incurred by the startup and teardown handshake
by using (best effort) datagrams without having to worry about MTU detection or
fragmentation of messages under 32KB.
</p>
<center>
<div class="box" id="tunnel.serverclient">
<img src="_static/images/i2ptunnel_serverclient.png" alt="Creating a server-client connection using I2PTunnel only requires creating a single tunnel." title="Creating a server-client connection using I2PTunnel only requires creating a single tunnel." />
<br /><br />
Figure 1: Creating a server-client connection using I2PTunnel only requires creating a single tunnel.
</div>
</center><br/>
<center>
<div class="box" id="tunnel.peertopeer">
<img src="_static/images/i2ptunnel_peertopeer.png" alt="Setting up connections for a peer-to-peer applications requires a very large amount of tunnels." title="Setting up connections for a peer-to-peer applications requires a very large amount of tunnels." />
<br /><br />
Figure 2: Setting up connections for a peer-to-peer applications requires a very large amount of tunnels.
</div>
</center><br/>
<p>
The ministreaming library itself uses a
functional but inefficient scheme for dealing with reliable and in order delivery
by requiring the equivalent of an ACK after each message which must traverse the
network end to end again (though there are plans for improving this with a more
efficient and robust algorithm). With ministreaming, an application
that uses one of the I2P message oriented protocols could in some situations get
substantially better performance.
However with the full streaming library now the standard interface,
it isn't clear if that is still the case.
In summary, a number of reasons to write I2P-specific code:
<ul>
<li>
Creating a large amount of I2PTunnel instances consumes a non-trivial amount of resources,
which is problematic for distributed applications (a new tunnel is required for each peer).
</li>
<li>
General network protocols often send a lot of additional data that can be used to identify users.
Programming specifically for I2P allows the creation of a network protocol
that does not leak such information, keeping users anonymous and secure.
</li>
<li>
Network protocols designed for use on the regular internet can be inefficient
on I2P, which is a network with a much higher latency.
</li>
</ul>
</p>
<p>
@ -74,7 +89,7 @@ using an HTML interface via the standard webapps/app.war
may be considered for inclusion in the i2p distribution.
</p>
<h2>Important ideas</h2>
<h2>Important concepts</h2>
<p>There are a few changes that require adjusting to when using I2P:</p>
@ -93,26 +108,30 @@ location of the end point signed as if there were universal deployment of DNSSEC
to another (or with some special software, it can even operate on multiple routers at
once). This is quite different from the TCP or UDP world where a single end point (port)
must stay on a single host.</li>
<li>I2P destinations are ugly and large - behind the scenes, they contain a 2048bit ElGamal
<li>
<p>
I2P destinations are ugly and large - behind the scenes, they contain a 2048bit ElGamal
public key for encryption, a 1024bit DSA public key for signing, and a variable size
certificate (currently this is the null type, but may contain proof of work, blinded
data, or other information to increase the 'cost' of a destination in an effort to fight
Sybil). <p>There are existing ways to refer to these large and ugly destinations by short
certificate, which may contain proof of work or blinded data.
</p>
<p>
There are existing ways to refer to these large and ugly destinations by short
and pretty names (e.g. "irc.duck.i2p"), but at the moment those techniques do not guarantee
globally uniqueness (since they're stored locally at each person's machine as "hosts.txt")
and the current mechanism is not especially scalable nor secure (updates to one host file is
and the current mechanism is not especially scalable nor secure (updates to one host file are
manually managed within Monotone, and as such, anyone with commit rights on the repository can
change the destinations). There may be some secure, human readable, scalable, and globally
unique, naming system some day, but applications shouldn't depend upon it being in place,
since there are those who don't think such a beast is possible.
<a href="naming.html">Further information on the naming system</a> is available.
</p>
</li>
</ul>
<h3>Anonymity and confidentiality</h3>
<p>A useful thing to remember is that I2P has transparent end to end encryption
and authentication for all data passed over the network - if Bob sends Alice's destination,
and authentication for all data passed over the network - if Bob sends to Alice's destination,
only Alice's destination can receive it, and if Bob is using the datagrams or streaming
library, Alice knows for certain that Bob's destination is the one who sent the data. </p>
@ -132,7 +151,7 @@ UDP, applications don't need to worry about MTU detection and can simply fire of
entire request or response, allowing them to transparently operate in I2P as a UDP-like
application without having to write fragmentation, resends, etc.</p>
<h2>Integration techniques</h2>
<h2 id="options">Development options</h2>
<p>There are several means of sending data over I2P, each with their own pros and cons.
The streaming lib is the recommended interface, used by the majority of I2P applications.
@ -141,8 +160,7 @@ The streaming lib is the recommended interface, used by the majority of I2P appl
<h3>Streaming Lib</h3>
<p>
The <a href="streaming.html">full streaming library</a> is now the standard
interface. Ministreaming and SAM are not recommended.
The streaming lib interface is similar to the ministreaming lib interface described below.
interface. It allows programming using TCP-like sockets, as explained in the <a href="#start.streaming">Streaming development guide</a>.
</p>
<h3>SAM, SAM V2, SAM V3</h3>
@ -185,43 +203,280 @@ their own unique I2P destination and their own set of tunnels, keys, etc.</p>
<h3>Ministreaming</h3>
<p><i>Not recommended</i></p>
<p>For applications written in Java, the simplest way to go is to use the libraries that the SAM
bridge and I2PTunnel applications use. The streaming functionality is exposed in the 'ministreaming'
library, which is centered on the
<a href="http://www.i2p.net/javadoc/net/i2p/client/streaming/package-summary.html">I2PSocketManager</a>,
the <a href="http://www.i2p.net/javadoc/net/i2p/client/streaming/I2PSocket.html">I2PSocket</a>, and the
<a href="http://www.i2p.net/javadoc/net/i2p/client/streaming/I2PServerSocket.html">I2PServerSocket</a>.</p>
<p>
It was possible to write I2P applications in Java using the ministreaming library.
However, the Streaming library has superceded this, and provides better functionality.
</p>
<h3>Datagrams</h3>
<p><i>Not recommended</i></p>
<p>For applications that want to use repliable datagrams, they can be built with the
<a href="http://www.i2p.net/javadoc/net/i2p/client/datagram/I2PDatagramMaker.html">I2PDatagramMaker</a>
and parsed on the receiving side by the
<a href="http://www.i2p.net/javadoc/net/i2p/client/datagram/I2PDatagramDissector.html">I2PDatagramDissector</a>.
In turn, these are sent and received through an
<a href="http://www.i2p.net/javadoc/net/i2p/client/I2PSession.html">I2PSession</a>.</p>
<p>Applications that want to use raw datagrams simply send directly through the I2PSession's
<a href="http://www.i2p.net/javadoc/net/i2p/client/I2PSession.html#sendMessage(net.i2p.data.Destination,%20byte[])">sendMessage(...)</a>
method, receiving notification of available messages through the
<a href="http://www.i2p.net/javadoc/net/i2p/client/I2PSessionListener.html">I2PSessionListener</a> and
then fetching those messages by calling
<a href="http://www.i2p.net/javadoc/net/i2p/client/I2PSession.html#receiveMessage(int)">receiveMessage(...)</a>.</p>
The <a href="datagrams">Datagram library</a> allows sending UDP-like packets.
It's possible to use:
<ul>
<li>Repliable datagrams</li>
<li>Raw datagrams</li>
</ul>
<h3>I2CP</h3>
<p><i>Not easy</i></p>
<p><i>Not recommended</i></p>
<p><a href="i2cp">I2CP</a> itself is a language independent protocol, but to implement an I2CP library
in something other than Java there is a significant amount of code to be written (encryption routines,
object marshalling, asynchronous message handling, etc). While someone could write an I2CP library in
C or something else, it would most likely be more useful to use the C SAM library instead.
I2CP also <a href="i2cp">needs documentation</a>.
</p>
<h3>Web Applications</h3>
I2P comes with the Jetty webserver, and configuring to use the Apache server instead is straightforward.
Any standard web app technology should work.
<h2 id="start">Start developing - a simple guide</h2>
Developing using I2P requires a working I2P installation and a development environment of your own choice.
If you are using Java, you can start development with the <a href="#start.streaming">streaming library</a> or datagram library.
Using another programming language, SAM or BOB can be used.
<h3 id="start.streaming">Developing with the streaming library</h3>
<p>
Development using the streaming library requires the following libraries in your classpath:
<ul>
<li>$I2P/lib/streaming.jar: the streaming library itself.</li>
<li>$I2P/lib/mstreaming.jar: the ministreaming library is used as the base for the streaming library.</li>
<li>$I2P/lib/i2p.jar: some standard I2P classes (like the Destination class) are very convenient when developing.</li>
</ul>
</p>
<p>
Network communication requires the usage of I2P network sockets.
To demonstrate this, we will create an application where a client can send text messages to a server,
who will print the messages and send them back to the client. In other words, the server will function as an echo.
</p>
<p>
We will start by initializing the server application. This requires getting an I2PSocketManager
and creating an I2PServerSocket.
In addition, we will ask the I2PSocketManager for an I2PSession, so we can find out the Destination we use.
</p>
<div class="box">
<pre>
package i2p.echoserver;
import net.i2p.client.I2PSession;
import net.i2p.client.streaming.I2PServerSocket;
import net.i2p.client.streaming.I2PSocketManager;
import net.i2p.client.streaming.I2PSocketManagerFactory;
public class Main {
public static void main(String[] args) {
//Initialize application
I2PSocketManager manager = I2PSocketManagerFactory.createManager();
I2PServerSocket serverSocket = manager.getServerSocket();
I2PSession session = manager.getSession();
System.out.println(session.getMyDestination().toBase64()); //Print the base64 string, the regular string would look like garbage.
//The additional main method code comes here...
}
}
</pre>
<br /><br />
<center>Code example 1: initializing the server application.</center>
</div>
<p>
Once we have an I2PServerSocket, we can create I2PSocket instances to accept connections from clients.
In this example, we will create a single I2PSocket instance, that can only handle one client at a time.
A real server would have to be able to handle multiple clients.
To do this, multiple I2PSocket instances would have to be created, each in separate threads.
Once we have created the I2PSocket instance, we read data, print it and send it back to the client.
The bold code is the new code we add.
</p>
<div class="box">
<pre>
package i2p.echoserver;
</pre>
<b><pre>
import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;
import java.net.ConnectException;
import java.net.SocketTimeoutException;
import net.i2p.I2PException;
import net.i2p.client.streaming.I2PSocket;
import net.i2p.util.I2PThread;
</pre></b>
<pre>
import net.i2p.client.I2PSession;
import net.i2p.client.streaming.I2PServerSocket;
import net.i2p.client.streaming.I2PSocketManager;
import net.i2p.client.streaming.I2PSocketManagerFactory;
public class Main {
public static void main(String[] args) {
I2PSocketManager manager = I2PSocketManagerFactory.createManager();
I2PServerSocket serverSocket = manager.getServerSocket();
I2PSession session = manager.getSession();
System.out.println(session.getMyDestination().toBase64()); //Print the base64 string, the regular string would look like garbage.
</pre>
<b><pre>
//Create socket to handle clients
I2PThread t = new I2PThread(new ClientHandler(serverSocket));
t.setName("clienthandler1");
t.setDaemon(false);
t.start();
}
private static class ClientHandler implements Runnable {
public ClientHandler(I2PServerSocket socket) {
this.socket = socket;
}
public void run() {
while(true) {
try {
I2PSocket sock = this.socket.accept();
if(sock != null) {
BufferedReader br = new BufferedReader(new InputStreamReader(sock.getInputStream())); //Receive from clients
BufferedWriter bw = new BufferedWriter(new OutputStreamWriter(sock.getOutputStream())); //Send to clients
String line = br.readLine();
if(line != null) {
System.out.println("Received from client: " + line);
bw.write(line);
bw.flush(); //Flush to make sure everything got sent
}
sock.close();
}
} catch (I2PException ex) {
System.out.println("General I2P exception!");
} catch (ConnectException ex) {
System.out.println("Error connecting!");
} catch (SocketTimeoutException ex) {
System.out.println("Timeout!");
} catch (IOException ex) {
System.out.println("General read/write-exception!");
}
}
}
private I2PServerSocket socket;
}
}
</pre></b>
<br /><br />
<center>Code example 2: accepting connections from clients and handling messages.</center>
</div>
<p>
When you run the above server code, it should print something like this (but without the line endings, it should just be
one huge block of characters):
<pre id="start.streaming.destination">
y17s~L3H9q5xuIyyynyWahAuj6Jeg5VC~Klu9YPquQvD4vlgzmxn4yy~5Z0zVvKJiS2Lk
poPIcB3r9EbFYkz1mzzE3RYY~XFyPTaFQY8omDv49nltI2VCQ5cx7gAt~y4LdWqkyk3au
6HdfYSLr45zxzWRGZnTXQay9HPuYcHysZHJP1lY28QsPz36DHr6IZ0vwMENQsnQ5rhq20
jkB3iheYJeuO7MpL~1xrjgKzteirkCNHvXN8PjxNmxe-pj3QgOiow-R9rEYKyPAyGd2pe
qMD-J12CGfB6MlnmH5qPHGdZ13bUuebHiyZ1jqSprWL-SVIPcynAxD2Uu85ynxnx31Fth
nxFMk07vvggBrLM2Sw82pxNjKDbtO8reawe3cyksIXBBkuobOZdyOxp3NT~x6aLOxwkEq
BOF6kbxV7NPRPnivbNekd1E1GUq08ltDPVMO1pKJuGMsFyZC4Q~osZ8nI59ryouXgn97Q
5ZDEO8-Iazx50~yUQTRgLMOTC5hqnAAAA
</pre>
This is the base64-representation of the server Destination. The client will need this string to reach the server.
</p>
<p>
Now, we will create the client application. Again, a number of steps are required for initialization.
Again, we will need to start by getting an I2PSocketManager.
We won't use an I2PSession and an I2PServerSocket this time.
Instead, we will use the server Destination string to start our connection.
We will ask the user for the Destination string, and create an I2PSocket using this string.
Once we have an I2PSocket, we can start sending and receiving data to and from the server.
</p>
<div class="box">
<pre>
package i2p.echoclient;
import java.io.BufferedReader;
import java.io.BufferedWriter;
import java.io.IOException;
import java.io.InputStreamReader;
import java.io.InterruptedIOException;
import java.io.OutputStream;
import java.io.OutputStreamWriter;
import java.net.ConnectException;
import java.net.NoRouteToHostException;
import java.util.logging.Level;
import java.util.logging.Logger;
import net.i2p.I2PException;
import net.i2p.client.streaming.I2PSocket;
import net.i2p.client.streaming.I2PSocketManager;
import net.i2p.client.streaming.I2PSocketManagerFactory;
import net.i2p.data.DataFormatException;
import net.i2p.data.Destination;
public class Main {
public static void main(String[] args) {
I2PSocketManager manager = I2PSocketManagerFactory.createManager();
System.out.println("Please enter a Destination:");
BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
String destinationString = null;
try {
destinationString = br.readLine();
} catch (IOException ex) {
System.out.println("Failed to get a Destination string.");
return;
}
Destination destination = null;
try {
destination = new Destination(destinationString);
} catch (DataFormatException ex) {
System.out.println("Destination string incorrectly formatted.");
return;
}
I2PSocket socket = null;
try {
socket = manager.connect(destination);
} catch (I2PException ex) {
System.out.println("General I2P exception occurred!");
} catch (ConnectException ex) {
System.out.println("Failed to connect!");
} catch (NoRouteToHostException ex) {
System.out.println("Couldn't find host!");
} catch (InterruptedIOException ex) {
System.out.println("Sending/receiving was interrupted!");
}
try {
//Write to server
BufferedWriter bw = new BufferedWriter(new OutputStreamWriter(socket.getOutputStream()));
bw.write("Hello I2P!\n");
bw.flush(); //Flush to make sure everything got sent
//Read from server
BufferedReader br2 = new BufferedReader(new InputStreamReader(socket.getInputStream()));
String s = null;
while ((s = br2.readLine()) != null) {
System.out.println("Received from server: " + s);
}
socket.close();
} catch (IOException ex) {
System.out.println("Error occurred while sending/receiving!");
}
}
}
</pre>
<br /><br />
<center>Code example 3: starting the client and connecting it to the server application.</center>
</div>
<p>
Finally, you can run both the server and the client application.
First, start the server application. It will print a Destination string (like shown <a href="#start.streaming.destination">above</a>).
Next, start the client application. When it requests a Destination string, you can enter the string printed by the server.
The client will then send 'Hello I2P!' (along with a newline) to the server, who will print the message and send it back to the client.
</p>
<p>
Congratulations, you have successfully communicated over I2P!
</p>
<h2>Existing Applications in Development</h2>
Contact us if you would like to help.
<ul>

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

@ -4,7 +4,11 @@
Updated August 2010, current as of router version 0.8
<h1>Data types Specification</h1>
<p>
This document describes some data types common to all I2P protocols, like I2NP, I2CP, NTCP, etc.
This document describes some data types common to all I2P protocols, like
<a href="i2np.html">I2NP</a>,
<a href="i2cp.html">I2CP</a>,
<a href="udp.html">SSU</a>,
etc.
</p>
<h2 id="type_Integer">Integer</h2>
@ -54,26 +58,28 @@ 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 appropriate spec.
This structure is used in ElGamal encryption, representing only the exponent, not the primes, which are constant and defined in
<a href="how_cryptography.html#elgamal">the cryptography specification</a>.
</p>
<h4>Contents</h4>
<p>
256 bytes
</p>
<h4><a href="http://docs.i2p2.de/core/net/i2p/data/PublicKey.html">Javadoc</a></h4>
<h4><a href="http://docs.i2p2.de/javadoc/net/i2p/data/PublicKey.html">Javadoc</a></h4>
<h2 id="type_PrivateKey">PrivateKey</h2>
<h4>Description</h4>
<p>
This structure is used in ElGamal decryption, representing only the exponent, not the primes which are constant and defined in the appropriate spec.
This structure is used in ElGamal decryption, representing only the exponent, not the primes which are constant and defined in
<a href="how_cryptography.html#elgamal">the cryptography specification</a>.
</p>
<h4>Contents</h4>
<p>
256 bytes
</p>
<h4><a href="http://docs.i2p2.de/core/net/i2p/data/PrivateKey.html">Javadoc</a></h4>
<h4><a href="http://docs.i2p2.de/javadoc/net/i2p/data/PrivateKey.html">Javadoc</a></h4>
<h2 id="type_SessionKey">SessionKey</h2>
<h4>Description</h4>
@ -85,7 +91,7 @@ Deprecated - unused
32 bytes
</p>
<h4><a href="http://docs.i2p2.de/core/net/i2p/data/SessionKey.html">Javadoc</a></h4>
<h4><a href="http://docs.i2p2.de/javadoc/net/i2p/data/SessionKey.html">Javadoc</a></h4>
<h2 id="type_SigningPublicKey">SigningPublicKey</h2>
<h4>Description</h4>
@ -97,7 +103,7 @@ Deprecated - unused
128 bytes
</p>
<h4><a href="http://docs.i2p2.de/core/net/i2p/data/SigningPublicKey.html">Javadoc</a></h4>
<h4><a href="http://docs.i2p2.de/javadoc/net/i2p/data/SigningPublicKey.html">Javadoc</a></h4>
<h2 id="type_SigningPrivateKey">SigningPrivateKey</h2>
<h4>Description</h4>
@ -109,7 +115,7 @@ Deprecated - unused
20 bytes
</p>
<h4><a href="http://docs.i2p2.de/core/net/i2p/data/SigningPrivateKey.html">Javadoc</a></h4>
<h4><a href="http://docs.i2p2.de/javadoc/net/i2p/data/SigningPrivateKey.html">Javadoc</a></h4>
<h2 id="type_Signature">Signature</h2>
<h4>Description</h4>
@ -121,7 +127,7 @@ Deprecated - unused
40 bytes
</p>
<h4><a href="http://docs.i2p2.de/core/net/i2p/data/Signature.html">Javadoc</a></h4>
<h4><a href="http://docs.i2p2.de/javadoc/net/i2p/data/Signature.html">Javadoc</a></h4>
<h2 id="type_Hash">Hash</h2>
<h4>Description</h4>
@ -133,7 +139,7 @@ Deprecated - unused
32 bytes
</p>
<h4><a href="http://docs.i2p2.de/core/net/i2p/data/Hash.html">Javadoc</a></h4>
<h4><a href="http://docs.i2p2.de/javadoc/net/i2p/data/Hash.html">Javadoc</a></h4>
<h2 id="type_SessionTag">Session Tag</h2>
<h4>Description</h4>
@ -145,19 +151,19 @@ Deprecated - unused
32 bytes
</p>
<h4><a href="http://docs.i2p2.de/core/net/i2p/data/SessionTag.html">Javadoc</a></h4>
<h4><a href="http://docs.i2p2.de/javadoc/net/i2p/data/SessionTag.html">Javadoc</a></h4>
<h2 id="type_TunnelId">TunnelId</h2>
<h4>Description</h4>
<p>
Defines an identifier that is unique within a particular set of routers for a tunnel.
Defines an identifier that is unique to each router in a tunnel.
</p>
<h4>Contents</h4>
<p>
4 byte <a href="#type_Integer">Integer</a>
</p>
<h4><a href="http://docs.i2p2.de/core/net/i2p/data/TunnelID.html">Javadoc</a></h4>
<h4><a href="http://docs.i2p2.de/javadoc/net/i2p/data/TunnelID.html">Javadoc</a></h4>
<h2 id="type_Certificate">Certificate</h2>
<h4>Description</h4>
@ -191,7 +197,20 @@ payload :: data
{% endfilter %}
</pre>
<h4><a href="http://docs.i2p2.de/core/net/i2p/data/Certificate.html">Javadoc</a></h4>
<h4>Notes</h4>
<ul>
<li>
For <a href="#struct_RouterIdentity">Router Identities</a>, the Certificate is always NULL, no others are currently implemented.
</li><li>
For <a href="i2np_spec.html#struct_GarlicClove">Garlic Cloves</a>, the Certificate is always NULL, no others are currently implemented.
</li><li>
For <a href="i2np_spec.html#msg_Garlic">Garlic Messages</a>, the Certificate is always NULL, no others are currently implemented.
</li><li>
For <a href="#struct_Destination">Destinations</a>, the Certificate may be non-NULL,
however non-NULL certs are not widely used, and any checking is left to the application-level.
</li></ul>
<h4><a href="http://docs.i2p2.de/javadoc/net/i2p/data/Certificate.html">Javadoc</a></h4>
<h2 id="type_Mapping">Mapping</h2>
@ -239,7 +258,7 @@ For example,
UTF-8 strings in a RouterInfo options mapping in a I2NP Database Store Message will be corrupted.
</ul>
<h4><a href="http://docs.i2p2.de/core/net/i2p/data/DataHelper.html">Javadoc</a></h4>
<h4><a href="http://docs.i2p2.de/javadoc/net/i2p/data/DataHelper.html">Javadoc</a></h4>
@ -292,7 +311,7 @@ Total length: 387+ bytes
<h4>Notes</h4>
The certificate for a RouterIdentity is currently unused and is always NULL.
<h4><a href="http://docs.i2p2.de/core/net/i2p/data/RouterIdentity.html">Javadoc</a></h4>
<h4><a href="http://docs.i2p2.de/javadoc/net/i2p/data/RouterIdentity.html">Javadoc</a></h4>
<h2 id="struct_Destination">Destination</h2>
<h4>Description</h4>
@ -338,7 +357,7 @@ Total length: 387+ bytes
{% endfilter %}
</pre>
<h4><a href="http://docs.i2p2.de/core/net/i2p/data/Destination.html">Javadoc</a></h4>
<h4><a href="http://docs.i2p2.de/javadoc/net/i2p/data/Destination.html">Javadoc</a></h4>
<h2 id="struct_Lease">Lease</h2>
<h4>Description</h4>
@ -365,7 +384,7 @@ Total length: 387+ bytes
| end_date |
+----+----+----+----+----+----+----+----+
tunnel_gw :: RouterIdentity
tunnel_gw :: RouterIdentity of the tunnel gateway
length -> >= 387 bytes
tunnel_id :: TunnelId
@ -376,7 +395,14 @@ end_date :: Date
{% endfilter %}
</pre>
<h4><a href="http://docs.i2p2.de/core/net/i2p/data/Lease.html">Javadoc</a></h4>
<h4>Notes</h4>
<ul>
<li>
Could this be optimized to include the Hash of the Router Identity instead of the full Router Identtity?
</li></ul>
<h4><a href="http://docs.i2p2.de/javadoc/net/i2p/data/Lease.html">Javadoc</a></h4>
<h2 id="struct_LeaseSet">LeaseSet</h2>
<h4>Description</h4>
@ -456,7 +482,7 @@ end_date :: Date
+----+----+----+----+----+----+----+----+
destination :: Destination
length -> >= 397 bytes
length -> >= 387 bytes
encryption_key :: PublicKey
length -> 256 bytes
@ -466,6 +492,7 @@ signing_key :: SigningPublicKey
num :: Integer
length -> 1 byte
value: 0 <= num <= 6
leases :: [Lease]
length -> >= $num*399 bytes
@ -482,7 +509,7 @@ The signature may be verified using the signing public key of the destination.
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>
<h4><a href="http://docs.i2p2.de/javadoc/net/i2p/data/LeaseSet.html">Javadoc</a></h4>
@ -527,7 +554,16 @@ options :: Mapping
{% endfilter %}
</pre>
<h4><a href="http://docs.i2p2.de/core/net/i2p/data/RouterAddress.html">Javadoc</a></h4>
<h4>Notes</h4>
<ul>
<li>
Cost is typically 5 or 6 for SSU, and 10 or 11 for NTCP.
</li><li>
Expiration is currently unused, always null (all zeroes))
</li></ul>
<h4><a href="http://docs.i2p2.de/javadoc/net/i2p/data/RouterAddress.html">Javadoc</a></h4>
<h2 id="struct_RouterInfo">RouterInfo</h2>
<h4>Description</h4>
@ -622,6 +658,10 @@ This is currently unused. It was intended for a form of restricted routes, which
<p>
The signature may be verified using the signing public key of the router_ident.
<h4><a href="http://docs.i2p2.de/core/net/i2p/data/RouterInfo.html">Javadoc</a></h4>
<h4><a href="http://docs.i2p2.de/javadoc/net/i2p/data/RouterInfo.html">Javadoc</a></h4>
<h2 id="struct_DeliveryInstructions">Delivery Instructions</h2>
Defined in the <a href="tunnel_message_spec.html#delivery">Tunnel Message Specification</a>.
{% endblock %}

21
www.i2p2/pages/datagrams.html
View File

@ -21,7 +21,7 @@ either protocol may be carried by either transport.
<h2>Application Guide</h2>
<p>Applications written in Java may use the
<a href="http://docs.i2p2.de/net/i2p/client/datagram/package-summary.html">datagram API</a>,
<a href="http://docs.i2p2.de/javadoc/net/i2p/client/datagram/package-summary.html">datagram API</a>,
while applications in other languages
can use <a href="sam">SAM</a>'s datagram support.
There is also limited support in i2ptunnel in the <a href="socks.html">SOCKS proxy</a>,
@ -66,11 +66,26 @@ indicate datagram type.
</p>
<p>
The protocols and ports may be set in I2CP's
<a href="http://docs.i2p2.de/net/i2p/client/I2PSession.html">I2PSession API</a>,
<a href="http://docs.i2p2.de/javadoc/net/i2p/client/I2PSession.html">I2PSession API</a>,
as implemented in
<a href="http://docs.i2p2.de/net/i2p/client/I2PSessionMuxedImpl.html">I2PSessionMuxedImpl</a>.
<a href="http://docs.i2p2.de/javadoc/net/i2p/client/I2PSessionMuxedImpl.html">I2PSessionMuxedImpl</a>.
</p>
<h3>Data Integrity</h3>
Data integrity is assured by the gzip CRC-32 checksum implemented in
<a href="i2cp.html#format">the I2CP layer</a>.
There is no checksum field in the datagram protocol.
<h3>Packet Encapsulation</h3>
Each datagram is sent through I2P as a single message (or as an individual clove in a
<a href="how_garlicrouting.html">Garlic Message</a>).
Message encapsulation is implemented in the underlying
<a href="i2cp.html">I2CP</a>,
<a href="i2np.html">I2NP</a>, and
<a href="tunnel_message_spec.html">tunnel message</a>layers.
There is no packet delimiter mechanism or length field in the datagram protocol.
<h2 id="spec">Specification</h2>
<h3 id="raw">Non-Repliable Datagrams</h3>

106
www.i2p2/pages/download_cs.html Normal file
View File

@ -0,0 +1,106 @@
{% extends "_layout_cs.html" %}
{% block title %}Stáhnout{% endblock %}
{% block content %}
<h1>Stáhnout I2P</h1>
<h3>Požadavky pro instalaci</h3>
<a href="http://java.com/download/">Sun Java</a> 1.5 nebo novější (doporučená verze <a href="http://java.com/download/">Sun Java 1.6</a>), nebo ekvivalentní JRE.
<br>
Svou aktuální nainstalovanou verzi Javy si můžete ověřit <a href="http://java.com/en/download/installed.jsp?detect=jre&try=1">na této stránce</a>
nebo z příkazové řádky pomocí příkazu <tt>java -version</tt>
<h3>Nová instalace</h3>
<ul class="downloadlist">
<li>Grafický instalační program:<br />
<a href="http://mirror.i2p2.de/i2pinstall_0.8.exe">i2pinstall_0.8.exe</a>
(SHA256
d14ef28ffff7ef95e5627d7bbeac8f5aad57c82b89d2071383787f2124152ca9
<a href="http://mirror.i2p2.de/i2pinstall_0.8.exe.sig">sig</a>)<br />
Pod Windows: stáhněte soubor a spusťte ho. Pod ostatními operačními systémy soubor spustíte
z příkazové řádky příkazem <code>java -jar i2pinstall_0.8.exe</code>
</li>
<li>Instalace z příkazové řádky:<br />
Stáhněte si grafický instalační program (viz výše) a spusťte ho příkazem <code>java -jar i2pinstall_0.8.exe -console</code> <br />
Tato instalace funguje pod operačními systémy Windows, Linux a Mac.
</li>
<li>Instalace ze zdrojového kódu:<br />
<a href="http://mirror.i2p2.de/i2psource_0.8.tar.bz2">i2psource_0.8.tar.bz2</a>
(SHA256
a179fc478279383af3420c84699a014a40f9cb0da87ab2a2d2b890639345b999
<a href="http://mirror.i2p2.de/i2psource_0.8.tar.bz2.sig">sig</a>)<br />
Alternativně lze zdrojový kód stáhnout <a href="newdevelopers">z repozitáře monotone</a>.<br/>
Spusťte sestavení programu příkazem <code>(tar xjvf i2psource_0.8.tar.bz2 ; cd i2p-0.8 ; ant pkg)</code> a potom
spusťte grafický instalační program nebo instalaci z příkazové řádky (viz výše).</li>
</ul>
Tyto soubory jsou podepsány uživatelem zzz,
<a href="release-signing-key.html">jehož klíč je k dispozici zde</a>.
<h3>Po dokončení instalace</h3>
<p>Windows: Klikněte na ikonu "Start I2P". Otevře se nové okno s
<a href="http://localhost:7657/index.jsp">ovládacím panelem</a>,
které obsahuje další pokyny.</p>
<p>Unix a kompatibilní systémy: I2P lze spustit jako službu skriptem "i2prouter".
Naleznete ho ve složce, kde jste nainstalovali I2P. Stav služby lze zjistit příkazem
"sh i2prouter status". Službu lze ovládat pomocí argumentů "start", "stop" a "restart".
Po jejím spuštění je k dispozici <a href="http://localhost:7657/index.jsp">ovládací panel</a>.
OpenSolaris a další systémy, pro které není podporován wrapper (i2psvc) mohou proces
spustit pomocí příkazu "sh runplain.sh"
</p>
<p>Při první instalaci prosím nezapomeňte <b>nastavit NAT/firewall</b>. Je-li to možné,
otevřete Internetové porty I2P <a href="faq#ports">popsané zde</a>. Pokud jste úspěšně
otevřeli TCP port pro příchozí spojení, nastavte jej i na
<a href="http://localhost:7657/config.jsp">konfigurační stránce</a>.
</p>
<p>Na <a href="http://localhost:7657/config.jsp">konfigurační stránce</a>
také prosím nastavte <b>povolenou přenosovou kapacitu</b>. Počáteční nastavení
96 kB/s pro příchozí a 40 kB/s pro odchozí data je poměrně pomalé.
</p>
<h3>Aktualizace z předchozích verzí:</h3>
<p>
K dispozici je buď automatická nebo manuální aktualizace.
</p><p>
Provozujete-li verzi 0.7.5 nebo novější, váš router by měl detekovat novou verzi.
Klikněte na odkaz 'Download Update' (Stáhnout aktualizaci) v ovládacím panelu, když se zobrazí.
</p><p>
Zvláštní případy
<ul>
<li>Vzhledem k závadě ve verzi 0.7.6 můžete za jistých podmínek obdržet chybové hlášení
"downloaded version is not greater than current version" (stažená verze není novější než
aktuální verze). V takovém případě použijte manuální aktualizaci popsanou níže.
</li>
<li>Provozujete-li verzi 0.7.4 nebo starší, přečtěte si prosím
<a href=release-0.7.5.html>poznámky k verzi 0.7.5</a>, které popisují jak nastavit router
pro automatickou detekci nových verzí.
</li>
<li>Provozujete-li verzi 0.6.1.30 nebo starší, přečtěte si prosím
<a href=upgrade-0.6.1.30.html>tyto instrukce</a> jak nastavit router pro automatickou detekci
nových verzí.
</li>
</ul>
</p>
<h3>Aktualizace z předchozích verzí (manuální postup):</h3>
<ol>
<li>Stáhněte si <a href="http://mirror.i2p2.de/i2pupdate_0.8.zip">i2pupdate_0.8.zip</a>
(SHA256
57c6dd9dab15dc52613e35ba538842de948ad5f230d17f693cdcc86fa056f97c
<a href="http://mirror.i2p2.de/i2pupdate_0.8.zip.sig">sig</a>) a uložte jej do
instalační složky I2P. <b>Přejmenujte tento soubor na i2pupdate.zip</b>.
(Alternativně si můžete stáhnout zdrojový kód jak je popsáno výše a spustit
"ant updater", výsledný soubor i2pupdate.zip pak nakopírovat do instalační složky
I2P.) Tento soubor nerozbalujte.</li>
<li>Klikněte na tlačítko "Graceful restart" (hladký restart) na stránce
<a href="http://localhost:7657/configservice.jsp">konfigurace služby I2P</a>.</li>
<li>Dejte si šálek kávy a vraťte se za 11 minut.</li>
</ol>
<p>Soubor je podepsán uživatelem zzz,
<a href="release-signing-key.html">jehož klíč je k dispozici zde</a>.
</p>
{% endblock %}

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

@ -42,7 +42,7 @@
<p>
Here are some places, pick one or more.
<ul>
<li><a href="http://trac.i2p2.i2p/newticket">trac.i2p2.i2p</a> ticket
<li><a href="http://trac.i2p2.de/newticket">trac.i2p2.de</a> ticket
<li><a href="http://forum.i2p/viewforum.php?f=10">forum.i2p</a>
<li><a href="http://paste.i2p2.i2p/">paste.i2p2.i2p</a> and follow up on IRC #i2p
<li>Discuss with the developers on IRC #i2p

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

@ -7,7 +7,7 @@
<p>
Hier sind ein paar Stellen, w&auml;hle einen oder mehrere
<ul>
<li><a href="http://trac.i2p2.i2p/newticket">trac.i2p2.i2p</a> Ticket
<li><a href="http://trac.i2p2.de/newticket">trac.i2p2.de</a> Ticket
<li><a href="http://forum.i2p/viewforum.php?f=10">forum.i2p</a>
<li><a href="http://paste.i2p2.i2p/">paste.i2p2.i2p</a> und melde den Link im IRC Kanal #i2p
<li>Diskussion mit den Entwicklern im IRC Kanal #i2p

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

@ -8,7 +8,7 @@
<p>
Voici les endroits ou vous pouvez le faire, utilisez en un ou plus :
<ul>
<li><a href="http://trac.i2p2.i2p/newticket">trac.i2p2.i2p</a> ticket
<li><a href="http://trac.i2p2.de/newticket">trac.i2p2.de</a> ticket
<li><a href="http://forum.i2p/viewforum.php?f=10">forum.i2p</a>
<li><a href="http://paste.i2p2.i2p/">paste.i2p2.i2p</a> et suivez le sur IRC #i2p
<li>Discutez avec les d&eacute;veloppeurs d'I2P sur IRC #i2p

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

@ -42,7 +42,7 @@
</ol></p>
<h3 id="bug">我想我发现了软件的一个错误，到哪报告？<span class="permalink">(<a href="#bug">链接</a>)</span></h3>
<p>以下这些地方都可以，您可以任选其一。<ul>
<li> <a href="http://trac.i2p2.i2p/newticket">trac.i2p2.i2p</a>申报故障
<li> <a href="http://trac.i2p2.de/newticket">trac.i2p2.de</a>申报故障
</li><li><a href="http://forum.i2p/viewforum.php?f=10">论坛 forum.i2p</a>
</li><li><a href="http://paste.i2p2.i2p/">将日志贴到公共剪切板 paste.i2p2.i2p</a> 然后来 IRC #i2p
</li><li> 到IRC的#i2p房间向开发组反馈问题

4
www.i2p2/pages/getinvolved.html
View File

@ -16,7 +16,7 @@ Fix up the Wikipedia article about I2P in your language.
Tell your friends.
<li><b>Testing</b> -
Run the latest builds from <a href="monotone.html">monotone</a>
and report results on #i2p or as bugs on <a href="http://trac.i2p2.i2p/">Trac</a>.
and report results on #i2p or as bugs on <a href="http://trac.i2p2.de/">Trac</a>.
<li><b>Documentation</b> -
Help fix the parts of the website that are outdated or incomplete.
Translate pages into other languages.
@ -33,7 +33,7 @@ Write or port applications for I2P! There's some guidelines and
a list of ideas on the <a href="applications.html">applications page</a>.
<li><b>Coding</b> -
There's plenty to do if you know Java or are ready to learn.
Check for open tickets on <a href="http://trac.i2p2.i2p/">Trac</a>
Check for open tickets on <a href="http://trac.i2p2.de/">Trac</a>
or the TODO list on <a href="http://zzz.i2p/">zzz.i2p</a> for
some ideas on where to start.
See the <a href="newdevelopers.html">new developer's guide</a> for details.

4
www.i2p2/pages/getinvolved_de.html
View File

@ -13,7 +13,7 @@ dich einzubringen! Hier ist eine Liste die dir beim Start hilft:
<ul>
<li><b>Testen</b> -
Benutze die letzten Versionen aus dem <a href="monotone_de.html">Monotone Archive</a>
und berichte Ergebnisse in #i2p oder Fehler und Bugs auf <a href="http://trac.i2p2.i2p/">Trac</a>.
und berichte Ergebnisse in #i2p oder Fehler und Bugs auf <a href="http://trac.i2p2.de/">Trac</a>.
<li><b>Dokumentation</b> -
Hilf mit beim aktualisieren und erstellen der fehlenden Dokumente auf der
Webseite, &uuml;bersetze die Webseite in andere Sprachen!
@ -30,7 +30,7 @@ Schreibe oder portiere eine Anwendung f&uuml;r I2P! Es gibt ein paar Richtlienen
und eine Liste von Ideen auf der <a href="applications_de.html">Anwendungsseite</a>.
<li><b>Coding</b> -
Es gibt viel zu tun falls Du Java kannst oder bereit bist, Java zu lernen.
Kontrolliere <a href="http://trac.i2p2.i2p/">Trac</a> nach offenen Tickets oder
Kontrolliere <a href="http://trac.i2p2.de/">Trac</a> nach offenen Tickets oder
die TODO Liste auf <a href="http://zzz.i2p/">zzz.i2p</a> f&uuml;r einige Ideen zum Start.
Schaue zur <a href="newdevelopers_de.html">Anleitung f&uuml;r neue Entwickler</a> Seite f&uuml;r Details.
<li><b>Analysen</b> -

4
www.i2p2/pages/getinvolved_ru.html
View File

@ -14,7 +14,7 @@
<ul>
<li><b>Расскажите о нас!</b> — Расскажите знакомым про I2P, дайте ссылку на проект в форумном обсуждении или в комментариях к статье, прорекламируйте в своём блоге. Создайте/обновите статью об I2P в Википедии на Вашем языке.
<li><b>Тестирование</b> — Обновляйтесь до текущего билда из <a href="monotone.html">monotone</a>-репозитория и сообщайте обо всех обнаруженных ошибках на канале #i2p или в <a href="http://trac.i2p2.i2p/">багтрекере</a>.
<li><b>Тестирование</b> — Обновляйтесь до текущего билда из <a href="monotone.html">monotone</a>-репозитория и сообщайте обо всех обнаруженных ошибках на канале #i2p или в <a href="http://trac.i2p2.de/">багтрекере</a>.
<li><b>Документация</b> — Исправьте устаревший текст, дополните незавершенные инструкции, добавьте перевод на свой язык.
@ -26,7 +26,7 @@
<li><b>Приложения</b> — Создавайте новые I2P-программы или переделайте уже существующие под работу через I2P-сеть. Несколько методических рекомендаций и список нереализованных задумок можно посмотреть на странице <a href="applications.html">Application Development Guide</a>.
<li><b>Разработка</b> — Если Вы Java-программист, то перед Вами широкий фронт работ. Для начала проверьте <a href="http://trac.i2p2.i2p/">багтрекер</a> на наличие открытых тикетов или загляните в TODO-список на форуме <a href="http://zzz.i2p/">zzz.i2p</a>. Подробнее смотрите на странице <a href="newdevelopers.html">New Developer's Guide</a>
<li><b>Разработка</b> — Если Вы Java-программист, то перед Вами широкий фронт работ. Для начала проверьте <a href="http://trac.i2p2.de/">багтрекер</a> на наличие открытых тикетов или загляните в TODO-список на форуме <a href="http://zzz.i2p/">zzz.i2p</a>. Подробнее смотрите на странице <a href="newdevelopers.html">New Developer's Guide</a>
<li><b>Поиск уязвимостей</b> — Проанализируйте или протестируйте код на слабые места. Требуют внимания как уязвимости, касающиеся анонимности (см. описание на странице <a href="how_threatmodel.html">I2P's Threat Model</a>), так и DoS-уязвимости, и прочие потенциальные угрозы.

11
www.i2p2/pages/glossary.html Normal file
View File

@ -0,0 +1,11 @@
{% extends "_layout.html" %}
{% block title %}Glossary{% endblock %}
{% block content %}
This page lists often-used terminology when discussing I2P and cryptography.
<table>
<tr>
<td>I2P</td>
<td>Invisible Internet Project: a project meant to provide an anonymity layer, so user can communicate anonymously using a range of applications.</td>
</tr>
</table>
{% endblock %}

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

@ -13,11 +13,6 @@
<tr><td>Welterde</td><td>8 &euro;/mo, since January, 2008 - i2p2.de</td></tr>
<tr><td>eche|on</td><td>32 &euro;/mo since January, 2008 - i2p-projekt.de and domains</td></tr>
</table>
<br />
<p>This fee went direct to the i2p.net hoster as it has it run out.
Because of the special <a href="http://www.i2p2.i2p/statnotes0108">situation</a> arisen early 2008
we decided to let it run til money was out.
From begin of Feb 2009 on we got a new fund setup. </p>
<p>Big thanks go to the following people who have donated to I2P!</p>
<b>Current monthly subscriptions:</b><br />
@ -58,7 +53,7 @@ From begin of Feb 2009 on we got a new fund setup. </p>
<tr><td>Jan, 2010</td><td>anonymous</td><td>500 &euro;</td><td>General fund</td></tr>
<tr><td>Jan, 2010</td><td>bernerbaer</td><td>50 &euro;</td><td>General fund</td></tr>
<tr><td>Jan, 2010</td><td>anonymous</td><td>15 &euro;</td><td>General fund</td></tr>
<tr><td>Apr, 2009-Jan, 2010</td><td>neutron</td><td>20 $euro;/month</td><td>outproxy fund</td></tr>
<tr><td>Apr, 2009-Jan, 2010</td><td>neutron</td><td>20 &euro;/month</td><td>outproxy fund</td></tr>
<tr><td>Jan, 2010</td><td>anonymous</td><td>$20 USD</td><td>General fund</td></tr>
<tr><td>Jan, 2010</td><td>anonymous</td><td>6.80 &euro;</td><td>General fund</td></tr>
<tr><td>Jan, 2010</td><td>anonymous</td><td>10 &euro;</td><td>General fund</td></tr>
@ -86,11 +81,8 @@ From begin of Feb 2009 on we got a new fund setup. </p>
<tr><td>Mar, 2009</td><td>[anonymous]</td><td>50 &euro;</td><td>General fund</td></tr>
<tr><td>Feb, 2009</td><td>[anonymous]</td><td>30 &euro;</td><td>General fund</td></tr>
<tr><td>Feb, 2009</td><td>DVT</td><td>20 &euro;</td><td>General fund</td></tr>
<tr></tr>
<tr><td>Oct, 2008</td><td>eche|on</td><td>500.0 &euro;</td><td>Datastorage bounty</td></tr>
<tr></tr>
<tr><td>Mar, 2007</td><td>zzz</td><td>$200 USD</td><td>General fund</td></tr>
<tr></tr>
<tr><td>Nov, 2006-Dec, 2007</td><td>[anonymous]</td><td>$10 USD/month</td><td>general fund</td></tr>
<tr><td>Dec, 2006</td><td>bar</td><td colspan="2">New mac testing machine</td></tr>
<tr><td>Dec, 2006</td><td>[anonymous]</td><td>$200 USD</td><td>General fund</td></tr>
@ -122,7 +114,6 @@ From begin of Feb 2009 on we got a new fund setup. </p>
<tr><td>Jan, 2006</td><td>[anonymous]</td><td>$40 USD</td><td>I2P general fund</td></tr>
<tr><td>Jan, 2006</td><td>[anonymous]</td><td>$50 USD</td><td>I2P general fund</td></tr>
<tr><td>Jan, 2006</td><td>[anonymous]</td><td>$20 USD</td><td>I2P general fund</td></tr>
<tr></tr>
<tr><td>Dec, 2005</td><td>[anonymous]</td><td>$10 USD</td><td>I2P general fund</td></tr>
<tr><td>Dec, 2005</td><td>[anonymous]</td><td>$10 USD</td><td>I2P general fund</td></tr>
<tr><td>Nov, 2005-Dec, 2007</td><td>[anonymous]</td><td>$10 USD/month</td><td>general fund</td></tr>
@ -152,7 +143,6 @@ From begin of Feb 2009 on we got a new fund setup. </p>
<tr><td>Jan, 2005-Dec, 2007</td><td>[anonymous]</td><td>$10 USD/month</td><td>general fund</td></tr>
<tr><td>Jan, 2005-Jun, 2005</td><td>Martin Stares</td><td>$60 USD</td><td>I2P general fund</td></tr>
<tr><td>Jan, 2005</td><td>Nico Zimmerman</td><td>$2 USD</td><td>I2P general fund</td></tr>
<tr></tr>
<tr><td>Nov, 2004-Dec, 2007</td><td>jnymo</td><td>$10 USD/month</td><td>general fund</td></tr>
<tr><td>Dec, 2004, May, 2005</td><td>Elliot Turner</td><td>$350 USD</td><td>I2P general fund</td></tr>
<tr><td>Dec, 2004</td><td>[anonymous]</td><td>$5 USD</td><td>I2P general fund</td></tr>

40
www.i2p2/pages/how.html
View File

@ -14,7 +14,7 @@ The interface between applications and the router is the I2CP (I2P Control Proto
</p><p>
The I2P Project is committed to maintaining accurate, current documentation.
If you find any inaccuracies in the documents linked below, please
<a href="http://trac.i2p2.i2p/newticket">enter a ticket identifying the problem</a>.
<a href="http://trac.i2p2.de/newticket">enter a ticket identifying the problem</a>.
<h2>Index to Technical Documentation</h2>
@ -23,7 +23,7 @@ If you find any inaccuracies in the documents linked below, please
<ul class="helplist">
<li><a href="techintro.html">Technical Introduction</a></li>
<li><a href="how_intro.html">A Less-Technical Introduction</a></li>
<li><a href="how_threatmodel.html">Threat model</a></li>
<li><a href="how_threatmodel.html">Threat model and analysis</a></li>
<li><a href="how_networkcomparisons.html">Comparisons to other anonymous networks</a></li>
<li><a href="protocols.html">Protocol stack chart</a></li>
</ul>
@ -63,11 +63,11 @@ The end-to-end protocols used by clients for reliable and unreliable communicati
<ul><li>
<a href="streaming.html">Streaming Library</a>
</li><li>
<a href="http://docs.i2p2.i2p/core/net/i2p/client/streaming/package-summary.html">Streaming Javadoc</a>
<a href="http://docs.i2p2.de/javadoc/net/i2p/client/streaming/package-summary.html">Streaming Javadoc</a>
</li><li>
<a href="datagrams.html">Datagrams</a>
</li><li>
<a href="http://docs.i2p2.i2p/core/net/i2p/client/datagram/package-summary.html">Datagram Javadoc</a>
<a href="http://docs.i2p2.de/javadoc/net/i2p/client/datagram/package-summary.html">Datagram Javadoc</a>
</li></ul>
<h3>Client-to-Router Interface API and Protocol</h3>
@ -76,13 +76,13 @@ Traditionally used only by Java applications and higher-level APIs.
<ul><li>
<a href="i2cp.html">I2CP</a> I2P Control Protocol / API overview
</li><li>
I2CP Specification
<a href="i2cp_spec.html">I2CP Specification</a>
</li><li>
<a href="http://docs.i2p2.i2p/core/net/i2p/client/package-summary.html">I2CP API Javadoc</a>
<a href="http://docs.i2p2.de/javadoc/net/i2p/client/package-summary.html">I2CP API Javadoc</a>
</li><li>
<a href="common_structures_spec.html">Common data structures specification</a>
</li><li>
<a href="http://docs.i2p2.i2p/core/net/i2p/data/package-summary.html">Data Structures Javadoc</a>
<a href="http://docs.i2p2.de/javadoc/net/i2p/data/package-summary.html">Data Structures Javadoc</a>
</li></ul>
<h3>End-to-End Encryption</h3>
@ -107,21 +107,21 @@ I2P is a message-oriented router. The messages sent between routers are defined
</li><li>
<a href="i2np_spec.html">I2NP Specification</a>
</li><li>
<a href="http://docs.i2p2.i2p/router/net/i2p/data/i2np/package-summary.html">I2NP Javadoc</a>
<a href="http://docs.i2p2.de/javadoc/net/i2p/data/i2np/package-summary.html">I2NP Javadoc</a>
</li><li>
<a href="common_structures_spec.html">Common data structures specification</a>
</li><li>
<a href="http://docs.i2p2.i2p/core/net/i2p/data/package-summary.html">Data Structures Javadoc</a>
<a href="http://docs.i2p2.de/javadoc/net/i2p/data/package-summary.html">Data Structures Javadoc</a>
</li></ul>
<h3>Tunnels</h3>
Selecting peers, requesting tunnels through those peers, and encrypting and routing messages through these tunnels.
<ul>
<li><a href="how_peerselection.html">Peer profiling and selection</a></li>
<li><a href="how_tunnelrouting.html">Tunnel routing</a></li>
<li><a href="how_garlicrouting.html">Garlic routing</a></li>
<li><a href="how_tunnelrouting.html">Tunnel routing overview</a></li>
<li><a href="how_garlicrouting.html">Garlic routing and "garlic" terminology</a></li>
<li><a href="tunnel-alt.html">Tunnel building and encryption</a></li>
<li><a href="how_elgamalaes.html">ElGamal/AES+SessionTag</a> for build request encryption</li>
<li><a href="how_elgamalaes.html">ElGamal/AES</a> for build request encryption</li>
<li><a href="how_cryptography.html">ElGamal and AES cryptography details</a></li>
<li><a href="tunnel-alt-creation.html">Tunnel building specification</a></li>
<li><a href="tunnel_message_spec.html">Low-level tunnel message specification</a></li>
@ -130,7 +130,7 @@ Selecting peers, requesting tunnels through those peers, and encrypting and rout
<h3>Transport Layer</h3>
The protocols for direct (point-to-point) router to router communication.
<ul><li>
<a href="transports.html">Transport layer overview</a>
<a href="transport.html">Transport layer overview</a>
</li><li>
<a href="ntcp.html">NTCP</a> TCP-based transport overview
</li><li>
@ -142,16 +142,20 @@ The protocols for direct (point-to-point) router to router communication.
</li><li>
<a href="how_cryptography.html#udp">SSU transport encryption</a>
</li><li>
<a href="http://docs.i2p2.i2p/router/net/i2p/router/transport/package-summary.html">Transport Javadoc</a>
<a href="http://docs.i2p2.de/javadoc/net/i2p/router/transport/package-summary.html">Transport Javadoc</a>
</li><li>
<a href="http://docs.i2p2.i2p/router/net/i2p/router/transport/ntcp/package-summary.html">NTCP Javadoc</a>
<a href="http://docs.i2p2.de/javadoc/net/i2p/router/transport/ntcp/package-summary.html">NTCP Javadoc</a>
</li><li>
<a href="http://docs.i2p2.i2p/router/net/i2p/router/transport/udp/package-summary.html">SSU Javadoc</a>
<a href="http://docs.i2p2.de/javadoc/net/i2p/router/transport/udp/package-summary.html">SSU Javadoc</a>
</li></ul>
<h3>Other Router Topics</h3>
<ul><li>
<a href="jbigi.html">Native BigInteger Library</a>
</li><li>
Time synchronization and NTP
</li><li>
<a href="performance.html">Performance</a>
</li></ul>
<h3>Developer's Guides</h3>
@ -161,6 +165,10 @@ Time synchronization and NTP
<a href="newtranslators.html">New Translator's Guide</a>
</li><li>
<a href="monotone.html">Monotone Guide</a>
</li><li>
<a href="http://docs.i2p2.de/javadoc/">Javadocs</a>
</li><li>
<a href="todo.html">To Do List</a>
</li></ul>

142
www.i2p2/pages/how_cryptography.html
View File

@ -18,30 +18,83 @@ technique used in <a href="how_elgamalaes">ElGamal/AES+SessionTag</a> (but we're
<p>
ElGamal is used for asymmetric encryption.
ElGamal is used in several places in I2P:
<ul><li>
To encrypt router-to-router <a href="tunnel-alt-creation.html">Tunnel Build Messages</a>
</li><li>
For end-to-end (destination-to-destination) encryption as a part of <a href="how_elgamalaes">ElGamal/AES+SessionTag</a>
</li><li>
For encryption of some <a href="how_networkdatabase.html#delivery">netDb stores and queries sent to floodfill routers</a>
as a part of <a href="how_elgamalaes">ElGamal/AES+SessionTag</a>
(destination-to-router or router-to-router).
</li></ul>
</p>
<p>
We use common primes for 2048 ElGamal encryption and decryption, as given by <a href="http://tools.ietf.org/html/rfc3526">IETF RFC-3526</a>.
We currently only use ElGamal to encrypt the IV and session key in a single block, followed by the
AES encrypted payload using that key and IV. Specifically, the unencrypted ElGamal
block is formatted (in network byte order):
AES encrypted payload using that key and IV.
<p>
The unencrypted ElGamal contains:
</p>
<p>
<PRE>
|_______1_______2_______3_______4_______5_______6_______7_______8
|nonzero|H(data)
|
|
|
| | data ... |
+----+----+----+----+----+----+----+----+
|nonz| H(data) |
+----+ +
| |
+ +
| |
+ +
| |
+ +----+----+----+----+----+----+----+
| | data...
+----+----+----+--//
</PRE>
<p>
The H(data) is the SHA256 of the data that is encrypted in the ElGamal block,
and is preceded by a random nonzero byte. The data encrypted in the block
can be up to 222 bytes long. See
<a href="http://trac.i2p2.de/browser/core/java/src/net/i2p/crypto/ElGamalEngine.java?rev=85a542c53d910dffbf34cdcefb8a2faeee96adc4">the ElGamal code</a>.
may be up to 222 bytes long.
As the encrypted data may contain a substantial number of zeros if the
cleartext is smaller than 222 bytes, it is recommended that higher layers pad
the cleartext to 222 bytes with random data.
Total length: typically 255 bytes.
</p><p>
The encrypted ElGamal contains:
</p>
<p>
ElGamal is never used on its own in I2P, but instead always as part of
<a href="how_elgamalaes">ElGamal/AES+SessionTag</a>.
<PRE>
+----+----+----+----+----+----+----+----+
| zero padding... | |
+----+----+----+--// ----+ +
| |
+ +
| ElG encrypted part 1 |
~ ~
| |
+ +----+----+----+----+----+----+----+
| | zero padding... | |
+----+----+----+----+--// ----+ +
| |
+ +
| ElG encrypted part 2 |
~ ~
| |
+ +----+----+----+----+----+----+
| +
+----+----+
</PRE>
Each encrypted part is prepended with zeros to a size of exactly 257 bytes.
Total length: 514 bytes.
In typical usage, higher layers pad the cleartext data to 222 bytes,
resulting in an unencrypted block of 255 bytes.
This is encoded as two 256-byte encrypted parts,
and there is a single byte of zero padding before each part at this layer.
</p><p>
See
<a href="http://trac.i2p2.de/browser/core/java/src/net/i2p/crypto/ElGamalEngine.java?rev=85a542c53d910dffbf34cdcefb8a2faeee96adc4">the ElGamal code</a>.
<p>
The shared prime is the
@ -98,8 +151,19 @@ It may be quite difficult to make any change backward-compatible.
<H2><a name="AES">AES</a></H2>
<p>
AES is used for symmetric encryption.
<p>
AES is used for symmetric encryption, in several cases:
<ul><li>
For <a href="#transports">transport encryption</a> after DH key exchange
</li><li>
For end-to-end (destination-to-destination) encryption as a part of <a href="how_elgamalaes">ElGamal/AES+SessionTag</a>
</li><li>
For encryption of some <a href="how_networkdatabase.html#delivery">netDb stores and queries sent to floodfill routers</a>
as a part of <a href="how_elgamalaes">ElGamal/AES+SessionTag</a>
(destination-to-router or router-to-router).
</li><li>
For encryption of <a href="how_tunnelrouting.html#testing">periodic tunnel test messages</a> sent from the router to itself, through its own tunnels.
</li></ul>
</p><p>
We use 256 bit AES in CBC mode.
The padding used is specified in <a href="http://tools.ietf.org/html/rfc2313">IETF RFC-2313 (PKCS#5 1.5, section 8.1 (for block type 02))</a>.
In this case, padding exists of pseudorandomly generated octets to match 16 byte blocks.
@ -119,12 +183,36 @@ Two situations are possible:
2. For situations where we know the size of the data to be sent, we AES encrypt the following:
<p>
<PRE>
|_______1_______2_______3_______4_______5_______6_______7_______8
|H(data)
|
|
+----+----+----+----+----+----+----+----+
| H(data) |
+ +
| |
| size of data (in bytes) | data ... | rand ... |
+ +
| |
+ +
| |
+----+----+----+----+----+----+----+----+
| size | data ... |
+----+----+ +
| |
~ ~
| |
+ +
| |
+ +----//---+----+
| | |
+----+----+----//---+----+ +
| Padding to 16 bytes |
+----+----+----+----+----+----+----+----+
H(data): 32-byte SHA-256 Hash of the data
size: 2-byte Integer, number of data bytes to follow
data: payload
padding: random data, to a multiple of 16 bytes
</PRE>
<p>
After the data comes an application specified number of randomly generated padding bytes.
@ -266,11 +354,15 @@ It may be quite difficult to make any change backward-compatible.
<h2 id="transports">Transports</h2>
<p>
At the lowest
level, inter-router communication is protected by the transport layer security.
At the lowest protocol layer,
point-to-point inter-router communication is protected by the transport layer security.
Both transports use 256 byte (2048 bit) Diffie-Hellman key exchange
using
<a href="#elgamal">the same shared prime and generator as specified above for ElGamal</a>.
<a href="#elgamal">the same shared prime and generator as specified above for ElGamal</a>,
followed by symmetric AES encryption as described above.
This provides
<a href="http://en.wikipedia.org/wiki/Perfect_forward_secrecy">perfect forward secrecy</a>
on the transport links.
</p>
<H3><a name="tcp">NTCP connections</a></H3>
@ -280,8 +372,8 @@ NTCP connections are negotiated with a 2048 Diffie-Hellman implementation,
using the router's identity to proceed with a station to station agreement, followed by
some encrypted protocol specific fields, with all subsequent data encrypted with AES
(as above).
A possible enhancement is to use session tags like we do with
<a href="how_elgamalaes">ElGamalAES+SessionTag</a> to avoid the 2048 bit DH negotiation.
The primary reason to do the DH negotiation instead of using <a href="how_elgamalaes">ElGamalAES+SessionTag</a> is that it provides '<a href="http://en.wikipedia.org/wiki/Perfect_forward_secrecy">(perfect) forward secrecy</a>', while <a href="how_elgamalaes">ElGamalAES+SessionTag</a> does not.
</p>
<p>
In order to migrate to a more standardized implementation (TLS/SSL or even SSH), the following issues must be addressed:
<p>
@ -305,7 +397,7 @@ checking.
See <a href="udp.html#keys">the SSU specification</a> for details.
<H3>References</H3>
<H2>References</H2>
<ul>
<li>
<a href="http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57-Part1-revised2_Mar08-2007.pdf">NIST 800-57</a>

20
www.i2p2/pages/how_cryptography_de.html
View File

@ -38,7 +38,7 @@ Die H(Daten) ist der SHA256 Wert der Daten, die in dem ElGamal Block
verschl&uuml;sselt sind. Vor den H(Daten) steht ein zuf&auml;lliges Byte, das
nicht Null ist. Die Daten im Block k&ouml;nnen bis zu 222 Bytes lang sein.
Die Spezifikation ist
<a href="http://docs.i2p2.de/core/net/i2p/crypto/ElGamalEngine.html">[im Quelltext]</a>.
<a href="http://docs.i2p2.de/javadoc/net/i2p/crypto/ElGamalEngine.html">[im Quelltext]</a>.
<p>
ElGamal wird in I2P nie alleine genutzt, es ist immer ein Teil von
<a href="how_elgamalaes">ElGamal/AES+SessionTag</a>.
@ -59,14 +59,14 @@ Wir benutzen 256bit AES im CBC Modus mit dem PKCS#5 Padding f&uuml;r 16 Byte Blo
(welches bedeuted, das jeder Block mit der Anzahl der aufgef&uuml;llten Bytes
als Daten aufgef&uuml;llt wird).
Zur Spezifikation schaue in den
<a href="http://docs.i2p2.de/core/net/i2p/crypto/CryptixAESEngine.html">[CBC Quelltext]</a>
<a href="http://docs.i2p2.de/javadoc/net/i2p/crypto/CryptixAESEngine.html">[CBC Quelltext]</a>
und f&uuml;r die Crytix AES
<a href="http://docs.i2p2.de/core/net/i2p/crypto/CryptixRijndael_Algorithm.html">[Implementation hier]</a>
<a href="http://docs.i2p2.de/javadoc/net/i2p/crypto/CryptixRijndael_Algorithm.html">[Implementation hier]</a>
<p>
In Situationen, in denen wir AES Daten streamen, nutzen wir die selben Algorhytmen, wie sie in
<a href="http://docs.i2p2.de/core/net/i2p/crypto/AESOutputStream.html">[AESOutputStream]</a> und
<a href="http://docs.i2p2.de/core/net/i2p/crypto/AESInputStream.html">[AESInputStream]</a>
<a href="http://docs.i2p2.de/javadoc/net/i2p/crypto/AESOutputStream.html">[AESOutputStream]</a> und
<a href="http://docs.i2p2.de/javadoc/net/i2p/crypto/AESInputStream.html">[AESInputStream]</a>
implementiert sind.
<p>
F&uuml;r Situationen, in denen die Gr&ouml;se der zu sendenden Daten bekannt ist,
@ -83,14 +83,14 @@ Ende der zuf&auml;lligen Daten ist AES verschl&uuml;sselt (256bit CBC mit PKCS#5
<p>
Dieser Code ist in den safeEncrypt und safeDecrypt Methoden der
<a href="http://docs.i2p2.de/core/net/i2p/crypto/AESEngine.html">[AESEngine]</a>
<a href="http://docs.i2p2.de/javadoc/net/i2p/crypto/AESEngine.html">[AESEngine]</a>
implementiert.
<p>
<H2>DSA</H2>
<p>
Signaturen werden mit 1024bit DSA erzeugt und verifiziert, wie es in der
<a href="http://docs.i2p2.de/core/net/i2p/crypto/DSAEngine.html">[DSAEngine]</a>
<a href="http://docs.i2p2.de/javadoc/net/i2p/crypto/DSAEngine.html">[DSAEngine]</a>
implementiert ist.
<p>
<H3>Die DSA Konstanten</H3>
@ -143,7 +143,7 @@ implementiert ist.
<p>
Hashes in I2P sind bekannte, alte SHA256 wie es im
<a href="http://docs.i2p2.de/core/net/i2p/crypto/SHA256Generator.html">[SHA256Generator]</a>
<a href="http://docs.i2p2.de/javadoc/net/i2p/crypto/SHA256Generator.html">[SHA256Generator]</a>
implementiert ist.
<p>
<H2>TCP Verbindungen</H2>
@ -170,11 +170,11 @@ RouterInfo Struktur nutzen (die die ElGamal und DSA Schl&uuml;ssel enth&auml;lt)
<p>
Die grundlegenden TCP Verbindungsalgorhythmen sind in der establishConnection() Funktion
implementiert (die wiederrum exchangeKey() und identifyStationToStation()) in
<a href="http://docs.i2p2.de/router/net/i2p/router/transport/tcp/TCPConnection.html">[TCPConnection]</a>
<a href="http://docs.i2p2.de/javadoc/net/i2p/router/transport/tcp/TCPConnection.html">[TCPConnection]</a>
aufruft).
<p>
Dieses wird erweitert durch die
<a href="http://docs.i2p2.de/router/net/i2p/router/transport/tcp/RestrictiveTCPConnection.html">[RestrictiveTCPConnection]</a>
<a href="http://docs.i2p2.de/javadoc/net/i2p/router/transport/tcp/RestrictiveTCPConnection.html">[RestrictiveTCPConnection]</a>
Funktion, die die establishConnection() Methode aktualisiert um die
Protokoll Version, die Uhrzeit und die &ouml;ffentlich erreichbare IP
Adresse des Knotens verifizieren zu k&ouml;nnen. (Da wir noch keine

22
www.i2p2/pages/how_de.html
View File

@ -14,7 +14,7 @@ Die Schnittstelle zwischen Anwendungen und dem Router tr&auml;gt den Namen I2CP
</p><p>
Das I2P-Projekt ist um eine vollst&auml;ndige und aktuelle Dokumentation bem&uuml;ht.
Wer in einer der unten verlinkten Seiten Ungenauigkeiten oder Unstimmigkeiten findet,
m&ouml;ge diese bitte <a href="http://trac.i2p2.i2p/newticket">hier melden</a>.
m&ouml;ge diese bitte <a href="http://trac.i2p2.de/newticket">hier melden</a>.
<h2>Inhaltsverzeichnis</h2>
@ -66,11 +66,11 @@ Die Java-Schnittstelle und die Kommunikationsprotokolle zur zuverl&auml;ssigen (
<ul><li>
<a href="streaming.html">Datenstr&ouml;me</a> <i>(Streaming)</i> <i>(englisch)</i>
</li><li>
<a href="http://docs.i2p2.i2p/core/net/i2p/client/streaming/package-summary.html">Java-Dokumentation zur Streaming-Bibliothek</a> <i>(englisch)</i>
<a href="http://docs.i2p2.de/javadoc/net/i2p/client/streaming/package-summary.html">Java-Dokumentation zur Streaming-Bibliothek</a> <i>(englisch)</i>
</li><li>
<a href="datagrams_de.html">Datenpakete</a> <i>(Datagrams)</i> <i>(englisch)</i>
</li><li>
<a href="http://docs.i2p2.i2p/core/net/i2p/client/datagram/package-summary.html">Java-Dokumentation zur Datagram-Bibliothek</a> <i>(englisch)</i>
<a href="http://docs.i2p2.de/javadoc/net/i2p/client/datagram/package-summary.html">Java-Dokumentation zur Datagram-Bibliothek</a> <i>(englisch)</i>
</li></ul>
<h3>Routerschnittstelle und zugeh&ouml;riges Protokoll</h3>
@ -78,13 +78,13 @@ Die unmittelbare Schnittstelle zum Router. Die Java-Programmierschnittstelle und
<ul><li>
<a href="i2cp.html">I2CP (<i>I2P Control Protocol</i>)</a> Beschreibung des Protokolls und der Schnittstelle <i>(englisch)</i>
</li><li>
Technische Beschreibung I2CP
<a href="i2cp_spec.html">Technische Beschreibung I2CP</a> <i>(englisch)</i>
</li><li>
<a href="http://docs.i2p2.i2p/core/net/i2p/client/package-summary.html">Java-Dokumentation zu I2CP</a> <i>(englisch)</i>
<a href="http://docs.i2p2.de/javadoc/net/i2p/client/package-summary.html">Java-Dokumentation zu I2CP</a> <i>(englisch)</i>
</li><li>
<a href="common_structures_spec.html">Techn. Beschreibung Datenstrukturen</a> <i>(englisch)</i>
</li><li>
<a href="http://docs.i2p2.i2p/core/net/i2p/data/package-summary.html">Java-Dokumentation zu den Datenstrukturen</a> <i>(englisch)</i>
<a href="http://docs.i2p2.de/javadoc/net/i2p/data/package-summary.html">Java-Dokumentation zu den Datenstrukturen</a> <i>(englisch)</i>
</li></ul>
<h3>Durchgehende Verschl&uuml;sselung</h3>
@ -109,11 +109,11 @@ I2P-Router sind nachrichtenbasiert. Der Versand von Nachrichten zwischen Routern
</li><li>
<a href="i2np_spec.html">Technische Beschreibung I2NP</a> <i>(englisch)</i>
</li><li>
<a href="http://docs.i2p2.i2p/router/net/i2p/data/i2np/package-summary.html">Java-Dokumentation zu I2NP</a> <i>(englisch)</i>
<a href="http://docs.i2p2.de/javadoc/net/i2p/data/i2np/package-summary.html">Java-Dokumentation zu I2NP</a> <i>(englisch)</i>
</li><li>
<a href="common_structures_spec.html">Techn. Beschreibung Datenstrukturen</a> <i>(englisch)</i>
</li><li>
<a href="http://docs.i2p2.i2p/core/net/i2p/data/package-summary.html">Java-Dokumentation zu den Datenstrukturen</a> <i>(englisch)</i>
<a href="http://docs.i2p2.de/javadoc/net/i2p/data/package-summary.html">Java-Dokumentation zu den Datenstrukturen</a> <i>(englisch)</i>
</li></ul>
<h3>Tunnel</h3>
@ -143,11 +143,11 @@ Protokolle zur direkten Kommunikation zwischen zwei Routern.
<a href="how_cryptography.html#tcp">Verschl&uuml;sselung des NTCP-Transports <i>(englisch)</i></li><li>
<a href="how_cryptography.html#udp">Verschl&uuml;sselung des SSU-Transports <i>(englisch)</i></li>
</li><li>
<a href="http://docs.i2p2.i2p/router/net/i2p/router/transport/package-summary.html">Java-Dokumentation zur Transportschicht</a> <i>(englisch)</i>
<a href="http://docs.i2p2.de/javadoc/net/i2p/router/transport/package-summary.html">Java-Dokumentation zur Transportschicht</a> <i>(englisch)</i>
</li><li>
<a href="http://docs.i2p2.i2p/router/net/i2p/router/transport/ntcp/package-summary.html">Java-Dokumentation zu NTCP</a> <i>(englisch)</i>
<a href="http://docs.i2p2.de/javadoc/net/i2p/router/transport/ntcp/package-summary.html">Java-Dokumentation zu NTCP</a> <i>(englisch)</i>
</li><li>
<a href="http://docs.i2p2.i2p/router/net/i2p/router/transport/udp/package-summary.html">Java-Dokumentation zu SSU</a> <i>(englisch)</i>
<a href="http://docs.i2p2.de/javadoc/net/i2p/router/transport/udp/package-summary.html">Java-Dokumentation zu SSU</a> <i>(englisch)</i>
</li></ul>
<h3>Sonstiges zum Thema Router</h3>

365
www.i2p2/pages/how_elgamalaes.html
View File

@ -1,80 +1,329 @@
{% extends "_layout.html" %}
{% block title %}How ElGamal and AES Encryption Work{% endblock %}
{% block content %}<p>
Within I2P, various messages are encrypted, but we don't want anyone to know
to whom or from whom it is bound, so we can't just toss a "to" or "from" address.
In addition, messages are not delivered in order (or reliably), so we can't simply
ElGamal encrypt the first message and AES the subsequent messages. The alternative
of ElGamal encrypting each individual message is daunting in light of the message
frequency desired. Instead, we take each message and evaluate whether it fits into
the three possible conditions:</p>
{% block title %}ElGamal/AES + SessionTag Encryption{% endblock %}
{% block content %}
Updated August 2010, current as of router version 0.8
<h2>Overview</h2>
<p>
ElGamal/AES+SessionTags is used for end-to-end encryption.
</p>
<p> As an unreliable, unordered, message based system, I2P uses a simple combination
of asymmetric and symmetric encryption algorithms to provide data confidentiality
and integrity to garlic messages. As a whole, the combination is referred
to as ElGamal/AES+SessionTags, but that is an excessively verbose way to describe
the use of 2048bit ElGamal, AES256, SHA256, and 32 byte nonces. </p>
<p> The first time a router wants to encrypt a garlic message to another router,
they encrypt the keying material for an AES256 session key with ElGamal and
append the AES256/CBC encrypted payload after that encrypted ElGamal block.
In addition to the encrypted payload, the AES encrypted section contains the
payload length, the SHA256 hash of the unencrypted payload, as well as a number
of "session tags" - random 32 byte nonces. The next time the sender wants
to encrypt a garlic message to another router, rather than ElGamal encrypt
a new session key they simply pick one of the previously delivered session
tags and AES encrypt the payload like before, using the session key used with
that session tag, prepended with the session tag itself. When a router receives
a garlic encrypted message, they check the first 32 bytes to see if it matches
an available session tag - if it does, they simply AES decrypt the message,
but if it does not, they ElGamal decrypt the first block. </p>
<p> Each session tag can be used only once so as to prevent internal adversaries
from unnecessarily correlating different messages as being between the same
routers. The sender of an ElGamal/AES+SessionTag encrypted message chooses
when and how many tags to deliver, prestocking the recipient with enough tags
to cover a volley of messages. Garlic messages may detect the successful tag
delivery by bundling a small additional message as a clove (a "delivery status
message") - when the garlic message arrives at the intended recipient and
is decrypted successfully, this small delivery status message is one of the
cloves exposed and has instructions for the recipient to send the clove back
to the original sender (through an inbound tunnel, of course). When the original
sender receives this delivery status message, they know that the session tags
bundled in the garlic message were successfully delivered. </p>
<p> Session tags themselves have a short lifetime, after which they are
discarded if not used. In addition, the quantity stored for each key is limited,
as are the number of keys themselves - if too many arrive, either new or old
messages may be dropped. The sender keeps track whether messages using session
tags are getting through, and if there isn't sufficient communication it may
drop the ones previously assumed to be properly delivered, reverting back
to the full expensive ElGamal encryption.
A session will continue to exist until all its tags are exhausted or expire.
</p><p>
Sessions are unidirectional. Tags are delivered from Alice to Bob,
and Alice then uses the tags, one by one, in subsequent messages to Bob.
</p><p>
Sessions may be established between Destinations, between Routers, or
between a Router and a Destination.
Each Router and Destination maintains its own Session Key Manager to
keep track of Session Keys and Session Tags.
Separate Session Key Managers prevents correlation of multiple Destinations
to each other or a Router by adversaries.
</p>
<h2>Message Reception</h2>
<p>
Each message received has one of two
the two possible conditions:</p>
<OL>
<li> its ElGamal encrypted to us</li>
<li> its AES encrypted to us</li>
<li> its not encrypted to us</li>
<li> It is part of an existing session and contains a Session Tag and an AES encrypted block</li>
<li> It is for a new session and contains both ElGamal and AES encrypted blocks</li>
</OL>
When a router receives a message, it will first assume it is from
an existing session and attempt to look up the Session Tag and decrypt the following data using AES.
If that fails, it will assume it is for a new session and attempt to
decrypt it using ElGamal.
</p>
<h2 id="new">New Session Message Specification</h2>
<p>
If its ElGamal encrypted to us, the message is considered a new session, and
is encrypted per encryptNewSession(...) in
<a href="http://docs.i2p2.de/core/net/i2p/crypto/ElGamalAESEngine.html">[ElGamalAESEngine]</a>
as follows -</p>
<p>An initial ElGamal block, encrypted <a href="how_cryptography">as before</a>:</p>
An ElGamal Message contains two parts, an encrypted ElGamal block
and an encrypted AES block.
</p><p>
The encrypted message contains:
<PRE>
|_______1_______2_______3_______4_______5_______6_______7_______8
| 32 byte session key
|
|
+----+----+----+----+----+----+----+----+
| |
| 32 byte pre-IV (first 16 bytes of H(pre-IV) == IV)
|
|
+ +
| ElGamal Encrypted Block |
~ ~
| |
| (158 bytes of random data)
| ...
+ +----+----+----+----+----+----+
| | |
+----+----+ +
| |
+ +
| AES Encrypted Block |
~ ~
| |
+ +----+----+----+----+----+----+
| +
+----+----+
</PRE>
<p>Followed by the following, AES encrypted <a href="how_cryptography">as before</a>,
using the session key and IV from the header:</p>
</p>
<h3>ElGamal Block</h3>
<p>
The encrypted ElGamal Block is always 514 bytes long.
The encrypted AES Block length is variable but is always a multiple of 16 bytes.
</p><p>
The unencrypted ElGamal data is 222 bytes long, containing:
<PRE>
|_______1_______2_______3_______4_______5_______6_______7_______8
| # session tags| that many sessionTags (32 byte random numbers)
| ...
| | size of the payload (bytes) | H(payload)
|
|
|
| | flag |payload
| ...
+----+----+----+----+----+----+----+----+
| |
| random bytes leaving the total AES block (size % 16 == 0) |
+ +
| Session Key |
+ +
| |
+ +
| |
+----+----+----+----+----+----+----+----+
| |
+ +
| Pre-IV |
+ +
| |
+ +
| |
+----+----+----+----+----+----+----+----+
+ +
| |
+ +
| 158 bytes random padding |
~ ~
| |
+ +----+----+
| |
+----+----+----+----+----+----+
</PRE>
The 32-byte
<a href="common_structures_spec#type_SessionKey">Session Key</a>
is the identifier for the session.
The 32-byte Pre-IV will be used to generate the IV for the AES block that follows;
the IV is the first 16 bytes of the SHA-256 Hash of the Pre-IV.
</p><p>
The 222 byte payload is encrypted
<a href="how_cryptography.html#elgamal">using ElGamal</a>
and the encrypted block is 514 bytes long.
</p>
<h3 id="aes">AES Block</h3>
<p>The unencrypted data in the AES block contains the following:
<PRE>
+----+----+----+----+----+----+----+----+
|tag count| |
+----+----+ +
| |
+ +
| Session Tags |
~ ~
| |
+ +
| |
+ +----+----+----+----+----+----+
| | payload size | |
+----+----+----+----+----+----+ +
| |
+ +
| Payload Hash |
+ +
| |
+ +----+----+
| |flag| |
+----+----+----+----+----+----+----+ +
| |
+ +
| New Session Key (opt.) |
+ +
| |
+ +----+
| | |
+----+----+----+----+----+----+----+ +
| |
+ +
| Payload |
~ ~
| |
+ +----//---+----+
| | |
+----+----+----//---+----+ +
| Padding to 16 bytes |
+----+----+----+----+----+----+----+----+
tag count: 2-byte <a href="common_structures_spec#type_Integer">Integer</a>, 0-200
Session Tags: That many 32-byte <a href="common_structures_spec#type_SessionTag">Session Tags</a>
payload size: 4-byte <a href="common_structures_spec#type_Integer">Integer</a>
Payload Hash: The 32-byte SHA256 <a href="common_structures_spec#type_Hash">SHA256 Hash</a> of the payload
flag: A one-byte value. Normally == 0. If == 0x01, a Session Key follows
New Session Key: A 32-byte <a href="common_structures_spec#type_SessionKey">Session Key</a>,
to replace the old key, and is only present if preceding flag is 0x01
Payload: the data
Padding: Random data to a multiple of 16 bytes for the total length.
May contain more than the minimum required padding.
Minimum length: 48 bytes
</PRE>
<p>If the flag is 0x01, it is followed by a new session key, replacing
the old one.</p>
</p><p>
The data is then <a href="how_cryptography">AES Encrypted</a>,
using the session key and IV (calculated from the pre-IV) from the ElGamal section.</p>
<h4>Notes</h4>
<ul>
<li>
Actual max payload length, and max block length, is less than 64 KB; see the<a href="i2np.html">I2NP Overview</a>.
</li><li>
New Session Key is currently unused and is never present.
</li></ul>
<h2 id="existing">Existing Session Message Specification</h2>
<p>The session tags delivered successfully are remembered for a
brief period (30 minutes currently) until they are used (and discarded).
They are used by packaging in a message that is not preceded by an
ElGamal block. Instead, it is encrypted per encryptExistingSession(...) in
<a href="http://docs.i2p2.de/core/net/i2p/crypto/ElGamalAESEngine.html">[ElGamalAESEngine]</a>
as follows -</p>
brief period (15 minutes currently) until they are used or discarded.
A tag is used by packaging one in an Existing Session Message that
contains only an AES encrypted block, and
is not preceded by an
ElGamal block.
</p><p?>
The existing session message is
as follows:
<PRE>
|_______1_______2_______3_______4_______5_______6_______7_______8
| session tag (32 byte random number previously delivered and
| not yet expired or used). the session tag also serves as
| the pre-IV (the first 16 bytes of H(sessionTag) == IV)
+----+----+----+----+----+----+----+----+
| |
</PRE>
+ +
| Session Tag |
+ +
| |
+ +
| |
+----+----+----+----+----+----+----+----+
| |
+ +
| AES Encrypted Block |
~ ~
| |
+ +
| |
+----+----+----+----+----+----+----+----+
Session Tag: A 32-byte <a href="common_structures_spec#type_SessionTag">Session Tag</a>
previously delivered in an AES block
AES Encrypyted Block: As specified <a href="#aes">above</a>.
</PRE>
The session tag also serves as
the pre-IV. The IV is the first 16 bytes of the SHA-256 Hash of the sessionTag.
</p><p>
To decode a message from an existing session, a router looks up the Session Tag to find an
associated Session Key. If the Session Tag is found, the AES block is decrypted using the associated Session Key.
If the tag is not found, the message is assumed to be a <a href="#new">New Session Message</a>.
</p>
<h2 id="future">Future Work</h2>
<p>
There are many possible areas to tune the Session Key Manager's algorithms;
some may interact with the streaming library behavior, or have significant
impact on overal performance.
<ul><li>
Delivery of too many tags at one time may impose substantial overhead for brief streaming connections
or datagrams, and increase the chance of message loss.
We currently deliver 40 tags at a time (1280 bytes).
32 (1024 bytes) may be better for tunnel fragmentation.
</li><li>
A few tags could be delivered in each of several messages, or lots of tags all at once.
</li><li>
It is also important to study and tune
the low-tag thresholds at which more tags are sent.
</li><li>
The number of tags delivered could depend on message size, keeping in mind
the eventual padding to 1KB at the tunnel message layer.
</li><li>
Clients could send an estimate of session lifetime to the router, as an advisory
on the number of tags required.
</li><li>
Delivery of too few tags causes the router to fall back to an expensive ElGamal encryption.
</li><li>
The router may assume delivery of Session Tags, or await acknowledgement before using them;
there are tradeoffs for each strategy.
</li><li>
For very brief messages, almost the full 222 bytes of the pre-IV and padding fields in the ElGamal block
could be used for the entire message, instead of establishing a session.
</li><li>
Evaluate padding strategy; currently we pad to a minimum of 128 bytes.
Would be better to add a few tags to small messages than pad.
</li><li>
Perhaps things could be more efficient if the Session Tag system was bidirectional,
so tags delivered in the 'forward' path could be used in the 'reverse' path,
thus avoiding ElGamal in the initial response.
The router currently plays some tricks like this when sending
tunnel test messages to itself.
</li><li>
Change from Session Tags to
<a href="performance.html#prng">a synchronized PRNG</a>.
</li><li>
Several of these ideas may require a new I2NP message type, or
set a flag in the
<a href="tunnel_message_spec.html#delivery">Delivery Instructions</a>,
or set a magic number in the first few bytes of the Session Key field
and accept a small risk of the random Session Key matching the magic number.
</li></ul>
</p>
<p>Followed by the AES encrypted block above (2 byte # session tags,
that many session tags, sizeof(payload), H(payload), flag, payload,
random padding).</p>
{% endblock %}

4
www.i2p2/pages/how_elgamalaes_de.html
View File

@ -22,7 +22,7 @@ testen, ob diese in eine der drei M&ouml;glichkeiten passt:
Falls es f&uuml;r uns ElGamal verschl&uuml;sselt ist, wird die Nachricht als
neue Session behandelt und wird verschl&uuml;sselt mittels encryptNewSession(....)
in der
<a href="http://docs.i2p2.de/core/net/i2p/crypto/ElGamalAESEngine.html">[ElGamalAESEngine]</a>
<a href="http://docs.i2p2.de/javadoc/net/i2p/crypto/ElGamalAESEngine.html">[ElGamalAESEngine]</a>
wie folgend -</p>
<p>Ein initialer ElGamal Block, verschl&uuml;sselt <a href="how_cryptography">wie zuvor</a>:</p>
@ -67,7 +67,7 @@ ersetzt.</p>
Zeit (zur Zeit 30 Minuten) gespeichert bis sie gebraucht (und weggeworfen) werden.
Sie werden f&uuml;r das Einpacken einer Nachricht ohne vorhergehnden ElGamal Block
genutzt. Dabei wird es mit encryptExistingSession(...) in der
<a href="http://docs.i2p2.de/core/net/i2p/crypto/ElGamalAESEngine.html">[ElGamalAESEngine]</a>
<a href="http://docs.i2p2.de/javadoc/net/i2p/crypto/ElGamalAESEngine.html">[ElGamalAESEngine]</a>
wie folgend verschl&uuml;sselt -</p>
<PRE>

276
www.i2p2/pages/how_garlicrouting.html
View File

@ -1,53 +1,261 @@
{% extends "_layout.html" %}
{% block title %}How Garlic Routing Works{% endblock %}
{% block title %}Garlic Routing{% endblock %}
{% block content %}<p>
As briefly explained on the <a href="how_intro">intro</a>, in addition to sending
messages through tunnels (via <a href="how_tunnelrouting">tunnels</a>), I2P uses a technique called
"garlic routing" - layered encryption of messages, passing through routers
selected by the original sender. This is similar to the way Mixmaster
Updated August 2010 for release 0.8
</p>
<h2>Garlic Routing and "Garlic" Terminology</h2>
<p>
The terms "garlic routing" and "garlic encryption" are often used rather loosely when referring to I2P's technology.
Here, we explain the history of the terms, the various meanings, and
the usage of "garlic" methods in I2P.
</p><p>
"Garlic routing" was first coined by
<a href="http://www.cs.princeton.edu/~mfreed/">Michael J. Freedman</a>
in Roger Dingledine's Free Haven
<a href="http://www.freehaven.net/papers.html">Master's thesis</a> Section 8.1.1 (June 2000), as derived from
<a href="http://onion-router.net/">Onion Routing</a>.
</p><p>
"Garlic" may have been used originally by I2P developers because I2P implements a form of
bundling as Freedman describes, or simply to emphasize general differences from Tor.
The specific reasoning may be lost to history.
Generally, when referring to I2P, the term "garlic" may mean one of three things:
<ol><li>
Layered Encryption
</li><li>
Bundling multiple messages together
</li><li>
ElGamal/AES Encryption
</li></ol>
Unfortunately, I2P's usage of "garlic" terminology over the past seven years has not always been precise; therefore the reader is
cautioned when encountering the term.
Hopefully, the explanation below will make things clear.
</p>
<h3>Layered Encryption</h3>
<p>
Onion routing is a technique for building paths, or tunnels, through a series of peers,
and then using that tunnel.
Messages are repeatedly encrypted by the originator, and then decrypted by each hop.
During the building phase, only the routing instructions for the next hop are exposed to each peer.
During the operating phase, messages are passed through the tunnel, and the
message and its routing instructions are only exposed to the endpoint of the tunnel.
</p><p>
This is similar to the way Mixmaster
(see <a href="how_networkcomparisons">network comparisons</a>) sends messages - taking a message, encrypting it
to the recipient's public key, taking that encrypted message and encrypting
it (along with instructions specifying the next hop), and then taking that
resulting encrypted message and so on, until it has one layer of encryption
per hop along the path. The only significant difference between that technique
and I2P's garlic routing is that at each layer, any number of messages can be
per hop along the path.
</p><p>
In this sense, "garlic routing" as a general concept is identical to "onion routing".
As implemented in I2P, of course, there are several differences from the implementation in Tor; see below.
Even so, there are substantial similarities such that I2P benefits from a
<a href="http://www.onion-router.net/Publications.html">large amount of academic research on onion routing</a>,
<a href="http://freehaven.net/anonbib/topic.html">Tor, and similar mixnets</a>.
</p>
<h3>Bundling Multiple Messages</h3>
<p>
Michael Freedman defined "garlic routing" as an extension to onion routing,
in which multiple messages are bundled together.
He called each message a "bulb".
All the messages, each with its own delivery instructions, are exposed at the
endpoint.
This allows the efficient bundling of an onion routing "reply block" with the original message.
</p><p>
This concept is implemented in I2P, as described below.
Our term for garlic "bulbs" is "cloves".
Any number of messages can be
contained, instead of just a single message.
This is a significant distinction from the onion routing implemented in Tor.
However, it is only one of many major architectural differences between I2P and Tor;
perhaps it is not, by itself, enough to justify a change in terminology.
</p><p>
Another difference
from the method described by Freedman
is that the path is unidirectional - there is no "turning point" as seen in onion routing
or mixmaster reply blocks, which greatly simplifies the algorithm and allows for more flexible
and reliable delivery.
</p>
<h3>ElGamal/AES Encryption</h3>
In some cases, "garlic encryption" may simply mean
<a href="how_elgamalaes">ElGamal/AES+SessionTag</a> encryption
(without multiple layers).
<H2>"Garlic" Methods in I2P</H2>
<p>
In addition to the cloves, each unwrapped garlic message contains a sender
specified amount of padding data, allowing the sender to take active countermeasures
against traffic analysis.
<H2>Uses within I2P</H2>
<p>
I2P uses garlic routing in three places:
<UL>
<li> For building tunnels
<li> For determining the success or failure of end to end message delivery (by wrapping an additional
DeliveryStatusMessage in with the payload, where the clove containing the DeliveryStatusMessage
has instructions forwarding it back through other routers and tunnels to the original sender)
Now that we've defined various "garlic" terms, we can say that
I2P uses garlic routing, bundling and encryption in three places:
<ol>
<li> For building and routing through tunnels (layered encryption)
<li> For determining the success or failure of end to end message delivery (bundling)
<li> For publishing some network database entries (dampening the probability of a successful traffic analysis attack)
</UL>
(ElGamal/AES)
</ol>
<p>
There are also significant ways that this technique can be used to improve the performance of the network,
exploiting transport latency/throughput tradeoffs, and branching data through redundant paths to increase reliability.
<H2>Encryption</H2>
<h3>Tunnel Building and Routing</h3>
<p>
The encryption of each layer in the garlic message uses the <a href="how_elgamalaes">ElGamal/AES+SessionTag</a> algorithm,
which avoids the cost of a full 2048bit ElGamal encryption for subsequent messages (using instead a random previously
specified SessionTag plus 256bit AES encryption).
In I2P, tunnels are unidirectional. Each party builds two tunnels,
one for outbound and one for inbound traffic.
Therefore, four tunnels are required for a single round-trip message and reply.
</p><p>
Tunnels are built, and then used, with layered encryption.
This is described on the
<a href="tunnel-alt.html">tunnel implementation page</a>.
Tunnel building details are defined on
<a href="tunnel-alt-creation.html">this page</a>.
We use
<a href="how_elgamalaes">ElGamal/AES+SessionTag</a> for the encryption.
</p><p>
Tunnels are a general-purpose mechanism to transport all
<a href="i2np.html">I2NP messages</a>, and
<a href="i2np_spec.html#msg_Garlic">Garlic Messages</a> are not used to build tunnels.
We do not bundle multiple
<a href="i2np.html">I2NP messages</a> into a single
<a href="i2np_spec.html#msg_Garlic">Garlic Message</a> for unwrapping at the outbound tunnel endpoint;
the tunnel encryption is sufficient.
</p>
<h3>End-to-End Message Bundling</h3>
<p>
At the layer above tunnels, I2P delivers end-to-end messages between
<a href="common_structures_spec#struct_Destination">Destinations</a>.
Just as within a single tunnel, we use
<a href="how_elgamalaes">ElGamal/AES+SessionTag</a> for the encryption.
Each client message as delivered to the router through the
<a href="i2cp.html">I2CP interface</a> becomes a single
<a href="i2np.html#struct_GarlicClove">Garlic Clove</a>
with its own
<a href="tunnel_message_spec.html#delivery">Delivery Instructions</a>,
inside a
<a href="i2np.html#msg_Garlic">Garlic Message</a>.
Delivery Instructions may specify a Destination, Router, or Tunnel.
</p><p>
Generally, a Garlic Message will contain only one clove.
However, the router will periodically bundle two additional
cloves in the Garlic Message:
<center>
<img src="/_static/images/garliccloves.png" alt="Garlic Message Cloves" />
</center>
<ol><li>
A
<a href="i2np.html#msg_DeliveryStatus">Delivery Status Message</a>,
with
<a href="tunnel_message_spec.html#delivery">Delivery Instructions</a>
specifying that it be sent back to the originating router as an acknowledgment.
This is similar to the "reply block" or "reply onion"
described in the references.
It is used for determining the success or failure of end to end message delivery.
The originating router may, upon failure to receive the Delivery Status Message
within the expected time period, modify the routing to the far-end Destination,
or take other actions.
</li><li>
A
<a href="i2np.html#msg_DatabaseStore">Database Store Message</a>,
containing a
<a href="common_structures_spec#struct_LeaseSet">LeaseSet</a>
for the originating Destination, with
<a href="tunnel_message_spec.html#delivery">Delivery Instructions</a>
specifying the far-end destination's router.
By periodically bundling a LeaseSet, the router ensures that the far-end will be able
to maintain communications.
Otherwise the far-end would have to query a floodfill router for the network database entry,
and all LeaseSets would have to be published to the network database, as explained on the
<a href="how_networkdatabase.html">network database page</a>.
</li></ol>
</p><p>
In the current implementation, the Delivery Status and Database Store Messages
are bundled when the local LeaseSet changes, when additional
<a href="common_structures_spec#type_SessionTag">Session Tags</a>
are delivered, or if the messages have not been bundled in the previous minute.
</p><p>
Obviously, the additional messages are currently bundled for specific purposes,
and not part of a general-purpose routing scheme.
</p>
<h3> Storage to the Floodfill Network Database</h3>
</p>
As explained on the
<a href="how_networkdatabase.html#delivery">network database page</a>,
local
<a href="common_structures_spec#struct_LeaseSet">LeaseSets</a>
are sent to floodfill routers in a
<a href="i2np.html#msg_DatabaseStore">Database Store Message</a>
wrapped in a
<a href="i2np.html#msg_Garlic">Garlic Message</a>
so it is not visible to the tunnel's outbound gateway.
</p>
<H2>Future Work</H2>
<p>
The Garlic Message mechanism is very flexible and provides a structure for
implementing many types of mixnet delivery methods.
Together with the unused delay option in the
<a href="tunnel_message_spec.html#delivery">tunnel message Delivery Instructions</a>,
a wide spectrum of batching, delay, mixing, and routing strategies are possible.
</p><p>
In particular, there is potential for much more flexibility at the outbound tunnel endpoint.
Messages could possibly be routed from there to one of several tunnels
(thus minimizing point-to-point connections), or multicast to several tunnels
for redundancy, or streaming audio and video.
</p><p>
Such experiments may conflict with the need to ensure security and anonymity, such
as limiting certain routing paths, restricting the types of I2NP messages that may
be forwarded along various paths, and enforcing certain message expiration times.
</p><p>
As a part of
<a href="how_elgamalaes">ElGamal/AES encryption</a>,
a garlic message contains a sender
specified amount of padding data, allowing the sender to take active countermeasures
against traffic analysis.
This is not currently used, beyond the requirement to pad to a multiple of 16 bytes.
</p><p>
Encryption of additional messages to and from the
<a href="how_networkdatabase.html#delivery">floodfill routers</a>.
</p>
<H2>References</H2>
<ul><li>
The term garlic routing was first coined in Roger Dingledine's Free Haven
<a href="http://www.freehaven.net/papers.html">Master's thesis</a> (June 2000),
see Section 8.1.1 authored by
<a href="http://www.cs.princeton.edu/~mfreed/">Michael J. Freedman</a>.
</li><li>
<a href="http://www.onion-router.net/Publications.html">Onion router publications</a>
</li><li>
<a href="http://en.wikipedia.org/wiki/Onion_routing">Onion Routing on Wikipedia</a>
</li><li>
<a href="http://en.wikipedia.org/wiki/Garlic_routing">Garlic Routing on Wikipedia</a>
</li><li>
<a href="meeting58.html#delivery">I2P Meeting 58</a> (2003) discussing the implementation of garlic routing
</li><li>
<a href="https://www.torproject.org/">Tor</a>
</li><li>
<a href="http://freehaven.net/anonbib/topic.html">Free Haven publications</a>
</li><li>
Onion routing was first described in <a href="http://www.onion-router.net/Publications/IH-1996.pdf">Hiding Routing Information</a>
by David M. Goldschlag, Michael G. Reed, and Paul F. Syverson in 1996.
</li></ul>
<p>
The term garlic routing was first coined by Michael Freedman in Roger Dingledine's Free Haven
<a href="http://www.freehaven.net/papers.html">Master's thesis</a> (June 2000), which was derived from
<a href="http://onion-router.net/">Onion Routing</a>. The main difference
from the method described by Freedman with I2P's garlic routing
is that the path is unidirectional - there is no "turning point" as seen in onion routing
or mixmaster reply blocks, which greatly simplifies the algorithm and allows for more flexible
and reliable delivery.{% endblock %}
{% endblock %}

14
www.i2p2/pages/how_networkcomparisons.html
View File

@ -169,6 +169,17 @@ these systems and I2P are related to I2P's <a href="how_threatmodel">threat mode
and their out-proxy design (as opposed to providing both sender and receiver
anonymity). There is source code available to both systems, but we are not aware
of their use outside of academic environments.</p>
<!--
Table needs correction, disabled for now.
Comments from arma on 2010-09-14 in #nottor:
You say "maybe" under the tarzan column, because tarzan says "we hope to get this level of protection, but it is an open research question how one would get it"
then i2p says "no, all solved, we solve that one" in its column. which either means you've got a brilliant new design but have failed to articulate it or publish about it, or you are misleading people.
this table has been around, and misleading people and frustrating me, for something like 8 or 10 years now.
the fundamental problem is that for the projects that exist, you put down their current levels of protection in the table (fine), but for i2p you put down your desired level of protection (not fine)
End of comments
<p>Stealing quite directly from the Tarzan paper, the following includes a quick
comparison of Tarzan, Crowds, Onion Routing (OR), and I2P:</p>
@ -265,8 +276,7 @@ comparison of Tarzan, Crowds, Onion Routing (OR), and I2P:</p>
<td><b>No</b></td>
</tr>
</table>
<p>(Original image at <a href="http://dev.i2p.net/~jrandom/wiki/comparison.png">
http://dev.i2p.net/~jrandom/wiki/comparison.png</a>)</p>
-->
<h2>Mixminion / Mixmaster</h2>
<i><a href="http://mixminion.net/">[Mixminion]</a>

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

@ -1,5 +1,5 @@
{% extends "_layout.html" %}
{% block title %}How the Network Database (netDb) Works{% endblock %}
{% block title %}The Network Database{% endblock %}
{% block content %}
<p>
@ -28,8 +28,8 @@
<p>
When an I2P router wants to contact another router, they need to know some
key pieces of data - all of which are bundled up and signed by the router into
a structure called the "RouterInfo", which is distributed under the key derived
from the SHA256 of the router's identity. The structure itself contains:
a structure called the "RouterInfo", which is distributed with the SHA256 of the router's identity
as the key. The structure itself contains:
</p>
<ul>
<li>The router's identity (a 2048bit ElGamal encryption key, a 1024bit DSA signing key, and a certificate)</li>
@ -95,7 +95,7 @@
<a href="common_structures_spec.html#struct_RouterInfo">RouterInfo specification</a>
</p>
<p>
<a href="http://docs.i2p2.de/core/net/i2p/data/RouterInfo.html">RouterInfo Javadoc</a>
<a href="http://docs.i2p2.de/javadoc/net/i2p/data/RouterInfo.html">RouterInfo Javadoc</a>
</p>
<h3>RouterInfo Expiration</h3>
@ -106,13 +106,15 @@
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 persistent 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>
<li>There is no expiration if there are 25 or less RouterInfos.</li>
<li>As the number of local RouterInfos grows, the expiration time shrinks, in an attempt to maintain
a reasonable number RouterInfos.
a reasonable number RouterInfos. The expiration time with less than 120 routers is 72 hours,
while expiration time with 300 routers is around 30 hours.</li>
<li>RouterInfos containing <a href="udp.html">SSU</a> introducers expire in about an hour, as
the introducer list expires in about that time
<li>Floodfills use a short expiration time for all local RouterInfos, as valid RouterInfos will
be frequently republished to them
the introducer list expires in about that time.</li>
<li>Floodfills use a short expiration time (1 hour) for all local RouterInfos, as valid RouterInfos will
be frequently republished to them.</li>
</ul>
<h3>RouterInfo Persistent Storage</h3>
@ -126,20 +128,25 @@
<p>
The second piece of data distributed in the netDb is a "LeaseSet" - documenting
a group of tunnel entry points (leases) for a particular client destination.
Each of these leases specify the tunnel's gateway router (with the hash of its
identity), the tunnel ID on that router to send messages (a 4 byte number), and
when that tunnel will expire. The LeaseSet itself is stored in the netDb under
a group of <b>tunnel entry points (leases)</b> for a particular client destination.
Each of these leases specify the following information:
<ul>
<li>The tunnel gateway router (by specifying its identity)</li>
<li>The tunnel ID on that router to send messages with (a 4 byte number)</li>
<li>When that tunnel will expire.</li>
</ul>
The LeaseSet itself is stored in the netDb under
the key derived from the SHA256 of the destination.
</p>
<p>
In addition to these leases, the LeaseSet includes the destination
itself (namely, the destination's 2048bit ElGamal encryption key, 1024bit DSA
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 public key was intended for LeaseSet revocation but is currently unused.
In addition to these leases, the LeaseSet includes:
<ul>
<li>The destination itself (a 2048bit ElGamal encryption key, 1024bit DSA signing key and a certificate)</li>
<li>Additional encryption public key: used for end-to-end encryption of garlic messages</li>
<li>Additional signing public key: intended for LeaseSet revocation, but is currently unused.</li>
<li>Signature of all the LeaseSet data, to make sure the Destination published the LeaseSet.</li>
</ul>
</p>
<p>
@ -148,9 +155,9 @@
<a href="common_structures_spec.html#struct_LeaseSet">LeaseSet specification</a>
</p>
<p>
<a href="http://docs.i2p2.de/core/net/i2p/data/Lease.html">Lease Javadoc</a>
<a href="http://docs.i2p2.de/javadoc/net/i2p/data/Lease.html">Lease Javadoc</a>
<br />
<a href="http://docs.i2p2.de/core/net/i2p/data/LeaseSet.html">LeaseSet Javadoc</a>
<a href="http://docs.i2p2.de/javadoc/net/i2p/data/LeaseSet.html">LeaseSet Javadoc</a>
</p>
@ -159,6 +166,8 @@
A LeaseSet for a destination used only for outgoing connections is <i>unpublished</i>.
It is never sent for publication to a floodfill router.
"Client" tunnels, such as those for web browsing and IRC clients, are unpublished.
Servers will still be able to send messages back to those unpublished destinations,
because of <a href="#leaseset_storage_peers">I2NP storage messages</a>.
</p>
@ -168,7 +177,7 @@
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 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.
This is the only planned use for that signing key, so it is currently unused.
</p>
<h3 id="encrypted">Encrypted LeaseSets</h3>
@ -210,14 +219,14 @@
<h2 id="floodfill">Floodfill</h2>
<p>
The floodfill netDb is simple distributed storage mechanism.
The storage algorithm is simple- send the data to the closest peer that has advertised itself
The floodfill netDb is a simple distributed storage mechanism.
The storage algorithm is simple: send the data to the closest peer that has advertised itself
as a floodfill router. Then wait 10 seconds, pick another floodfill router and ask them
for the entry to be sent, verifying its proper insertion / distribution. If the
verification peer doesn't reply, or they don't have the entry, the sender
repeats the process. When the peer in the floodfill netDb receives a netDb
store from a peer not in the floodfill netDb, they send it to all of the peers
in the floodfill netDb.
store from a peer not in the floodfill netDb, they send it to a subset of the floodfill netDb-peers.
The peers selected are the ones closest (according to the <a href="#kademlia_closeness">XOR-metric</a>) to a specific key.
</p>
<p>
Determining who is part of the floodfill netDb is trivial - it is exposed in each
@ -272,17 +281,18 @@
A floodfill router's only services that are in addition to those of non-floodfill routers
are in accepting netDb stores and responding to netDb queries.
Since they are generally high-bandwidth, they are more likely to participate in a high number of tunnels
(i.e. be a "relay" for others), but this not directly related to their distributed database services.
(i.e. be a "relay" for others), but this is not directly related to their distributed database services.
</p>
<h2 id="kad">Kademlia Closeness Metric</h2>
<a name="kademlia_closeness"><h2 id="kad">Kademlia Closeness Metric</h2></a>
<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 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,
as <a href="#sybil-partial">explained below</a>).
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.
A modification to this algorithm is done to increase the costs of <a href="#sybil-partial">Sybil attacks</a>.
Instead of the SHA256 hash of the key being looked up of stored, the SHA256 hash is taken
of the key appended with the date: yyyyMMdd (SHA256(key + yyyyMMdd).
</p>
@ -300,7 +310,7 @@
</p>
<h3>LeaseSet Storage to Peers</h3>
<a name="leaseset_storage_peers"><h3>LeaseSet Storage to Peers</h3></a>
<p>
<a href="i2np.html">I2NP</a> DatabaseStoreMessages containing the local LeaseSet are periodically exchanged with peers
by bundling them in a garlic message along with normal traffic from the related Destination.
@ -354,7 +364,7 @@
valid RouterInfo or LeaseSet which is newer than that previously stored in its
local NetDb, it "floods" it.
To flood a NetDb entry, it looks up the 7 floodfill routers closest to the key
of the NetDb entry. (The key is the SHA256 Hash of the RouterIdentity or Destination)
of the NetDb entry. (The key is the SHA256 Hash of the RouterIdentity or Destination with the date (yyyyMMdd) appended.)
</p>
<p>
It then directly connects to each of the 7 peers
@ -373,7 +383,7 @@
The replies are specified to return via one of the router's inbound exploratory tunnels.
</p>
<p>
Lookups are generally sent to the two "good" floodfill routers closest to the requested key, in parallel.
Lookups are generally sent to the two "good" (the connection doesn't fail) floodfill routers closest to the requested key, in parallel.
</p>
<p>
If the key is found locally by the floodfill router, it responds with a
@ -482,7 +492,7 @@
<p>
Destinations may be hosted on multiple routers simultaneously, by using the same
private and public keys (traditionally named eepPriv.dat files).
private and public keys (traditionally stored in eepPriv.dat files).
As both instances will periodically publish their signed LeaseSets to the floodfill peers,
the most recently published LeaseSet will be returned to a peer requesting a database lookup.
As LeaseSets have (at most) a 10 minute lifetime, should a particular instance go down,
@ -566,7 +576,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 responses in the I2P case, none of them satisfactory:
Some possible responses for the I2P network are listed below, however none of them is completely satisfactory:
</p>
<ul>
<li>Compile a list of bad router hashes or IPs, and announce the list through various means
@ -615,7 +625,7 @@ This attack becomes more difficult as the network size grows.
we use the Hash of the key appended with the current date string, i.e. H(k + YYYYMMDD).
A function called the "routing key generator" does this, which transforms the original key into a "routing key".
In other words, the entire netdb keyspace "rotates" every day at UTC midnight.
Any partial-keyspace attack would have to be regenerated every day, as
Any partial-keyspace attack would have to be regenerated every day, for
after the rotation, the attacking routers would no longer be close
to the target key, or to each other.
</p>
@ -679,7 +689,7 @@ This attack becomes more difficult as the network size grows.
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>
much less likely, until <a href="#future">iterative lookups are implemented</a>.
is much less likely, until <a href="#future">iterative lookups are implemented</a>.
</p>
<h3>DHT-Based Relay Selection</h3>

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

@ -62,7 +62,7 @@ about how long it takes for them to reply to a network database query, how
often their tunnels fail, and how many new peers they are able to introduce
us to, as well as simple data points such as when we last heard from them or
when the last communication error occurred. The specific data points gathered
can be found in the <a href="http://docs.i2p2.de/router/net/i2p/router/peermanager/PeerProfile.html">code</a>
can be found in the <a href="http://docs.i2p2.de/javadoc/net/i2p/router/peermanager/PeerProfile.html">code</a>
</p>
<p>
@ -90,7 +90,7 @@ send or receive on a single tunnel through the peer in a minute. For this estim
performance in the previous minute.
</p>
<h3>Capacity</h3>
<h3 id="capacity">Capacity</h3>
<p>The capacity calculation
simply goes through the profile and estimates how many tunnels the peer
@ -125,7 +125,7 @@ groups - fast, high capacity, and standard.
</ul>
These groupings are implemented in the router's <a
href="http://docs.i2p2.de/router/net/i2p/router/peermanager/ProfileOrganizer.html">ProfileOrganizer</a>.
href="http://docs.i2p2.de/javadoc/net/i2p/router/peermanager/ProfileOrganizer.html">ProfileOrganizer</a>.
<h3>Group size limits</h3>

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

@ -23,7 +23,7 @@ mitteilen k&ouml;nnen. Auch einfachere Daten sind enthalten, wie etwa der
Zeitpunkt des letzten Kontaktes oder wann der letzte Fehler in der
Kommunikation war. Die einzelnen gesammelten Datenpunkte k&ouml;nnen
im Monotone abgelesen werden (Link folgt).</p>
<!-- <a href="http://docs.i2p2.de/router/net/i2p/router/peermanager/PeerProfile.html">code</a>
<!-- <a href="http://docs.i2p2.de/javadoc/net/i2p/router/peermanager/PeerProfile.html">code</a>
</p> --!>
<p>Momentan gibt es keine "L&ouml;schstrategie, um sich der Profile der Knoten
@ -55,7 +55,7 @@ Netzwerk integriert ist und ob er nicht funktioniert.</p>
<p>Die Berechnung der Geschwindigkeit (wie im Quellkode implementiert)
<!--
<a href="http://docs.i2p2.de/router/net/i2p/router/peermanager/SpeedCalculator.html">here</a>) --!>
<a href="http://docs.i2p2.de/javadoc/net/i2p/router/peermanager/SpeedCalculator.html">here</a>) --!>
wird einfach mit den Profilen durchgef&uuml;hrt und sch&auml;tzt, wie viele
Daten wir durch einen einzigen Tunnel durch diesen Knoten in einer Minute
senden oder empfangen k&ouml;nnen. Daf&uuml;r werden einfach die Werte der
@ -77,7 +77,7 @@ dem derzeitigem Netzwerk zu best&auml;tigen.
<h3>Kapazit&auml;t/h3>
<p>die Berechnung der Kapazit&auml;t <!--(as implemented
<a href="http://docs.i2p2.de/router/net/i2p/router/peermanager/CapacityCalculator.html">here</a>) --!>
<a href="http://docs.i2p2.de/javadoc/net/i2p/router/peermanager/CapacityCalculator.html">here</a>) --!>
bearbeitet die Profile und sch&auml;tzt wie viele von uns angefragte Tunnel
der Knoten in der n&auml;chsten Stunde akzeptiert. Daf&uuml;r betrachtet
die Methode, wieviele Tunnel der Knoten in letzter Zeit akzeptiert hat, wie
@ -104,7 +104,7 @@ zur Effektivit&auml;t im aktuellem Netzwerk.
<p>Die Berechnung der Integration
<!-- (as implemented
<a href="http://docs.i2p2.de/router/net/i2p/router/peermanager/IntegrationCalculator.html">here</a>) --!>
<a href="http://docs.i2p2.de/javadoc/net/i2p/router/peermanager/IntegrationCalculator.html">here</a>) --!>
ist nur f&uuml;r die Netzwerkdatenbank notwendig (und, falls eingebaut, zum
Erkennen und reparieren von Netzwerk`splits`). Zur Zeit wird es f&uuml;r nichts
benutzt, da der Kode zum Erkennen der Splits in gut verbundenen Netzwerken
@ -131,7 +131,7 @@ Schwachstelle im derzeitigem Floodfillsystem behoben.
<p>Die Berechung zum Versagen
<!-- (as implemented
<a href="http://docs.i2p2.de/router/net/i2p/router/peermanager/IsFailingCalculator.html">here</a>) --!)
<a href="http://docs.i2p2.de/javadoc/net/i2p/router/peermanager/IsFailingCalculator.html">here</a>) --!)
eines Knoten kontrolliert ein paar Daten aus den Profilen und erkennt, ob
der Knoten &uuml;berladen ist oder nicht seine Versprechen zum Tunnelaufbau
einhalten kann. Sobald ein Knoten als "Versager" gekennzeichnet ist, wird
@ -165,7 +165,7 @@ Beziehungen zueinander: <ul>
<!--
These groupings are implemented in the <a
href="http://docs.i2p2.de/router/net/i2p/router/peermanager/ProfileOrganizer.html">ProfileOrganizer</a>'s
href="http://docs.i2p2.de/javadoc/net/i2p/router/peermanager/ProfileOrganizer.html">ProfileOrganizer</a>'s
reorganize() method (using the calculateThresholds() and locked_placeProfile() methods in turn).</p>
--!>

460
www.i2p2/pages/how_threatmodel.html
View File

@ -1,15 +1,18 @@
{% extends "_layout.html" %}
{% block title %}I2P's Threat Model{% endblock %}
{% block content %}<h1>What do we mean by "anonymous"?</h1>
{% block content %}
<p>Your level of anonymity can be described as how hard it is for someone
to find out information you don't want them to know - who you are, where
Updated August 2010, current as of router version 0.8
<h2>What do we mean by "anonymous"?</h2>
<p>Your level of anonymity can be described as "how hard it is for someone
to find out information you don't want them to know?" - who you are, where
you are located, who you communicate with, or even when you communicate.
"Perfect" anonymity is not a useful concept here - software will not make
you indistinguishable from people that don't use computers or who are not on
the Internet. Instead, I2P is working to provide sufficient anonymity to meet the
real needs of whomever we can - from Joe Sixpack browsing porn to Tommy Trader
sharing files to Irene Insurgent organizing an upcoming action.</p>
the Internet. Instead, we are working to provide sufficient anonymity to meet the
real needs of whomever we can - from those simply browsing websites, to those exchanging
data, to those fearful of discovery by powerful organizations or states.</p>
<p>The question of whether I2P provides sufficient anonymity for your
particular needs is a hard one, but this page will hopefully assist in
@ -17,47 +20,80 @@ answering that question by exploring how I2P operates under various attacks
so that you may decide whether it meets your needs.</p>
<p>We welcome further research and analysis on I2P's resistance to the threats described below.
Both review of existing literature (much of it focused on Tor) and original
More review of existing literature (much of it focused on Tor) and original
work focused on I2P is needed.</p>
<h2>Mix summary</h2>
<h2>Network Topology Summary</h2>
<p>I2P builds off the ideas of many <a href="how_networkcomparisons">other</a>
<a href="links">systems</a>, but a few key points should be kept in mind when
reviewing related literature:</p><ul>
<li><b>I2P is a free route mixnet</b> - the message creator explicitly defines the
path that messages will be sent out (the outbound tunnel), and the message
recipient explicitly defines the path that messages will be received on (the
inbound tunnel). However, any of these hops along the path may inject an
arbitrary number of hops before forwarding the message to the next peer (though
the current implementation does not).</li>
<li><b>I2P is variable latency</b> - each application (destination) determines its
own tradeoff of latency, throughput, bandwidth, and anonymity by configuring
the number of hops in their tunnels, the number of tunnels to keep in parallel,
and how frequently to rotate tunnels. In addition, there are plans to implement
<a href="todo#stop">nontrivial delays</a> and <a href="todo#batching">batching strategies</a>
whose existence is only known to the particular hop or tunnel gateway that
receives the message, allowing a mostly low latency mixnet to provide cover
traffic for higher latency communication (e.g. email).</li>
<li><b>I2P has no entry and exit points</b> - all peers fully participate in the
inbound tunnel).
</li>
<li><b>I2P has no official entry and exit points</b> - all peers fully participate in the
mix, and there are no network layer in- or out-proxies (however, at the
application layer, a few outbound HTTP proxies exist at the moment)</li>
<li><b>I2P is fully distributed</b> - there are no central controls or peers who
take on uneven responsibilities (beyond load balancing due to resource constraints).
application layer, a few proxies do exist)</li>
<li><b>I2P is fully distributed</b> - there are no central controls or authorities.
One could modify some routers to operate mix cascades (building tunnels and giving
out the keys necessary to control the forwarding at the tunnel endpoint) or directory
based profiling and selection, all without breaking compatibility with the rest of
the network, but doing so is of course not necessary (and may even harm one's
anonymity).</li>
</ul>
<p>
We have documented plans to implement
<a href="todo#stop">nontrivial delays</a> and <a href="todo#batching">batching strategies</a>
whose existence is only known to the particular hop or tunnel gateway that
receives the message, allowing a mostly low latency mixnet to provide cover
traffic for higher latency communication (e.g. email).
However we are aware that significant delays are required to provide meaningful
protection, and that implementation of such delays will be a significant challenge.
It is not clear at this time whether we will actually implement these delay features.
</p><p>
In theory, routers along the message path may inject an
arbitrary number of hops before forwarding the message to the next peer, though
the current implementation does not.
</p>
<h2>Attacks</h2>
<p>Taking from the attacks and analyzes put forth in the
<h2>The Threat Model (Attacks)</h2>
<p>
I2P design started in 2003, not long after the advent of
<a href="http://www.onion-router.net">[Onion Routing]</a>,
<a href="http://freenetproject.org/">[Freenet]</a>, and
<a href="http://www.torproject.org/">[Tor]</a>.
Our design benefits substantially from the research published around that time.
I2P uses several onion routing techniques, so we continue to benefit
from the significant academic interest in Tor.
</p><p>
Taking from the attacks and analysis put forth in the
<a href="http://freehaven.net/anonbib/topic.html">anonymity literature</a> (largely
<a href="http://citeseer.ist.psu.edu/454354.html">Traffic Analysis: Protocols, Attacks, Design
Issues and Open Problems</a>), the following briefly describes a wide variety
of attacks as well as many of I2Ps defenses. We will update
this list to include new attacks as they are identified.</p>
of attacks as well as many of I2Ps defenses. We update
this list to include new attacks as they are identified.
</p><p>
Included are some attacks that may be unique to I2P.
We do not have good answers for all these attacks, however
we continue to do research and improve our defenses.
</p><p>
In addition, many of these attacks are significantly easier than
they should be, due to the modest size of the current network.
While we are aware of some limitations that need to be addressed,
I2P is designed to support hundreds of thousands, or millions, of
participants.
As we continue to spread the word and grow the network,
these attacks will become much harder.
</p><p>
The
<a href="how_networkcomparisons.html">network comparisons</a> and
<a href="how_garlicrouting.html">"garlic" terminology</a> pages may also be helpful
to review.
</p>
<h3 id="index">Index</h3>
<ul>
<li><a href="#bruteforce">Brute force attacks</a></li>
<li><a href="#timing">Timing attacks</a></li>
@ -67,9 +103,11 @@ this list to include new attacks as they are identified.</p>
<li><a href="#partitioning">Partitioning attacks</a></li>
<li><a href="#predecessor">Predecessor attacks</a></li>
<li><a href="#harvesting">Harvesting attacks</a></li>
<li><a href="#traffic">Identification Through Traffic Analysis</a></li>
<li><a href="#sybil">Sybil attacks</a></li>
<li><a href="#crypto">Cryptographic attacks</a></li>
<li><a href="#floodfill">Floodfill attacks</a></li>
<li><a href="#netdb">Other Network Database attacks</a></li>
<li><a href="#central">Attacks on centralized resources</a></li>
<li><a href="#dev">Development attacks</a></li>
<li><a href="#impl">Implementation attacks</a></li>
@ -99,7 +137,17 @@ would want to make appropriate countermeasures, such as not communicating with
unknown destinations, not publishing one's current leaseSet in the network
database, actively rerouting the associated tunnels 'mid stream', throttling the
inbound tunnels themselves, and/or using restricted routes with trusted links
to secure the local connection.</p>
to secure the local connection.
</p><p>
As a partial defense against routers trying to route all the network's traffic,
routers contain limits as to how many tunnels can be routed through a single peer.
As the network grows, these limits are subject to further adjustment.
Other mechanisms for peer rating, selection and avoidance
are discussed on the
<a href="how_peerselection.html">peer selection page</a>.
</p>
<h3 id="timing">Timing attacks</h3>
@ -120,10 +168,12 @@ automatic replies though - the streaming library does (with the SYN+ACK) as does
message mode of guaranteed delivery (with the DataMessage+DeliveryStatusMessage).</p>
<p>Without protocol scrubbing or higher latency, global active adversaries can
gain substantial information. As such, people concerned with these attacks should
increase the latency (per <a href="todo#stop">nontrivial delays</a> or
gain substantial information. As such, people concerned with these attacks could
increase the latency (using <a href="todo#stop">nontrivial delays</a> or
<a href="todo#batching">batching strategies</a>), include protocol scrubbing, or
other advanced tunnel routing <a href="todo#batching">techniques</a>.</p>
other advanced tunnel routing <a href="todo#batching">techniques</a>,
but these are unimplemented in I2P.
</p>
<p>References:
<a href="http://www.cs.colorado.edu/department/publications/reports/docs/CU-CS-1025-07.pdf">Low-Resource Routing Attacks Against Anonymous Systems</a>
@ -139,31 +189,71 @@ peers that are online when a message successfully goes through. The cost of
this attack is significant as the network grows, but may be feasible in some
scenarios.</p>
<p>I2P does not attempt to address this for low latency communication,
but does for peers who can afford delays (per <a href="todo#stop">nontrivial
<p>
In summary, if an attacker is at both ends of your tunnel at the same time,
he may be successful.
I2P does not have a full defense to this for low latency communication.
This is an inherent weakness of low-latency onion routing.
Tor provides a <a href="https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/TorFAQ#Whatattacksremainagainstonionrouting">similar disclaimer</a>.
</p><p>
Partial defenses implemented in I2P:
<ul><li>
<a href="tunnel-alt.html#ordering">strict ordering</a> of peers
</li><li>
<a href="how_peerselection.html">peer profiling and selection</a> from a small group that changes slowly
</li><li>
Limits on the number of tunnels routed through a single peer
</li><li>
Prevention of peers from the same /16 IP range from being members of a single tunnel
</li></ul>
Even in total, these defenses are not a complete solution.
Also, we have made some design choices that may significantly increase our vulnerability:
<ul><li>
We do not use low-bandwidth "guard nodes"
</li><li>
We use tunnel pools comprised of several tunnels, and traffic can shift from tunnel to tunnel.
</li><li>
Tunnels are not long-lived; new tunnels are built every 10 minutes.
</li><li>
Tunnel lengths are configurable.
While 3-hop tunnels are recommended for full protection, several applications and
services use 2-hop tunnels by default.
</li></ul>
</p><p>
In the future, it could
for peers who can afford significant delays (per <a href="todo#stop">nontrivial
delays</a> and <a href="todo#batching">batching strategies</a>). In addition,
this is only relevant for destinations that other people know about - a private
group whose destination is only known to trusted peers does not have to worry,
as an adversary can't "ping" them to mount the attack.</p>
<p>Reference:
<a href="http://blog.torproject.org/blog/one-cell-enough">One Cell Enough</a>
</p>
<h3 id="dos">Denial of service attacks</h3>
<p>There are a whole slew of denial of service attacks available against I2P,
each with different costs and consequences:</p><ul>
<li><b>Greedy user attack:</b> The most plausible attack against I2P will simply
be people trying to consume significantly more resources than they are
willing to contribute. The defense against this is twofold:<ul>
<li>First, for people who do not need very strong anonymity, simply set the tunnel length
to 0 hops (1 hop until <a href="todo#ordering">strict ordering</a> and
<a href="todo#tunnelLength">permuted lengths</a> is implemented). This will
provide optimal throughput while still providing a degree of anonymity via
plausible deniability. In addition, it will not consume significant network
resources.</li>
<li>Second, for people who do need stronger anonymity, educate them so they
understand that without routing other people's traffic, their own anonymity
is weakened, so that if they want to consume significant network resources
while still being anonymous, they need to provide significant network
resources.</li></ul>
<li><b>Greedy user attack:</b> This is simply
people trying to consume significantly more resources than they are
willing to contribute. The defense against this is:<ul>
<li>Set defaults so that most users provide resources to the network.
In I2P, users route traffic by default. In sharp distinction to
<a href="https://torproject.org/">other networks</a>,
over 95% of I2P users relay traffic for others.
</li>
<li>Provide easy configuration options so that users may increase their
contribution (share percentage) to the network. Display easy-to-understand
metrics such as "share ratio" so that users may see what they are contributing.
</li><lil>
Maintain a strong community with blogs, forums, IRC, and other means of communication.
</li></ul>
<li><b>Starvation attack:</b> A hostile user may attempt to harm the network by
creating a significant number of peers in the network who are not identified as
being under control of the same entity (as with Sybil). These nodes then
@ -176,10 +266,9 @@ each with different costs and consequences:</p><ul>
I2P addresses these issues by maintaining <a href="how_peerselection.html">profiles</a> on the
peers, attempting to identify underperforming ones and simply ignoring
them, or using them rarely.
In the process of fixing several problems and bugs with peer reachability
in the 0.6.1.32 and 0.6.1.33 releases, we have significantly enhanced the
ability to recognize and avoid troublesome peers. These efforts will
continue in the 0.6.2.x release cycle.
We have significantly enhanced the
ability to recognize and avoid troublesome peers; however there are still
significant efforts required in this area.
</li>
<li><b>Flooding attack:</b> A hostile user may attempt to flood the network,
a peer, a destination, or a tunnel. Network and peer flooding is possible,
@ -202,20 +291,17 @@ each with different costs and consequences:</p><ul>
engineering practices and potentially requiring nontrivial certificates
(e.g. HashCash) to be attached to these expensive requests should mitigate
the issue, though there may be room for an attacker to exploit various
bugs in the implementation.</p>
bugs in the implementation.</li>
<li id="ffdos"><b>Floodfill DOS attack:</b> A hostile user may attempt to harm the network by
becoming a floodfill router. The current defenses against unreliable,
intermittent, or malicious floodfill routers are poor.
To fix problems with floodfill peer selection
in the 0.6.1.32 and earlier releases, significantly enhancements in the
ability to recognize and avoid troublesome floodfill peers
were included in release 0.6.1.33.
However, there is much more to do.
A floodfill router may provide bad or no response to lookups, and
it may also interfere with inter-floodfill communication.
A brief summary of the issues is
listed on <a href="http://zzz.i2p/#floodfill">zzz.i2p</a>.
These efforts will continue in the 0.6.2.x release cycle.
Some defenses and
<a href="how_peerselection">peer profiling</a> are implemented,
however there is much more to do.
For more information see the
<a href="how_networkdatabase.html#threat">network database page</a>.
</li>
</ul>
@ -260,7 +346,11 @@ particular hops with non-zero delays will likely stand out. However, this data
is only exposed to those specific hops, so to partition effectively on that
matter, the attacker would need to control a significant portion of the network
(and still that would only be a probabilistic partition, as they wouldn't know
which other tunnels or messages have those delays).</p>
which other tunnels or messages have those delays).
</p><p>
Also discussed on the
<a href="how_networkdatabase.html#threat">network database page</a> (bootstrap attack).
</p>
<h3 id="predecessor">Predecessor attacks</h3>
@ -275,14 +365,21 @@ target is located. </p>
<p>I2P avoids this in four ways: first, the peers selected to participate in
tunnels are not randomly sampled throughout the network - they are derived from
the <a href="how_peerselection">peer selection</a> algorithm which breaks them
into tiers. Second, with <a href="todo#ordering">strict ordering</a> of peers
into tiers. Second, with <a href="tunnel-alt.html#ordering">strict ordering</a> of peers
in a tunnel, the fact that a peer shows up more frequently does not mean they're
the source. Third, with <a href="todo#tunnelLength">permuted tunnel length</a>
the source. Third, with <a href="tunnel-alt.html#length">permuted tunnel length</a>
(not enabled by default)
even 0 hop tunnels can provide plausible deniability as the occasional
variation of the gateway will look like normal tunnels. Fourth, with
<a href="todo#fullRestrictedRoutes">restricted routes</a>, only the peer with
<a href="todo#fullRestrictedRoutes">restricted routes</a> (unimplemented), only the peer with
a restricted connection to the target will ever contact the target, while
attackers will merely run into that gateway.</p>
attackers will merely run into that gateway.
</p><p>
The current
<a href="tunnel-alt-creation.html">tunnel build method</a>
was specifically designed to combat the predecessor attack.
See also <a href="#intersection">the intersection attack</a>.
</p>
<p>References:
<a href="http://prisms.cs.umass.edu/brian/pubs/wright.tissec.2008.pdf">http://prisms.cs.umass.edu/brian/pubs/wright.tissec.2008.pdf</a>
@ -290,21 +387,83 @@ which is an update to the 2004 predecessor attack paper
<a href="http://prisms.cs.umass.edu/brian/pubs/wright-tissec.pdf">http://prisms.cs.umass.edu/brian/pubs/wright-tissec.pdf</a>.
</p>
<h3 id="harvesting">Harvesting attacks</h3>
<p>The harvesting attack can be used for legal attacks and to help mounting
<h3 id="harvesting">Harvesting attacks</h3>
<p>
"Harvesting" means compiling a list of users running I2P.
It can be used for legal attacks and to help
other attacks by simply running a peer, seeing who it connects to, and
harvesting whatever references to other peers it can find. I2P itself is
built to optimize this attack, since there is the distributed network database
containing just this information. However, this by itself isn't a problem,
since there are ways to track down who is participating in the network with
essentially all public systems - I2P just makes it easier to do (and, in
turn, gains the ability to combat partitioning and provide well bounded
discovery time). With <a href="todo#nat">basic</a> and
harvesting whatever references to other peers it can find.
</p><p>
I2P itself is not designed with effective defenses against
this attack, since there is the distributed network database
containing just this information.
The following factors make the attack somewhat harder in practice:
<ul><li>
Network growth will make it more difficult to obtain a given proportion of the network
</li><li>
Floodfill routers implement query limits as DOS protection
</li><li>
"Hidden mode", which prevents a router from publishing its information to the netDb,
(but also prevents it from relaying data) is not widely used now but could be.
</li></ul>
In future implementations,
<a href="todo#nat">basic</a> and
<a href="todo#fullRestrictedRoutes">comprehensive</a> restricted routes,
this attack loses much of its power, as the "hidden" peers do not publish their
contact addresses in the network database - only the tunnels through which
they can be reached (as well as their public keys, etc).</p>
they can be reached (as well as their public keys, etc).
</p><p>
In the future, routers could use GeoIP to identify if they are in a particular
country where identification as an I2P node would be risky.
In that case, the router could automatically enable hidden mode, or
enact other restricted route methods.
</p>
<h3 id="traffic">Identification Through Traffic Analysis</h3>
<p>
By inspecting the traffic into and out of a router, a malicious ISP
or state-level firewall could identify that a computer is running I2P.
As discussed <a href="#harvesting">above</a>, I2P is not specifically designed
to hide that a computer is running I2P. However, several design decisions made
in the design of the
<a href="transport.html">transport layer and protocols</a>
make it somewhat difficult to identify I2P traffic:
<ul><li>
Random port selection
</li><li>
Point-to-Point Encryption of all traffic
</li><li>
DH key exchange with no protocol bytes or other unencrypted constant fields
</li><li>
Simultaneous use of both
<a href="ntcp.html">TCP</a> and
<a href="udp.html">UDP</a> transports.
UDP may be much harder for some Deep Packet Inspection (DPI) equipment to track.
</li></ul>
In the near future, we plan to directly address traffic analysis issues by further obfuscation of I2P transport protocols, possibly including:
<ul><li>
Padding at the transport layer to random lengths, especially during the connection handshake
</li><li>
Study of packet size distribution signatures, and additional padding as necessary
</li><li>
Development of additional transport methods that mimic SSL or other common protocols
</li><li>
Review of padding strategies at higher layers to see how they affect packet sizes at the transport layer
</li><li>
Review of methods implemented by various state-level firewalls to block Tor
</li><li>
Working directly with DPI and obfuscation experts
</li></ul>
</p><p>
Reference:
<a href="http://www.cse.chalmers.se/%7Ejohnwolf/publications/hjelmvik_breaking.pdf">Breaking and Improving Protocol Obfuscation</a>
</p>
<h3 id="sybil">Sybil attacks</h3>
@ -322,28 +481,93 @@ IIP used
identity. We currently have not implemented any particular technique to address
Sybil, but do include placeholder certificates in the router's and
destination's data structures which can contain a HashCash certificate of
appropriate value when necessary (or some other certificate proving scarcity).</p>
appropriate value when necessary (or some other certificate proving scarcity).
</p><p>
Requiring HashCash Certificates in various places has two major problems:
<ul><li>
Maintaining backward compatibility
</li><li>
The classic HashCash problem -
selecting HashCash values that are meaningful proofs of work on high-end machines,
while still being feasible on low-end machines such as mobile devices.
</li></ul>
</p><p>
Various limitations on the number of routers in a given IP range restrict
the vulnerability to attackers that don't have the ability to put machines
in several IP blocks.
However, this is not a meaningful defense against a powerful adversary.
</p><p>
See the
<a href="how_networkdatabase.html#threat">network database page</a>
for more Sybil discussion.
</p>
<h3 id="crypto">Cryptographic attacks</h3>
<p>
We are still assuming the security of the cryptographic primitives explained
<a href="how_cryptography">elsewhere</a>. That includes the immediate detection of
We use strong cryptography with long keys, and
we assume the security of the industry-standard cryptographic primitives used in I2P, as documented
<a href="how_cryptography">on the low-level cryptography page</a>.
Security features
include the immediate detection of
altered messages along the path, the inability to decrypt messages not addressed to you,
and defense against man-in-the-middle attacks. The network protocol and data structures
and defense against man-in-the-middle attacks.
The key sizes chosen in 2003 were quite conservative at the time, and are still longer than
those used in <a href="https://torproject.org/">other anonymity networks</a>.
We don't think the current key lengths are our biggest weakness,
especially for traditional, non-state-level adversaries;
bugs and the small size of the network are much more worrisome.
Of course, all cryptographic algorithms eventually become obsolete due to
the advent of faster processors, cryptographic research, and advancements in
methods such as rainbow tables, clusters of video game hardware, etc.
Unfortunately, I2P was not designed with easy mechanisms to lengthen keys or change
shared secret values while maintaining backward compatibility.
</p><p>
Upgrading the various data structures and protocols to support longer keys
will have to be tackled eventually, and this will be a
<a href="how_cryptography">major undertaking</a>, just as it will be for
<a href="https://torproject.org/">others</a>.
Hopefully, through careful planning, we can minimize the disruption, and
implement mechanisms to make it easier for future transitions.
</p><p>
In the future,
several I2P protocols and data structures
support securely padding messages to arbitrary sizes, so messages could be made constant
size or garlic messages could be modified randomly so that some cloves appear to contain
more subcloves than they actually do. At the moment, however, garlic, tunnel, and
end to end messages include simple random padding.</p>
<h3 id="floodfill">Floodfill Anonymity attacks</h3>
<p>
In addition to the floodfill DOS attacks described
<a href="#ffdos">above</a>, floodfill routers are uniquely positioned
to learn about network participants, due to their centralized role
to learn about network participants, due to their role
in the netDb, and the high frequency of communication with those participants.
The specific potential threats and corresponding defenses are a topic for further research.
</li>
This is somewhat mitigated because floodfill routers only manage a portion
of the total keyspace, and the keyspace rotates daily, as explained.
on the
<a href="how_networkdatabase.html#threat">network database page</a>.
The specific mechanisms by which routers communicate with floodfills have been
<a href="how_networkdatabase.html#delivery">carefully designed</a>.
However, these threats should be studied further.
The specific potential threats and corresponding defenses are a topic for future research.
</p>
<h3 id="netdb">Other Network Database attacks</h3>
<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 responses.
Several scenarios are discussed on the
<a href="how_networkdatabase.html#threat">network database page</a>.
</p>
<h3 id="central">Central Resource Attacks</h3>
<p>
@ -355,7 +579,7 @@ most of which are now distributed.
Attacks on externally-reachable resources mainly affect the ability of new users to find us,
not the operation of the network itself.
<ul>
<li>The <a href="/">new website</a> is mirrored and uses DNS round-robin for external public access.
<li>The <a href="/">website</a> is mirrored and uses DNS round-robin for external public access.
<li>Routers now support <a href="faq.html#reseed">multiple external reseed locations</a>,
however more reseed hosts may be needed, and the handling of unreliable or malicious
reseed hosts may need improvement.
@ -365,7 +589,7 @@ not the operation of the network itself.
<li>Routers now better handle <a href="#ffdos">multiple unreliable floodfill peers</a>.
Malicious floodfills <a href="#ffdos">needs</a> <a href="#floodfill">more</a> study.
<li>The code is now stored in a <a href="monotone.html">distributed source control system</a>.
<li>Routers still rely on a single news host, update for this is TBD.
<li>Routers rely on a single news host, but there is a hardcoded backup URL pointing to a different host.
A malicious news host could feed a huge file, need to limit the size.
<li><a href="naming.html">Naming system services</a>, including addressbook subscription providers, add-host services,
and jump services, could be malicious. Substantial protections for subscriptions were implemented
@ -385,9 +609,9 @@ These attacks aren't directly on the network, but instead go after its developme
by either introducing legal hurdles on anyone contributing to the development
of the software, or by using whatever means are available to get the developers to
subvert the software. Traditional technical measures cannot defeat these attacks, and
if someone threatened the lives of a developer's loved ones (or even just issuing a
court order along with a gag order, under threat of prison), everyone should expect that
the code would be modified. </p>
if someone threatened the life or livelihood of a developer (or even just issuing a
court order along with a gag order, under threat of prison), we would have a big problem.
</p>
<p>
However, two techniques help defend against these attacks:
@ -407,22 +631,42 @@ However, two techniques help defend against these attacks:
discussion forums (forum.i2p), and the software distribution sites,
all available within I2P.</li>
</ul>
We also maintain relationships with various organizations that offer legal advice,
should any defense be necessary.
</p>
<h3 id="impl">Implementation attacks</h3>
<h3 id="impl">Implementation attacks (bugs)</h3>
<p>
Try as we might, most nontrivial applications include errors in the design or
implementation, and I2P is no exception. There may be bugs that could be exploited to
attack the anonymity or security of the communication running over I2P in unexpected
ways. To help withstand attacks against the design or protocols in use, we publish
all designs and documentation in the open and asking for any and all criticism with
the hope that many eyes will improve the system. In addition, the code is being
all designs and documentation and solicit review and criticism with
the hope that many eyes will improve the system.
We do not believe in
<a href="http://www.haystacknetwork.com/">security through obscurity</a>.
</p><p>
In addition, the code is being
treated the same way, with little aversion towards reworking or throwing out
something that isn't meeting the needs of the software system (including ease of
modification). Documentation for the design and implementation of the network and
the software components are an essential part of security, as without them it is
unlikely that developers would be willing to spend the time to learn the software
enough to identify shortcomings and bugs.</p>
enough to identify shortcomings and bugs.
</p><p>
Our software is likely, in particular, to contain bugs related to denial of service
through out-of-memory errors (OOMs), cross-site-scripting (XSS) issues in the router console,
and other vulnerabilities to non-standard inputs via the various protocols.
</p><p>
I2P is still a small network with a small development community and almost no
interest from academic or research groups.
Therefore we lack the analysis that
<a href="https://torproject.org/">other anonymity networks</a>
may have received. We continue to recruit people to
<a href="getinvolved.html">get involved</a> and help.
</p>
<h2>Other Defenses</h2>
@ -437,23 +681,6 @@ blocking by only a subset of peers would tend to segment the network,
exacerbate reachability problems, and decrease overall reliability.
Therefore we would want to agree on a particular blocklist and
enable it by default.
<p>
Any blocking within i2p would have to be implemented at the following
places in the code to be fully effective.
Different places address the various possible malicious behaviors.
<ol>
<li>Outbound connections (bids)
<li>Inbound NTCP
<li>Inbound SSU
<li>Peer selection for inbound and outbound tunnels
<li>Other-end inbound gateway
<li>Netdb stores / shitlisting
<li>Floodfill stores
<li>Floodfill queries
<li>Inter-floodfill flooding
<li>SSU peer tests
<li>SSU address determination
</ol>
<p>
Blocklists are only a part (perhaps a small part) of an array of defenses
@ -467,15 +694,16 @@ If a blocklist is hosted at a central location with automatic updates
the network is vulnerable to a
<a href="#central">central resource attack</a>.
Automatic subscription to a list gives the list provider the power to shut
the i2p network down. Completely. So we probably won't be doing that.
Inclusion in i2pupdate files perhaps? Signed or unsigned?
In-I2P subscription?
the i2p network down. Completely.
<p>
Initial test results
show that the common splist.txt blocklist is overly broad for our use - at the least
we don't want to block Tor users that are in splist.
Level1 + bogon + (maybe) level2 is more reasonable?
But we don't want to block potential anonymity researchers at .edu locations.
Currently, a default blocklist is distributed with our software,
listing only the IPs of past DOS sources.
There
is no automatic update mechanism.
Should a particular IP range implement serious attacks on the I2P network,
we would have to ask people to update their blocklist manually through
out-of-band mechanisms such as forums, blogs, etc.
</p>
{% endblock %}

263
www.i2p2/pages/how_tunnelrouting.html
View File

@ -1,22 +1,35 @@
{% extends "_layout.html" %}
{% block title %}How Tunnel Routing Works{% endblock %}
{% block content %}<i>Note: these documents have not yet been updated to include the changes made
in I2P 0.5 - the new
<a href="tunnel-alt.html">tunnel
routing and encryption</a> algorithms, addressing <a href="todo#tunnelId">several</a>
<a href="todo#tunnelLength">issues</a> (with the groundwork for addressing
<a href="todo#ordering">others</a>).</i>
{% block title %}Tunnel Overview{% endblock %}
{% block content %}
<p>
Updated August 2010 for release 0.8
</p>
<p>As briefly explained in the <a href="how_intro">intro</a>, I2P builds virtual "tunnels" -
<h2>Tunnel Overview</h2>
<p>
This page contains an overview of I2P tunnel terminology and operation, with
links to more technical pages, details, and specifications.
</p>
<p>As briefly explained in the <a href="how_intro">introduction</a>, I2P builds virtual "tunnels" -
temporary and unidirectional paths through a sequence of routers. These
tunnels can be categorized as either inbound tunnels (where everything
given to it goes towards the creator of the tunnel) and outbound tunnels
tunnels are classified as either inbound tunnels (where everything
given to it goes towards the creator of the tunnel) or outbound tunnels
(where the tunnel creator shoves messages away from them). When Alice
wants to send a message to Bob, she will (typically) send it out one of
her existing outbound tunnels with instructions for that tunnel's endpoint
to forward it to the gateway router for one of Bob's current inbound
tunnels, which in turn passes it to Bob.</p>
<p><center>
<img src="/_static/images/tunnelSending.png" alt="Tunnel" />
<pre>
A: Outbound Gateway (Alice)
B: Outbound Participant
C: Outbound Endpoint
D: Inbound Gateway
E: Inbound Participant
F: Inbound Endpoint (Bob)
</pre>
</center></p>
<h2>Tunnel vocabulary</h2>
<ul>
@ -32,77 +45,105 @@ tunnels, which in turn passes it to Bob.</p>
<li><b>0-hop tunnel</b> - a tunnel where the gateway is also the endpoint</li>
<li><b>1-hop tunnel</b> - a tunnel where the gateway talks directly to the
endpoint</li>
<li><b>2-(or more)-hop tunnel</b> - a tunnel where there is at least one
<li><b>2-(or more)-hop tunnel</b> - a tunnel where there is at least one intermediate
tunnel participant. (the above diagram includes two 2-hop tunnels - one
outbound from Alice, one inbound to Bob)</li>
</ul>
</li>
<li class="gap"><b>Tunnel lifetime</b> - how long a particular tunnel is
supposed to be in operation for (each client specifies this when contacting
their router, and the router makes sure sufficient tunnels meeting that
criteria are built)</li>
<li class="gap"><b>Tunnel ID</b> - A <a href="common_structures_spec.html#type_TunnelId">4 byte integer</a>
different for each hop in a tunnel, and unique among all tunnels on a router.
Chosen randomly by the tunnel creator.</li>
</ul>
<h2>Tunnel information</h2>
<p>Routers performing the three roles (gateway, endpoint, participant) are given
different pieces of data to accomplish their tasks:</p>
<h2>Tunnel Build Information</h2>
<p>Routers performing the three roles (gateway, participant, endpoint) are given
different pieces of data in the initial
<a href="tunnel-alt-creation.html">Tunnel Build Message</a>
to accomplish their tasks:</p>
<ul>
<li class="gap"><b>The tunnel gateway gets:</b>
<ul>
<li><b>tunnel signing key</b> - a DSA private key for authenticating
messages sent down the tunnel</li>
<li><b>tunnel encryption key</b> - an AES private key for encrypting
messages and instructions to the endpoint</li>
<li><b>tunnel id</b> - 4 byte integer (each router can obviously only have
one tunnel with each tunnel id at any time)</li>
<li><b>next hop [optional]</b> - what router is the next one in the path</li>
<li><b>configuration key</b> - an AES private key used by the tunnel's
creator for updating the tunnel later on (if necessary)</li>
<li><b>tunnel encryption key</b> - an <a href="common_structures_spec.html#type_SessionKey">AES private key</a> for encrypting
messages and instructions to the next hop</li>
<li><b>tunnel IV key</b> - an <a href="common_structures_spec.html#type_SessionKey">AES private key</a> for double-encrypting
the IV to the next hop</li>
<li><b>reply key</b> - an <a href="common_structures_spec.html#type_SessionKey">AES public key</a> for encrypting
the reply to the tunnel build request</li>
<li><b>reply IV</b> - the IV for encrypting
the reply to the tunnel build request</li>
<li><b>tunnel id</b> - 4 byte integer (inbound gateways only)
</li>
<li><b>next hop</b> - what router is the next one in the path (unless this is a 0-hop tunnel, and the gateway is also the endpoint)</li>
<li><b>next tunnel id</b> - The tunnel ID on the next hop</li>
</ul>
</li>
<li class="gap"><b>All intermediate tunnel participants get:</b>
<ul>
<li><b>tunnel encryption key</b> - an <a href="common_structures_spec.html#type_SessionKey">AES private key</a> for encrypting
messages and instructions to the next hop</li>
<li><b>tunnel IV key</b> - an <a href="common_structures_spec.html#type_SessionKey">AES private key</a> for double-encrypting
the IV to the next hop</li>
<li><b>reply key</b> - an <a href="common_structures_spec.html#type_SessionKey">AES public key</a> for encrypting
the reply to the tunnel build request</li>
<li><b>reply IV</b> - the IV for encrypting
the reply to the tunnel build request</li>
<li><b>tunnel id</b> - 4 byte integer
</li>
<li><b>next hop</b> - what router is the next one in the path</li>
<li><b>next tunnel id</b> - The tunnel ID on the next hop</li>
</ul>
</li>
<li class="gap"> <b>The tunnel endpoint gets:</b>
<ul>
<li><b>tunnel verification key</b> - a DSA public key for authenticating
messages sent down the tunnel</li>
<li><b>tunnel encryption key</b> - an AES private key for decrypting
messages and instructions sent by the gateway</li>
<li><b>tunnel id</b> - 4 byte integer (each router can obviously only have
one tunnel with each tunnel id at any time)</li>
<li><b>configuration key</b> - an AES private key used by the tunnel's
creator for updating the tunnel later on (if necessary)</li>
</ul>
<li><b>tunnel encryption key</b> - an <a href="common_structures_spec.html#type_SessionKey">AES private key</a> for encrypting
messages and instructions to the the endpoint (itself)</li>
<li><b>tunnel IV key</b> - an <a href="common_structures_spec.html#type_SessionKey">AES private key</a> for double-encrypting
the IV to the endpoint (itself)</li>
<li><b>reply key</b> - an <a href="common_structures_spec.html#type_SessionKey">AES public key</a> for encrypting
the reply to the tunnel build request (outbound endpoints only)</li>
<li><b>reply IV</b> - the IV for encrypting
the reply to the tunnel build request (outbound endpoints only)</li>
<li><b>tunnel id</b> - 4 byte integer (outbound endpoints only)
</li>
<li class="gap"><b>All tunnel participants get:</b>
<ul>
<li><b>tunnel verification key</b> - a DSA public key for authenticating
messages sent down the tunnel</li>
<li><b>tunnel id</b> - 4 byte integer (each router can obviously only have
one tunnel with each tunnel id at any time)</li>
<li><b>next hop [optional]</b> - what router is the next one in the path</li>
<li><b>configuration key</b> - an AES private key used by the tunnel's
creator for updating the tunnel later on (if necessary)</li>
<li><b>reply router</b> - the inbound gateway of the tunnel to send the reply through (outbound endpoints only)</li>
<li><b>reply tunnel id</b> - The tunnel ID of the reply router (outbound endpoints only)</li>
</ul>
</li>
</ul>
<p>In addition, there are a series of options that the creator of a tunnel sends
when requesting a router to join a tunnel, such as the expiration date. In I2P
3.0, options specifying the pooling, mixing, and chaff generation settings will
be honored, and limits on the quantity and size of messages allowed during the
tunnel's lifetime will be implemented earlier (e.g. no more than 300 messages or
1MB per minute).</p>
<p>
Details are in the
<a href="tunnel-alt-creation.html">tunnel creation specification</a>.
</p>
<h2>Tunnel length</h2>
<h2>Tunnel pooling</h2>
<p>
Several tunnels for a particular purpose may be grouped into a "tunnel pool",
as described in the
<a href="tunnel-alt.html#tunnel.pooling">tunnel specification</a>.
This provides redundancy and additional bandwidth.
The pools used by the router itself are called "exploratory tunnels".
The pools used by applications are called "client tunnels".
</p>
<h2 id="length">Tunnel length</h2>
<p>As mentioned above, each client requests that their router provide tunnels to
include at least a certain number of hops (plus other criteria that aren't
honored yet, such as bandwidth limits, etc). The decision as to how many routers
include at least a certain number of hops.
The decision as to how many routers
to have in one's outbound and inbound tunnels has an important effect upon the
latency, throughput, reliability, and anonymity provided by I2P - the more peers
that messages have to go through, the longer it takes to get there and the more
likely that one of those routers will fail prematurely. The less routers in a
tunnel, the easier it is for an adversary to mount traffic analysis attacks and
pierce someone's anonymity.</p>
pierce someone's anonymity.
Tunnel lengths are specified by clients via
<a href="i2cp.html#options">I2CP options</a>.
The maximum number of hops in a tunnel is 7.
</p>
<h3>0-hop tunnels</h3>
<p>With no remote routers in a tunnel, the user has very basic plausible
@ -121,54 +162,92 @@ if the adversary ran a sufficient number of routers such that the single remote
router in the tunnel is often one of those compromised ones, they would be able
to mount the above statistical traffic analysis attack.</p>
<h3>2-hop (or more) tunnels</h3>
<h3>2-hop tunnels</h3>
<p>With two or more remote routers in a tunnel, the costs of mounting the traffic
analysis attack increases, since all remote routers would have to be compromised
analysis attack increases, since many remote routers would have to be compromised
to mount it.</p>
<p>The router will by default use <b>2-hop tunnels</b>, at least in the main
distribution. Prior to the 0.2.5 release, all tunnels were 1-hop by default.</p>
<h3>3-hop (or more) tunnels</h3>
To reduce the susceptibility to <a href="http://blog.torproject.org/blog/one-cell-enough">some attacks</a>,
3 or more hops are recommended for the highest level of protection.
<a href="http://blog.torproject.org/blog/one-cell-enough">recent studies</a>
also conclude that more than 3 hops does not provide additional protection.
<h2>Tunnel pooling</h2>
<p>[explain tunnel pools, how we keep a free inbound pool, an outbound pool, and
a client inbound pool, and how the pools are refreshed every minute or so, using
the router's default settings]</p>
<h2>Tunnel testing</h2>
<p>All tunnels are periodically tested by their creator by sending a
DeliveryStatusMessage out the tunnel and bound for another inbound tunnel
(testing both tunnels at once). If either fails, both are marked as no longer
functional, and if they were used for a client's inbound tunnel, a new leaseSet
is created. Other techniques can be used to test tunnels later on, such as
garlic wrapping a number of tests into cloves, testing individual tunnel
participants separately (and using the tunnel configuration key to update the
next hop to work around failures), etc, but that is not implemented at the
moment.
<h3>Tunnel default lengths</h3>
<p>The router uses 2-hop tunnels by default for its exploratory tunnels.
Client tunnel defaults are set by the application, using
<a href="i2cp.html#options">I2CP options</a>.
Most applications use 2 or 3 hops as their default.
</p>
<h2 id="testing">Tunnel testing</h2>
<p>All tunnels are periodically tested by their creator by sending a
DeliveryStatusMessage out an outbound tunnel and bound for another inbound tunnel
(testing both tunnels at once). If either fails a number of consecutive tests, it is marked as no longer
functional. If it was used for a client's inbound tunnel, a new leaseSet
is created.
Tunnel test failures are also reflected in the
<a href="how_peerselection.html#capacity">capacity rating in the peer profile</a>.
</p>
<h2>Tunnel creation</h2>
<p>Tunnel creation is handled by <a href="how_garlicrouting">garlic routing</a>
a TunnelCreateMessage to a router, requesting that they participate in the
a Tunnel Build Message to a router, requesting that they participate in the
tunnel (providing them with all of the appropriate information, as above, along
with a certificate, which right now is a 'null' cert, but will support hashcash
or other non-free certificates when necessary). The message also includes a
SourceRouteReplyBlock, which allows the router to encrypt their
TunnelCreateStatusMessage into a SourceRouteReplyMessage, which is sent to
another router (specified in the SourceRouteReplyBlock), who then decrypts the
rest of the SourceRouteReplyBlock, reads out the delivery instructions contained
therein, and forwards the TunnelCreateStatusMessage accordingly. (the delivery
instructions can specify delivery to a specific router or can point at a tunnel)
or other non-free certificates when necessary).
That router forwards the message to the next hop in the tunnel.
Details are in the
<a href="tunnel-alt-creation.html">tunnel creation specification</a>.
</p>
<h2>Issues/TODO</h2>
<h2>Tunnel encryption</h2>
<p>Multi-layer encryption is handled by <a href="how_garlicrouting">garlic encryption</a>
of tunnel messages.
Details are in the
<a href="tunnel-alt.html">tunnel specification</a>.
The IV of each hop is encrypted with a separate key as explained there.
</p>
<h2>Future Work</h2>
<ul><li>
Other tunnel test techniques could be used, such as
garlic wrapping a number of tests into cloves, testing individual tunnel
participants separately,
etc.
</li><li>
Move to 3-hop exploratory tunnels defaults.
</li><li>
In a distant future release,
options specifying the pooling, mixing, and chaff generation settings may be implemented.
</li><li>
In a distant future release,
limits on the quantity and size of messages allowed during the
tunnel's lifetime may be implemented (e.g. no more than 300 messages or
1MB per minute).
</li></ul>
<h2>See Also</h2>
<ul>
<li>We will assign unique tunnel IDs for each router in the tunnel, rather
than having a single ID across the whole tunnel. this would make traffic
analysis even harder</li>
<li>Get rid of the sourceRouteBlock stuff</li>
<li>Should inbound tunnels that will be used by clients ever be used for
general messages (network database, etc), rather than being free for use until
its allocated?</li>
<li>I2P 3.0 tunnel mixing / pooling details</li>
<li>Tunnel throttling details</li>
</ul>{% endblock %}
<li>
<a href="tunnel-alt.html">tunnel specification</a>
</li><li>
<a href="tunnel-alt-creation.html">tunnel creation specification</a>
</li><li>
<a href="tunnel_message_spec.html">tunnel message specification</a>
</li><li>
<a href="how_garlicrouting.html">garlic routing</a>
</li><li>
<a href="how_elgamalaes.html">ElGamal/AES+SessionTag</a>
</li><li>
<a href="i2cp.html#options">I2CP options</a>
</li>
</ul>
{% endblock %}

203
www.i2p2/pages/i2cp.html
View File

@ -1,6 +1,8 @@
{% extends "_layout.html" %}
{% block title %}I2CP{% endblock %}
{% block content %}
Updated September 2010, current as of router version 0.8
<p>The I2P Client Protocol (I2CP) exposes a strong separation of concerns between
the router and any client that wishes to communicate over the network. It enables
secure and asynchronous messaging by sending and receiving messages over a
@ -8,24 +10,29 @@ single TCP socket, yet never exposing any private keys and authenticating itself
to the router only through signatures. With I2CP, a client application tells the
router who they are (their "destination"), what anonymity, reliability, and
latency tradeoffs to make, and where to send messages. In turn the router uses
I2CP to tell the client when any messages have arrived, to request authorization
for some tunnels to be used, and, if necessary, to notify the client that the
router is under attack and unable to operate safely.</p>
I2CP to tell the client when any messages have arrived, and to request authorization
for some tunnels to be used.
</p>
<p>As the I2CP requires all client libraries to provide an implementation of the
end to end encryption (including <a href="how_elgamalaes">ElGamal/AES+SessionTag</a>),
the protocol itself isn't likely to be adopted for normal client applications
(except for those implemented in Java that can use the existing I2P
<a href="package-client.html">Client SDK</a>).
<p>
The protocol itself has only been implemented in Java, to provide the
<a href="package-client.html">Client SDK</a>.
This SDK is exposed in the i2p.jar package, which implements the client-side of I2CP.
Clients should never need to access the router.jar package, which contains the
router itself and the router-side of I2CP.
</p>
<p>
While implementing the client side of I2CP in a non-Java language is certainly feasible,
a non-Java client would also have to implement the
<a href="streaming.html">streaming library</a> for TCP-style connections.
Together, implementing I2CP and the streaming library would be a sizable task.
</p>
<p>
Applications can take advantage of the base I2CP plus the
<a href="ministreaming">streaming</a> and <a href="datagrams">datagram</a> libraries
by using the <a href="sam">Simple Anonymous Messaging</a> or BOB protocols,
by using the <a href="sam">Simple Anonymous Messaging</a> or <a href="bob.html">BOB</a> protocols,
which do not require clients to deal with any sort of cryptography.
Also, clients may access the network by one of several proxies -
HTTP, CONNECT, and SOCKS 4/4a/5.
@ -33,21 +40,13 @@ Alternatively, Java clients may access those libraries in ministreaming.jar and
So there are several options for both Java and non-Java applications.
</p>
<p>I2CP end-to-end encryption was disabled in I2P release 0.6,
leaving in place the end-to-end garlic encryption.
However, client libraries must still implement public/private key signing
for LeaseSets, and key management.
</p>
<p>While the I2CP has been quite stable since its inception in
August of 2003, there have been several messages added.
Here is the
<a href="/_static/pdf/I2CP_spec.pdf">I2CP Protocol Specification Version 0.9</a>
(PDF) dated August 28, 2003.
That document also references the
<a href="/_static/pdf/datastructures.pdf">Common Data Structures Specification Version 0.9</a>.
There have been several changes to the protocol since that time,
and many of the messages in those documents were never implemented.
<p>Client-side end-to-end encryption (encrypting the data over the I2CP connection)
was disabled in I2P release 0.6,
leaving in place the <a href="how_elgamalaes.html">ElGamal/AES end-to-end encryption</a>
which is implemented in the router.
The only cryptography that client libraries must still implement is
<a href="how_cryptography.html#DSA">DSA public/private key signing</a>
for <a href="i2cp_spec.html#msg_CreateLeaseSet">LeaseSets</a> and <a href="i2cp_spec.html#type_SessionConfig">Session Configurations</a>, and management of those keys.
</p>
<p>In a standard I2P installation, port 7654 is used by java clients to communicate
@ -56,113 +55,26 @@ By default, the router binds to address 127.0.0.1. To bind to 0.0.0.0, set the
router advanced configuration option <tt>i2cp.tcp.bindAllInterfaces=true</tt> and restart.
</p>
<h2>I2CP Definition</h2>
<h2>I2CP Protocol Specification</h2>
<p>
<i>Note</i> - The following information is extracted from the current code base,
however it may be incomplete and/or inaccurate. Check the code to be sure.
Rather than completely document the messages here, we refer you to the
old protocol and data specifications linked above, together with the actual code.
<p>
R-&gt;C is Router to Client;
C-&gt;R is Client to Router
<p>
<table border=1>
<tr><th>Message<th>Direction<th>Type
<tr><td>
BandwidthLimitsMessage <i>(new in release 0.7.2)</i>
<td align="center">R-&gt;C
<td align=right>23
<tr><td>
CreateLeaseSetMessage
<td align="center">C-&gt;R
<td align=right>4
<tr><td>
CreateSessionMessage
<td align="center">C-&gt;R
<td align=right>1
<tr><td>
DestLookupMessage <i>(new in release 0.7)</i>
<td align="center">C-&gt;R
<td align=right>34
<tr><td>
DestReplyMessage <i>(new in release 0.7)</i>
<td align="center">R-&gt;C
<td align=right>35
<tr><td>
DestroySessionMessage
<td align="center">C-&gt;R
<td align=right>3
<tr><td>
DisconnectMessage
<td align="center">R-&gt;C
<td align=right>30
<tr><td>
GetBandwidthLimitsMessage <i>(new in release 0.7.2)</i>
<td align="center">C-&gt;R
<td align=right>8
<tr><td>
GetDateMessage
<td align="center">C-&gt;R
<td align=right>32
<tr><td>
MessagePayloadMessage
<td align="center">R-&gt;C
<td align=right>31
<tr><td>
MessageStatusMessage
<td align="center">R-&gt;C
<td align=right>22
<tr><td>
ReceiveMessageBeginMessage
<td align="center">R-&gt;C
<td align=right>6
<tr><td>
ReceiveMessageEndMessage
<td align="center">C-&gt;R
<td align=right>7
<tr><td>
ReconfigureSessionMessage <i>(new in release 0.7.1)</i>
<td align="center">C-&gt;R
<td align=right>2
<tr><td>
ReportAbuseMessage
<td align="center">R-&gt;C
<td align=right>29
<tr><td>
RequestLeaseSetMessage
<td align="center">R-&gt;C
<td align=right>21
<tr><td>
SendMessageExpiresMessage <i>(new in release 0.7.1)</i>
<td align="center">C-&gt;R
<td align=right>36
<tr><td>
SendMessageMessage
<td align="center">C-&gt;R
<td align=right>5
<tr><td>
SessionStatusMessage
<td align="center">R-&gt;C
<td align=right>20
<tr><td>
SetDateMessage
<td align="center">R-&gt;C
<td align=right>33
</table>
Now on the
<a href="i2cp_spec.html">I2CP Specification page</a>.
</p>
<h2>I2CP Initialization</h2>
<p>
When a client connects to the router, it first sends a single protocol version byte (0x2A).
Then it sends a GetDateMessage and waits for the SetDateMessage response.
Next, it sends a CreateSessionMessage containing the session configuration.
It next awaits a RequestLeaseSetMessage from the router, indicating that inbound tunnels
Then it sends a <a href="i2cp_spec.html#msg_GetDate">GetDate Message</a> and waits for the <a href="i2cp_spec.html#msg_GetDate">SetDate Message</a> response.
Next, it sends a <a href="i2cp_spec.html#msg_GetDate">CreateSession Message</a> containing the session configuration.
It next awaits a <a href="i2cp_spec.html#msg_GetDate">RequestLeaseSet Message</a> from the router, indicating that inbound tunnels
have been built, and responds with a CreateLeaseSetMessage containing the signed LeaseSet.
The client may now initiate or receive connections from other I2P destinations.
<h2 id="options">I2CP Options</h2>
<p>
The following options are traditionally passed to the router via
a SessionConfig contained in a CreateSessionMessage or a ReconfigureSessionMessage.
a <a href="i2cp_spec.html#type_SessionConfig">SessionConfig</a> contained in a <a href="i2cp_spec.html#msg_CreateSession">CreateSession Message</a> or a <a href="i2cp_spec.html#msg_ReconfigureSession">ReconfigureSession Message</a>.
<p>
<table border=1>
<tr><th>Option <th>Recommended Arguments <th>Allowable Range<th>Default<th>Description
@ -194,6 +106,7 @@ a SessionConfig contained in a CreateSessionMessage or a ReconfigureSessionMessa
<tr><td>i2cp.dontPublishLeaseSet <td>true, false<td>&nbsp;<td>false<td>Should generally be set to true for clients
and false for servers
<tr><td>i2cp.messageReliability <td>&nbsp;<td>BestEffort, Guaranteed<td>BestEffort<td>Guaranteed is disabled
<tr><td>explicitPeers<td>&nbsp;<td>&nbsp;<td>null<td>Comma-separated list of Base 64 Hashes of peers to build tunnels through; for debugging only
</table>
<p>
Note: Large quantity, length, or variance settings may cause significant performance or reliability problems.
@ -225,7 +138,7 @@ Note: All arguments, including numbers, are strings. True/false values are case-
Anything other than case-insensitive "true" is interpreted as false.
All option names are case-sensitive.
<h2 id="format">I2CP Data Format and Multiplexing</h2>
<h2 id="format">I2CP Payload Data Format and Multiplexing</h2>
<p>
The end-to-end messages handled by I2CP (i.e. the data sent by the client in a SendMessageMessage and
received by the client in a MessagePayloadMessage) is gzipped with a standard 10-byte gzip
@ -249,5 +162,53 @@ turns the gzip effort setting to 0, which may save a little CPU.
<tr><td>9<td>I2P Protocol (6 = Streaming, 17 = Datagram) (Gzip OS)
</table>
<p>
Data integrity is verified with the standard gzip CRC-32 as
specified by <a href="http://www.ietf.org/rfc/rfc1952.txt">RFC 1952</a>.
</p>
<h2 id="future">Future Work</h2>
<ul><li>
There is an in-JVM version of I2CP that uses a Java pipe instead of real sockets.
However, it still does message serialization and deserialization.
It should be refactored to pass the Message objects directly.
</li><li>
The protocol is highly inefficient, with three I2CP messages for every outgoing message,
and four I2CP messages for every incoming message.
Perhaps the acknowledgments and queueing could be eliminated, especially for the in-JVM version.
This would eliminate a lot of data structures and memory for holding
unacknowledged messages.
</li><li>
Implement i2cp.messageReliablity=none to disable the two Message Status Message responses
to a Send Message Message.
Make it the default? At least via the streaming lib.
</li><li>
The API does not support Dest Lookups or Get Bandwidth Limits Messages in a standard session,
only in a simple session.
This should be fixed.
</li><li>
The API does not support parallel Dest Lookups or Get Bandwidth Limits Messages in a session.
This should be fixed.
</li><li>
Implement I2CP and the streaming library in another programming language.
</li><li>
Is the initial Get Date / Set Date handshake required?
</li><li>
There is currently no authorization mechanism.
This would be required on the socket version only, not in the in-JVM version.
</li><li>
Private Keys are included in the Create Lease Set message,
are they really required? Revocation is unimplemented.
</li><li>
Some improvements may be able to use messages previously defined but not implemented.
For reference, here is the
<a href="/_static/pdf/I2CP_spec.pdf">I2CP Protocol Specification Version 0.9</a>
(PDF) dated August 28, 2003.
That document also references the
<a href="/_static/pdf/datastructures.pdf">Common Data Structures Specification Version 0.9</a>.
</li></ul>
{% endblock %}

876
www.i2p2/pages/i2cp_spec.html Normal file
View File

@ -0,0 +1,876 @@
{% extends "_layout.html" %}
{% block title %}I2CP Specification{% endblock %}
{% block content %}
Updated September 2010, current as of router version 0.8
<h1>I2P Control Protocol (I2CP) Specification</h1>
<h2>Overview</h2>
<p>
This page specified the I2P Control Protocol (I2CP),
which is the interface between clients and the router.
Java clients will use the I2CP client API, which implements this protocol.
Non-Java clients will most likely use a higher-layer protocol
such as SAM or BOB.
More information is on the <a href="i2cp.html">I2CP Overview page</a>.
</p>
<h2>Sessions</h2>
<p>
The protocol was designed to handle multiple "sessions", each with a 2-byte session ID,
over a single TCP connection.
This does not appear to be fully implemented.
Do not attempt to use multiple sessions on a single I2CP connection.
</p>
<p>
It also appears that there are some provisions for a single client to talk to multiple
routers over separate connections. This is also untested,
and probably not useful.
</p>
<p>
It does not appear that there is currently a way for a session to be
maintained after a disconnect, or to be
recovered on a different
I2CP connection.
</p>
<h2>Example Message Sequences</h2>
<h3>Standard Session Establish</h3>
<pre>
{% filter escape %}
Client Router
---------------------> Protocol Byte (0x2a)
---------------------> Get Date Message
Set Date Message <---------------------
---------------------> Create Session Message
Session Status Message <---------------------
Request LeaseSet Message <---------------------
---------------------> Create LeaseSet Message
{% endfilter %}
</pre>
<h3>Get Bandwidth Limits (Simple Session)</h3>
<pre>
{% filter escape %}
Client Router
---------------------> Protocol Byte (0x2a)
---------------------> Get Bandwidth Limits Message
Bandwidth Limits Message <---------------------
{% endfilter %}
</pre>
<h3>Destination Lookup (Simple Session)</h3>
<pre>
{% filter escape %}
Client Router
---------------------> Protocol Byte (0x2a)
---------------------> Dest Lookup Message
Dest Reply Message <---------------------
{% endfilter %}
</pre>
<h3>Outgoing Message</h3>
<p>(existing session)</p>
<pre>
{% filter escape %}
Client Router
---------------------> Send Message Message
Message Status Message <---------------------
(accepted)
Message Status Message <---------------------
(succeeded)
{% endfilter %}
</pre>
<h3>Incoming Message</h3>
<p>(existing session)</p>
<pre>
{% filter escape %}
Client Router
Message Status Message <---------------------
(available)
---------------------> Receive Message Begin Message
Message Payload Message <---------------------
---------------------> Receive Message End Message
{% endfilter %}
</pre>
<h2 id="structures">Common structures</h2>
<h3 id="struct_header">I2CP message header</h3>
<h4>Description</h4>
<p>
Common header to all I2CP messages, containing the message length and message type.
</p>
<h4>Contents</h4>
<ol><li>
4 byte <a href="common_structures_spec#type_Integer">Integer</a> specifying the length of the message body
</li><li>
1 byte <a href="common_structures_spec#type_Integer">Integer</a> specifying the message type.
</li><li>
The I2CP message body, 0 or more bytes
</li></ol>
<h4>Notes</h4>
<p>
Actual message length limit is about 64 KB.
</p>
<h3 id="struct_MessageId">Message ID</h3>
<h4>Description</h4>
<p>
Uniquely identifies a message waiting on a particular router at a
point in time.
</p>
<h4>Contents</h4>
<ol><li>
4 byte <a href="common_structures_spec#type_Integer">Integer</a>
</li></ol>
<h4>Notes</h4>
<p>
Message IDs are unique within a session only; they are not globally unique.
</p>
<h3 id="struct_Payload">Payload</h3>
<h4>Description</h4>
<p>
This structure is the content of a message being delivered from one
Destination to another.
</p>
<h4>Contents</h4>
<ol><li>
4 byte <a href="common_structures_spec#type_Integer">Integer</a> length
</li><li>
That many bytes
</li></ol>
<h4>Notes</h4>
<p>
The payload is in a gzip format as specified on the
<a href="i2cp.html#format">I2CP Overview page</a>.
</p>
<h3 id="struct_SessionConfig">Session Config</h3>
<h4>Description</h4>
<p>
Defines the configuration options for a particular client session.
</p>
<h4>Contents</h4>
<ol><li>
<a href="common_structures_spec#struct_Destination">Destination</a>
</li><li>
<a href="common_structures_spec#type_Mapping">Mapping</a> of options
</li><li>
Creation <a href="common_structures_spec#type_Date">Date</a>
</li><li>
DSA <a href="common_structures_spec#type_Signature">Signature</a> of the previous 3 fields, signed by the
<a href="common_structures_spec#type_SigningPrivateKey">Signing Private Key</a>
</li></ol>
<h4>Notes</h4>
<p>
The options are specified on the
<a href="i2cp.html#options">I2CP Overview page</a>.
</p>
<h3 id="struct_SessionId">Session ID</h3>
<h4>Description</h4>
<p>
Uniquely identifies a session on a particular router at a point in
time.
</p>
<h4>Contents</h4>
<ol><li>
2 byte <a href="common_structures_spec#type_Integer">Integer</a>
</li></ol>
<h4>Notes</h4>
<p>
</p>
<h2 id="messages">Messages</h2>
<h3 id="types">Message Types</h3>
<table border=1>
<tr><th>Message<th>Direction<th>Type
<tr><td>
<a href="#msg_BandwidthLimits">
BandwidthLimitsMessage
</a>
</a>
<td align="center">R-&gt;C
<td align=right>23
<tr><td>
<a href="#msg_CreateLeaseSet">
CreateLeaseSetMessage
</a>
<td align="center">C-&gt;R
<td align=right>4
<tr><td>
<a href="#msg_CreateSession">
CreateSessionMessage
</a>
<td align="center">C-&gt;R
<td align=right>1
<tr><td>
<a href="#msg_DestLookup">
DestLookupMessage
</a>
<td align="center">C-&gt;R
<td align=right>34
<tr><td>
<a href="#msg_DestReply">
DestReplyMessage
</a>
<td align="center">R-&gt;C
<td align=right>35
<tr><td>
<a href="#msg_DestroySession">
DestroySessionMessage
</a>
<td align="center">C-&gt;R
<td align=right>3
<tr><td>
<a href="#msg_Disconnect">
DisconnectMessage
</a>
<td align="center">bidir.
<td align=right>30
<tr><td>
<a href="#msg_GetBandwidthLimits">
GetBandwidthLimitsMessage
</a>
<td align="center">C-&gt;R
<td align=right>8
<tr><td>
<a href="#msg_GetDate">
GetDateMessage
</a>
<td align="center">C-&gt;R
<td align=right>32
<tr><td>
<a href="#msg_MessagePayload">
MessagePayloadMessage
</a>
<td align="center">R-&gt;C
<td align=right>31
<tr><td>
<a href="#msg_MessageStatus">
MessageStatusMessage
</a>
<td align="center">R-&gt;C
<td align=right>22
<tr><td>
<a href="#msg_ReceiveMessageBegin">
ReceiveMessageBeginMessage
</a>
<td align="center">C-&gt;R
<td align=right>6
<tr><td>
<a href="#msg_ReceiveMessageEnd">
ReceiveMessageEndMessage
</a>
<td align="center">C-&gt;R
<td align=right>7
<tr><td>
<a href="#msg_ReconfigureSession">
ReconfigureSessionMessage
</a>
<td align="center">C-&gt;R
<td align=right>2
<tr><td>
<a href="#msg_ReportAbuse">
ReportAbuseMessage
</a>
<td align="center">bidir.
<td align=right>29
<tr><td>
<a href="#msg_RequestLeaseSet">
RequestLeaseSetMessage
</a>
<td align="center">R-&gt;C
<td align=right>21
<tr><td>
<a href="#msg_SendMessage">
SendMessageMessage
</a>
<td align="center">C-&gt;R
<td align=right>5
<tr><td>
<a href="#msg_SendMessageExpires">
SendMessageExpiresMessage
</a>
<td align="center">C-&gt;R
<td align=right>36
<tr><td>
<a href="#msg_SessionStatus">
SessionStatusMessage
</a>
<td align="center">R-&gt;C
<td align=right>20
<tr><td>
<a href="#msg_SetDate">
SetDateMessage
</a>
<td align="center">R-&gt;C
<td align=right>33
</table>
<h3 id="msg_BandwidthLimits">Bandwidth Limits</h3>
<h4>Description</h4>
<p>
Tell the client what the bandwidth limits are.
Sent from Router to Client in response to a Get Bandwidth Limits Message.
</p>
<h4>Contents</h4>
<ol><li>
4 byte <a href="common_structures_spec#type_Integer">Integer</a>
Client inbound limit (KBps)
</li><li>
4 byte <a href="common_structures_spec#type_Integer">Integer</a>
Client outbound limit (KBps)
</li><li>
4 byte <a href="common_structures_spec#type_Integer">Integer</a>
Router inbound limit (KBps)
</li><li>
4 byte <a href="common_structures_spec#type_Integer">Integer</a>
Router inbound burst limit (KBps)
</li><li>
4 byte <a href="common_structures_spec#type_Integer">Integer</a>
Router outbound limit (KBps)
</li><li>
4 byte <a href="common_structures_spec#type_Integer">Integer</a>
Router outbound burst limit (KBps)
</li><li>
4 byte <a href="common_structures_spec#type_Integer">Integer</a>
Router burst time (seconds)
</li><li>
Nine 4-byte <a href="common_structures_spec#type_Integer">Integers</a>
undefined
</li></ol>
<h4>Notes</h4>
<p>
Currently, the client limits are the only values set,
and are actually the router limits. All the values labeled as router limits are always 0.
As of release 0.7.2.
</p>
<h3 id="msg_CreateLeaseSet">Create Lease Set</h3>
<h4>Description</h4>
<p>
This message is sent in response to a RequestLeaseSetMessage and contains all
of the Lease structures that should be published to the I2NP Network Database.
Sent from Client to Router.
</p>
<h4>Contents</h4>
<ol><li>
<a href="#struct_SessionId">Session ID</a>
</li><li>
<a href="common_structures_spec#type_SigningPrivateKey">Signing Private Key</a>
</li><li>
<a href="common_structures_spec#type_PrivateKey">Private Key</a>
</li><li>
<a href="common_structures_spec#struct_LeaseSet">LeaseSet</a>
</li></ol>
<h4>Notes</h4>
<p>
The SigningPrivateKey matches the SigningPublicKey from within the
LeaseSet, as does the PrivateKey with the PublicKey. The Signing keys are
necessary to allow the router to revoke the LeaseSet if the client goes offline,
and the normal keys are necessary for decrypting garlic routed messages. The
LeaseSet granted may include Lease structures for tunnels pointing at another
router if the client is actively connected to multiple routers with Leases granted
to each.
Really?
Revocation is unimplemented.
Connection to multiple routers is untested.
</p>
<h3 id="msg_CreateSession">Create Session</h3>
<h4>Description</h4>
<p>
This message is sent from a client to initiate a session, where a session is defined
as a single Destination's connection to the network, to which all messages for
that Destination will be delivered and from which all messages that
Destination sends to any other Destination will be sent through.
Sent from Client to Router.
The router responds with a <a href="#msg_SessionStatus">Session Status Message</a>.
</p>
<h4>Contents</h4>
<ol><li>
<a href="#struct_SessionConfig">Session Config</a>
</li></ol>
<h4>Notes</h4>
<p>
The second message sent by the client after sending the Get Date Message and receiving the Set Date Message response.
If the Date in the Session Config is too far from the router's current time, the session will be rejected.
If there is already a session on the router for this Destination, the session will be rejected.
</p>
<h3 id="msg_DestLookup">Dest Lookup</h3>
<h4>Description</h4>
<p>
Sent from Client to Router.
The router responds with a <a href="#msg_DestReply">Dest Reply Message</a>.
</p>
<h4>Contents</h4>
<ol><li>
<a href="common_structures_spec#struct_Hash">SHA-256 Hash</a>
</li></ol>
<h4>Notes</h4>
<p>
Only one Dest Lookup may be outstanding at a time.
Currently supported only by client sessions set up with I2PSimpleSession.
These limitations should be fixed.
As of release 0.7.
</p>
<h3 id="msg_DestReply">Dest Reply</h3>
<h4>Description</h4>
<p>
Sent from Router to Client in response to a Dest Lookup Message.
</p>
<h4>Contents</h4>
<ol><li>
<a href="common_structures_spec#struct_Destination">Destination</a> (optional)
</li></ol>
<h4>Notes</h4>
<p>
If the Destination is not present, the lookup failed.
As of release 0.7.
In the future,
we should return the Hash instead of nothing if the lookup failed,
so we can have multiple lookups outstanding and correlate the replies.
</p>
<h3 id="msg_Destroy Session">Destroy Session</h3>
<h4>Description</h4>
<p>
This message is sent from a client to destroy a session.
Sent from Client to Router.
The router responds with a <a href="#msg_SessionStatus">Session Status Message</a>.
</p>
<h4>Contents</h4>
<ol><li>
<a href="#struct_SessionId">Session ID</a>
</li></ol>
<h4>Notes</h4>
<p>
The router at this point should release all resources related to the session.
</p>
<h3 id="msg_Disconnect">Disconnect</h3>
<h4>Description</h4>
<p>
Tell the other party that there are problems and the current connection is about to
be destroyed. This does not necessarily end a session.
Sent either from router to client or from client to router.
</p>
<h4>Contents</h4>
<ol><li>
Reason <a href="common_structures_spec#struct_String">String</a>
</li></ol>
<h4>Notes</h4>
<p>
Only implemented in the router-to-client direction.
Disconnecting probably does end a session, in practice.
</p>
<h3 id="msg_GetBandwidthLimits">Get Bandwidth Limits</h3>
<h4>Description</h4>
<p>
Request that the router state what its current bandwidth limits are.
Sent from Client to Router.
The router responds with a <a href="#msg_BandwidthLimits">Bandwidth Limits Message</a>.
</p>
<h4>Contents</h4>
<i>None</i>
<h4>Notes</h4>
<p>
Currently supported only by client sessions set up with I2PSimpleSession.
These limitations should be fixed.
As of release 0.7.2.
</p>
<h3 id="msg_GetDate">Get Date</h3>
<h4>Description</h4>
<p>
Sent from Client to Router.
The router responds with a <a href="#msg_SetDate">Set Date Message</a>.
</p>
<h4>Contents</h4>
<i>None</i>
<h4>Notes</h4>
<p>
Generally the first message sent by the client after sending the protocol version byte.
</p>
<h3 id="msg_MessagePayload">Message Payload</h3>
<h4>Description</h4>
<p>
Deliver the payload of a message to the client.
Sent from Router to Client.
The client responds with a <a href="#msg_ReceiveMessageEnd">Receive Message End Message</a>.
</p>
<h4>Contents</h4>
<ol><li>
<a href="#struct_SessionId">Session ID</a>
</li><li>
<a href="#struct_MessageId">Message ID</a>
</li><li>
<a href="#struct_Payload">Payload</a>
</li></ol>
<h4>Notes</h4>
<p>
</p>
<h3 id="msg_MessageStatus">Message Status</h3>
<h4>Description</h4>
<p>
Notify the client of the delivery status of an incoming or outgoing message.
Sent from Router to Client.
If this message indicates that an incoming message is available,
the client responds with a <a href="#msg_ReceiveMessageBegin">Receive Message Begin Message</a>.
For an outgoing message, this is a response to a
<a href="#msg_SendMessage">Send Message Message</a> or
<a href="#msg_SendMessageExpires">Send Message Expires Message</a>.
</p>
<h4>Contents</h4>
<ol><li>
<a href="#struct_SessionId">Session ID</a>
</li><li>
<a href="#struct_MessageId">Message ID</a>
</li><li>
1 byte <a href="common_structures_spec#type_Integer">Integer</a> status
</li><li>
4 byte <a href="common_structures_spec#type_Integer">Integer</a> size
</li><li>
4 byte <a href="common_structures_spec#type_Integer">Integer</a> nonce
</li></ol>
<h4>Notes</h4>
<p>
The known status values are 0 for message is available, 1 for accepted, 2 for best
effort succeeded, 3 for best effort failed, 4 for guaranteed succeeded, 5 for
guaranteed failed. The size Integer specifies the size of the available
message and is only relevant for status = 0.
Even though guaranteed is unimplemented, (best effort is the only service), the current
router implementation uses the guaranteed status codes, not the best effort codes.
</p>
<p>
When status = 1 (accepted), the nonce matches the nonce in the
Send Message Message, and the included Message ID
will be used for subsequent success or failure notification.
Otherwise, the nonce may be ignored.
</p>
<h3 id="msg_ReceiveMessageBegin">Receive Message Begin</h3>
<h4>Description</h4>
<p>
Request the router to deliver a message that it was previously notified of.
Sent from Client to Router.
The router responds with a <a href="#msg_MessagePayload">Message Payload Message</a>.
</p>
<h4>Contents</h4>
<ol><li>
<a href="#struct_SessionId">Session ID</a>
</li><li>
<a href="#struct_MessageId">Message ID</a>
</li></ol>
<h4>Notes</h4>
<p>
The ReceiveMessageBeginMessage is sent as a response to a
MessageStatusMessage stating that a new message is available for pickup. If the
message id specified in the ReceiveMessageBeginMessage is invalid or
incorrect, the router may simply not reply, or it may send back a
DisconnectMessage.
</p>
<h3 id="msg_ReceiveMessageEnd">Receive Message End</h3>
<h4>Description</h4>
<p>
Tell the router that delivery of a message was completed successfully and that
the router can discard the message.
Sent from Client to Router.
</p>
<h4>Contents</h4>
<ol><li>
<a href="#struct_SessionId">Session ID</a>
</li><li>
<a href="#struct_MessageId">Message ID</a>
</li></ol>
<h4>Notes</h4>
<p>
The ReceiveMessageBeginMessage is sent after a MessagePayloadMessage fully
delivers a message's payload.
</p>
<h3 id="msg_RecconfigureSession">Reconfigure Session</h3>
<h4>Description</h4>
<p>
Sent from Client to Router to update the session configuration.
The router responds with a <a href="#msg_SessionStatus">Session Status Message</a>.
</p>
<h4>Contents</h4>
<ol><li>
<a href="#struct_SessionId">Session ID</a>
</li><li>
<a href="#struct_SessionConfig">Session Config</a>
</li></ol>
<h4>Notes</h4>
<p>
As of release 0.7.1.
</p>
<h3 id="msg_ReportAbuse">Report Abuse</h3>
<h4>Description</h4>
<p>
Tell the other party (client or router) that they are under attack, potentially with reference to a
particular messageId. If the router is under attack, the client may decide to
migrate to another router, and if a client is under attack, the router may rebuild
its routers or shitlist some of the peers that sent it messages delivering the attack.
Sent either from router to client or from client to router.
</p>
<h4>Contents</h4>
<ol><li>
<a href="#struct_SessionId">Session ID</a>
</li><li>
1 byte <a href="common_structures_spec#type_Integer">Integer</a> abuse severity
(0 is minimally abusive, 255 being extremely abusive)
</li><li>
Reason <a href="common_structures_spec#struct_String">String</a>
</li><li>
<a href="#struct_MessageId">Message ID</a>
</li></ol>
<h4>Notes</h4>
<p>
Unused.
Not fully implemented. Both router and client can generate Report Abuse Messages,
but neither has a handler for the message when received.
</p>
<h3 id="msg_RequestLeaseSet">Request LeaseSet</h3>
<h4>Description</h4>
<p>
Request that a client authorize the inclusion of a particular set of inbound tunnels.
Sent from Router to Client.
The client responds with a <a href="#msg_SessionStatus">Create LeaseSet Message</a>.
</p>
<h4>Contents</h4>
<ol><li>
<a href="#struct_SessionId">Session ID</a>
</li><li>
1 byte <a href="common_structures_spec#type_Integer">Integer</a> number of tunnels
</li><li>
That many pairs of:
<ol><li>
<a href="common_structures_spec#struct_RouterIdentity">Router Identity</a>
</li><li>
<a href="common_structures_spec#type_TunnelId">Tunnel ID</a>
</li></ol>
</li><li>
End <a href="common_structures_spec#type_Date">Date</a>
</li></ol>
<h4>Notes</h4>
<p>
</p>
<h3 id="msg_SendMessage">Send Message</h3>
<h4>Description</h4>
<p>
This is how a client sends a message (the payload) to the Destination.
The router will use a default expiration.
Sent from Client to Router.
The router responds with a <a href="#msg_MessageStatus">Message Status Message</a>.
</p>
<h4>Contents</h4>
<ol><li>
<a href="#struct_SessionId">Session ID</a>
</li><li>
<a href="common_structures_spec#struct_Destination">Destination</a>
</li><li>
<a href="#struct_Payload">Payload</a>
</li><li>
4 byte <a href="common_structures_spec#type_Integer">Integer</a> nonce
</li></ol>
<h4>Notes</h4>
<p>
As soon as the SendMessageMessage arrives fully intact, the router should return
a MessageStatusMessage stating that it has been accepted for delivery.
That message will contain the same nonce sent here.
Later on,
based on the delivery guarantees of the session configuration, the router may
additionally send back another MessageStatusMessage updating the status.
</p>
<h3 id="msg_SendMessageExpires">Send Message Expires</h3>
<h4>Description</h4>
<p>
Sent from Client to Router. Same as Send Message Message, except includes an expiration.
</p>
<h4>Contents</h4>
<ol><li>
<a href="#struct_SessionId">Session ID</a>
</li><li>
<a href="common_structures_spec#struct_Destination">Destination</a>
</li><li>
<a href="#struct_Payload">Payload</a>
</li><li>
4 byte <a href="common_structures_spec#type_Integer">Integer</a> nonce
</li><li>
Expiration <a href="common_structures_spec#type_Date">Date</a>
</li></ol>
<h4>Notes</h4>
<p>
As of release 0.7.1.
</p>
<h3 id="msg_SessionStatus">Session Status</h3>
<h4>Description</h4>
<p>
Instruct the client as to the status of its session.
Sent from Router to Client.
</p>
<h4>Contents</h4>
<ol><li>
<a href="#struct_SessionId">Session ID</a>
</li><li>
1 byte <a href="common_structures_spec#type_Integer">Integer</a> status
</li></ol>
<h4>Notes</h4>
<p>
Status values include 0 for destroyed, 1 for created, 2 for updated, and
3 for invalid session.
If created, the Session ID is the identifier to be used for the rest of the session.
</p>
<h3 id="msg_SetDate">Set Date</h3>
<h4>Description</h4>
<p>
The current date and time.
Sent from Router to Client as a part of the initial handshake.
</p>
<h4>Contents</h4>
<ol><li>
<a href="common_structures_spec#type_Date">Date</a>
</li></ol>
<h4>Notes</h4>
<p>
This is generally the first message sent by the router.
</p>
{% endblock %}

11
www.i2p2/pages/i2np.html
View File

@ -27,11 +27,6 @@ These are global queues for all peers.
NTCP has a trivial linear search for the highest priority within
each buffer for a particular peer.
This is much less effective.
<p>
It isn't clear whether the current priority scheme is generally effective,
and whether the priorities for various messages should be adjusted further.
This is a topic for further research, analysis and testing.
<h3>Message Format</h3>
<p>
@ -178,4 +173,10 @@ Others listed in
See also the
<a href="common_structures_spec.html">Common Data Structure Specification page</a>.
<h3>Future Work</h3>
<p>
It isn't clear whether the current priority scheme is generally effective,
and whether the priorities for various messages should be adjusted further.
This is a topic for further research, analysis and testing.
{% endblock %}

103
www.i2p2/pages/i2np_spec.html
View File

@ -132,20 +132,36 @@ Cleartext:
| reply_iv |
+ +
| |
+----+----+----+----+----+----+----+----+----+
|flag| request_time | send_message_id |
+----+----+----+----+----+----+----+----+----+
| padding...
+----+----+----+--//
+----+----+----+----+----+----+----+----+
|flag| request_time | send_msg_id
+----+----+----+----+----+----+----+----+
| |
+----+ +
| 29 bytes padding |
+ +
| |
+ +----+----+
| |
+----+----+----+----+----+----+
encrypted:
ElGamal encrypted:
+----+----+----+----+----+----+----+----+
| toPeer |
+ +
| |
+----+----+----+----+----+----+----+----+
| encrypted data ... |
~ ~
| |
+----+----+----+----+----+----+----+----+
ElGamal and AES encrypted:
+----+----+----+----+----+----+----+----+
| encrypted data ... |
~ ~
| |
+----+----+----+----+----+----+----+----+
{% endfilter %}
</pre>
@ -190,27 +206,41 @@ send_message_id :: Integer
padding :: Data
length -> 29 bytes
source -> random
total length: 222
encrypted:
toPeer :: Hash
ElGamal encrypted:
toPeer :: First 16 bytes of the SHA-256 Hash of the peer's router identity
length -> 16 bytes
encrypted_data :: ElGamal-2048 encrypted data
encrypted_data :: ElGamal-2048 encrypted data (see notes)
length -> 512
total length: 528
ElGamal and AES encrypted:
encrypted_data :: ElGamal and AES encrypted data
length -> 528
total length: 528
{% endfilter %}
</pre>
<h4>Notes</h4>
<p>
<ul><li>
In the 512-byte encrypted record,
the ElGamal data contains bytes 1-256 and 258-513 of the
<a href="how_cryptography.html#elgamal">514-byte ElGamal encrypted block</a>.
The two padding bytes from the block (the zero bytes at locations 0 and 257) are removed.
</li><li>
See also the <a href="tunnel-alt-creation.html">tunnel creation specification</a>.
</li></ul>
</p>
@ -220,7 +250,7 @@ total length: 528
unencrypted:
+----+----+----+----+----+----+----+----+
| random data... |
~ ~
| |
+ +----+
| |ret |
@ -235,7 +265,7 @@ bytes 0-526: random data
byte 527 : reply
encrypted:
bytes 0-527: AES-encrypted record(note: same size as BuildRequestRecord!)
bytes 0-527: AES-encrypted record(note: same size as BuildRequestRecord)
total length: 528
@ -298,6 +328,10 @@ Certificate :: Always NULL in the current implementation (3 bytes total, all zer
</ul>
<h3 id="struct_DeliveryInstructions">Delivery Instructions</h3>
Defined in the <a href="tunnel_message_spec.html#delivery">Tunnel Message Specification</a>.
<h2 id="messages">Messages</h2>
<table border=1>
<tr>
@ -397,7 +431,7 @@ with reply token == 0:
+ +
| |
+----+----+----+----+----+----+----+----+
|type| reply token | data ...
|type| 0 | data ...
+----+-------------------+---------\\
</pre>
<h4>Definition</h4>
@ -421,7 +455,7 @@ reply token:
if the token is greater than zero.
reply tunnelId:
4 bytes
4 byte Tunnel ID
only included if reply token &gt; 0
This is the <a href="common_structures_spec#type_TunnelID">tunnel ID</a> of the inbound gateway of the tunnel the response should be sent to
@ -439,7 +473,6 @@ data:
<h3 id="msg_DatabaseLookup">DatabaseLookup</h3>
<pre>
{% filter escape %}
if flag==TRUE
+----+----+----+----+----+----+----+----+
| SHA256 hash as the key to look up |
+ +
@ -450,8 +483,8 @@ if flag==TRUE
| |
+----+----+----+----+----+----+----+----+
| SHA256 hash of the routerInfo |
+ who is asking +
| |
+ who is asking, or the gateway to +
| send the reply to |
+ +
| |
+ +
@ -486,17 +519,18 @@ from:
flag:
1 byte
mapping:
valid values:
0 FALSE => send reply directly
1 TRUE => send reply to some tunnel
reply tunnelId:
4 bytes
4 byte Tunnel ID
only included if flag==TRUE
tunnelId of the tunnel to send the reply to
size:
2 bytes
2 byte Integer
valid range: 0-512
number of peers to exclude from the Database Search Reply Message
excludedPeers:
@ -509,6 +543,15 @@ excludedPeers:
{% endfilter %}
</pre>
<h4>Notes</h4>
<p>
To do:
Use a bit of the flag field to request an AES-encrypted response.
Use parts of this message as the key and IV? Add a message ID also?
Backward compatibility?
</p>
<h3 id="msg_DatabaseSearchReply">DatabaseSearchReply</h3>
<h4>Description</h4>
<p>
@ -564,7 +607,7 @@ key:
SHA256 of the object being searched
num:
1 byte
1 byte Integer
number of peer hashes that follow
peer hash:
@ -663,7 +706,7 @@ unencrypted data:
Encrypted:
length:
4 bytes
4 byte Integer
number of bytes that follow 0 - 64 KB
data:
@ -720,7 +763,7 @@ Expiration :: Date (8 bytes)
<pre>
{% filter escape %}
length:
4 bytes
4 byte Integer
number of bytes that follow 0 - 64 KB - should always be 1024
data:
@ -749,11 +792,11 @@ data:
<pre>
{% filter escape %}
tunnelId:
4 bytes
4 byte Tunnel ID
identifies the tunnel this message is directed at
length:
2 bytes
2 byte Integer
length of the payload
data:
@ -763,8 +806,6 @@ data:
</pre>
{% endblock %}
<h3 id="msg_Data">Data</h3>
<h4>Description</h4>
<p>
@ -856,7 +897,7 @@ same format as TunnelBuild message, with Build Response Records
Same format as TunnelBuildMessage, except for the addition of an "num" field in front and $num number of Build Request Records instead of 8
num:
1 byte
1 byte Integer
Valid values: 1-8
Record size: 528 bytes
@ -886,3 +927,7 @@ Same format as VariableTunnelBuild message, with Build Response Records
<li>
See also the <a href="tunnel-alt-creation.html">tunnel creation specification</a>.
</ul>
{% endblock %}

206
www.i2p2/pages/i2ptunnel.html
View File

@ -1,85 +1,141 @@
{% extends "_layout.html" %}
{% block title %}i2ptunnel{% endblock %}
{% block content %}Below is quick copy of aum's eepsite deployment guide.
<br />
<br />
{% block content %}Description of i2ptunnel and tunneling modes
<ol>
<li><strong>Deploy a local server</strong>
default services
client modes
serrver modes
<h1>I2PTunnel</h1>
<h2 id="overview">Overview</h2>
<p>
I2PTunnel is a tool for interfacing with and providing services on I2P.
Destination of an I2PTunnel can be defined using a <a href="naming.html">hostname</a>,
<a href="naming.html#base32">Base32</a>, or a full 516-byte destination key.
An established I2PTunnel will be available on your client machine as localhost:port.
If you wish to provide a service on I2P network, you simply create I2PTunnel to the
appropriate ip_address:port. A corresponding 516-byte destination key will be generated
for the service and it will become avaliable throughout I2P.
A web interface for I2PTunnel management is avaliable on
<a href="http://localhost:7657/i2ptunnel/">localhost:7657/i2ptunnel/</a>.
</p>
<br>
<h2 id="default-services">Default Services</h2>
<h3 id="default-server-tunnels">Server tunnels</h3>
<ul>
<li>For simplicity's sake, we will walk through the setup of a web server; however, this procedure is the same regardless what protocol of servers and/or clients you are setting up.</li>
<li>I recommend the Tiny Httpd web server , thttpd, (windows version available on site) although you can use anything that you feel comfortable with.</li>
<li>With the web server you've chosen, configure it to listen on a port of your choice, and serve its documents from a directory of your choice. For this example, we'll assume port 10880.</li>
<li>Make sure your firewall is set up so that you cannot receive incoming connections on this port (which would breach your anonymity).</li>
<li>Test the webserver, by pointing your normal browser (the one with the "direct connection") at <a href="http://localhost:10880" target="_blank">http://localhost:10880</a> (changing the 10880 to the port number you have chosen).</li>
<li>Once your webserver is working, and you can access it locally with your browser, continue to the next step.</li>
</ul></li>
<li><strong>Open a 'Tunnel' from I2P To Your Server</strong>
<li><b>I2P Webserver</b> - A tunnel pointed to a Jetty webserver run
on <a href="http://localhost:7658">localhost:7658</a> for convenient and quick hosting on I2P.
<br>The document root is:
<br><b>Unix</b> - %APPDATA%\I2P\eepsite\docroot
<br><b>Windows</b> - C:\Users\**username**\AppData\Roaming\I2P\eepsite\docroot
</li>
</ul>
<h3 id="default-client-tunnels">Client tunnels</h3>
<ul>
<li>I2P does not deal in IP addresses. To protect your anonymity, it deals in unique addresses called destination keys.</li>
<li>A destination key works a lot like a regular IP address, except that it can't be traced to your IP address or physical location. When users place a request to speak with you, your gateways are the ones that answer for you. So the requesting user can only know the IP address of your gateways. However, gateways don't know your IP address, because gateways are the last nodes on your tunnels, and you anonymously create tunnels by way of garlic routing. (So gateways are like puppets that can't see their masters, and everyone communicates through these puppets)</li>
<li>To deploy a server on I2P, you create a destination keypair. You use the private key to authenticate your server when connecting it to I2P, and you make the public key (aka destination key) known publicly, so others can connect to your server. (indirectly, through your gateways)</li>
<li>Each service you run on I2P requires a different keypair.</li>
<li>The next steps will include the creation of your keypair.</li>
<li>For clients elsewhere in I2P to be able to access your server, you must run a 'bridge' or 'tunnel', which takes connections from these clients and forwards them to your local server</li>
<li>To activate such a tunnel, fire up your browser and open <a href="http://localhost:7657/i2ptunnel/">http://localhost:7657/i2ptunnel/</a></li>
<li>Here you'll see a list of active and non-active tunnels already set up for you, there is the eepProxy, which all sites in I2P use, ircProxy, which is the tunnel that irc.duck.i2p uses, cvs.i2p, which is a way to view and edit (for those who have access) the cvs of i2p with a special kind of program. Under that list there is a line of buttons which do not interest us right now and under that button line there's a line with a drop down menu and a button which says: "GO".</li>
<li>Click on the drop down menu and choose "Server tunnel", then press "GO".</li>
<li>Now you will configure your server tunnel which will communicate your web server to the I2P network.</li>
<li><q>Name: server 80</q><br />the name your server tunnel will be called on the tunnel list.</li>
<li><q>Description: server 80</q><br />same as above, the description on the tunnel list.</li>
<li><q>Type: Server tunnel</q><br />This is unchangeable because it's exactly what we want to make, a web server tunnel, so leave it as it is. ;-)</li>
<li><q>Target host: localhost</q><br />Here is the web server's address</li>
<li><q>Target port: 10880</q><br />This is the port your web server listens on which we've talked about before.</li>
<li><q>Private key file: myServer.privKey</q><br />Here you'll write the name of your server's private key, after you'll create the tunnel it will tell you what's your public key.</li>
<li><q>Tunnel depth: [0, 1 or 2]</q><br />This will tell I2P how many routers there will be connected in a line (router-1 -> router-2 ... ). The higher: slower and more anonymous; the lower: the faster and less anonymous. Read more about it in this <a href="how_tunnelrouting">tunnel routing document</a>.</li>
<li><q>Tunnel count: [1, 2 or 3]</q><br />The higher the number, higher reliability, bigger bandwidth; the lower, lower reliability, smaller bandwidth - experiment.</li>
<li><q>I2CP host: localhost</q>This address is where the tunnel talks to I2P server.</li>
<li><q>I2CP port: 7654</q> The port of the address</li>
<li><q>Other custom options: [leave blank]</q><br />Other options we don't care about.</li>
<li><q>Start automatically? [left click to check]</q><br />Will the tunnel start automatically when I2P starts?</li>
<li><q>Left click: Save</q> Click here when you're done to create the tunnel.</li>
<li>Copy the destination key and save it, people who'll want to read your site will need it.</li>
<li>If you did not check "Start automatically", you should go back to the tunnel list page and start it manually. Click "back" on the top of the page and click on "start" when you get to the tunnel list page.</li>
<li>Within a few seconds, the 'tunnel' should now be active, and remote clients should be able to reach your server anonymously. Remember to let your router "warm up" before opening clients to it.</li>
</ul></li>
<li><b>I2P HTTP Proxy</b> - <i>localhost:4444</i></a> - A HTTP proxy used for browsing I2P and the regular internet anonymously through I2P.
Browsing internet through I2P uses a random proxy specified by the "Outproxies:" option.
</li>
<li><b>IRC Proxy</b> - <i>localhost:6668</i> - A IRC proxy to the default anonymous IRC-servers.</li>
<li><b>mtn.i2p2.i2p</b> - <i>localhost:8998</i> - The anonymous <a href="http://en.wikipedia.org/wiki/Monotone_%28software%29">monotone</a>
sourcecode repository for I2P
</li>
<li><b>smtp.postman.i2p</b> - <i>localhost:7659</i> - A SMTP service provided by postman at
<a href="http://hq.postman.i2p/?page_id=16">hq.postman.i2p</a>
(<a href="http://hq.postman.i2p.to/?page_id=16">via inproxy</a>)
</li>
<li><b>pop3.postman.i2p</b> - <i>localhost:7660</i> - The accompanying POP sevice of postman at
<a href="http://hq.postman.i2p/?page_id=16">hq.postman.i2p</a>
(<a href="http://hq.postman.i2p.to/?page_id=16">via inproxy</a>)
</ul>
<li><strong>Update Your hosts.txt File</strong>
<br>
<h2 id="client-modes">Client Modes</h2>
<h3 id="client-modes-standard">Standard</h3>
Opens a local TCP port that connects to a service (like HTTP, FTP or SMTP) on a destination inside of I2P.
The tunnel is directed to a random host from the comma seperated (", ") list of destinations.
<br>
<h3 id="client-mode-http">HTTP</h3>
<p>A HTTP-client tunnel. The tunnel connects to the destination specified by the URL
in a HTTP request. Supports proxying onto internet if an outproxy is provided. Strips HTTP connections of the following headers:
</p>
<ul>
<li>To test your own server locally, you'll need to create an entry in your hosts.txt file, so I2P can translate the simple URL you place in the browser's address bar into the full public key text needed to find your server.</li>
<li>Edit your hosts.txt, and add the line myserver.i2p=blahblahblah, where myserver.i2p is an I2P 'domain' you want to associate with your site, and the blahblahblah is the text of the base64 public key you created earlier in the file myWebPubKey.txt</li>
<li>With this in place, you and others can reach your server with the simple domain name myserver.i2p in the browser's address bar.</li>
</ul></li>
<li><strong>Surf Your Site Within I2P</strong><ul><li>Using your secondary browser - the one you earlier configured to use localhost:4444 as a proxy - point this browser to the address <a href="http://myserver.i2p" target="_blank">http://myserver.i2p</a></li>
<li>You should see the main page of your webserver come up.</li>
</ul></li>
<li><strong>Create a Local Client Tunnel Connection</strong>
<li><b>Accept, Accept-Charset, Accept-Encoding, Accept-Language
and Accept-Ranges</b> as they vary greatly between browsers and can be used as an identifier.
</li>
<li><b>Referer:</b></li>
<li><b>Via:</b></li>
<li><b>From:</b></li>
</ul>
<p>
HTTP client/server tunnels are via I2Ptunnel force-enabling compression via the following http headers:
<ul>
<li>We now have to think beyond just web servers.</li>
<li>As you grow into I2P and get more of a 'feel' for it, you will want to use all manner of servers and clients.</li>
<li>The beauty of I2P is that it allows standard Internet clients and servers for most protocols to be transparently 'tunneled' through the anonymous network.</li>
<li>You can run mailservers/clients, newsservers/clients - almost anything at all.</li>
<li>Now, we'll create a client tunnel. This is like the server tunnel we created earlier, but works in reverse. It listens to a port on your local machine; your local client connects to this port; the connection gets forwarded through I2P to the service on the other end.</li>
<li>To open your client tunnel for your server, type the command java -jar lib/i2ptunnel.jar -nogui -e "config localhost 7654" -e "client 10888 textofbase64key" (all one line).</li>
<li>The port 10888 is arbitrary - it just needs to be something other than the physical port your server is listening on.</li>
<li>textofbase64key is simply the contents of the public key text file myWebPubKey.txt, reproduced fully on one line (alternately, instead of textofbase64key, you can specify the name from your hosts.txt - e.g. myserver.i2p)</li>
<li>Within a minute or two of launching this command, the client tunnel from your local machine into I2P will be open and ready for use.</li>
<li>Point your regular web browser (ie, not the one you configured to use localhost:4444), and point it to <a href="http://localhost:10888" target="_blank">http://localhost:10888</a></li>
<li>Verify that the mainpage of your server eventually comes up in your browser.</li>
<li>You use the same procedure for using any local client program to access a remote I2P server - just get the base64 public key (called destination key) of the remote server, choose a local port to connect to the remote server, open the tunnel, and just connect with your client to your heart's content.</li>
</ul></li>
<li><strong>Share your server details with others</strong>
<li><b>Accept-Encoding: </b></li>
<li><b>X-Accept-Encoding: </b> x-i2p-gzip;q=1.0, identity;q=0.5, deflate;q=0, gzip;q=0, *;q=0</li>
</ul>
<p>
Depending on if the tunnel is using an outproxy or not it will append the following User-Agent:
</p>
<ul>
<li>Using an anonymous medium (eg the one of the I2P IRC servers or ugha's wiki), post your domain name (eg <a href="http://www.mynick.i2p" target="_blank">www.mynick.i2p</a> as well as your destination key. Others will then be able to reach your server remotely, without either of you jeopardizing your anonymity.</li>
<li>Remember, you can go to What's on I2P and find the latest public keys linked to their URL. You should also post your own public key and URL their. However, you will want to do this anonymously, of course. Drupal.i2p.net is currently, as of this writing, only accessible from the net. So, to access the outside WWW anonymously from inside of I2P, you will need to start up your script called startSquid. Do it the same way you have been doing these other scripts. Reconfigure your browser to proxy on localhost:5555, as defined in the script, and when the script has generated it's keys, you can access the squid proxy. Put any WWW URL (such as Google or this i2p site) into your browser's address bar and you will be surfing the World Wide Web anonymously. Now you can safely post your public key, and no one can detect your IP address.</li>
<li>Aum's website <a href="http://www.freenet.org.nz/i2p/" target="_blank">http://www.freenet.org.nz/i2p/</a> has a script called setupServer.py which automates all this nonsense into one simple command line . But I respect that people's tastes in user interfaces differ, and trying to write something which satisfies everyone's needs usually results in something so complex that it turns into newbie-repellent.</li>
<li>So please feel free to use and/or customize setupServer.py to taste, or write your own in Python or another language.</li>
<li>Also, you may want to write a script which handles the startup of the I2P Router, the eepProxy, plus any and all tunnels you are using. I've got such a script called startEverything.sh, which gets launched at system startup. (Be sure to search this site for template scripts to automate your I2P commands. If I create a page for one, I'll try to remember to link it here.</li>
<li>Exercise for Windows users - port setupServer.py into a MS-DOS .BAT file.</li>
</ul></li>
</ol>
<li><i>Outproxy: </i><b>User-Agent:</b> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.6) Gecko/20100625 Firefox/3.6.6</li>
<li><i>Internal I2P use: </i><b>User-Agent:</b> MYOB/6.66 (AN/ON)</li>
</ul>
</p>
<h3 id="client-mode-irc">IRC</h3>
Creates a connection to a random IRC server specified by the comma seprated (", ")
list of destinations. Only a whitelisted subset of IRC commands are allowed due to anonymity concerns.
<br>Whitelist:
<ul>
<li>MODE</li>
<li>JOIN</li>
<li>NICK</li>
<li>QUIT</li>
<li>PART</li>
<li>WALLOPS</li>
<li>ERROR</li>
<li>KICK</li>
<li>H</li>
<li>TOPIC</li>
</ul>
<h3 id="client-mode-socks">SOCKS 4/4a/5</h3>
Enables using the I2P router as a SOCKS proxy.
<h3 id="client-mode-socks-irc">SOCKS IRC</h3>
Enables using the I2P router as a SOCKS proxy with the command whitelist specified by
<a href="#client-mode-irc">IRC</a> client mode.
<h3 id="client-mode-connect">CONNECT</h3>
Creates a HTTP tunnel and uses the HTTP request method "CONNECT"
to build a TCP tunnel that usually is used for SSL and HTTPS.
<h3 id="client-mode-streamr">Streamr</h3>
Creates a UDP-server attached to a Streamr client I2PTunnel. The streamr client tunnel will
subscribe to a streamr server tunnel.
<br>
<img src="_static/images/I2PTunnel-streamr.png">
<br>
<h2 id="server-modes">Server Modes</h2>
<h3 id="server-mode-standard">Standard</h3>
Creates a destination to a local ip:port with an open TCP port.
<h3 id="server-mode-http">HTTP</h3>
Creates a destination to a local HTTP server ip:port. Supports gzip for requests with
Accept-encoding: x-i2p-gzip, replies with Content-encoding: x-i2p-gzip in such a request.
<h3 id="server-mode-http-bidir">HTTP Bidirectional</h3>
Functions as both a I2PTunnel HTTP Server, and a I2PTunnel HTTP client with no outproxying
capabilities. An example application would be a web application that does client-type
requests, or loopback-testing an eepsite as a diagnostic tool.
<h3 id="server-mode-irc">IRC</h3>
Creates a destination that filters the reqistration sequence of a client and passes
the clients destination key as a hostname to the IRC-server.
<h3 id="server-mode-streamr">Streamr</h3>
A UDP-client that connects to a media server is created. The UDP-Client is coupled with a Streamr server I2PTunnel.
{% endblock %}

80
www.i2p2/pages/index_cs.html Normal file
View File

@ -0,0 +1,80 @@
{% extends "_layout_cs.html" %}
{% block title %}Anonymní síť I2P{% endblock %}
{% block content %}
<table cellspacing="10" class="announce"><tr class="announce"><td valign="top" class="announce">
<div class="version">
<b>Aktuální verze:</b>
<div class="underline"></div>
2010-07-12 - <strong>I2P 0.8</strong> - {{ urlify("release-0.8", "Poznámky k vydání", "html")}}
- <a href="download">Stáhnout</a>
<br /><div class="underline"></div>
2007-09-28 - <strong>Syndie 1.101a</strong> -
<!-- <a href="http://dev.i2p.net/pipermail/i2p/2007-September/001355.html">Poznámky k vydání</a> -->
- <a href="http://syndie.i2p2.de/download.html">Stáhnout</a>
</div>
<div class="news">
<b>Novinky:</b><div class=underline></div>
2010-07-12 - I2P 0.8
<a href="release-0.8.html">Vydání</a>
<br />
2010-06-07 - I2P 0.7.14
<a href="release-0.7.14.html">Vydání</a>
<br />
2010-04-27 - I2P 0.7.13
<a href="release-0.7.13.html">Vydání</a>
<br />
2010-03-15 - I2P 0.7.12
<a href="release-0.7.12.html">Vydání</a>
<br /></div>
<!--
<td>
<a href="download"><img src="/_static/images/logo07c.jpg" alt="0.7 logo" border="none"/></a> -->
</table>
<div class="underline"></div>
<p>
I2P je anonymizační síť, která nabízí jednoduchou aplikační vrstvu pro bezpečnou komunikaci
s utajením totožnosti. Všechna přenášená data jsou několikanásobně zašifrována. Celá síť je
distribuovaná a dynamická a žádná strana není považována za důvěryhodnou.
</p><p>
Existuje celá řada aplikací, které mohou komunikovat přes I2P síť,
včetně e-mailu, P2P, IRC chatu a dalších.
</p><p>
I2P síť roste rychle. V roce 2009 bylo uvolněno devět nových verzí a objem přenášených dat
vzrostl pětinásobně:
</p>
<center>
<img src="/_static/images/bandwidth2009.png" alt="Objem přenášených dat v roce 2009" />
</center>
<p>
Projekt I2P vzniknul v roce 2003, aby podpořil snahy těch, kteří se pokouší budovat svobodnější
společnost poskytováním necenzurovatelného, anonymního a bezpečného komunikačního systému. I2P
je výzkumným projektem, jehož výsledkem je plně distribuovaná, autonomní, škálovatelná, anonymní,
odolná a bezpečná síť s nízkým zpožděním. Cílem je úspěšný provoz v nepřátelském prostředí, a to
i v případě napadení organizací se značnými finančními a politickými prostředky. Všechny prvky
sítě jsou k dispozici ve formě otevřeného zdrojového kódu a zcela zdarma. Obojí by mělo uživatelům
sítě dodat jistoty v tom, že software dělá to, co tvrdí. Také to všem umožňuje přispívat a kód
vylepšovat, a odrážet tak agresivní pokusy o potlačení svobody projevu.
</p><p>
Anonymita není booleovská hodnota, zapnuto/vypnuto - nesnažíme se něco učinit "dokonale anonymním".
Namísto toho pracujeme na tom, aby útoky na anonymitu byly čím dál tím nákladnější. I2P je mixující
sítí s nízkým zpožděním (low latency mix network) a anonymita, kterou takový systém poskytuje má
svá omezení. Aplikace, které skrze tuto síť komunikují, jako jsou
<a href="http://syndie.i2p2.de/">Syndie</a>, I2P mail a I2PSnark, však poskytují další funkčnost
a ochranu.
</p><p>
Síť I2P není dokončená. Zatím se na ni nelze spoléhat pro "zaručenou" anonymitu. Síť je dosud
poměrně malá a postrádá zevrubné akademické posouzení. Není odolná proti útokům s neomezenými
prostředky, a díky inherentním omezením mixujících sítí s nízkým zpožděním asi nikdy nebude.
</p><p>
Síť I2P přenáší data prostřednictvím ostatních rovnocenných uzlů (peers), jak ukazuje následující
obrázek. Všechna data jsou šifrována po celou dobu přenosu. Více informací o tom, jak síť funguje
naleznete v <a href="how_intro">úvodu</a>.
</p>
<center>
<div class="box">
<img src="/_static/images/endToEndEncryption.png" alt="end to end layered encryption" />
</div>
</center>
{% endblock %}

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

@ -291,7 +291,7 @@ See the <a href="monotone.html">Monotone Page</a> for details.
<p>
However, to have changes included in a release, developers
must be trusted by the release managers (currently Complication and zzz).
must be trusted by the release manager (currently zzz).
In addition, they must explicitly agree with the above terms to be trusted.
That means that they must send one of the release managers a signed message affirming that:</p>
<ul>

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

@ -262,7 +262,7 @@ Siehe auf die <a href="monotone.html">Monotone Seite</a> f&uuml;r Details.
</p>
<p>
Dennoch muss der Releasemanager (derzeit Complication und zzz) dem Entwickler
Dennoch muss der Releasemanager (derzeit zzz) dem Entwickler
vertrauen, wenn dieser &Auml;nderungen in ein Release einbringen m&ouml;chte.
Zus&auml;tzlich muss ein Entwickler den oberen Bestimmungen explizit zustimmen
um vertrauensw&uuml;rdig zu sein.

334
www.i2p2/pages/meeting208.html Normal file
View File

@ -0,0 +1,334 @@
{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 208{% endblock %}
{% block content %}<h3>I2P dev meeting, September 8, 2010</h3>
<div>
<h4>Quick recap</h4>
<ul>
<li><b>Present:</b> duck, eche|on, Mathiasdm, Moru (later on), superuser, whitenoise, zzz</li>
<li>
<b>Website content progress:</b>
<p>
The website overhaul has taken 7 weeks so far. Progress is not fast enough. We need more people to join in!
</p>
</li>
<li>
<b>Website backend progress:</b>
<p>
No report yet, welterde could not attend the meeting.
</p>
</li>
<li>
<b>Location for development discussion:</b>
<p>
Most people agree that IRC is not an ideal location to post long-winded development discussions, it's too volatile, not backed up and not everyone can read it. <b>All developers are advised to post their discussions (or a writeup) to another medium, like zzz.i2p, mailing lists or forum.i2p</b>.
Opinions on the alternatives are a bit more divided. zzz.i2p is currently the location for most discussions, but a number of people also like the idea of a mailing list. No decision has been made on which alternative would be best suited.
</p>
</li>
<li>
<b>Task appointing and disagreements:</b>
<p>
Currently, people appoint themselves to a task by editing the team.html page (this requires monotone access, so there is at least a level of trust implied before being allowed to appoint yourself).
However, what happens if people disagree?
</p>
<p>
The discussion pointed out that when disagreeing, a discussion should be held (for example on zzz.i2p). If that doesn't resolve the issue, a vote is a possibility, or the Project Manager (zzz) or repository maintainers (welterde, eche|on) can make a decision.
</p>
</li>
<li>
<b>Status updates:</b>
<p>
Status updates will be started next weekend. They will mostly consist of a 'what work did you do last week?' and 'what work will you do next week?'.
</p>
</li>
<li>
<b>Development conferences:</b>
<p>
Nothing big was mentioned.
</p>
</li>
<li>
<b>Promoting the usage of the bittorrent protocol inside I2P: pros and cons:</b>
<p>
Filesharing in general and bittorrent more specifically can be either good or bad for I2P.
On one hand, they could give I2P a bad reputation. On the other hand, they could boost I2P popularity.
What to do?
</p>
<p>
Filesharing on I2P will not be promoted specifically. Instead, general usability should be looked at and improved.
If people decide to use filesharing on I2P (or any other service, like e-mail or browsing), it should become easier as a result of improving the usability.
</p>
</li>
</ul>
</div>
<div class="irclog">
<h4>Full IRC Log</h4>
<pre>
{% filter escape %}
22:02 <@Mathiasdm> okay
22:02 <@Mathiasdm> meeting time
22:03 <@Mathiasdm> 0) Hello
22:03 <@Mathiasdm> 1) Website content progress
22:03 <@Mathiasdm> 2) Website backend progress
22:03 <@Mathiasdm> 3) Location for dev discussion
22:03 <@Mathiasdm> 4) Task appointing + handling of disagreements
22:03 <@Mathiasdm> 5) Status updates
22:03 <@Mathiasdm> 6) Upcoming dev conferences
22:03 <@Mathiasdm> okay
22:03 <@Mathiasdm> 0) Hello
22:04 <@Mathiasdm> Welcome to the 208th dev meeting! (shamelessly stolen from badger :p)
22:04 * Mathiasdm pokes everyone
22:04 < eche|on> *poke*
22:04 * Mathiasdm pokes zzz, thanks for the op
22:06 <@Mathiasdm> hm, more poking needed to wake everyone up? zzz badger dr|z3d dream duck eche|on hottuna postman sponge superuser ReturningNovice (sorry :))
22:06 < eche|on> *POKE*
22:06 <@Mathiasdm> sorry, eche|on :p saw your poke
22:08 < duck> moin
22:08 <@Mathiasdm> moin duck
22:09 < hawk> * Mathiasd1 pokes welterde
22:11 <@Mathiasdm> okay, waiting a bit longer then, since there's only 3 of us so far
22:11 <@Mathiasdm> anyone who wants to join in, just poke back
22:11 < whitenoise> *poke*
22:11 <@zzz> ack
22:12 <@Mathiasdm> aha, lead dev, good :)
22:13 <@Mathiasdm> and just to be sure as many people as possible can join in, waiting 2 more minutes and then starting
22:14 <@Mathiasdm> 1 more minute now
22:14 < superuser> mooin
22:15 <@Mathiasdm> right on time, superuser ;)
22:15 <@Mathiasdm> hi all
22:15 < superuser> ;-)
22:15 < superuser> hi Mathiasdm
22:15 < superuser> and all
22:15 <@Mathiasdm> 1) Website content progress
22:15 <@Mathiasdm> as we probably all know, I2P development is currently halted due to the specs overhaul
22:16 * Mathiasdm hands the hot potato to zzz, so he can talk about the specs overhaul progress
22:16 < eche|on> right
22:17 <@zzz> it's been 7 weeks, progress is slow. I'm working on i2cp right now, I've spent several hours on it already
22:17 <@zzz> need other ppl to chip in both on what they've promised to do, and on the stuff that is unclaimed
22:17 <@zzz> eot
22:18 <@Mathiasdm> okay
22:18 * Mathiasdm will get started again tomorrow, now dev environment is set up again
22:18 <@Mathiasdm> others having something to say about it, go ahead :)
22:19 <@Mathiasdm> guess not
22:19 <@Mathiasdm> hm
22:19 <@Mathiasdm> 2) Website backend progress
22:19 < eche|on> I think is is great form the peoples doing it.
22:19 <@Mathiasdm> oh
22:19 <@Mathiasdm> sorry :)
22:21 <@Mathiasdm> we're skipping 2) for now, unless welt comes in
22:21 <@Mathiasdm> 3) Location for dev discussion
22:22 <@Mathiasdm> this is related to http://zzz.i2p/topics/719
22:22 <@Mathiasdm> I quote:
22:22 <@Mathiasdm> "* Post developer discussions on zzz.i2p. What I mean is: IRC is a highly 'volatile' medium, where not everyone is online all the time, and not everyone logs. It's a great medium for a short discussion, but do consider posting a short write-up on zzz.i2p, so others can join in on the discussion."
22:22 < eche|on> dev discussion is a hard topic. IRC is nice, but not reliant neither an archive
22:22 <@Mathiasdm> yes, agreed
22:23 <@Mathiasdm> but there are many things to chose from
22:23 <@Mathiasdm> zzz.i2p, forum.i2p, mailing list
22:23 <@Mathiasdm> well, okay, 3 things :p
22:23 < eche|on> I would suggest some central point of archive
22:23 < eche|on> with a backup.
22:24 <@Mathiasdm> yes
22:24 <@Mathiasdm> but setting up distributed storage for this sounds like a hard thing :p
22:24 <@Mathiasdm> though mailing list is doable, I guess
22:25 <@Mathiasdm> mailing list is 'kinda distributed'
22:25 < eche|on> :-)
22:25 < superuser> isn't the website itself already distributed?
22:25 <@Mathiasdm> anyone else, ideas?
22:25 < eche|on> a mailinglist is a good solution, to
22:26 < superuser> could also go there
22:26 <@Mathiasdm> yes, but that doesn't include the forum, superuser
22:26 < eche|on> rightm website is in monotone
22:26 <@Mathiasdm> true
22:26 < superuser> no, I don't mean the forum, but website itself
22:26 < superuser> aren't old dev meetings available there somewhere too?
22:26 <@Mathiasdm> but it's hard to discuss when you have to check your discussions into monotone :p
22:27 < superuser> true
22:27 <@Mathiasdm> perhaps with the new backend welt is working on, it'll be more doable
22:27 < superuser> would only be of interest for archiving, not for keeping discussing
22:28 <@Mathiasdm> for a temporary way, I would propose: if you keep a big discussion on IRC, post a few notes on _a_ persistent medium
22:29 <@Mathiasdm> be it zzz.i2p, mailing list or forum
22:29 <@Mathiasdm> I know, that's a bit vague
22:29 < eche|on> I vote mailinglist ++
22:29 <@Mathiasdm> hm, welt, are mailinglist instructions on the website somewhere?
22:29 < superuser> you mean welt's nntp service?
22:29 <@Mathiasdm> mailing list sounds good to me too, eche|on, but I wonder if it will work to get everyone to use it?
22:29 < eche|on> currently no ml available
22:29 <@Mathiasdm> yes, superuser
22:29 <@Mathiasdm> er
22:29 <@Mathiasdm> or what was it
22:29 <@Mathiasdm> I think so
22:30 <@Mathiasdm> eche|on: welt set a few ml's up this summer
22:30 < eche|on> nntp is news server
22:30 <@Mathiasdm> but not widely used yet
22:30 <@Mathiasdm> yes, indeed, but there's a mailing list now too
22:30 <@Mathiasdm> but I don't have the location here
22:30 <@Mathiasdm> zzz, duck: opinions?
22:31 < superuser> I have no mailing list info so far, just seen welt's and Mathiasdm's and ReturningNovice's posts on news server
22:32 <@zzz> I'm not a big fan of an ML but I'll use it if ppl want. welt's seems to be a big secret atm
22:33 < duck> I think zzz.i2p is fine
22:33 <@Mathiasdm> imho anything not-irc would be useful (I like IRC, as said before, but too much dev discussions are unfolloweable)
22:33 < eche|on> zzz.i2p is fine, but: irc discussions needs to be copied intoi AND somehow a kind of backup would be nice
22:34 <@Mathiasdm> hm, maybe I can set s omething up like
22:34 <@Mathiasdm> er
22:34 <@Mathiasdm> what was it called
22:34 <@Mathiasdm> 2 or 3 years ago
22:34 <@Mathiasdm> trevorreznik.i2p?
22:36 <@Mathiasdm> how about: we keep using zzz.i2p, and we start using a mailing list, and try to make sure IRC discussions don't stay IRC-only?
22:36 < duck> all major design stuff is already on zzz.i2p
22:36 < eche|on> better: try keep using zzz.i2p and copy IRC into it.
22:36 < duck> I dont see your problem
22:37 < superuser> what if zzz one disappearsß
22:37 < superuser> s/ß/?
22:37 < duck> dev/design
22:37 <@Mathiasdm> for example, everything sponge posts (just an example, sponge :p) about seedless and bob is often irc-only discussion
22:38 < duck> I dont think a mailinglist will result into sponge documenting his protocol and api
22:38 < duck> but sure, give it a try
22:39 <@Mathiasdm> nooo, that's not what I meant, duck
22:39 <@Mathiasdm> as said, I don't care if it's on zzz.i2p or on mailing list
22:39 <@Mathiasdm> I just don't want it to be IRC-only, those discussions
22:39 <@Mathiasdm> but yes, you have a good point too
22:39 <@Mathiasdm> that some things will perhaps stay irc-only
22:39 < duck> then go talk to sponge
22:39 <@Mathiasdm> it was an example
22:40 < duck> (which you might be doing through this meeting ofc)
22:40 < duck> ok, understood
22:40 <@Mathiasdm> :)
22:41 <@Mathiasdm> okay, I guess if everyone just tries to post things on zzz.i2p (or mailing list -- but we'll wait for welt :p), that's settled
22:42 <@Mathiasdm> for now, at least
22:42 <@Mathiasdm> anyone have anything to add on this?
22:44 <@Mathiasdm> okay
22:44 <@Mathiasdm> next
22:44 <@Mathiasdm> 4) Task appointing + handling of disagreements
22:45 -!- Moru [kvirc@irc2p] has joined #i2p-dev
22:45 <@Mathiasdm> currently, tasks (displayed on http://www.i2p2.de/team.html ) are appointed/chosen by people simply changing the webpage
22:45 < hawk> <preforce> Title: Team - I2P (at www.i2p2.de)
22:45 <@Mathiasdm> so if you want to do a task, you just do it, and you add yourself to the webpage
22:45 <@Mathiasdm> which is good, I guess :)
22:46 < eche|on> if someone disagree: discussion in IRC/zzz.i2p
22:46 <@Mathiasdm> yes, disagreeing is the point
22:46 < eche|on> but people need checkin-rights to change, means: need som etrust from existant devs
22:46 <@Mathiasdm> there was disagreement this summer, and we didn't really handle that
22:46 <@Mathiasdm> true, eche|on
22:47 <@Mathiasdm> how do we resolve a discussio if the people disagreeing can't come to agreement?
22:47 <@Mathiasdm> vote or something?
22:47 <@Mathiasdm> that's what I was wondering about
22:48 <@Mathiasdm> suggestions?
22:48 < eche|on> last line of defense was noted once
22:48 < eche|on> which was zzz
22:48 <@Mathiasdm> last line of defense?
22:48 <@Mathiasdm> ah
22:49 < whitenoise> what about a third better solution?
22:49 < duck> if all else fails; resort to zzz
22:49 < eche|on> but voting is a nice idea, but I think a solution will be found ahead
22:49 <@Mathiasdm> if the third solution is definitely better, the two parties will choose that one ;)
22:50 <@Mathiasdm> hm, okay
22:50 <@Mathiasdm> just out of curiosity, zzz, you agree to being 'the last line of defense'? :)
22:50 <@Mathiasdm> it sounds okay to me, but do you want that yourself?
22:51 <@zzz> not particularly. my rule is whoever is actually doing something is in charge. ppl that do nothing but talk and piss other ppl off are not.
22:52 <@zzz> there's plenty of work to go around.
22:53 <@Mathiasdm> okay :) sounds good
22:53 <@Mathiasdm> anyone have additional comments? if not, next item
22:53 < superuser> generally "the one who does it is in charge" sounds good
22:53 < superuser> but what if two parties actually do
22:53 < superuser> and still go in opposite directions?
22:54 < superuser> I guess in that case a voting mechanism would not be too uncool
22:54 <@Mathiasdm> true
22:54 <@zzz> if it's code I can pick. I'm definitely not the last line of defense for the website. welt and echelon are.
22:55 <@Mathiasdm> well, if discussion happens and a solution cannot be found, there can be a vote or someone (zzz, welt?) can pick
22:55 <@zzz> they would pick a winner by pulling privs from the loser.
22:56 <@Mathiasdm> *only if it's a nasty discussion, I would hope ;) friendly disagreements shouldn't result in losing privs :p
22:57 < eche|on> right
22:58 <@Mathiasdm> okay then
22:58 <@Mathiasdm> next point
22:58 <@Mathiasdm> if that's okay
22:58 <@Mathiasdm> 5) Status updates
22:58 < eche|on> ok
22:59 <@Mathiasdm> I will start 'collecting' status updates this weekend, I think
22:59 <@Mathiasdm> I was going to do so last week, but caught up in work
22:59 < eche|on> great. go ahead.
22:59 <@Mathiasdm> basically, simply 'what did you do last week?' and 'what are your plans for next week?'
23:00 <@Mathiasdm> and I'll post them a bit summarized on the website
23:00 <@Mathiasdm> suggestions are always welcome :)
23:00 <@Mathiasdm> okay, final point (added only a bit before starting the meeting)
23:00 <@Mathiasdm> 6) Upcoming dev conferences
23:01 <@Mathiasdm> -who's going to 27c3?
23:01 <@Mathiasdm> -who's going to brucon?
23:01 <@Mathiasdm> -any others?
23:02 <@Mathiasdm> I will certainly attend brucon, and most likely 27c3 for a day (and will stay in berlin for a few days)
23:02 < whitenoise> Mathiasdm, I added 1 more point 10 min. before the beginning.
23:02 <@Mathiasdm> oh? sorry, didn't see
23:03 <@Mathiasdm> okay, will do that in a minute, whitenoise
23:03 < whitenoise> ok
23:03 < whitenoise> thanks
23:03 <@Mathiasdm> nobody remarks on dev conferences?
23:04 <@Mathiasdm> then: 7) Promoting the usage of the bittorrent protocol inside I2P: pros and cons
23:04 * Mathiasdm hands hot potato to whitenoise
23:04 < whitenoise> Ok, so we discussed this a little bit with duck
23:05 < whitenoise> While it's a good way for cover traffic and network growth, it may lead to the notoriety of I2P as a illegal file-sharing network
23:05 < eche|on> I decided to not attend to 27c3
23:06 <@Mathiasdm> ah, too bad, eche|on
23:06 <@Mathiasdm> true, whitenoise
23:06 < whitenoise> On the other hand...
23:06 < superuser> I think, bt should not be empahsized more than other services, but i2p be promoted as general use network
23:07 < superuser> oh, he had not yet finished...
23:07 <@Mathiasdm> he might be lagging, give him a bit :)
23:08 < whitenoise> if we don't promote this protocol, in some not very near future, if the business model for selling digital media is not changed, the pressure on torrent users will be higher, so they will start looking for ways to hide
23:08 < whitenoise> which can lead to my first point (notoriety) anyway
23:08 < whitenoise> but it's doubtful, of course
23:08 < Moru> Hello! Excuse me for butting here... sad but true, promote it as filesharing and you will have loads more users and plenty of developers joining. Mabe even get funded by those that wants to use a safe filesharing platform.
23:09 <@Mathiasdm> simply promoting it would not do that, imho
23:09 <@Mathiasdm> and whitenoise, you are right about notoriety
23:09 <@Mathiasdm> but are we promoting it?
23:10 < whitenoise> Imo, right now we don't
23:10 <@Mathiasdm> and bittorrent in itself is not causing the notoriety, file sharing is (imho important distinction, but perhaps not in this discussion)
23:10 <@Mathiasdm> (and hi, Moru)
23:11 < whitenoise> Well, bittorrent is the most used way, that's why I talk about it
23:11 < whitenoise> of course, it may be emule or anything else
23:11 <@Mathiasdm> how would you see promoting it?
23:12 < whitenoise> For example, current simple users have some difficulties setting everything up
23:12 < whitenoise> We could make info about bittorrent more conspicuous
23:13 <@Mathiasdm> hm, yes
23:13 < whitenoise> description more simple
23:13 < whitenoise> and so on.
23:13 <@Mathiasdm> but that's (imho) more a general I2P problem
23:13 < whitenoise> maybe improve i2psnark a little
23:13 <@Mathiasdm> I2P could become a lot more conspicuous :p
23:13 < whitenoise> yes
23:14 < whitenoise> but doing it (as well as advertising it on twitter, for example) will surely attract some users
23:14 <@Mathiasdm> yes
23:14 <@Mathiasdm> well, I agree, and I hope we will more towards making everything clearer (better usability and such) in the near future
23:14 < whitenoise> so, the question is, I guess, what we should do and what we shouldn't
23:15 < whitenoise> improve description but don't advertise as a filesharing network, maybe?
23:15 <@Mathiasdm> what we should do (once development of 0.9 starts) is imho take a look at the 'pain points' of usability
23:15 < eche|on> laready got some ideas of those
23:17 <@Mathiasdm> yes, I2P description would help; console overhaul (perhaps? I don't know) would help
23:17 <@Mathiasdm> eche|on: didn't we have a .pdf with usability remarks from a conference you went?
23:17 < eche|on> hm
23:18 <@zzz> i have it
23:18 < eche|on> need to look for it, but we had some issues over all.
23:18 <@Mathiasdm> have a link, zzz?
23:19 <@Mathiasdm> okay, we could focus on it a bit after the website specs?
23:20 <@zzz> http://zzz.i2p/files/petcon-usability-long.pdf
23:20 <@Mathiasdm> thx
23:20 < eche|on> thats a nice idea
23:21 <@Mathiasdm> okay then
23:21 <@Mathiasdm> other remarks or ideas, whitenoise?
23:21 < whitenoise> hm...
23:22 <@Mathiasdm> you are of course always free to start working on website usability improvements too
23:22 < eche|on> just wait for some mails with contact data to pay out some money ;-)
23:23 < whitenoise> well, I guess we decided to improve usability in general without any accent on bittorrent, right?
23:23 < whitenoise> :-)
23:23 <@Mathiasdm> that looks like it, yes, whitenoise
23:23 <@Mathiasdm> I will mail you my bank account, eche|on, just send me the money ;)
23:23 <@Mathiasdm> okay then
23:23 <@Mathiasdm> 8) cookies for everyone who attended
23:24 < eche|on> *g*
23:24 <@Mathiasdm> ===Meeting over===
23:24 <@Mathiasdm> thanks all :)
23:24 < eche|on> COOKIES!
23:25 <@Mathiasdm> don't eat all of them
23:25 * Mathiasdm pokes eche|on
{% endfilter %}
{# TODO: pygments #}
</pre>
</div>
{% endblock %}

1
www.i2p2/pages/meetings.html
View File

@ -7,6 +7,7 @@ If you have something to discuss, please find the developers on IRC #i2p.
See also <a href="statusnotes.html">the old weekly status notes</a>.
</p><div class="underline"></div>
<ul class="infolist">
<li><a href="meeting208">Meeting 208</a> - September 8, 2010</li>
<li><a href="meeting207">Meeting 207</a> - February 10, 2009</li>
<li><a href="meeting206">Meeting 206</a> - April 10, 2007</li>
<li><a href="meeting205">Meeting 205</a> - April 3, 2007</li>

4
www.i2p2/pages/ministreaming.html
View File

@ -9,7 +9,7 @@ Ministreaming is deprecated and is incompatible with today's applications.
The following documentation is old.
Also note that streaming extends ministreaming in the same Java package (net.i2p.client.streaming),
so the current
<a href="http://docs.i2p2.de/net/i2p/client/streaming/package-summary.html">API documentation</a>
<a href="http://docs.i2p2.de/javadoc/net/i2p/client/streaming/package-summary.html">API documentation</a>
contains both.
Obsolete ministreaming classes and methods are clearly marked as deprecated in the Javadocs.
@ -38,7 +38,7 @@ messages sent (or include any application level ACK or SACK), so it must wait
on average twice the time it takes to send a message before sending another.</p>
<p>Even with those issues, the ministreaming library performs quite well in many
situations, and its <a href="http://docs.i2p2.de/net/i2p/client/streaming/package-summary.html">API</a>
situations, and its <a href="http://docs.i2p2.de/javadoc/net/i2p/client/streaming/package-summary.html">API</a>
is both quite simple and capable of remaining unchanged as different streaming
implementations are introduced. The library is deployed in its own
ministreaming.jar.

50
www.i2p2/pages/naming.html
View File

@ -145,23 +145,23 @@ to other routers.
</p><p>
Naming rules:</p>
<ul>
<li>Names are converted to lower case on import
<li>Names are converted to lower case on import.
<li>Names are checked for conflict with existing names in the existing userhosts.txt and hosts.txt
(but not privatehosts.txt)
after conversion to lower case
<li>Must contain only [a-z] [0-9] '.' and '-' after conversion to lower case
<li>Must not start with '.' or '-'
<li>Must end with '.i2p'
<li>67 characters maximum, including the '.i2p'
<li>Must not contain '..'
<li>Must not contain '.-' or '-.' (as of 0.6.1.33)
<li>Must not contain '--' except in 'xn--' for IDN
(but not privatehosts.txt) after conversion to lower case.
<li>Must contain only [a-z] [0-9] '.' and '-' after conversion to lower case.
<li>Must not start with '.' or '-'.
<li>Must end with '.i2p'.
<li>67 characters maximum, including the '.i2p'.
<li>Must not contain '..'.
<li>Must not contain '.-' or '-.' (as of 0.6.1.33).
<li>Must not contain '--' except in 'xn--' for IDN.
<li>Base 32 hostnames (*.b32.i2p) are not allowed.
<li>Certain hostnames reserved for project use are not allowed.
<li>Keys are checked for base64 validity
<li>Certain hostnames reserved for project use are not allowed
(proxy.i2p, router.i2p, console.i2p, *.proxy.i2p, *.router.i2p, *.proxy.i2p).
<li>Keys are checked for base64 validity.
<li>Keys are checked for conflict with existing keys in hosts.txt (but not privatehosts.txt).
<li>Maximum key length 516 bytes
<li>Maximum key length 616 bytes
<li>Minimum key length 516 bytes.
<li>Maximum key length 616 bytes (to account for certs up to 100 bytes).
</ul>
<p>
Any name received via subscription that passes all the checks is added to the local hosts.txt.
@ -223,17 +223,17 @@ It is recommended that host add services impose, at a minimum, the restrictions
Host add services may impose additional restrictions on hostnames and keys, for example:
</p>
<ul>
<li>Limit on number of 'subdomains'
<li>Authorization for 'subdomains' through various methods
<li>Hashcash or signed certificates
<li>Editorial review of host names and/or content
<li>Categorization of hosts by content
<li>Reservation or rejection of certain host names
<li>Restrictions on number of names registered in a given time period
<li>Delays between registration and publication
<li>Requirement that the host be up for verification
<li>Expiration and/or revocation
<li>IDN spoof rejection
<li>A limit on number of 'subdomains'.
<li>Authorization for 'subdomains' through various methods.
<li>Hashcash or signed certificates.
<li>Editorial review of host names and/or content.
<li>Categorization of hosts by content.
<li>Reservation or rejection of certain host names.
<li>Restrictions on the number of names registered in a given time period.
<li>Delays between registration and publication.
<li>Requirement that the host be up for verification.
<li>Expiration and/or revocation.
<li>IDN spoof rejection.
</ul>
<h2 id="jump-services">Jump Services</h2>

4
www.i2p2/pages/newdevelopers.html
View File

@ -24,7 +24,7 @@ get the monotone source repository installed - short instructions:
<ul>
<li>Install <a href="http://www.monotone.ca/">monotone</a>
<li>Skim over the <a href="http://monotone.ca/docs/Tutorial.html">monotone tutorial</a>
<li>Enable the <a href="i2ptunnel.html">i2ptunnel</a> client tunnel on port 8998 pointing to mtn.i2p2.i2p (if you are having nonce issues, see <a href="http://trac.i2p2.i2p/ticket/64">ticket #64</a> for a workaround)
<li>Enable the <a href="i2ptunnel.html">i2ptunnel</a> client tunnel on port 8998 pointing to mtn.i2p2.i2p (if you are having nonce issues, see <a href="http://trac.i2p2.de/ticket/64">ticket #64</a> for a workaround)
<li>mtn -d i2p.mtn db init
<li>mtn -d i2p.mtn pull 127.0.0.1:8998 i2p.i2p
<li>mtn -d i2p.mtn co --branch=i2p.i2p
@ -59,7 +59,7 @@ see the <a href="applications">application development guide</a>.
<li>
See <a href="http://zzz.i2p/forums/3">zzz's TODO lists</a>,
<a href="todo.html">this website's TODO list</a> or
<a href="http://trac.i2p2.i2p/report/2">Trac</a>
<a href="http://trac.i2p2.de/report/2">Trac</a>
for ideas.
<li>

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

@ -54,7 +54,7 @@ schaue dir die <a href="applications_de">Anleitung zum Entwickeln von Anwendunge
<li>
Siehe nach in der <a href="http://zzz.i2p/forums/3">zzz Aufgabenliste</a>,
<a href="todo_de.html">Aufgabenliste dieser Webseite</a> oder
<a href="http://trac.i2p2.i2p/report/2">Trac</a>
<a href="http://trac.i2p2.de/report/2">Trac</a>
f&uuml;r Ideen.
<li>

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

@ -53,7 +53,7 @@ leggete la<a href="applications">guida su come creare nuove applicazioni</a>.
<li>
Guardate <a href="http://zzz.i2p/forums/3">zzz's TODO lists</a>,
<a href="todo.html">TODO list di questo sito</a> o
<a href="http://trac.i2p2.i2p/report/2">Trac</a>
<a href="http://trac.i2p2.de/report/2">Trac</a>
per idee.
<li>

39
www.i2p2/pages/ntcp.html
View File

@ -34,16 +34,18 @@ because it uses the underlying Java TCP transport for reliable delivery.
<h3>Standard Message Format</h3>
<p>
After establishment,
the NTCP transport sends individual I2NP messages AES/256/CBC encrypted with
a simple checksum. The unencrypted message is encoded as follows:
the NTCP transport sends individual I2NP messages, with a simple checksum.
The unencrypted message is encoded as follows:
<pre>
* +-------+-------+--//--+---//----+-------+-------+-------+-------+
* | sizeof(data) | data | padding | Adler checksum of sz+data+pad |
* +-------+-------+--//--+---//----+-------+-------+-------+-------+
</pre>
That message is then encrypted with the DH/2048 negotiated session key
(station to station authenticated per the EstablishState class) using the
last 16 bytes of the previous encrypted message as the IV.
The data is then AES/256/CBC encrypted. The session key for the encryption
is negotiated during establishment (using Diffie-Hellman 2048 bit).
The establishment between two routers is implemented in the EstablishState class
and detailed below.
The IV for AES/256/CBC encryption is the last 16 bytes of the previous encrypted message.
</p>
<p>
@ -90,7 +92,7 @@ Then, DSA signatures of the critical data are exchanged to confirm the connectio
<pre>
Legend:
X, Y: 256 byte DH keys
X, Y: 256 byte DH public keys
H(): 32 byte SHA256 Hash
E(data, session key, IV): AES256 Encrypt
S(): 40 byte DSA Signature
@ -102,10 +104,28 @@ Then, DSA signatures of the critical data are exchanged to confirm the connectio
<h4 id="DH">DH Key Exchange</h4>
<p>
The initial 2048-bit DH key exchange
uses the same shared prime and generator as that used for I2P's
uses the same shared prime (p) and generator (g) as that used for I2P's
<a href="how_cryptography.html#elgamal">ElGamal encryption</a>.
</p>
<p>
The DH key exchange consists of a number of steps, displayed below.
The mapping between these steps and the messages sent between I2P routers,
is marked in bold.
<ol>
<li>Alice generates a secret 226-bit integer x.
She then calculates X = g^x mod p.
</li>
<li>Alice sends X to Bob <b>(Message 1)</b>.</li>
<li>Bob generates a secret 226-bit integer y.
He then calculates Y = g^y mod p.</li>
<li>Bob sends Y to Alice.<b>(Message 2)</b></li>
<li>Alice can now compute sessionKey = Y^x mod p.</li>
<li>Bob can now compute sessionKey = X^y mod p.</li>
<li>Both Alice and Bob now have a shared key sessionKey = g^(x*y) mod p.</li>
</ol>
The sessionKey is then used to exchange identities in <b>Message 3</b> and <b>Message 4</b>.
</p>
<h4>Message 1 (Session Request)</h4>
This is the DH request.
@ -184,7 +204,7 @@ Unencrypted Contents:
Y: 256 byte Y from Diffie Hellman
HXY: SHA256 Hash(X concatentated with Y)
HXY: SHA256 Hash(X concatenated with Y)
(32 bytes)
tsB: 4 byte timestamp (seconds since the epoch)
@ -404,6 +424,9 @@ to create a limited number of message sizes.
</li><li>
Memory utilization (including that of the kernel) for NTCP should be compared to that for SSU.
</li><li>
Can the establishment messages be randomly padded somehow, to frustrate
identification of I2P traffic based on initial packet sizes?
</li><li>
Review and possibly disable 'check connection'
</li></ul>
</p>

118
www.i2p2/pages/performance-history.html Normal file
View File

@ -0,0 +1,118 @@
{% extends "_layout.html" %}
{% block title %}Performance History{% endblock %}
{% block content %}
<p>Notable performance improvements have been made using the techniques below.
There is more to do, see the <a href="performance.html">Performance</a> page
for current issues and thoughts.</p>
<h2>Native math <b>[implemented]</b></h2>
<p>When I last profiled the I2P code, the vast majority of time was spent within
one function: java.math.BigInteger's
<a href="http://java.sun.com/j2se/1.4.2/docs/api/java/math/BigInteger.html#modPow(java.math.BigInteger,%20java.math.BigInteger)">modPow</a>.
Rather than try to tune this method, we'll call out to
<a href="http://www.swox.com/gmp/">GNU MP</a> - an insanely fast math library
(with tuned assembler for many architectures). (<i>Editor: see
<a href="jbigi">NativeBigInteger for faster public key cryptography</a></i>)</p>
<p>ugha and duck are working on the C/JNI glue code, and the existing java code
is already deployed with hooks for that whenever its ready. Preliminary results
look fantastic - running the router with the native GMP modPow is providing over
a 800% speedup in encryption performance, and the load was cut in half. This
was just on one user's machine, and things are nowhere near ready for packaging
and deployment, yet.</p>
<h2>Garlic wrapping a "reply" LeaseSet <b>[implemented but needs tuning]</b></h2>
<p>This algorithm tweak will only be relevant for applications that want their
peers to reply to them (though that includes everything that uses I2PTunnel or
mihi's ministreaming lib):</p>
<p>Previously, when Alice sent Bob a message, when Bob replied he had to do a
lookup in the network database - sending out a few requests to get Alice's
current LeaseSet. If he already has Alice's current LeaseSet, he can instead
just send his reply immediately - this is (part of) why it typically takes a
little longer talking to someone the first time you connect, but subsequent
communication is faster. Currently - for all clients - we wrap
the sender's current LeaseSet in the garlic that is delivered to the recipient,
so that when they go to reply, they'll <i>always</i> have the LeaseSet locally
stored - completely removing any need for a network database lookup on replies.
This trades off a large portion of the sender's bandwidth for that faster reply.
If we didn't do this very often,
overall network bandwidth usage would decrease, since the recipient doesn't
have to do the network database lookup.</p>
<p>
For unpublished LeaseSets such as "shared clients", this is the only way to
get the LeaseSet to Bob. Unfortunately this bundling every time adds
almost 100% overhead to a high-bandwidth connection, and much more to
a connection with smaller messages.
</p><p>
Changes scheduled for release 0.6.2 will bundle the LeaseSet only when
necessary, at the beginning of a connection or when the LeaseSet changes.
This will substantially reduce the total overhead of I2P messaging.
</p>
<h2>More efficient TCP rejection <b>[implemented]</b></h2>
<p>At the moment, all TCP connections do all of their peer validation after
going through the full (expensive) Diffie-Hellman handshaking to negotiate a
private session key. This means that if someone's clock is really wrong, or
their NAT/firewall/etc is improperly configured (or they're just running an
incompatible version of the router), they're going to consistently (though not
constantly, thanks to the shitlist) cause a futile expensive cryptographic
operation on all the peers they know about. While we will want to keep some
verification/validation within the encryption boundary, we'll want to update the
protocol to do some of it first, so that we can reject them cleanly
without wasting much CPU or other resources.</p>
<h2>Adjust the tunnel testing <b>[implemented]</b></h2>
<p>Rather than going with the fairly random scheme we have now, we should use a
more context aware algorithm for testing tunnels. e.g. if we already know its
passing valid data correctly, there's no need to test it, while if we haven't
seen any data through it recently, perhaps its worthwhile to throw some data its
way. This will reduce the tunnel contention due to excess messages, as well as
improve the speed at which we detect - and address - failing tunnels.</p>
<h2>Persistent Tunnel / Lease Selection</h2>
<p>Outbound tunnel selection implemented in 0.6.1.30, inbound lease selection
implemented in release 0.6.2.</p>
<p>Selecting tunnels and leases at random for every message creates a large
incidence of out-of-order delivery, which prevents the streaming lib from
increasing its window size as much as it could. By persisting with the
same selections for a given connection, the transfer rate is much faster.
</p>
<h2>Compress some data structures <b>[implemented]</b></h2>
<p>The I2NP messages and the data they contain is already defined in a fairly
compact structure, though one attribute of the RouterInfo structure is not -
"options" is a plain ASCII name = value mapping. Right now, we're filling it
with those published statistics - around 3300 bytes per peer. Trivial to
implement GZip compression would nearly cut that to 1/3 its size, and when you
consider how often RouterInfo structures are passed across the network, that's
significant savings - every time a router asks another router for a networkDb
entry that the peer doesn't have, it sends back 3-10 RouterInfo of them.</p>
<h2>Update the ministreaming protocol</h2> [replaced by full streaming protocol]
<p>Currently mihi's ministreaming library has a fairly simple stream negotiation
protocol - Alice sends Bob a SYN message, Bob replies with an ACK message, then
Alice and Bob send each other some data, until one of them sends the other a
CLOSE message. For long lasting connections (to an IRC server, for instance),
that overhead is negligible, but for simple one-off request/response situations
(an HTTP request/reply, for instance), that's more than twice as many messages as
necessary. If, however, Alice piggybacked her first payload in with the SYN
message, and Bob piggybacked his first reply with the ACK - and perhaps also
included the CLOSE flag - transient streams such as HTTP requests could be
reduced to a pair of messages, instead of the SYN+ACK+request+response+CLOSE.</p>
<h2>Implement full streaming protocol</h2> [<a href="streaming.html">implemented</a>]
<p>The ministreaming protocol takes advantage of a poor design decision in the
I2P client protocol (I2CP) - the exposure of "mode=GUARANTEED", allowing what
would otherwise be an unreliable, best-effort, message based protocol to be used
for reliable, blocking operation (under the covers, its still all unreliable and
message based, with the router providing delivery guarantees by garlic wrapping
an "ACK" message in with the payload, so once the data gets to the target, the
ACK message is forwarded back to us [through tunnels, of course]).</p>
<p>As I've
<a href="http://dev.i2p.net/pipermail/i2p/2004-March/000167.html">said</a>, having
I2PTunnel (and the ministreaming lib) go this route was the best thing that
could be done, but more efficient mechanisms are available. When we rip out the
"mode=GUARANTEED" functionality, we're essentially leaving ourselves with an
I2CP that looks like an anonymous IP layer, and as such, we'll be able to
implement the streaming library to take advantage of the design experiences of
the TCP layer - selective ACKs, congestion detection, nagle, etc.</p>
{% endblock %}

162
www.i2p2/pages/performance.html
View File

@ -1,6 +1,8 @@
{% extends "_layout.html" %}
{% block title %}Performance{% endblock %}
{% block content %}
Updated August 2010, current as of router version 0.8
<p>Probably one of the most frequent things people ask is "how fast is I2P?",
and no one seems to like the answer - "it depends". After trying out I2P, the
next thing they ask is "will it get faster?", and the answer to that is a most
@ -11,50 +13,8 @@ related, and others still are protocol related. However, all of those
dimensions affect the latency, throughput, and perceived performance of the
network, as they reduce contention for scarce resources. This list is of course
not comprehensive, but it does cover the major ones that are seen.</p>
<h2>Native math <b>[implemented]</b></h2>
<p>When I last profiled the I2P code, the vast majority of time was spent within
one function: java.math.BigInteger's
<a href="http://java.sun.com/j2se/1.4.2/docs/api/java/math/BigInteger.html#modPow(java.math.BigInteger,%20java.math.BigInteger)">modPow</a>.
Rather than try to tune this method, we'll call out to
<a href="http://www.swox.com/gmp/">GNU MP</a> - an insanely fast math library
(with tuned assembler for many architectures). (<i>Editor: see
<a href="jbigi">NativeBigInteger for faster public key cryptography</a></i>)</p>
<p>ugha and duck are working on the C/JNI glue code, and the existing java code
is already deployed with hooks for that whenever its ready. Preliminary results
look fantastic - running the router with the native GMP modPow is providing over
a 800% speedup in encryption performance, and the load was cut in half. This
was just on one user's machine, and things are nowhere near ready for packaging
and deployment, yet.</p>
<h2>Garlic wrapping a "reply" LeaseSet <b>[implemented but needs tuning]</b></h2>
<p>This algorithm tweak will only be relevant for applications that want their
peers to reply to them (though that includes everything that uses I2PTunnel or
mihi's ministreaming lib):</p>
<p>Previously, when Alice sent Bob a message, when Bob replied he had to do a
lookup in the network database - sending out a few requests to get Alice's
current LeaseSet. If he already has Alice's current LeaseSet, he can instead
just send his reply immediately - this is (part of) why it typically takes a
little longer talking to someone the first time you connect, but subsequent
communication is faster. Currently - for all clients - we wrap
the sender's current LeaseSet in the garlic that is delivered to the recipient,
so that when they go to reply, they'll <i>always</i> have the LeaseSet locally
stored - completely removing any need for a network database lookup on replies.
This trades off a large portion of the sender's bandwidth for that faster reply.
If we didn't do this very often,
overall network bandwidth usage would decrease, since the recipient doesn't
have to do the network database lookup.</p>
<p>
For unpublished LeaseSets such as "shared clients", this is the only way to
get the LeaseSet to Bob. Unfortunately this bundling every time adds
almost 100% overhead to a high-bandwidth connection, and much more to
a connection with smaller messages.
</p><p>
Changes scheduled for release 0.6.2 will bundle the LeaseSet only when
necessary, at the beginning of a connection or when the LeaseSet changes.
This will substantially reduce the total overhead of I2P messaging.
</p>
<p>For past performance improvements see the <a href="performance-history.html">
Performance History</a>.
<h2>Better peer profiling and selection</h2>
<p>Probably one of the most important parts of getting faster performance will
@ -75,7 +35,7 @@ gave us a reference to someone we had never heard of). We can also do some
tuning on what we actually send - how many peers we bounce back (or even if we
bounce back a reply), as well as how many concurrent searches we perform.</p>
<h2>Longer SessionTag lifetime</h2>
<h2>Session Tag Tuning and Improvements</h2>
<p>The way the <a href="how_elgamalaes">ElGamal/AES+SessionTag</a> algorithm
works is by managing a set of random one-time-use 32 byte arrays, and expiring
them if they aren't used quickly enough. If we expire them too soon, we're
@ -86,6 +46,33 @@ tags, even more encryption failures may occur prior to detection). With some
more active detection and feedback driven algorithms, we can safely and more
efficiently tune the lifetime of the tags, replacing the ElGamal encryption with
a trivial AES operation.</p>
<p>
Additional ideas for improving Session Tag delivery are described on the
<a href="how_elgamalaes.html#future">ElGamal/AES+SessionTag page</a>.
</p>
<h2 id="prng">Migrate sessionTag to synchronized PRNG</h2>
<p>Right now, our <a href="how_elgamalaes.html">ElGamal/AES+SessionTag</a>
algorithm works by tagging each encrypted message with a unique random
32 byte nonce (a "session tag"), identifying that message as being encrypted
with the associated AES session's key. This prevents peers from distinguishing
messages that are part of the same session, since each message has a completely
new random tag. To accomplish this, every few messages bundle a whole
new set of session tags within the encrypted message itself, transparently
delivering a way to identify future messages. We then have to keep track
of what messages are successfully delivered so that we know what tags
we may use.</p>
<p>This works fine and is fairly robust, however it is inefficient in terms
of bandwidth usage, as it requires the delivery of these tags ahead of
time (and not all tags may be necessary, or some may be wasted, due to
their expiration). On average though, predelivering the session tag costs
32 bytes per message (the size of a tag). As Taral suggested though, that
size can be avoided by replacing the delivery of the tags with a synchronized
PRNG - when a new session is established (through an ElGamal encrypted
block), both sides seed a PRNG for use and generate the session tags on
demand (with the recipient precalculating the next few possible values
to handle out of order delivery).</p>
<h2>Longer lasting tunnels</h2>
<p>The current default tunnel duration of 10 minutes is fairly arbitrary, though
@ -96,13 +83,12 @@ network and CPU load (due to expensive tunnel creation messages).</p>
<p>
This appears to be an easy fix for high load on the big-bandwidth routers, but
we should not resort to it until we've tuned the tunnel building algorithms further.
However, the 10 minute tunnel lifetime is hardcoded in a few places,
so the code needs to be cleaned up before we could change the duration.
However, the 10 minute tunnel lifetime is hardcoded in quite a few places,
so substantial effort would be required to change the duration.
Also, it would be difficult to maintain backward compatibility with such a change.
</p><p>
A new tunnel build algorithm was introduced in release 0.6.1.32 and it has greatly
reduced the number of tunnel builds. Together with better detection of
unreachable peers and other peer selection strategies implemented in release 0.6.1.33,
the situation is much improved, and there are no current plans to extend tunnel lifetime.
Currently, since the network average tunnel build success rate is fairly high,
there are no current plans to extend tunnel lifetime.
</p>
@ -119,62 +105,20 @@ doesn't pass our test within 60 seconds "dead"?</p>
as tunable parameters to allow for more appropriate tradeoffs between
bandwidth, latency, and CPU usage.</p>
<h2>More efficient TCP rejection <b>[implemented]</b></h2>
<p>At the moment, all TCP connections do all of their peer validation after
going through the full (expensive) Diffie-Hellman handshaking to negotiate a
private session key. This means that if someone's clock is really wrong, or
their NAT/firewall/etc is improperly configured (or they're just running an
incompatible version of the router), they're going to consistently (though not
constantly, thanks to the shitlist) cause a futile expensive cryptographic
operation on all the peers they know about. While we will want to keep some
verification/validation within the encryption boundary, we'll want to update the
protocol to do some of it first, so that we can reject them cleanly
without wasting much CPU or other resources.</p>
<h2>Adjust the tunnel testing <b>[implemented]</b></h2>
<p>Rather than going with the fairly random scheme we have now, we should use a
more context aware algorithm for testing tunnels. e.g. if we already know its
passing valid data correctly, there's no need to test it, while if we haven't
seen any data through it recently, perhaps its worthwhile to throw some data its
way. This will reduce the tunnel contention due to excess messages, as well as
improve the speed at which we detect - and address - failing tunnels.</p>
<h2>Compress some data structures <b>[implemented]</b></h2>
<p>The I2NP messages and the data they contain is already defined in a fairly
compact structure, though one attribute of the RouterInfo structure is not -
"options" is a plain ASCII name = value mapping. Right now, we're filling it
with those published statistics - around 3300 bytes per peer. Trivial to
implement GZip compression would nearly cut that to 1/3 its size, and when you
consider how often RouterInfo structures are passed across the network, that's
significant savings - every time a router asks another router for a networkDb
entry that the peer doesn't have, it sends back 3-10 RouterInfo of them.</p>
<h2>Update the ministreaming protocol</h2> [replaced by full streaming protocol]
<p>Currently mihi's ministreaming library has a fairly simple stream negotiation
protocol - Alice sends Bob a SYN message, Bob replies with an ACK message, then
Alice and Bob send each other some data, until one of them sends the other a
CLOSE message. For long lasting connections (to an IRC server, for instance),
that overhead is negligible, but for simple one-off request/response situations
(an HTTP request/reply, for instance), that's more than twice as many messages as
necessary. If, however, Alice piggybacked her first payload in with the SYN
message, and Bob piggybacked his first reply with the ACK - and perhaps also
included the CLOSE flag - transient streams such as HTTP requests could be
reduced to a pair of messages, instead of the SYN+ACK+request+response+CLOSE.</p>
<h2>Implement full streaming protocol</h2> [<a href="streaming.html">implemented</a>]
<p>The ministreaming protocol takes advantage of a poor design decision in the
I2P client protocol (I2CP) - the exposure of "mode=GUARANTEED", allowing what
would otherwise be an unreliable, best-effort, message based protocol to be used
for reliable, blocking operation (under the covers, its still all unreliable and
message based, with the router providing delivery guarantees by garlic wrapping
an "ACK" message in with the payload, so once the data gets to the target, the
ACK message is forwarded back to us [through tunnels, of course]).</p>
<p>As I've
<a href="http://dev.i2p.net/pipermail/i2p/2004-March/000167.html">said</a>, having
I2PTunnel (and the ministreaming lib) go this route was the best thing that
could be done, but more efficient mechanisms are available. When we rip out the
"mode=GUARANTEED" functionality, we're essentially leaving ourselves with an
I2CP that looks like an anonymous IP layer, and as such, we'll be able to
implement the streaming library to take advantage of the design experiences of
the TCP layer - selective ACKs, congestion detection, nagle, etc.</p>
<h2>Full streaming protocol improvements</h2>
<ul>
<li>Perhaps re-enable the interactive stream profile (the
current implementation only uses the bulk stream profile).</li>
<li>Client level bandwidth limiting (in either or both directions on a stream,
or possibly shared across multiple streams). This would be in addition to
the router's overall bandwidth limiting, of course.</li>
<li>Access control lists (only allowing streams to or from certain other known
destinations).</li>
<li>Web controls and monitoring the health of the various streams, as well
as the ability to explicitly close or throttle them.</li>
</ul>
<p>
Additional ideas for improving the streaming library are described on the
<a href="streaming.html#future">streaming library page</a>.
</p>
{% endblock %}

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

@ -205,52 +205,36 @@ foo.xpi2p is a sud file containing the following:
</pre>
<h3>Plugin installer tasks
</h3>
<h3>Plugin installer tasks</h3>
This lists what happens when a plugin is installed by I2P.
<ul>
<li>
download .xpi2p
<li>
verify sud sig against stored keys, or else:
- extract, get pubkey from properties, then verify, then store key
<li>
verify zip integrity
<li>
extract plugin.config file
<li>
verify min/max/version/etc
<li>
check that webapps don't duplicate those in $I2P
<li>
stop existing plugin
<li>
verify install dir doesn't exist if update=false, or ask
<li>
verify install dir does exist if update=true, or ask
<li>
unzip into appDir/plugins/name/
<li>
add to plugins.config
<li>The .xpi2p file is downloaded.</li>
<li>The .sud signature is verified against stored keys.
If there is no matching key, the .sud is extracted, the key is loaded from the properties, then verified and stored.</li>
<li>Verify the integrity of the zip file.</li>
<li>Extract the plugin.config file.</li>
<li>Verify the I2P version, to make sure the plugin will work.</li>
<li>Check that webapps don't duplicate the existing $I2P applications.</li>
<li>Stop the existing plugin (if present).</li>
<li>Verify that the install directory does not exist yet if update=false, or ask to overwrite.</li>
<li>Verify that the install directory does exist if update=false, or ask to create.</li>
<li>Unzip the plugin in to appDir/plugins/name/</li>
<li>Add the plugin to plugins.config</li>
</ul>
<h3>
Plugin starter tasks
</h3>
Check plugins.config for which to start.
For each one:
This lists what happens when plugins are started.
First, plugins.config is checked to see which plugins need to be started.
For each plugin:
<ul>
<li>
check clients.config, load and start each item (add configured jars to classpath)
<li>
check console/webapp and console/webapp.config, load and start (add configured jars to classpath)
<li>
add console/locale/foo.jar to translate classpath if present
<li>
add console/theme to theme search path if present
<li>
add summary bar link
<li>Check clients.config, and load and start each item (add the configured jars to the classpath).</li>
<li>Check console/webapp and console/webapp.config. Load and start required items (add the configured jars to the classpath).</li>
<li>Add console/locale/foo.jar to the translation classpath if present.</li>
<li>Add console/theme to the theme search path if present.</li>
<li>Add the summary bar link.</li>
</ul>
<h3>
@ -342,7 +326,7 @@ Pack200 unpacking is supported on routers 0.7.11-5 or higher, which is essential
support plugins at all.
<li>
Plugins should not attempt to write anywhere in $I2P as it may be readonly, and that isn't good policy anyway
Plugins should not attempt to write anywhere in $I2P as it may be readonly, and that isn't good policy anyway.
<li>
Plugins may write to $CONFIG but keeping files in $PLUGIN only is recommended.
All files in $PLUGIN will be deleted at uninstall.
@ -352,9 +336,9 @@ If the user may want to save data after uninstallation, the uninstallargs hook
could ask.
<li>
$CWD may be anywhere; do not assume it is in a particular place, do not attempt to read or write files relative to $CWD
$CWD may be anywhere; do not assume it is in a particular place, do not attempt to read or write files relative to $CWD.
<li>
Java programs should find out where they are with the directory getters in I2PAppContext
Java programs should find out where they are with the directory getters in I2PAppContext.
<li>
Plugin directory is I2PAppContext.getGlobalContext().getAppDir().getAbsolutePath() + "/plugins/" + appname,
or put a $PLUGIN argument in the args line in clients.config.
@ -363,7 +347,7 @@ context API in i2p.jar.
<li>
See <a href="http://zzz.i2p/topics/16">Howto</a> for info on generating signing keys and generating/verifying keys and sud files
<li>
All config files must be UTF-8
All config files must be UTF-8.
<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...
@ -394,7 +378,7 @@ Since each version must be higher than the one before, you could enhance your bu
script to add a build number to the end of the version.
This helps for testing. Most of zzz's plugins have that feature, check build.xml for an example.
<li>
Plugins must never call System.exit()
Plugins must never call System.exit().
<li>
Please respect licenses by meeting license requirements for any software you bundle.

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

@ -86,7 +86,7 @@ Plugins are a great way to learn more about I2P or easily add some feature.
<h3>Getting Started</h3>
To create a plugin from an existing binary package you will need to get
makeplugin.sh from
<a href="http://stats.i2p/cgi-bin/viewmtn/branch/head/browse/i2p.scripts/plugin/makeplugin.sh">the i2p.scripts branch in monotone</a>.
<a href="http://trac.i2p2.de/browser/plugin/makeplugin.sh?rev=776519571fda0689ef09c42f66e7398f30432e87">the i2p.scripts branch in monotone</a>.
<h3>Known Issues</h3>
@ -98,23 +98,23 @@ Updates of a plugin with included jars (not wars) won't be recognized if the plu
it requires class loader trickery to flush the class cache;
a full router restart is required.
<li>
Automatic updates (and check-for-updates) unimplemented.
Automatic updates (and check-for-updates) are currently unimplemented.
<li>
Stop button displayed even if there is nothing to stop.
The stop button is displayed even if there is nothing to stop.
<li>
Plugins running in a separate JVM create a logs/ directory in $CWD.
<li>
No initial keys except for jrandom and zzz (using same keys as for router update),
No initial keys are present, except for jrandom and zzz (using the same keys as for router update),
so the first key seen for a signer is automatically accepted - there is no signing key authority.
<li>
When deleting a plugin, the directory is not always deleted, especially on Windows.
<li>
Installing a plugin requiring Java 1.6 on a Java 1.5 machine will result in a "plugin is corrupt"
message if pack200 is used.
message if pack200 compression of the plugin file is used.
<li>
Theme and translation plugins are untested.
<li>
Disabling autostart doesn't always work
Disabling autostart doesn't always work.
</ul>
{% endblock %}

167
www.i2p2/pages/protocols.html
View File

@ -8,87 +8,100 @@ See also the<a href="how.html">Index to Technical Documentation</a>.
Updated August 2010, current for router version 0.8.
<p>
<table border=1>
<tr>
<td>Standard Apps
<td align="center">Jetty, Apache, Monotone, CVS, browsers
<td>&nbsp;
<p>
Each of the layers in the stack provides extra capabilities.
The capabilities are listed below, starting at the bottom of the protocol stack.
<ul>
<li>
<b>Internet Layer:</b>
<br />
IP: Internet Protocol, allow addressing hosts on the regular internet and routing packets across the internet using best-effort delivery.
</li>
<li>
<b>Transport Layer:</b>
<br />
TCP: Transmission Control Protocol, allow reliable, in-order delivery of packets across the internet.
<br />
UDP: User Datagram Protocol, allow unreliable, out-of-order delivery of packets across the internet.
</li>
<li>
<b>I2P Transport Layer:</b> provide encrypted connections between 2 I2P routers. These are not anonymous yet, this is strictly a hop-to-hop connection.
Two protocols are implemented to provide these capabilities. NTCP builds on top of TCP, while SSU uses UDP.
<br />
<a href="ntcp.html">NTCP</a>: NIO-based TCP
<br />
<a href="udp.html">SSU</a>: Secure Semi-reliable UDP
</li>
<li>
<b>I2P Tunnel Layer:</b> provide full encrypted tunnel connections.
<br />
<a href="tunnel_message_spec.html">Tunnel messages</a>: tunnel messages are large messages containing encrypted I2NP (see below) messages and encrypted instructions for their delivery.
The encryption is layered. The first hop will decrypt the tunnel message and read a part. Another part can still be encrypted (with another key),
so it will be forwarded.
<br />
<a href="i2np.html">I2NP messages</a>: I2P Network Protocol messages are used to pass messages through multiple routers. These I2NP messages are combined in tunnel messages.
</li>
<li>
<b>I2P Garlic Layer:</b> provide encrypted and anonymous end-to-end I2P message delivery.
<br />
<a href="i2np.html">I2NP messages</a>: I2P Network Protocol messages are wrapped in each other and used to ensure encryption between two tunnels and are passed along from source to destination, keeping both anonymous.
</li>
</ul>
</p>
<tr>
<td>Other I2P Apps
<td align="center">Syndie, EepGet, <a href="plugins.html">plugins</a>
<td>&nbsp;
<p>
The following layers are strictly speaking no longer part of the I2P Protocol stack, they are not part of the core 'I2P router' functionality.
However, each of these layers adds additional functionality, to allow applications simple and convenient I2P usage.
<ul>
<li>
<b>I2P Client Layer:</b> allow any client to use I2P functionality, without requiring the direct use of the router API.
<br />
<a href="i2cp.html">I2CP</a>: I2P Client Protocol, allows secure and asynchronous messaging over I2P by communicating messages over the I2CP TCP socket.
</li>
<li>
<b>I2P End-to-end Transport Layer:</b> allow TCP- or UDP-like functionality on top of I2P.
<br />
<a href="streaming.html">Streaming Library</a>: an implementation of TCP-like streams over I2P. This allows easier porting of existing applications to I2P.
<br />
<a href="datagrams.html">Datagram Library</a>: an implementation of UDP-like messages over I2P. This allows easier porting of existing applications to I2P.
</li>
<li>
<b>I2P Application Interface Layer:</b> additional (optional) libraries allowing easier implementations on top of I2P.
<br />
<a href="i2ptunnel.html">I2PTunnel</a>
<br />
<a href="sam.html">SAM</a>/<a href="samv2.html">SAMv2</a>/<a href="samv3.html">SAMv3</a>(*),
<a href="bob.html">BOB</a>
</li>
<li>
<b>I2P Application Proxy Layer:</b> proxy systems.
<br />
HTTP Client/Server, IRC Client, <a href="socks.html">SOCKS</a>, Streamr
</li>
</ul>
</p>
<p>
Finally, what could be considered the <b>'I2P application layer'</b>, is a large number of applications on top of I2P.
We can order this based on the I2P stack layer they use.
<ul>
<li><b>Streaming/datagram applications</b>: i2psnark, Syndie, i2phex...</li>
<li><b>SAM/BOB applications</b>: IMule, i2p-bt, i2prufus, Robert...</li>
<li><b>Other I2P applications</b>: Syndie, EepGet, <a href="plugins.html">plugins...</a></li>
<li><b>Regular applications</b>: Jetty, Apache, Monotone, CVS, browsers, e-mail...</li>
</ul>
</p>
<tr>
<td>SAM/BOB Apps
<td>
<td align="center">IMule, i2p-bt, i2prufus, Robert
<center>
<div class="box">
<img src="_static/images/protocol_stack.png" alt="I2P Network stack" title="I2P Network stack" />
<br /><br />
Figure 1: The layers in the I2P Network stack.
</div>
</center>
<br/>
<tr>
<td>Proxy Apps
<td align="center">HTTP Client/Server, IRC Client, <a href="socks.html">SOCKS</a>
<td align="center">Streamr
<tr>
<td>Interface Apps
<td align="center"><a href="i2ptunnel.html">I2PTunnel</a>
<td align="center"><a href="sam.html">SAM</a>
/
<a href="samv2.html">SAMv2</a>
/
<a href="samv3.html">SAMv3</a>
(*), <a href="bob.html">BOB</a>
<tr>
<td>Java Apps
<td align="center">i2psnark, Syndie, i2phex
<td>&nbsp;
<tr>
<td>End-to-End Transport
<td align="center"><a href="streaming.html">Streaming Lib</a>
<td align="center"><a href="datagrams.html">Datagrams</a>
<tr>
<td>Client Protocol
<td align="center" colspan=2><a href="i2cp.html">I2CP</a>
<tr>
<td>Network Protocol
<td align="center" colspan=2><a href="i2np.html">I2NP</a>
<tr>
<td>Garlic Encryption
<td align="center" colspan=2><a href="how_elgamalaes.html">ElGamal/AES+SessionTag</a>
<tr>
<td>Tunnel Messages
<td align="center" colspan=2><a href="tunnel_message_spec.html">Tunnel Messages</a>
<tr>
<td>Tunnel Message Encryption
<td align="center" colspan=2><a href="techintro.html#op.crypto">AES256/CBC</a>
<tr>
<td><a href="transports.html">Transports</a>
<td align="center"><a href="ntcp.html">NTCP</a>
<td align="center"><a href="udp.html">SSU</a>
<tr>
<td>Transport Encryption
<td align="center" colspan=2><a href="techintro.html#op.crypto">AES256/CBC</a>
<tr>
<td>
<td align="center">Java NIO TCP
<td align="center" rowspan=2>UDP
<tr>
<td>OS
<td align="center">TCP
</table>
<p>
* Note: SAM/SAMv2 can use both the streaming lib and datagrams.
</p>
{% endblock %}

570
www.i2p2/pages/streaming.html
View File

@ -1,6 +1,7 @@
{% extends "_layout.html" %}
{% block title %}Streaming Lib{% endblock %}
{% block title %}Streaming Library{% endblock %}
{% block content %}
Updated August 2010, current as of router version 0.8
<h2>Overview</h2>
<p>
@ -9,10 +10,12 @@ as it is not a core router function.
In practice, however, it provides a vital function for almost all
existing I2P applications, by providing a TCP-like
streams over I2P, and allowing existing apps to be easily ported to I2P.
The other end-to-end transport library for client communication is the
<a href="datagrams.html">datagram library</a>.
</p>
<p>The streaming library is a layer on top of the core
<a href="i2cp">I2CP</a> that allows reliable, in order, and authenticated streams
<a href="i2cp.html">I2CP API</a> that allows reliable, in-order, and authenticated streams
of messages to operate across an unreliable, unordered, and unauthenticated
message layer. Just like the TCP to IP relationship, this streaming
functionality has a whole series of tradeoffs and optimizations available, but
@ -20,23 +23,9 @@ rather than embed that functionality into the base I2P code, it has been factore
off into its own library both to keep the TCP-esque complexities separate and to
allow alternative optimized implementations.</p>
<h2>History</h2>
<p>
The streaming library has grown organically for I2P - first mihi implemented the
"mini streaming library" as part of I2PTunnel, which was limited to a window
size of 1 message (requiring an ACK before sending the next one), and then it was
refactored out into a generic streaming interface (mirroring TCP sockets) and the
full streaming implementation was deployed with a sliding window protocol and
optimizations to take into account the high bandwidth x delay product. Individual
streams may adjust the maximum packet size and other options. The default
message size is selected to fit precisely in two 1K I2NP tunnel messages,
and is a reasonable tradeoff between the bandwidth costs of
retransmitting lost messages and the latency of multiple messages.
</p>
<p>
In addition, in consideration of the relatively high cost of subsequent messages,
the streaming library's protocol for scheduling and delivering messages has been optimized to
In consideration of the relatively high cost of messages,
the streaming library's protocol for scheduling and delivering those messages has been optimized to
allow individual messages passed to contain as much information as is available.
For instance, a small HTTP transaction proxied through the streaming library can
be completed in a single round trip - the first messages bundle a SYN, FIN, and
@ -48,20 +37,51 @@ immediately.
</p>
<p>
On the whole, however, the streaming library bears much resemblance to an
The streaming library bears much resemblance to an
abstraction of TCP, with its sliding windows, congestion control algorithms
(both slow start and congestion avoidance), and general packet behavior (ACK,
SYN, FIN, RST, rto calculation, etc).
</p>
<h2>Usage</h2>
<p>
The standard interface to the streaming lib is for the application to set up
a I2PSocketManagerFactory from the <a href="ministreaming.html">ministreaming lib</a>.
Only I2PSocketManagerFactory is used here - everything else is from the full streaming lib
(I2PSocketManagerFull, not I2PSocketManagerImpl, and I2PSocketFull, not I2PSocketImpl).
The remainder of the ministreaming lib is not normally used - don't be confused.
The streaming library is
a robust library
which is optimized for operation over I2P.
It has a one-phase setup, and
it contains a full windowing implementation.
</p>
<h2 id="api">API</h2>
<p>
The streaming library API provides a standard socket paradigm to Java applications.
The lower-level
<a href="i2cp.html">I2CP</a>
API is completely hidden, except that applications may pass
<a href="i2cp.html#options">I2CP parameters</a> through the streaming library,
to be interpreted by I2CP.
</p>
<p>
The standard interface to the streaming lib is for the application to use the
<a href="http://docs.i2p2.de/javadoc/net/i2p/client/streaming/I2PSocketManagerFactory.html">I2PSocketManagerFactory</a>
to create an
<a href="http://docs.i2p2.de/javadoc/net/i2p/client/streaming/I2PSocketManager.html">I2PSocketManager</a>.
The application then asks the socket manager for an
<a href="http://docs.i2p2.de/javadoc/net/i2p/client/streaming/I2PSession.html">I2PSession</a>,
which will cause a connection to the router via
<a href="i2cp.html">I2CP</a>.
The application can then setup connections with an
<a href="http://docs.i2p2.de/javadoc/net/i2p/client/streaming/I2PSocket.html">I2PSocket</a>
or receive connections with an
<a href="http://docs.i2p2.de/javadoc/net/i2p/client/streaming/I2PServerSocket.html">I2PServerSocket</a>.
</p>
<p>
Here are the
<a href="http://docs.i2p2.de/javadoc/net/i2p/client/streaming/package-summary.html">full streaming library Javadocs</a>.
</p>
<p>
@ -69,218 +89,376 @@ For a good example of usage, see the i2psnark code.
</p>
<h2>Advantages</h2>
<p>The streaming lib has many advantages over the ministreaming library written by mihi as a part of his
<a href="i2ptunnel">I2PTunnel</a> application.
The streaming library is
a more robust streaming library
which is further optimized for operation over I2P. The two main issues with
the ministreaming library are its use of the traditional TCP two phase
establishment protocol and the current fixed window size of 1.
The streaming lib fixes both of these issues - it has a one-phase setup, and
it contains a full windowing implementation.
</p>
<h3 id="options">Options and Defaults</h3>
<p>
Significant tuning of the streaming lib parameters,
greatly increasing outbound performance, was implemented in 0.6.1.28.
Subsequent releases include additional tuning and bug fixes.
<h2 id="options">Default Parameters</h2>
The current default values are listed below.
Lower case values are streaming lib parameters that can changed on a
The options and current default values are listed below.
Options are case-sensitive and may be set for the whole router, for a particular client, or for an individual socket on a
per-connection basis.
These values are tuned for HTTP performance over typical I2P conditions. Other applications such
Many values are tuned for HTTP performance over typical I2P conditions. Other applications such
as peer-to-peer services are strongly encouraged to
modify as necessary, by setting the options and passing them via the call to
I2PSocketManagerFactory.createManager(_i2cpHost, _i2cpPort, opts).
<a href="http://docs.i2p2.de/javadoc/net/i2p/client/streaming/I2PSocketManagerFactory.html">I2PSocketManagerFactory</a>.createManager(_i2cpHost, _i2cpPort, opts).
Time values are in ms.
<ul>
<li>MIN_RESEND_DELAY = 2*1000
<li>MAX_RESEND_DELAY = 45*1000
<li>i2p.streaming.connectTimeout = 5*60*1000
<li>i2p.streaming.initialReceiveWindow = 1
<li>i2p.streaming.initialWindowSize = 12
<li>MIN_WINDOW_SIZE = 1
<li>i2p.streaming.maxWindowSize = 128 // as of release 0.6.3 (was 64)
<li>TREND_COUNT = 3
<li>i2p.streaming.maxResends = 8
<li>RTT_DAMPENING = 0.875 // as of release 0.6.5 (was 0.9)
<li>i2p.streaming.profile = 1 (bulk) (2=interactive not supported)
<li>MIN_MESSAGE_SIZE = 512 // as of release 0.6.5
<li>i2p.streaming.maxMessageSize = 1730 // as of release 0.6.5 (was 960)
<li>INBOUND_BUFFER_SIZE = maxMessageSize * (maxWindowSize + 2)
<li>i2p.streaming.initialRTT = 10*1000
<li>INITIAL_TIMEOUT = 1.5 * initialRTT
<li>i2p.streaming.initialResendDelay = 1000
<li>i2p.streaming.initialAckDelay = 2000
<li>i2p.streaming.inactivityTimeout = 90*1000
<li>i2p.streaming.inactivityAction = 2 (send) (0=noop, 1=disconnect)
<li>i2p.streaming.congestionAvoidanceGrowthRateFactor = 1
<li>i2p.streaming.slowStartGrowthRateFactor = 1
<li>PASSIVE_FLUSH_DELAY = 250 // as of release 0.6.5 (was 500)
<li>i2p.streaming.answerPings = true // new option as of release 0.7.7
<li>i2p.streaming.maxConcurrentStreams = -1 // 0 or negative value means unlimited
<li>i2p.streaming.maxConnsPerMinute = 0 // per peer; 0 means disabled; as of release 0.7.14
<li>i2p.streaming.maxConnsPerHour = 0 // per peer; 0 means disabled; as of release 0.7.14
<li>i2p.streaming.maxConnsPerDay = 0 // per peer; 0 means disabled; as of release 0.7.14
<li>i2p.streaming.maxTotalConnsPerMinute = 0 // all peers; 0 means disabled; as of release 0.7.14
<li>i2p.streaming.maxTotalConnsPerHour = 0 // all peers; 0 means disabled; as of release 0.7.14
<li>i2p.streaming.maxTotalConnsPerDay = 0 // all peers; 0 means disabled; as of release 0.7.14
</ul>
</p>
<p>
The streaming lib uses standard slow-start (exponential window growth) and congestion avoidance (linear window growth)
phases. However, before the 0.6.1.33 release, window growth was substantially slower than optimal;
these issues were fixed in release 0.6.1.33.
Note that higher-layer APIs, such as
<a href="samv3.html">SAM</a>,
<a href="bob.html">BOB</a>, and
<a href="i2ptunnel.html">I2PTunnel</a>,
may override these defaults with their own defaults.
Also note that many options only apply to servers listening for incoming connections.
</p>
<table>
<tr><th>Option</th><th>Default</th><th>Notes</th>
</tr>
<tr><td>i2cp.accessList</td><td>null</td><td>Comma- or space-separated list of Base64 peer Hashes used for either access list or blacklist
</td></tr><tr><td>i2cp.enableAccessList</td><td>false
</td><td>Use the access list as a whitelist for incoming connections
</td></tr><tr><td>i2cp.enableBlackList</td><td>false
</td><td>Use the access list as a blacklist for incoming connections
</td></tr><tr><td>i2p.streaming.answerPings</td><td>true</td><td>Whether to respond to incoming pings
</td></tr><tr><td>i2p.streaming.congestionAvoidanceGrowthRateFactor</td><td>1
</td><td>
When we're in congestion avoidance, we grow the window size at the rate
of 1/(windowSize*factor). In standard TCP, window sizes are in bytes,
while in I2P, window sizes are in messages.
A higher number means slower growth.
</td></tr><tr><td>i2p.streaming.connectDelay</td><td>-1
</td><td>
How long to wait after instantiating a new con
before actually attempting to connect. If this is
&lt;= 0, connect immediately with no initial data. If greater than 0, wait
until the output stream is flushed, the buffer fills,
or that many milliseconds pass, and include any initial data with the SYN.
</td></tr><tr><td>i2p.streaming.connectTimeout</td><td>5*60*1000</td><td>5 minutes!
</td></tr><tr><td>i2p.streaming.inactivityAction</td><td>2 (send) </td><td>(0=noop, 1=disconnect)
What to do on an inactivity timeout - do nothing, disconnect, or send a duplicate ack.
</td></tr><tr><td>i2p.streaming.inactivityTimeout</td><td>90*1000
</td></tr><tr><td>i2p.streaming.initialAckDelay</td><td>2000
</td></tr><tr><td>i2p.streaming.initialResendDelay</td><td>1000
</td><td>
The initial value of the resend delay field in the packet header, times 1000.
Not fully implemented; see below.
</td></tr><tr><td>i2p.streaming.initialRTT</td><td>8000 </td><td>(if no <a href="#sharing">sharing data</a> available)
</td></tr><tr><td>i2p.streaming.initialWindowSize</td><td>6</td><td>(if no <a href="#sharing">sharing data</a> available)
In standard TCP, window sizes are in bytes, while in I2P, window sizes are in messages.
</td></tr><tr><td>i2p.streaming.maxConcurrentStreams</td><td>-1 </td><td>(0 or negative value means unlimited)
This is a total limit for incoming and outgoing combined.
</td></tr><tr><td>i2p.streaming.maxConnsPerMinute</td><td>0 </td><td>Incoming connection limit (per peer; 0 means disabled)
</td></tr><tr><td>i2p.streaming.maxConnsPerHour</td><td>0 </td><td>(per peer; 0 means disabled)
</td></tr><tr><td>i2p.streaming.maxConnsPerDay</td><td>0 </td><td>(per peer; 0 means disabled)
</td></tr><tr><td>i2p.streaming.maxMessageSize</td><td>1730</td><td>The MTU in bytes.
</td></tr><tr><td>i2p.streaming.maxResends</td><td>8
</td><td>
Maximum number of retransmissions before failure.
</td></tr><tr><td>i2p.streaming.maxTotalConnsPerMinute</td><td>0 </td><td>Incoming connection limit (all peers; 0 means disabled)
</td></tr><tr><td>i2p.streaming.maxTotalConnsPerHour</td><td>0 </td><td>(all peers; 0 means disabled)
Use with caution as exceeding this will disable a server for a long time.
</td></tr><tr><td>i2p.streaming.maxTotalConnsPerDay</td><td>0 </td><td>(all peers; 0 means disabled)
Use with caution as exceeding this will disable a server for a long time.
</td></tr><tr><td>i2p.streaming.maxWindowSize</td><td>128
</td></tr><tr><td>i2p.streaming.profile</td><td>1 (bulk)</td><td>(2=interactive not supported)
This doesn't currently do anything, but setting it to a value other than 1 will cause an error.
</td></tr><tr><td>i2p.streaming.slowStartGrowthRateFactor</td><td>1
</td><td>
When we're in slow start, we grow the window size at the rate
of 1/(factor). In standard TCP, window sizes are in bytes,
while in I2P, window sizes are in messages.
A higher number means slower growth.
</td></tr>
</table>
<h2>Protocol Specification</h2>
<h3>Packet Format</h3>
<p>
The format of a single packet in the streaming protocol is:
<pre>
+----+----+----+----+----+----+----+----+
| send Stream ID | rcv Stream ID |
+----+----+----+----+----+----+----+----+
| sequence Num | ack Through |
+----+----+----+----+----+----+----+----+
| nc | NACKs ...
+----+----+----+----+----+----+----+----+
| rd | flags | opt size| opt data
+----+----+----+----+----+----+----+----+
... |
+----+----+----+----+----+----+----+----+
| payload ...
+----+----+----+----//
</pre>
<table>
<tr><th>Field<th>Length<th>Contents
<tr><td>sendStreamId <td>4 byte <a href="common_structures_spec.html#type_Integer">Integer</a><td>Random number selected by the connection recipient
and constant for the life of the connection.
0 in the SYN message sent by the originator, and in subsequent messages, until a SYN reply is received,
containint the peer's stream ID.
<tr><td>receiveStreamId <td>4 byte <a href="common_structures_spec.html#type_Integer">Integer</a><td>Random number selected by the connection originator
and constant for the life of the connection. May be 0 if unknown, for example in a RESET packet.
<tr><td>sequenceNum <td>4 byte <a href="common_structures_spec.html#type_Integer">Integer</a><td>
The sequence for this message, starting at 0 in the SYN message,
and incremented by 1 in each message except for plain ACKs and retransmissions.
If the sequenceNum is 0 and the SYN flag is not set, this is a plain ACK
packet that should not be ACKed.
<tr><td>ackThrough <td>4 byte <a href="common_structures_spec.html#type_Integer">Integer</a><td>
The highest packet sequence number that was received
on the receiveStreamId. This field is ignored on the initial
connection packet (where receiveStreamId is the unknown id) or
if the NO_ACK flag set.
All packets up to and including this sequence number are ACKed,
EXCEPT for those listed in NACKs below.
<tr><td>NACK count<td>1 byte <a href="common_structures_spec.html#type_Integer">Integer</a><td>
The number of 4-byte NACKs in the next field
<tr><td>NACKs <td>n * 4 byte <a href="common_structures_spec.html#type_Integer">Integers</a><td>
Sequence numbers less than ackThrough that are not yet received.
Two NACKs of a packet is a request for a 'fast retransmit' of that packet.
<tr><td>resendDelay<td>1 byte <a href="common_structures_spec.html#type_Integer">Integer</a><td>
How long is the creator of this packet going to wait before
resending this packet (if it hasn't yet been ACKed). The
value is seconds since the packet was created.
Currently ignored on receive.
<tr><td>flags <td>2 byte value<td>
See below.
<tr><td>option size<td>2 byte <a href="common_structures_spec.html#type_Integer">Integer</a><td>
The number of bytes in the next field
<tr><td>option data<td>0 or more bytes<td>
As specified by the flags. See below.
<tr><td>payload <td>remaining packet size<td>
</table>
<h3>Flags and Option Data Fields</h3>
<p>The flags field above specifies some metadata about the packet, and in
turn may require certain additional data to be included. The flags are
as follows. Any data structures specified must be added to the options area
in the given order.</p>
<p>
Bit order: 15....0 (15 is MSB)
</p>
<table>
<tr><th>Bit<th>Flag<th>Option Data<th>Function
<tr><td>0<td>SYNCHRONIZE<td align="center">--<td>
Similar to TCP SYN. Set in the intial packet and in the first response.
<tr><td>1<td>CLOSE<td align="center">--<td>
Similar to TCP FIN. If the response to a SYNCHRONIZE fits in a single message, the response
will contain both SYNCHRONIZE and CLOSE.
<tr><td>2<td>RESET<td align="center">--<td>
Abnormal close.
<tr><td>3<td>SIGNATURE_INCLUDED<td>40 byte <a href="common_structures_spec.html#type_Signature">DSA Signature</a>
<td>
Currently sent only with SYNCHRONIZE and CLOSE, where it is required.
The signature uses the Destination's <a href="common_structures_spec.html#type_SigningPublicKey">DSA signing keys</a>
to sign the entire header and payload with the 40-byte space in the option data field
for the signature being set to all zeroes.
<tr><td>4<td>SIGNATURE_REQUESTED<td align="center">--<td>
Unused. Requests every packet in the other direction to have SIGNATURE_INCLUDED
<tr><td>5<td>FROM_INCLUDED<td>387+ byte <a href="common_structures_spec.html#struct_Destination">Destination</a>
<td>
Currently sent only with SYNCHRONIZE, where it is required.
<tr><td>6<td>DELAY_REQUESTED<td>2 byte <a href="common_structures_spec.html#type_Integer">Integer</a><td>
Optional delay.
How many milliseconds the sender of this packet wants the recipient
to wait before sending any more data.
A value greater than 60000 indicates choking.
<tr><td>7<td>MAX_PACKET_SIZE_INCLUDED<td>2 byte <a href="common_structures_spec.html#type_Integer">Integer</a><td>
Currently sent with SYNCHRONIZE or with a retransmission;
could be optimized to only send with a SYN.
<tr><td>8<td>PROFILE_INTERACTIVE<td align="center">--<td>
Unused or ignored; the interactive profile is unimplemented.
<tr><td>9<td>ECHO<td align="center">--<td>
Unused except by ping programs
<tr><td>10<td>NO_ACK<td align="center">--<td>
This flag simply tells the recipient to ignore the ackThrough field in the header.
Currently unused, the ackThrough field is always valid.
<tr><td>11-15<td>unused<td><td>
</table>
<h2>Implementation Details</h2>
<h3>Setup</h3>
<p>
The initiator sends a packet with the SYNCHRONIZE flag set. This packet may contain the initial data as well.
The peer replies with a packet with the SYNCHRONIZE flag set. This packet may contain the initial response data as well.
</p>
<p>
The initiator may send additional data packets, up to the initial window size, before receiving the SYNCHRONIZE response.
These packets will also have the send Stream ID field set to 0.
Recipients must buffer packets received on unknown streams for a short period of time, as they may
arrive out of order, in advance of the SYNCHRONIZE packet.
</p>
<h3>MTU Selection and Negotiation</h3>
<p>
The maximum message size (also called the MTU / MRU) is negotiated to the lower value supported by
the two peers. As tunnel messages are padded to 1KB, a poor MTU selection will lead to
a large amount of overhead.
The MTU is chosen to fit precisely in an integral number of 1K I2NP tunnel messages,
The MTU is specified by the option i2p.streaming.maxMessageSize.
The current default MTU of 1730 was chosen to fit precisely into two 1K I2NP tunnel messages,
including overhead for the typical case.
</p>
<p>
The first message in a connection includes a 387 byte (typical) Destination added by the streaming layer,
and usually a 898 byte (typical) LeaseSet bundled in the Garlic message.
Therefore, the goal of fitting a complete HTTP request in a single 1KB I2NP message is not realistic.
and usually a 898 byte (typical) LeaseSet, and Session keys, bundled in the Garlic message by the router.
(The LeaseSet and Session Keys will not be bundled if an ElGamal Session was previously established).
Therefore, the goal of fitting a complete HTTP request in a single 1KB I2NP message is not always attainable.
However, the selection of the MTU, together with careful implementation of fragmentation
and batching strategies in the tunnel gateway processor, are important factors in network bandwidth,
latency, reliability, and efficiency, especially for long-lived connections.
</p>
<p>
The interaction of the routing algorithms with the streaming lib strongly affects performance.
In particular, random distribution of messages to multiple tunnels in a pool
leads to a high degree of out-of-order delivery which results in smaller window
sizes than would otherwise be the case.
In release 0.6.1.30, the routing of messages to the outbound tunnels was made
consistent, with pushback when a tunnel was backlogged.
This had a significant positive impact on bandwidths.
The pushback code was reverted in release 0.6.1.31 due to anonymity concerns.
Consistent message routing to inbound tunnels
was implemented in release 0.6.1.32.
</p>
<h3>Data Integrity</h3>
Data integrity is assured by the gzip CRC-32 checksum implemented in
<a href="i2cp.html#format">the I2CP layer</a>.
There is no checksum field in the streaming protocol.
<h3>Packet Encapsulation</h3>
Each packet is sent through I2P as a single message (or as an individual clove in a
<a href="how_garlicrouting.html">Garlic Message</a>).
Message encapsulation is implemented in the underlying
<a href="i2cp.html">I2CP</a>,
<a href="i2np.html">I2NP</a>, and
<a href="tunnel_message_spec.html">tunnel message</a>layers.
There is no packet delimiter mechanism or payload length field in the streaming protocol.
<h3>Windowing</h3>
<p>
Another area for research is the interaction of the streaming lib with the
NTCP and SSU transport layers.
See <a href="ntcp.html">the NTCP page</a> for a discussion.
The streaming lib uses standard slow-start (exponential window growth) and congestion avoidance (linear window growth)
phases, with exponential backoff.
Windowing and acknowledgements use packet count, not byte count.
</p>
<h2>Packet Format</h2>
<h3>Close</h3>
<p>
Here is the format of a single packet transferred as part of a streaming connection.
<table>
<tr><th>Field<th>Length<th>Contents
<tr><td>sendStreamId <td>4 byte value<td>Random number selected by the connection recipient
and constant for the life of the connection.
0 in the SYN message sent by the originator.
<tr><td>receiveStreamId <td>4 byte value<td>Random number selected by the connection originator
and constant for the life of the connection.
<tr><td>sequenceNum <td>4 byte unsigned integer<td>
The sequence for this message, starting at 0 in the SYN message,
and incremented by 1 in each message except for plain ACKs and retransmissions.
If the sequenceNum is 0 and the SYN is not set, this is a plain ACK
packet that should not be ACKed.
<tr><td>ackThrough <td>4 byte unsigned integer<td>
The highest packet sequence number that was received
on the receiveStreamId. This field is ignored on the initial
connection packet (where receiveStreamId is the unknown id) or
if FLAG_NO_ACK is set.
All packets up to and including this sequence number are ACKed,
EXCEPT for those listed in NACKs below.
<tr><td>number of NACKs <td>1 byte unsigned integer<td>
<tr><td>that many NACKs <td>n * 4 byte unsigned integers<td>
Sequence numbers less than ackThrough that are not yet received.
Two NACKs of a packet is a request for a 'fast retransmit' of that packet.
<tr><td>resendDelay <td>1 byte unsigned integer<td>
How long is the creator of this packet going to wait before
resending this packet (if it hasn't yet been ACKed). The
value is seconds since the packet was created.
Ignored on receive. Broken on send before release 0.7.8 (the sender did not divide by 1000,
and the default is 1000 ms, so the included value was 1000 &amp 0xff = 0xe8 = 232 seconds.
<tr><td>flags <td>2 byte value<td>
See below.
<tr><td>option data size <td>2 byte unsigned integer<td>
See below.
<tr><td>option data specified by those flags <td>0 or more bytes<td>
See below.
<tr><td>payload <td>remaining packet size<td>
</table>
<p>The flags field above specifies some metadata about the packet, and in
turn may require certain additional data to be included. The flags are
as follows (with any data structures specified added to the options area
in the given order):</p>
<table>
<tr><th>Bit Number<th>Flag<th>Option Data<th>Function
<tr><td>0<td>FLAG_SYNCHRONIZE<td>no option data<td>
Similar to TCP SYN.
<tr><td>1<td>FLAG_CLOSE<td>no option data<td>
Similar to TCP FIN. If the response to a SYN fits in a single message, the response
will contain both FLAG_SYNCHRONIZE and FLAG_CLOSE.
<tr><td>2<td>FLAG_RESET<td>no option data<td>
Abnormal close.
<tr><td>3<td>FLAG_SIGNATURE_INCLUDED<td>40 bytes<td>net.i2p.data.Signature
Typically sent only with FLAG_SYNCHRONIZE and FLAG_CLOSE, where it is required.
If the signature is included, it uses the Destination's DSA key
to sign the entire header and payload with the space in the options
for the signature being set to all zeroes.
<tr><td>4<td>FLAG_SIGNATURE_REQUESTED<td>no option data<td>
Unused. Requests every packet in the other direction to have FLAG_SIGNATURE_INCLUDED
<tr><td>5<td>FLAG_FROM_INCLUDED<td>typ. 387 bytes<td>net.i2p.data.Destination
Typically sent only with FLAG_SYNCHRONIZE.
<tr><td>6<td>FLAG_DELAY_REQUESTED<td>2 byte integer<td>
Optional delay.
How many milliseconds the sender of this packet wants the recipient
to wait before sending any more data.
A value greater than 60000 indicates choking.
<tr><td>7<td>FLAG_MAX_PACKET_SIZE_INCLUDED<td>2 byte integer<td>
Sent with FLAG_SYNCHRONIZE or with a retransmission,
could be optimized to only send with a SYN.
<tr><td>8<td>FLAG_PROFILE_INTERACTIVE<td>no option data<td>
Apparently unused or ignored
<tr><td>9<td>FLAG_ECHO<td>no option data<td>
Unused except by ping programs
<tr><td>10<td>FLAG_NO_ACK<td>no option data<td>
Apparently unused, an ACK is always included.
This flag simply tells the recipient to ignore the ackThrough field in the header.
<tr><td>11-15<td>unused<td><td>
</table>
Any packet, including one with the SYNCHRONIZE flag set, may have the CLOSE flag sent as well.
The connection is not closed until the peer responds with the CLOSE flag.
CLOSE packets may contain data as well.
</p>
<h2>Control Block Sharing</h2>
<h3 id="sharing">Control Block Sharing</h3>
<p>
As of release 0.7.1, the streaming lib supports "TCP" Control Block sharing.
The streaming lib supports "TCP" Control Block sharing.
This shares two important streaming lib parameters
(window size and round trip time)
across connections to the same remote peer.
This is used for "temporal" sharing at connection open/close time,
not "ensemble" sharing during a connection (See RFC 2140).
not "ensemble" sharing during a connection (See
<a href="http://www.ietf.org/rfc/rfc2140.txt">RFC 2140</a>).
There is a separate share per ConnectionManager (i.e. per local Destination)
so that there is no information leakage to other Destinations on the
same router.
The share data for a given peer expires after a few minutes.
</p>
<h2>Future Work and Proposals</h2>
<h3 id="other">Other Parameters</h3>
The following parameters are hardcoded, but may be of interest for analysis:
<ul>
<li>MIN_RESEND_DELAY = 2*1000 (minimum RTO)
<li>MAX_RESEND_DELAY = 45*1000 (maximum RTO)
<li>MIN_WINDOW_SIZE = 1
<li>TREND_COUNT = 3
<li>RTT_DAMPENING = 0.875
<li>MIN_MESSAGE_SIZE = 512 (minimum MTU)
<li>INBOUND_BUFFER_SIZE = maxMessageSize * (maxWindowSize + 2)
<li>INITIAL_TIMEOUT = 1.5 * initialRTT
<li>PASSIVE_FLUSH_DELAY = 250
<li>Maximum RTT estimate: 60*1000
</ul>
</p>
<h3>History</h3>
<p>
The streaming library has grown organically for I2P - first mihi implemented the
"mini streaming library" as part of I2PTunnel, which was limited to a window
size of 1 message (requiring an ACK before sending the next one), and then it was
refactored out into a generic streaming interface (mirroring TCP sockets) and the
full streaming implementation was deployed with a sliding window protocol and
optimizations to take into account the high bandwidth x delay product. Individual
streams may adjust the maximum packet size and other options. The default
message size is selected to fit precisely in two 1K I2NP tunnel messages,
and is a reasonable tradeoff between the bandwidth costs of
retransmitting lost messages, and the latency and overhead of multiple messages.
</p>
<h2 id="future">Future Work</h2>
The behavior of the streaming library has a profound impact on
application-level performance, and as such, is an important
area for further analysis.
<ul>
<li>
Additional tuning of the streaming lib parameters may be necessary.
</li>
<li>
Another area for research is the interaction of the streaming lib with the
NTCP and SSU transport layers.
See <a href="ntcp_discussion.html">the NTCP discussion page</a> for details.
</li>
<li>
The interaction of the routing algorithms with the streaming lib strongly affects performance.
In particular, random distribution of messages to multiple tunnels in a pool
leads to a high degree of out-of-order delivery which results in smaller window
sizes than would otherwise be the case.
The router currently routes messages for a single from/to destination pair
through a consistent set of tunnels, until tunnel expiration or deli>very failure.
The router's failure and tunnel selection algorithms should be reviewed
for possible improvements.
</li>
<li>
The data in the first SYN packet may exceed the receiver's MTU.
</li>
<li>
The DELAY_REQUESTED field could be used more.
</li>
<li>
Duplicate initial SYNCHRONIZE packets on short-lived streams may not be recognized and removed.
</li>
<li>
Don't send the MTU in a retransmission.
</li>
<li>
Data is sent along unless the outbound window is full.
(i.e. no-Nagle or TCP_NODELAY)
Probably should have a configuration option for this.
</li>
<li>
zzz has added debug code to the streaming library to log packets in a wireshark-compatible
(pcap) format; Use this to further analyze performance.
The format may require enhancement to map more streaming lib parameters to TCP fields.
</li>
<li>
There are proposals to replace the streaming lib with standard TCP
(or perhaps a null layer together with raw sockets).
This would unfortunately be incompatible with the streaming lib
but it would be good to compare the performance of the two.
</p>
</li>
</ul>
{% endblock %}

995
www.i2p2/pages/supported_applications.html Normal file
View File

@ -0,0 +1,995 @@
{% extends "_layout.html" %}
{% block title %}Supported Applications{% endblock %}
{% block content %}
<h1 class="title">Supported Applications</h1>
<div id="TOC"
><ul
><li
><a href="#blogging-and-forums"
>Blogging and Forums</a
></li
><li
><a href="#decentralized-file-storage"
>Decentralized File Storage</a
></li
><li
><a href="#development-tools"
>Development Tools</a
><ul
><li
><a href="#version-control"
>Version control</a
></li
></ul
></li
><li
><a href="#domain-naming"
>Domain Naming</a
></li
><li
><a href="#email"
>Email</a
></li
><li
><a href="#file-sharing"
>File Sharing</a
><ul
><li
><a href="#bittorrent-clients"
>BitTorrent clients</a
></li
><li
><a href="#bittorrent-trackers-and-indexers"
>BitTorrent trackers and indexers</a
></li
><li
><a href="#ed2k"
>ED2K</a
></li
><li
><a href="#gnutella"
>Gnutella</a
></li
></ul
></li
><li
><a href="#network-administration"
>Network Administration</a
><ul
><li
><a href="#general-purpose-socket-utilities"
>General-purpose socket utilities</a
></li
><li
><a href="#sshscpsftp"
>SSH/SCP/SFTP</a
></li
></ul
></li
><li
><a href="#real-time-chat"
>Real-time Chat</a
><ul
><li
><a href="#instant-messaging-clients"
>Instant messaging clients</a
></li
><li
><a href="#irc-clients"
>IRC clients</a
></li
><li
><a href="#irc-servers"
>IRC servers</a
></li
></ul
></li
><li
><a href="#web-browsing"
>Web Browsing</a
><ul
><li
><a href="#anonymous-websites"
>Anonymous websites</a
></li
><li
><a href="#proxy-software"
>Proxy software</a
></li
><li
><a href="#inproxies"
>Inproxies</a
></li
><li
><a href="#outproxies"
>Outproxies</a
></li
></ul
></li
><li
><a href="#website-hosting"
>Website Hosting</a
><ul
><li
><a href="#web-servers"
>Web servers</a
></li
></ul
></li
></ul
></div
>
<p
>This is intended to be a comprehensive listing of applications used with I2P. If you know of something that’s missing please submit a ticket on <a href="http://trac.i2p2.de/newticket/"
>Trac</a
>, and be sure to select the “www” component in the submission form.</p
><p
>Supported applications are tagged with one or more of the following:</p
><dl
><dt
><em
>bundled</em
></dt
><dd
><p
><em
>Bundled application</em
> — I2P ships with a few officially supported applications that let new users take immediate advantage of some of I2P’s more useful capabilities.</p
></dd
><dt
><em
>plugin</em
></dt
><dd
><p
><em
>Third-party plugin</em
> — I2P’s plugin system provides convenient deployment of I2P-enabled applications and allows tighter integration with the router.</p
></dd
></dl
><!--
Leaving this line out until we can link to a plugin review site which is more
concerned with promoting its trustworthiness than with posing as "edgy,"
subversive, or with similarly counterproductive affectations:
Plugins are [reviewed by the community](http://i2plugins.i2p) to identify
security and anonymity issues.
-->
<dl
><dt
><em
>standalone, standalone/mod</em
></dt
><dd
><p
><em
>Third-party standalone application</em
> — Many standard network applications only require careful setup and configuration to communicate anonymously over I2P. These are tagged with <em
>standalone</em
>. Some applications, tagged with <em
>standalone/mod</em
>, require patching to function properly over I2P or to prevent inadvertent disclosure of identifying information such as the user’s hostname or external IP address.</p
></dd
><dt
><em
>service</em
></dt
><dd
><p
><em
>Third-party essential network service</em
> — Services which on the I2P network are analogous to those provided on the public Internet by hosting providers, ISPs, and Google: eepsite indexes and jump services, search engines, email, DNS-style name services, hosting, proxies, etc. These services focus on boosting the usefulness of the network as a whole, and making network content more discoverable.</p
></dd
><dt
><em
>unmaintained</em
></dt
><dd
><p
><em
>Unmaintained</em
> — This is used to tag plugins, applications, and services which appear to be unmaintained and may be removed from this listing in the future.</p
></dd
></dl
><p
><strong
>Warning: Using an application, plugin, or service with I2P doesn’t automatically protect your anonymity. I2P is merely a set of tools which can help you mitigate certain <a href="how_threatmodel"
>identified threats to anonymity</a
>. We do not and cannot make any guarantees about the safety of the applications, plugins, and services listed below. Most applications and plugins must be properly configured, and some will need to be patched — and even then your anonymity might not be assured. Similarly, services could put your anonymity at risk, either by design or through carelessness on their part or your own.</strong
></p
><p
><strong
>If you have doubts about the suitability of an application, plugin, or service for use with I2P, you are urged to inquire about privacy issues with its maintainers, to search its mailing lists and bug tracker if one exists, and consult trusted, knowledgeable members of the I2P community.</strong
></p
><p
><strong
>Take responsibility for your own anonymity and safety — always seek expert advice, educate yourself, practice good judgment, be mindful of disclosing personally identifying information, and don’t take shortcuts.</strong
></p
><h3 id="blogging-and-forums"
><a href="#TOC"
>Blogging and Forums</a
></h3
><ul
><li
><p
><a href="http://www.blojsom.com/blog/"
><strong
>Blojsom</strong
></a
> — Lightweight blogging platform. <sup
><em
>[plugin, standalone/mod]</em
></sup
></p
></li
><li
><p
><a href="http://github.com/trevorturk/eldorado/"
><strong
>El Dorado</strong
></a
> — Lightweight forum software. <sup
><em
>[standalone/mod]</em
></sup
></p
></li
><li
><p
><a href="http://pebble.sourceforge.net/"
><strong
>Pebble</strong
></a
> — Another lightweight blogging platform. <sup
><em
>[plugin, standalone/mod]</em
></sup
></p
></li
><li
><p
><a href="http://www.phpbb.com/"
><strong
>phpBB</strong
></a
> — Most popular open source forum software. <sup
><em
>[standalone/mod]</em
></sup
></p
></li
><li
><p
><a href="http://syndie.i2p2.de/"
><strong
>Syndie</strong
></a
> — Distributed forums software, originally developed by jrandom. <sup
><em
>[plugin, standalone, unmaintained]</em
></sup
></p
></li
></ul
><h3 id="decentralized-file-storage"
><a href="#TOC"
>Decentralized File Storage</a
></h3
><ul
><li
><a href="http://duck.i2p/tahoe-lafs/"
><strong
>Tahoe-LAFS-I2P</strong
></a
> — Port of the <a href="http://tahoe-lafs.org/"
><strong
>Tahoe-LAFS</strong
></a
> distributed file system to the I2P network. Controller plugin <a href="http://stats.i2p/i2p/plugins/"
>here</a
>. <sup
><em
>[plugin, standalone]</em
></sup
></li
></ul
><h3 id="development-tools"
><a href="#TOC"
>Development Tools</a
></h3
><h4 id="version-control"
><a href="#TOC"
>Version control</a
></h4
><ul
><li
><p
><a href="http://git-scm.com/"
><strong
>Git</strong
></a
> — Most popular distributed version control system. <sup
><em
>[standalone]</em
></sup
></p
></li
><li
><p
><a href="http://monotone.ca/"
><strong
>Monotone</strong
></a
> — Another distributed version control system. Currently <a href="monotone.html"
>used in I2P development</a
>. <sup
><em
>[standalone]</em
></sup
></p
></li
></ul
><h3 id="domain-naming"
><a href="#TOC"
>Domain Naming</a
></h3
><ul
><li
><a href="http://127.0.0.1:7657/susidns/"
><strong
>susidns</strong
></a
> — Provides management of addressbooks, which are part of a simple, user-controlled <a href="naming.html"
>I2P naming system</a
> somewhat analogous to the Internet’s Domain Name System (DNS). Addressbooks map Base64 destinations to short, usually human-readable “domain” names ending with a .i2p suffix which the I2P router’s HTTP client can resolve back to Base64 addresses. (<em
>Note:</em
> While Base64 destinations are globally unique, addressbook “domain” names only resolve to unique destinations locally.) <sup
><em
>[bundled]</em
></sup
></li
></ul
><h3 id="email"
><a href="#TOC"
>Email</a
></h3
><ul
><li
><p
><a href="http://i2pbote.i2p/"
><strong
>I2P-Bote</strong
></a
> — Serverless peer-to-peer email application using a distributed hash table (DHT) for secure mail storage. <sup
><em
>[plugin]</em
></sup
></p
></li
><li
><p
><a href="http://hq.postman.i2p/"
><strong
>Postman’s anonymous email service</strong
></a
> — Provides email service within the I2P network via @mail.i2p addresses, and email gateway service between the I2P network and the public Internet via @i2pmail.org addresses. One of the oldest continuous services on I2P. <sup
><em
>[service]</em
></sup
></p
></li
><li
><p
><a href="http://127.0.0.1:7657/susimail/susimail"
><strong
>susimail</strong
></a
> — Simple web browser-based email interface. Configured to use Postman’s email service by default. <sup
><em
>[bundled]</em
></sup
></p
></li
></ul
><h3 id="file-sharing"
><a href="#TOC"
>File Sharing</a
></h3
><h4 id="bittorrent-clients"
><a href="#TOC"
>BitTorrent clients</a
></h4
><ul
><li
><p
><a href="http://127.0.0.1:7657/i2psnark/"
><strong
>I2PSnark</strong
></a
> — I2P’s integrated BitTorrent client. <sup
><em
>[bundled]</em
></sup
></p
></li
><li
><p
><a href="http://forum.i2p/viewtopic.php?t=4532"
><strong
>I2PSnarkXL</strong
></a
> — Modified version of I2PSnark. <sup
><em
>[standalone]</em
></sup
></p
></li
><li
><p
><a href="http://bob.i2p/Robert.html"
><strong
>Robert</strong
></a
> — a fork of rufus that uses the Basic Open Bridge (BOB) and has many improvements, including using the latest wxwidgets and python. It also supports use of seedless if installed for trackerless torrents and magnet-link like fetching of torrents within i2p. <sup
><em
>[plugin, standalone]</em
></sup
></p
></li
><li
><p
><a href="http://www.transmissionbt.com/"
><strong
>Transmission</strong
></a
> — Clean, full-featured cross-platform BitTorrent client with official ports for several GUI toolkits. <sup
><em
>[standalone/mod]</em
></sup
></p
></li
><li
><p
><a href="http://www.vuze.com/"
><strong
>Azureus/Vuze</strong
></a
> — Had a built-in I2P transport for a while. <sup
><em
>[standalone, unmaintained]</em
></sup
></p
></li
></ul
><h4 id="bittorrent-trackers-and-indexers"
><a href="#TOC"
>BitTorrent trackers and indexers</a
></h4
><p
>For a detailed feature comparison of I2P-enabled trackers/indexers, see <a href="http://zzz.i2p/files/trackers.html"
>here</a
>.</p
><ul
><li
><p
><a href="http://echelon.i2p/tracker/"
><strong
>Bytemonsoon</strong
></a
> — The code that powered one of the first major tracker/indexer sites on the Internet. Patched for I2P. <sup
><em
>[standalone/mod]</em
></sup
></p
></li
><li
><p
><a href="http://erdgeist.org/arts/software/opentracker/"
><strong
>opentracker</strong
></a
> — Lightweight tracker/indexer. I2P mod available in the i2p.opentracker branch of the <a href="newdevelopers.html"
>I2P Monotone repository</a
>. <sup
><em
>[standalone/mod]</em
></sup
></p
></li
><li
><p
><a href="http://stats.i2p/i2p/plugins/"
><strong
>zzzot</strong
></a
> — <a href="http://zzz.i2p/"
>zzz’s</a
> Java-based open tracker. More info <a href="http://zzz.i2p/topics/598?page=1#p2085"
>here</a
>. <sup
><em
>[plugin]</em
></sup
></p
></li
></ul
><h4 id="ed2k"
><a href="#TOC"
>ED2K</a
></h4
><ul
><li
><a href="http://forum.i2p/viewtopic.php?t=2213"
><strong
>iMule</strong
></a
> — I2P port of the aMule ED2K client. <sup
><em
>[standalone]</em
></sup
></li
></ul
><h4 id="gnutella"
><a href="#TOC"
>Gnutella</a
></h4
><ul
><li
><p
><a href="http://forum.i2p/viewforum.php?f=25"
><strong
>I2Phex</strong
></a
> — Port of the <a href="http://www.phex.org/"
>Phex</a
> Gnutella client. Website for plugin version <a href="http://stats.i2p/i2p/plugins/"
>here</a
>. <sup
><em
>[plugin, standalone]</em
></sup
></p
></li
><li
><p
><a href="http://forum.i2p/viewtopic.php?p=9486#9486"
><strong
>jwebcache</strong
></a
> — Cache for Gnutella peers on I2P. Website for plugin version <a href="http://stats.i2p/i2p/plugins/"
>here</a
>. <sup
><em
>[plugin, standalone]</em
></sup
></p
></li
></ul
><h3 id="network-administration"
><a href="#TOC"
>Network Administration</a
></h3
><h4 id="general-purpose-socket-utilities"
><a href="#TOC"
>General-purpose socket utilities</a
></h4
><ul
><li
><p
><a href="http://nc110.sourceforge.net/"
><strong
>netcat</strong
></a
> — Unix standard tool for socket relaying. Several clones, ports, and forks have appeared over the years. <sup
><em
>[standalone]</em
></sup
></p
></li
><li
><p
><a href="http://www.dest-unreach.org/socat/"
><strong
>socat</strong
></a
> — Like netcat but more powerful. <sup
><em
>[standalone]</em
></sup
></p
></li
><li
><p
><a href="http://tsocks.sourceforge.net/"
><strong
>tsocks</strong
></a
> — Proxy providing simple, transparent SOCKS-ification of network applications. <sup
><em
>[standalone]</em
></sup
></p
></li
></ul
><h4 id="sshscpsftp"
><a href="#TOC"
>SSH/SCP/SFTP</a
></h4
><ul
><li
><p
><a href="http://www.openssh.com/"
><strong
>OpenSSH</strong
></a
> — Most popular implementation of the Secure Shell (SSH) protocol and related tools. <sup
><em
>[standalone]</em
></sup
></p
></li
><li
><p
><a href="http://www.chiark.greenend.org.uk/~sgtatham/putty/"
><strong
>PuTTY</strong
></a
> — Open source Secure Shell (SSH) client for Windows. <sup
><em
>[standalone]</em
></sup
></p
></li
></ul
><h3 id="real-time-chat"
><a href="#TOC"
>Real-time Chat</a
></h3
><h4 id="instant-messaging-clients"
><a href="#TOC"
>Instant messaging clients</a
></h4
><ul
><li
><a href="http://forum.i2p/viewtopic.php?t=2474"
><strong
>I2P Messenger</strong
></a
> — IM client with multiple incarnations. <sup
><em
>[standalone]</em
></sup
></li
></ul
><h4 id="irc-clients"
><a href="#TOC"
>IRC clients</a
></h4
><p
>Many IRC clients leak identifying information to servers or other clients, so I2P’s IRC and SOCKS IRC client tunnels filter certain inbound and outbound messages to scrub data such as LAN IP addresses, external IP addresses, local hostnames, and the name and version of the IRC client. Two message types in particular, DCC and CTCP, can’t be sufficiently anonymized without changes to the protocols or to IRC client/server code, so they are completely blocked, except for CTCP ACTION (the message emitted by the <code
>/me</code
> command) which isn’t inherently dangerous.</p
><p
>I2P’s IRC filtering may not cover every possible leak — users should also check if their client is sending their real name or local username. Packet sniffers such as <a href="http://www.wireshark.org/"
>Wireshark</a
> are useful here. Eliminating remaining leaks may be as simple as changing the client’s default configuration. If that doesn’t help, inform the I2P developers; they may be able to solve it via additional filtering.</p
><ul
><li
><p
><a href="http://jircii.dashnine.org/"
><strong
>jIRCii</strong
></a
> — Small Java-based IRC client. Plugin available <a href="http://stats.i2p/i2p/plugins/"
>here</a
>. <sup
><em
>[plugin, standalone]</em
></sup
></p
></li
><li
><p
><a href="http://xchat.org/"
><strong
>XChat</strong
></a
> — Cross-platform graphical IRC client. <sup
><em
>[standalone]</em
></sup
></p
></li
><li
><p
><a href="http://www.irssi.org/"
><strong
>irssi</strong
></a
> — Unixy terminal-based IRC client. <sup
><em
>[standalone]</em
></sup
></p
></li
><li
><p
><a href="http://www.weechat.org/"
><strong
>WeeChat</strong
></a
> — Another Unixy terminal-based IRC client. <sup
><em
>[standalone]</em
></sup
></p
></li
></ul
><h4 id="irc-servers"
><a href="#TOC"
>IRC servers</a
></h4
><ul
><li
><p
><a href="http://ngircd.barton.de/index.php.en"
><strong
>ngIRCd</strong
></a
> — IRC server developed from scratch. <sup
><em
>[standalone/mod]</em
></sup
></p
></li
><li
><p
><a href="http://www.unrealircd.com/"
><strong
>UnrealIRCd</strong
></a
> — Most popular IRC server. <sup
><em
>[standalone/mod]</em
></sup
></p
></li
></ul
><h3 id="web-browsing"
><a href="#TOC"
>Web Browsing</a
></h3
><h4 id="anonymous-websites"
><a href="#TOC"
>Anonymous websites</a
></h4
><ul
><li
><p
><strong
>Eepsites</strong
> — Any website hosted anonymously on I2P, reachable through the I2P router’s HTTP proxy. <sup
><em
>[service]</em
></sup
></p
></li
><li
><p
><strong
>Deepsites</strong
> — Distributed anonymous websites hosted using Tahoe-LAFS-I2P, currently only reachable with Tahoe-LAFS-I2P clients or through the Tahoe-LAFS-I2P HTTP proxy. <sup
><em
>[service]</em
></sup
></p
></li
><li
><p
><a href="http://i2host.i2p/"
><strong
>i2host.i2p</strong
></a
> — Website for <a href="http://sponge.i2p/"
>sponge’s</a
> jump service. Source code available. <sup
><em
>[service]</em
></sup
></p
></li
><li
><p
><a href="http://i2jump.i2p/"
><strong
>i2jump.i2p</strong
></a
> — Another jump service. <sup
><em
>[service]</em
></sup
></p
></li
><li
><p
><a href="http://perv.i2p/"
><strong
>perv.i2p</strong
></a
> — Dynamically updated eepsite index. <sup
><em
>[service]</em
></sup
></p
></li
><li
><p
><a href="http://stats.i2p/"
><strong
>stats.i2p</strong
></a
> — Website for <a href="http://zzz.i2p/"
>zzz’s</a
> jump service. <sup
><em
>[service]</em
></sup
></p
></li
></ul
><h4 id="proxy-software"
><a href="#TOC"
>Proxy software</a
></h4
><ul
><li
><p
><a href="http://www.pps.jussieu.fr/~jch/software/polipo/"
><strong
>Polipo</strong
></a
> — SOCKS-enabled caching web proxy with basic filtering capabilities. <sup
><em
>[standalone]</em
></sup
></p
></li
><li
><p
><a href="http://www.privoxy.org/"
><strong
>Privoxy</strong
></a
> — Privacy-focused non-caching web proxy with advanced filtering capabilities. Excels at removing ads and other junk. <sup
><em
>[standalone]</em
></sup
></p
></li
><li
><p
><a href="http://www.squid-cache.org/"
><strong
>Squid</strong
></a
> — Venerable caching web proxy. <sup
><em
>[standalone]</em
></sup
></p
></li
></ul
><h4 id="inproxies"
><a href="#TOC"
>Inproxies</a
></h4
><p
>Gateways allowing users on the public Internet to access eepsites.</p
><ul
><li
><a href="http://i2p.to/"
><strong
>i2p.to</strong
></a
> — <a href="http://tino.i2p/"
>tino’s</a
> inproxy on the public Internet. <sup
><em
>[service]</em
></sup
></li
></ul
><h4 id="outproxies"
><a href="#TOC"
>Outproxies</a
></h4
><p
>Gateways allowing I2P users to access content hosted on the public Internet.</p
><ul
><li
><a href="http://false.i2p/"
><strong
>false.i2p</strong
></a
> — Publicly advertised outproxy running Squid. Appears to be located in Germany. <sup
><em
>[service]</em
></sup
></li
></ul
><h3 id="website-hosting"
><a href="#TOC"
>Website Hosting</a
></h3
><ul
><li
><a href="http://jetty.codehaus.org/jetty/"
><strong
>Jetty</strong
></a
> — Lightweight web server and Java servlet container. I2P is tightly integrated with a bundled copy of Jetty which by default is configured to host the <a href="http://127.0.0.1:7658/"
>user’s eepsite</a
>. The bundled Jetty also serves the I2P router console and web applications bundled with I2P. <sup
><em
>[bundled, standalone]</em
></sup
></li
></ul
><h4 id="web-servers"
><a href="#TOC"
>Web servers</a
></h4
><p
>In addition to Jetty, any web server should function over I2P without modification so long as it’s HTTP-compliant. Some web servers known to currently serve content on the I2P network are:</p
><ul
><li
><p
><a href="http://httpd.apache.org/"
><strong
>Apache HTTP Server</strong
></a
> — Most popular web server on the public WWW. <sup
><em
>[standalone]</em
></sup
></p
></li
><li
><p
><a href="http://tomcat.apache.org/"
><strong
>Apache Tomcat</strong
></a
> — Web server and Java servlet container. More features than Jetty. <sup
><em
>[standalone]</em
></sup
></p
></li
><li
><p
><a href="http://www.lighttpd.net/"
><strong
>lighttpd</strong
></a
> — Fast lightweight web server. <sup
><em
>[standalone]</em
></sup
></p
></li
><li
><p
><a href="http://www.nginx.org/"
><strong
>nginx</strong
></a
> — High-performance lightweight web server. <sup
><em
>[standalone]</em
></sup
></p
></li
></ul
><!-- vim: set ft=pdc tw=79 spell spelllang=en: -->
{% endblock %}

4
www.i2p2/pages/team.html
View File

@ -27,7 +27,7 @@ network.
</tr>
<tr>
<td valign="top"><b><a href="http://forum.i2p/">Forum</a> admin</b></td>
<td valign="top">cervantes, smeghead</td>
<td valign="top">cervantes</td>
<td valign="top"><i>manage the public user forum</i></td>
</tr>
<tr>
@ -42,7 +42,7 @@ network.
</tr>
<tr>
<td valign="top"><b>Packager; Linux</b></td>
<td valign="top">smeghead</td>
<td valign="top" style="color:blue">[vacant]</td>
<td valign="top"><i>Linux distribution packager</i></td>
</tr>
<tr>

356
www.i2p2/pages/techintro.html
View File

@ -6,80 +6,24 @@
<b class="title">
<h1>I2P: <font size="3">A scalable framework for anonymous communication</font></h1>
</b>
<br/>
<div class="toc">
<table border="0">
<tr class="invisible">
<td valign="top" align="left" class="invisible"> <pre>
<font size="2"><b>IN THIS DOCUMENT</b></font><br />
* <a href="#intro">Introduction</a>
* <a href="#op">Operation</a>
* <a href="#op.overview">Overview</a>
* <a href="#op.tunnels">Tunnels</a>
* <a href="#op.netdb">Network Database</a>
* <a href="#op.transport">Transport protocols</a>
* <a href="#op.crypto">Cryptography</a>
</pre></td>
<td valign="top" align="left" class="invisible"> <pre>
<br/>
* <a href="#future">Future</a>
* <a href="#future.restricted">Restricted routes</a>
* <a href="#future.variablelatency">Variable latency</a>
* <a href="#future.open">Open questions</a>
</pre></td>
<td valign="top" align="left" class="invisible"> <pre>
<br/>
* <a href="#similar">Similar systems</a>
* <a href="#similar.tor">Tor</a>
* <a href="#similar.freenet">Freenet</a>
* <a href="#app">Appendix A: Application layer</a>
</pre></td>
</tr>
<tr class="invisible">
<td height="10" colspan="3" align="left" valign="middle" class="invisible">
<div class="underline"></div></td>
</tr>
<tr class="invisible">
<td valign="top" align="left" class="invisible"><pre>
<font size="2"><b>FOR MORE INFORMATION</b></font><br>
* <a href="package-client.html">Client Javadoc</a>
* <a href="datagrams.html">Datagrams</a>
* <a href="package-datagram.html">Datagram Javadoc</a>
* <a href="_static/pdf/datastructures.pdf">Data Structures</a>
* <a href="i2cp.html">I2CP</a>
* <a href="i2np.html">I2NP</a>
* <a href="i2ptunnel.html">I2PTunnel</a>
* <a href="ministreaming.html">Ministreaming Lib</a>
* <a href="how_networkdatabase.html">NetDb</a>
</pre></td>
<td valign="top" align="left" class="invisible"><pre><br/>
* <a href="naming.html">Naming and Addressbook</a>
* <a href="package-naming.html">Naming Javadoc</a>
* <a href="jbigi.html">Native BigInteger Lib</a>
* <a href="ntcp.html">NTCP</a>
* <a href="how_peerselection.html">Peer Selection</a>
* <a href="performance.html">Performance</a>
* <a href="protocols.html">Protocol Stack</a>
* <a href="sam.html">SAM</a>
* <a href="samv2.html">SAM V2</a>
* <a href="samv3.html">SAM V3</a>
* <a href="bob.html">BOB</a>
</pre></td>
<td valign="top" align="left" class="invisible"><pre><br/>
* <a href="socks.html">SOCKS</a>
* <a href="udp.html">SSU</a>
* <a href="streaming.html">Streaming Lib</a>
* <a href="package-streaming.html">Streaming Javadoc</a>
* <a href="http://syndie.i2p2.de/">Syndie</a>
* <a href="package-tcp.html">Old TCP Javadoc</a>
* <a href="tunnel-alt.html">Tunnel Implementation</a>
* <a href="tunnel-alt-creation.html">Tunnel Creation</a>
* <a href="tunnel.html">Old Tunnel Implementation</a>
</pre></td>
</tr>
</table>
</div>
</center>
<div id="toc">
<h2>Table of Contents</h2>
<ul>
<li><a href="#intro">Introduction</a></li>
<li>
<a href="#op">I2P Operation</a>
<ul>
<li><a href="#op.overview">Overview</a></li>
<li><a href="#op.tunnels">Tunnels</a></li>
<li><a href="#op.netdb">Network Database</a></li>
<li><a href="#op.transport">Transport protocols</a></li>
<li><a href="#op.crypto">Cryptography</a></li>
</ul>
</li>
</ul>
</div>
<br/>
<h1 id="intro">Introduction</h1>
<p>
@ -168,7 +112,13 @@
and an end point. Messages can be sent only in one way. To send messages back,
another tunnel is required.
</p>
<center><div class="box"><img src="_static/images/tunnels.png" alt="Inbound and outbound tunnel schematic" title="Inbound and outbound tunnel schematic" /></div></center><br/>
<center>
<div class="box">
<img src="_static/images/tunnels.png" alt="Inbound and outbound tunnel schematic" title="Inbound and outbound tunnel schematic" />
<br /><br />
Figure 1: Two types of tunnels exist: inbound and outbound.
</div>
</center><br/>
<p>
Two types of tunnels exist:
<b>"outbound" tunnels</b> send messages away from the tunnel creator,
@ -186,24 +136,42 @@
inbound gateway (the gateway to "Bob").
</p>
<p>
A third critical concept to understand is I2P's "network database" (or "netDb")
A third critical concept to understand is I2P's <b>"network database"</b> (or "netDb")
- a pair of algorithms used to share network metadata. The two types of metadata
carried are "routerInfo" and "leaseSets" - the routerInfo gives routers the
carried are <b>"routerInfo"</b> and <b>"leaseSets"</b> - the routerInfo gives routers the
data necessary for contacting a particular router (their public keys, transport
addresses, etc), while the leaseSet gives routers the information necessary
for contacting a particular destination. Within each leaseSet, there are any
number of "leases", each of which specifies the gateway for one of that destination's
inbound tunnels as well as when that tunnel will expire. The leaseSet also
contains a pair of public keys which can be used for layered garlic encryption.
for contacting a particular destination. A leaseSet contains a number of "leases".
Each of this leases specifies a tunnel gateway, which allows reaching a specific destination.
The full information contained in a lease:
<ul>
<li>Inbound gateway for a tunnel that allows reaching a specific destination.</li>
<li>Time when a tunnel expires.</li>
<li>Pair of public keys to be able to encrypt messages (to send through the tunnel and reach the destination).</li>
</ul>
Routers themselves send their routerInfo to the netDb directly, while leaseSets are sent through outbound tunnels
(leaseSets need to be sent anonymously, to avoid correlating a router with his leaseSets).
</p>
<!--
<p>
I2P's operation can be understood by putting those three concepts together:
We can combine the above concepts to build successful connections in the network.
</p>
<p><img src="net.png"></p>
!-->
<p> When Alice wants to send a message to Bob, she first does a lookup in the
<p>
To build up her own inbound and outbound tunnels, Alice does a lookup in the netDb to collect routerInfo.
This way, she gathers lists of peers she can use as hops in her tunnels.
She can then send a build message to the first hop, requesting the construction of a tunnel, and asking
that router to send the construction message onward, until the tunnel has been constructed.
</p>
<center>
<div class="box">
<img src="_static/images/netdb_get_routerinfo_1.png" alt="Request information on other routers" title="Request information on other routers" />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<img src="_static/images/netdb_get_routerinfo_2.png" alt="Build tunnel using router information" title="Build tunnel using router information" />
<br /><br />
Figure 2: Router information is used to build tunnels.
</div>
</center><br/>
<p>
When Alice wants to send a message to Bob, she first does a lookup in the
netDb to find Bob's leaseSet, giving her his current inbound tunnel gateways.
She then picks one of her outbound tunnels and sends the message down it with
instructions for the outbound tunnel's endpoint to forward the message on
@ -211,12 +179,22 @@ I2P's operation can be understood by putting those three concepts together:
receives those instructions, it forwards the message as requested, and when
Bob's inbound tunnel gateway receives it, it is forwarded down the tunnel
to Bob's router. If Alice wants Bob to be able to reply to the message, she
needs to transmit her own destination explicitly as part of the message itself
(taken care of transparently in the <a href="#app.streaming">streaming</a>
library). Alice may also cut down on the response time by bundling her most
needs to transmit her own destination explicitly as part of the message itself.
This can be done by introducing a higher-level layer, which is done in the
<a href="#app.streaming">streaming</a> library.
Alice may also cut down on the response time by bundling her most
recent leaseSet with the message so that Bob doesn't need to do a netDb lookup
for it when he wants to reply, but this is optional. </p>
<p> While the tunnels themselves have layered encryption to prevent unauthorized
for it when he wants to reply, but this is optional.
</p>
<center>
<div class="box">
<img src="_static/images/netdb_get_leaseset.png" alt="Connect tunnels using leaseSets" title="Connect tunnels using leaseSets" />
<br /><br />
Figure 3: Leasesets are used to connect outbound and inbound tunnels.
</div>
</center><br/>
<p>
While the tunnels themselves have layered encryption to prevent unauthorized
disclosure to peers inside the network (as the transport layer itself does
to prevent unauthorized disclosure to peers outside the network), it is necessary
to add an additional end to end layer of encryption to hide the message from
@ -227,16 +205,20 @@ I2P's operation can be understood by putting those three concepts together:
those messages say, or where those individual cloves are destined. For typical
end to end communication between Alice and Bob, the garlic will be encrypted
to the public key published in Bob's leaseSet, allowing the message to be
encrypted without giving out the public key to Bob's own router. </p>
<p> Another important fact to keep in mind is that I2P is entirely message based
encrypted without giving out the public key to Bob's own router.
</p>
<p>
Another important fact to keep in mind is that I2P is entirely message based
and that some messages may be lost along the way. Applications using I2P can
use the message oriented interfaces and take care of their own congestion
control and reliability needs, but most would be best served by reusing the
provided <a href="#app.streaming">streaming</a> library to view I2P as a streams
based network. </p>
based network.
</p>
<h2 id="op.tunnels">Tunnels</h2>
<p> Both inbound and outbound tunnels work along similar principles - the tunnel
gateway accumulates a number of tunnel messages, eventually preprocessing
<p>
Both inbound and outbound tunnels work along similar principles.
The tunnel gateway accumulates a number of tunnel messages, eventually preprocessing
them into something for tunnel delivery. Next, the gateway encrypts that preprocessed
data and forwards it to the first hop. That peer and subsequent tunnel participants
add on a layer of encryption after verifying that it isn't a duplicate before
@ -246,18 +228,22 @@ I2P's operation can be understood by putting those three concepts together:
the creator is the endpoint and they simply decrypt all of the layers added,
while for outbound tunnels, the creator is the gateway and they pre-decrypt
all of the layers so that after all of the layers of per-hop encryption are
added, the message arrives in the clear at the tunnel endpoint. </p>
<p> The choice of specific peers to pass on messages as well as their particular
added, the message arrives in the clear at the tunnel endpoint.
</p>
<p>
The choice of specific peers to pass on messages as well as their particular
ordering is important to understanding both I2P's anonymity and performance
characteristics. While the network database (below) has its own criteria for
picking what peers to query and store entries on, tunnels may use any peers
picking what peers to query and store entries on, tunnel creators may use any peers
in the network in any order (and even any number of times) in a single tunnel.
If perfect latency and capacity data were globally known, selection and ordering
would be driven by the particular needs of the client in tandem with their
threat model. Unfortunately, latency and capacity data is not trivial to gather
anonymously, and depending upon untrusted peers to provide this information
has its own serious anonymity implications. </p>
<p> From an anonymity perspective, the simplest technique would be to pick peers
has its own serious anonymity implications.
</p>
<p>
From an anonymity perspective, the simplest technique would be to pick peers
randomly from the entire network, order them randomly, and use those peers
in that order for all eternity. From a performance perspective, the simplest
technique would be to pick the fastest peers with the necessary spare capacity,
@ -266,8 +252,10 @@ I2P's operation can be understood by putting those three concepts together:
former is both brittle and inefficient, the later requires inaccessible information
and offers insufficient anonymity. I2P is instead working on offering a range
of peer selection strategies, coupled with anonymity aware measurement code
to organize the peers by their profiles. </p>
<p> As a base, I2P is constantly profiling the peers with which it interacts
to organize the peers by their profiles.
</p>
<p>
As a base, I2P is constantly profiling the peers with which it interacts
with by measuring their indirect behavior - for instance, when a peer responds
to a netDb lookup in 1.3 seconds, that round trip latency is recorded in the
profiles for all of the routers involved in the two tunnels (inbound and outbound)
@ -281,19 +269,22 @@ I2P's operation can be understood by putting those three concepts together:
to be. These calculations are then compared for active peers to organize the
routers into four tiers - fast and high capacity, high capacity, not failing,
and failing. The thresholds for those tiers are determined dynamically, and
while they currently use fairly simple algorithms, alternatives exist. </p>
while they currently use fairly simple algorithms, alternatives exist.
</p>
<p> Using this profile data, the simplest reasonable peer selection strategy
is to pick peers randomly from the top tier (fast and high capacity), and
this is currently deployed for client tunnels. Exploratory tunnels (used for
netDb and tunnel management) pick peers randomly from the not failing tier
netDb and tunnel management) pick peers randomly from the "not failing" tier
(which includes routers in 'better' tiers as well), allowing the peer to sample
routers more widely, in effect optimizing the peer selection through randomized
hill climbing. These strategies alone do however leak information regarding
the peers in the router's top tier through predecessor and netDb harvesting
attacks. In turn, several alternatives exist which, while not balancing the
load as evenly, will address the attacks mounted by particular classes of
adversaries. </p>
<p> By picking a random key and ordering the peers according to their XOR distance
adversaries.
</p>
<p>
By picking a random key and ordering the peers according to their XOR distance
from it, the information leaked is reduced in predecessor and harvesting attacks
according to the peers' failure rate and the tier's churn. Another simple
strategy for dealing with netDb harvesting attacks is to simply fix the inbound
@ -309,89 +300,79 @@ I2P's operation can be understood by putting those three concepts together:
using individual peers if all of them agree to participate in the same way
each time. This varies from the XOR based ordering in that the predecessor
and successor of each peer is always the same, while the XOR only makes sure
their order doesn't change. </p>
<p> As mentioned before, I2P currently (release 0.6.1.1) includes the tiered
random strategy above. Release 0.6.1.33 will contain the XOR-based ordering
strategy. Additional improvements may be included in the 0.6.2 release. A
their order doesn't change.
</p>
<p>
As mentioned before, I2P currently (release 0.8) includes the tiered
random strategy above, with XOR-based ordering. A
more detailed discussion of the mechanics involved in tunnel operation, management,
and peer selection can be found in the <a href="tunnel-alt.html">tunnel spec</a>.
</p>
<h2 id="op.netdb">Network Database</h2>
<p> <i>Kademlia has been disabled - see <a href="how_networkdatabase.html">NetDb
Status</a></i> </p>
<p> As mentioned earlier, I2P's netDb works to share the network's metadata.
Two algorithms are used to accomplish this - primarily, a small set of routers
are designated as "floodfill peers", while the rest of the routers participate
in the <a href="http://en.wikipedia.org/wiki/Kademlia">Kademlia </a> derived
distributed hash table for redundancy. To integrate the two algorithms, each
router always uses the Kademlia style store and fetch, but acts as if the
floodfill peers are 'closest' to the key in question. Additionally, when a
peer publishes a key into the netDb, after a brief delay they query another
random floodfill peer, asking them for the key, and if that peer does not
have it, they move on and republish the key again. Behind the scenes, when
one of the floodfill peers receives a new valid key, they republish it to
the other floodfill peers who then cache it locally. </p>
<p> Each piece of data in the netDb is self authenticating - signed by the appropriate
party and verified by anyone who uses or stores it. In addition, the data
has liveliness information within it, allowing irrelevant entries to be dropped,
newer entries to replace older ones, and, for the paranoid, protection against
certain classes of attack. This is also why I2P bundles the necessary code
for maintaining the correct time, occasionally querying some SNTP servers
(the <a href="http://www.pool.ntp.org/">pool.ntp.org</a> round robin by default)
and detecting skew between routers at the transport layer. </p>
<p> The routerInfo structure itself contains all of the information that one
router needs to know to securely send messages to another router. This includes
their identity (made up of a 2048bit ElGamal public key, a 1024bit DSA public
key, and a certificate), the transport addresses which they can be reached
on, such as an IP address and port, when the structure was published, and
a set of arbitrary uninterpreted text options. In addition, there is a signature
against all of that data as generated by the included DSA public key. The
key for this routerInfo structure in the netDb is the SHA256 hash of the router's
identity. The options published are often filled with information helpful
in debugging I2P's operation, but when I2P reaches the 1.0 release, the options
will be disabled and kept blank. </p>
<p> The leaseSet structure is similar, in that it includes the I2P destination
(comprised of a 2048bit ElGamal public key, a 1024bit DSA public key, and
a certificate), a list of "leases", and a pair of public keys for garlic encrypting
messages to the destination. Each of the leases specify one of the destination's
inbound tunnel gateways by including the SHA256 of the gateway's identity,
a 4 byte tunnel id on that gateway, and when that tunnel will expire. The
key for the leaseSet in the netDb is the SHA256 of the destination itself.
<p>
As mentioned earlier, I2P's netDb works to share the network's metadata.
This is detailed in <a href="how_networkdatabase.html">the networkdatabase</a> page,
but a basic explanation is available below.
</p>
<p>
A percentage of I2P users are appointed as 'floodfill peers'.
Currently, I2P installations that have a lot of bandwidth and are fast enough,
will appoint themselves as floodfill as soon as the number of existing floodfill routers
drops too low.
</p>
<p>
Other I2P routers will store their data and lookup data by sending simple 'store' and 'lookup' queries to the floodfills.
If a floodfill router receives a 'store' query, it will spread the information to other floodfill routers
using the <a href="http://en.wikipedia.org/wiki/Kademlia">Kademlia algorithm</a>.
The 'lookup' queries currently function differently, to avoid an important
<a href="how_networkdatabase.html#lookup">security issue</a>.
When a lookup is done, the floodfill router will not forward the lookup to other peers,
but will always answer by itself (if it has the requested data).
</p>
<p>
Two types of information are stored in the network database.
<ul>
<li>A <b>routerInfo</b> stores information on a specific I2P router and how to contact it</li>
<li>A <b>leaseSet</b> stores information on a specific destination (e.g. I2P website, e-mail server...)</li>
</ul>
All of this information is signed by the publishing party, and verified by any I2P router using or storing the information.
In addition, the data contains timing information, to avoid storage of old entries and possible attacks.
This is also why I2P bundles the necessary code for maintaining the correct time, occasionally querying some SNTP servers
(the <a href="http://www.pool.ntp.org/">pool.ntp.org</a> round robin by default)
and detecting skew between routers at the transport layer.
</p>
<p>
Some additional remarks are also important.
<ul>
<li>
<b>Unpublished and encrypted leasesets:</b>
<p>
One could only want specific people to be able to reach a destination.
This is possible by not publishing the destination in the netDb. You will however have to transmit the destination by other means.
An alternative are the 'encrypted leaseSets'. These leaseSets can only be decoded by people with access to the decryption key.
</p>
</li>
<li>
<b>Bootstrapping:</b>
<p>
Bootstrapping the netDb is quite simple. Once a router manages to receive a single routerInfo of a reachable peer,
it can query that router for references to other routers in the network.
Currently, a number of users post their routerInfo files to a website to make this information available.
I2P automatically connects to one of these websites to gather routerInfo files and bootstrap.
</p>
</li>
<li>
<b>Lookup scalability:</b>
<p>
Lookups in the I2P network are not forwarded to other netDb routers.
Currently, this is not a major problem, since the network is not very large.
However, as the network grows, not all routerInfo and leaseSet files will be present
on each netDb router. This will cause a deterioration of the percentage of successful lookups.
Because of this, refinements to the netDb will be done in the next releases.
</p>
</li>
</ul>
</p>
<p> As the router currently automatically bundles the leaseSet for the sender
inside a garlic message to the recipient, the leaseSet for destinations which
will not receive unsolicited messages do not need to be published in the netDb
at all. If the destination itself is sensitive, the leaseSet could instead
be transmitted through other means without ever going into the netDb. </p>
<p> Bootstrapping the netDb itself is simple - once a router has at least one
routerInfo of a reachable peer, they query that router for references to other
routers in the network with the Kademlia healing algorithm. Each routerInfo
reference is stored in an individual file in the router's netDb subdirectory,
allowing people to easily share their references to bootstrap new users. </p>
<p> Unlike traditional DHTs, the very act of conducting a search distributes
the data as well, since rather passing Kademlia's standard IP+port pairs,
references are given to the routers that the peer should query next (namely,
the SHA256 of those routers' identities). As such, iteratively searching for
a particular destination's leaseSet or router's routerInfo will also provide
you with the routerInfo of the peers along the way. In addition, due to the
time sensitivity of the data published, the information doesn't often need
to migrate between peers - since a tunnel is only valid for 10 minutes, the
leaseSet can be dropped after that time has passed. To take into account Sybil
attacks on the netDb, the Kademlia routing location used for any given key
varies over time. For instance, rather than storing a routerInfo on the peers
closest to SHA256(routerInfo.identity), they are stored on the peers closest
to SHA256(routerInfo.identity + YYYYMMDD), requiring an adversary to remount
the attack again daily so as to maintain their closeness to the current routing
key. As the very fact that a router is making a lookup for a given key may
expose sensitive data (and the fact that a router is <i>publishing</i> a given
key even more so), all netDb messages are transmitted through the router's
exploratory tunnels. </p>
<p> The netDb plays a very specific role in the I2P network, and the algorithms
have been tuned towards our needs. This also means that it hasn't been tuned
to address the needs we have yet to run into. As the network grows, the primary
floodfill algorithm will need to be refined to exploit the capacity available,
or perhaps replaced with another technique for securely distributing the network
metadata. </p>
<h2 id="op.transport">Transport protocols</h2>
<p> Communication between routers needs to provide confidentiality and integrity
against external adversaries while authenticating that the router contacted
@ -520,7 +501,8 @@ I2P's operation can be understood by putting those three concepts together:
<h2 id="future.restricted">Restricted route operation</h2>
<p> I2P is an overlay network designed to be run on top of a functional packet
switched network, exploiting the end to end principle to offer anonymity and
security. While the Internet no longer fully embraces the end to end principle,
security. While the Internet no longer fully embraces the end to end principle
(due to the usage of NAT),
I2P does require a substantial portion of the network to be reachable - there
may be a number of peers along the edges running using restricted routes,
but I2P does not include an appropriate routing algorithm for the degenerate
@ -789,7 +771,7 @@ What other tunnel peer selection and ordering strategies should be available?
needs for security and anonymity. Rather than building its own content distribution
network, Syndie is designed to run on top of existing networks, syndicating
content through eepsites, Tor hidden services, Freenet freesites, normal websites,
usenet newgroups, email lists, RSS feeds, etc. Data published with Syndie
usenet newsgroups, email lists, RSS feeds, etc. Data published with Syndie
is done so as to offer pseudonymous authentication to anyone reading or archiving
it. </p>

77
www.i2p2/pages/todo.html
View File

@ -31,11 +31,7 @@
<li><a href="#batching">Advanced tunnel operation (batching/mixing/throttling/padding)</a></li>
<li><a href="#stop">Stop &amp; go mix w/ garlics &amp; tunnels</a></li>
</ul>
<h2>Performance <font size="-1"><a href="#performance">[link]</a></font></h2>
<ul class="targetlist">
<li><a href="#sessionTag">Migrate sessionTag to synchronized PRNG</a></li>
<li><a href="#streaming">Full streaming protocol improvements</a></li>
</ul>
<h2>Performance <font size="-1"><a href="performance.html">[link]</a></font></h2>
<h2 id="core">Core functionality</h2>
<ul class="targetlist">
<li>
@ -342,73 +338,8 @@
</li>
</ul>
<h2 id="performance">Performance</h2>
<ul class="targetlist">
<li>
<h3 id="reply">Persistent Tunnel / Lease Selection</h3>
<b><i>Outbound tunnel selection implemented in 0.6.1.30, inbound lease selection
implemented in release 0.6.2</i></b>
<p>Selecting tunnels and leases at random for every message creates a large
incidence of out-of-order delivery, which prevents the streaming lib from
increasing its window size as much as it could. By persisting with the
same selections for a given connection, the transfer rate is much faster.
<p>
Performance related improvements are listed on the
<a href="performance.html">Performance</a> page.
</p>
</li>
<li>
<h3 id="reply">Reduction of Reply LeaseSet Bundling</h3>
<b><i>Implemented in release 0.6.2</i></b>
<p>I2P bundled a reply leaseset (typically 1056 bytes) with every outbound
client message, which was a massive overhead. Fixed in 0.6.2. </p>
</li>
<li>
<h3 id="sessionTag">Migrate sessionTag to synchronized PRNG</h3>
<p>Right now, our <a href="how_elgamalaes.html">ElGamal/AES+SessionTag</a>
algorithm works by tagging each encrypted message with a unique random
32 byte nonce (a "session tag"), identifying that message as being encrypted
with the associated AES session's key. This prevents peers from distinguishing
messages that are part of the same session, since each message has a completely
new random tag. To accomplish this, every few messages bundle a whole
new set of session tags within the encrypted message itself, transparently
delivering a way to identify future messages. We then have to keep track
of what messages are successfully delivered so that we know what tags
we may use.</p>
<p>This works fine and is fairly robust, however it is inefficient in terms
of bandwidth usage, as it requires the delivery of these tags ahead of
time (and not all tags may be necessary, or some may be wasted, due to
their expiration). On average though, predelivering the session tag costs
32 bytes per message (the size of a tag). As Taral suggested though, that
size can be avoided by replacing the delivery of the tags with a synchronized
PRNG - when a new session is established (through an ElGamal encrypted
block), both sides seed a PRNG for use and generate the session tags on
demand (with the recipient precalculating the next few possible values
to handle out of order delivery).</p>
</li>
<li>
<h3 id="streaming">Full streaming protocol improvements</h3>
<b><i>Several improvements implemented in I2P 0.6.1.28, and significant
additional fixes in 0.6.1.33, but still lots here to investigate</i></b>
</li>
</ul>
<ul class="targetlist">
<p>Since I2P <a href="http://dev.i2p.net/pipermail/i2p/2004-November/000491.html">0.4.2</a>,
we have had a full sliding window streaming library, improving upon the
older fixed window size and resend delay implementation greatly. However,
there are still a few avenues for further optimization:</p>
</ul>
<ul>
<li>some algorithms to share congestion and RTT information across streams
(per target destination? per source destination? for all of the local destinations?)</li>
<li>further optimizations for interactive streams (most of the focus in the
current implementation is on bulk streams)</li>
<li>more explicit use of the new streaming lib's features in I2PTunnel and
the SAM bridge, reducing the per-tunnel overhead.</li>
<li>client level bandwidth limiting (in either or both directions on a stream,
or possibly shared across multiple streams). This would be in addition to
the router's overall bandwidth limiting, of course.</li>
<li>various controls for destinations to throttle how many streams they accept
or create (we have some basic code, but largely disabled)</li>
<li>access control lists (only allowing streams to or from certain other known
destinations)</li>
<li>web controls and monitoring the health of the various streams, as well
as the ability to explicitly close or throttle them</li>
</ul>
{% endblock %}

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

@ -42,7 +42,6 @@ The transport subsystem in I2P provides the following services:
<li>Coordination of firewall status and local IP, and changes to either, among the transports
<li>Communication of firewall status and local IP, and changes to either, to the router and the user interface
<li>Determination of a consensus clock, which is used to periodically update the router's clock, as a backup for NTP
<li>GeoIP lookup of router IPs for the user interface
<li>Maintenance of status for each peer, including whether it is connected, whether it was recently connected,
and whether it was reachable in the last attempt
<li>Qualification of valid IP addresses according to a local rule set
@ -118,5 +117,11 @@ the memory requirements for an NTCP connection are higher than that for SSU.
However, as NTCP buffers are partially in the kernel and SSU buffers are on the Java heap,
that assumption is difficult to verify.
</p><p>
Analyze
<a href="http://www.cse.chalmers.se/%7Ejohnwolf/publications/hjelmvik_breaking.pdf">Breaking and Improving Protocol Obfuscation</a>
and see how transport-layer padding may improve things.
</p>
{% endblock %}

98
www.i2p2/pages/tunnel-alt-creation.html
View File

@ -17,9 +17,13 @@ for an overview of the process, including peer selection and ordering methods.
the path of peers in the tunnel, rewritten in place, and transmitted
back to the tunnel creator. This single tunnel message is made up
of a variable number of records (up to 8) - one for each potential peer in
the tunnel. Individual records are asymmetrically encrypted to be
the tunnel. Individual records are asymmetrically
<a href="how_cryptography.html#elgamal">(ElGamal)</a>
encrypted to be
read only by a specific peer along the path, while an additional
symmetric layer of encryption is added at each hop so as to expose
symmetric layer of encryption
<a href="how_cryptography.html#AES">(AES)</a>
is added at each hop so as to expose
the asymmetrically encrypted record only at the appropriate time.</p>
<h3 id="number">Number of Records</h3>
@ -37,7 +41,7 @@ with the desired amount of tunnel length obfuscation.
In the current network, most tunnels are 2 or 3 hops long.
The current implementation uses a 5-record VTBM to build tunnels of 4 hops or less,
and the 8-record TBM for longer tunnels.
The 5-record VTBM (which fits in 3 1KB tunnel messaages) reduces network traffic
The 5-record VTBM (which, when fragmented, fits in three 1KB tunnel messaages) reduces network traffic
and increases build sucess rate, because smaller messages are less likely to be dropped.
<p>
The reply message must be the same type and length as the build message.
@ -56,11 +60,11 @@ Also specified in the
bytes 72-103: AES-256 tunnel layer key
bytes 104-135: AES-256 tunnel IV key
bytes 136-167: AES-256 reply key
bytes 168-183: reply IV
bytes 168-183: AES-256 reply IV
byte 184: flags
bytes 185-188: request time (in hours since the epoch)
bytes 189-192: next message ID
bytes 193-222: uninterpreted / random padding</pre>
bytes 193-221: uninterpreted / random padding</pre>
<p>The next tunnel ID and next router identity hash fields are used to
specify the next hop in the tunnel, though for an outbound tunnel
@ -73,23 +77,44 @@ message ID that the message (or reply) should use.</p>
Bit order: 76543210 (bit 7 is MSB)
bit 7: if set, allow messages from anyone
bit 6: if set, allow messages to anyone, and send the reply to the
specified next hop in a tunnel message
specified next hop in a Tunnel Build Reply Message
bits 5-0: Undefined
</pre>
Bit 7 indicates that the hop will be an inbound gateway (IBGW).
Bit 6 indicates that the hop will be an outbound endpoint (OBEP).
If neither bit is set, the hop will be an intermediate participant.
<h4 id="encryption">Request Encryption</h4>
<h4>Request Record Creation</h4>
<p>
Every hop gets a random Tunnel ID.
The current and next-hop Tunnel IDs are filled in.
Every record gets a random tunnel IV key, and reply IV.
The layer and reply key pairs are generated.
</p>
<h4 id="encryption">Request Record Encryption</h4>
<p>That cleartext record is <a href="how_cryptography.html#elgamal">ElGamal 2048 encrypted</a> with the hop's
public encryption key and formatted into a 528 byte record:</p><pre>
bytes 0-15: First 16 bytes of the SHA-256 of the current hop's router identity
bytes 16-527: ElGamal-2048 encrypted request record</pre>
In the 512-byte encrypted record,
the ElGamal data contains bytes 1-256 and 258-513 of the
<a href="how_cryptography.html#elgamal">514-byte ElGamal encrypted block</a>.
The two padding bytes from the block (the zero bytes at locations 0 and 257) are removed.
<p>Since the cleartext uses the full field, there is no need for
additional padding beyond <code>SHA256(cleartext) + cleartext</code>.</p>
<p>
Each 528-byte record is then iteratively encrypted
(using AES decryption, with the reply key and reply IV for each hop) so that the router identity will only be in cleartext
for the hop in question.
</p>
<h3 id="tunnelCreate.hopProcessing">Hop Processing and Encryption</h3>
<p>When a hop receives a TunnelBuildMessage, it looks through the
@ -103,9 +128,17 @@ are dropped.</p>
<p>After deciding whether they will agree to participate in the tunnel
or not, they replace the record that had contained the request with
an encrypted reply block. All other records are <a href="how_cryptography.html#AES">AES-256/CBC
encrypted</a> with the included reply key and IV (though each is
encrypted separately, rather than chained across records).</p>
an encrypted reply block. All other records are <a href="how_cryptography.html#AES">AES-256
encrypted</a> with the included reply key and IV. Each is
encrypted separately, rather than chained across records.</p>
<p>
Each hop knows only its own response.
If it agrees, it will maintain the tunnel until expiration,
even if it will not be used,
as it cannot know whether all other hops agreed.
</p>
<h4 id="tunnelCreate.replyRecord">Reply Record Specification</h4>
@ -140,19 +173,23 @@ The padding is placed before the status byte:
This is also described in the
<a href="i2np_spec.html#msg_TunnelBuildReply">I2NP spec</a>.
<h3 id="tunnelCreate.requestPreparation">Request Preparation</h3>
<h3 id="tunnelCreate.requestPreparation">Tunnel Build Message Preparation</h3>
<p>When building a new request, all of the records must first be
built and asymmetrically encrypted. Each record should then be
decrypted with the reply keys and IVs of the hops earlier in the
path. That decryption should be run in reverse order so that the
<p>When building a new Tunnel Build Messaage, all of the Build Request Records must first be
built and asymmetrically encrypted using
<a href="how_cryptography.html#elgamal">ElGamal</a>.
Each record is then
premptively decrypted with the reply keys and IVs of the hops earlier in the
path, using
<a href="how_cryptography.html#AES">AES</a>.
That decryption should be run in reverse order so that the
asymmetrically encrypted data will show up in the clear at the
right hop after their predecessor encrypts it.</p>
<p>The excess records not needed for individual requests are simply
filled with random data by the creator.</p>
<h3 id="tunnelCreate.requestDelivery">Request Delivery</h3>
<h3 id="tunnelCreate.requestDelivery">Tunnel Build Message Delivery</h3>
<p>For outbound tunnels, the delivery is done directly from the tunnel
creator to the first hop, packaging up the TunnelBuildMessage as if
@ -163,7 +200,7 @@ If no outbound tunnel is available in that pool, an outbound exploratory tunnel
At startup, when no outbound exploratory tunnel exists yet, a fake 0-hop
outbound tunnel is used.</p>
<h3 id="tunnelCreate.endpointHandling">Endpoint Handling</h3>
<h3 id="tunnelCreate.endpointHandling">Tunnel Build Message Endpoint Handling</h3>
<p>
For creation of an outbound tunnel,
@ -179,10 +216,12 @@ or
(the type of message and number of records must match that of the request)
and delivers it to the
reply tunnel specified within the request record. That reply tunnel
forwards the reply records down to the tunnel creator for
processing, as below.</p>
forwards the Tunnel Build Reply Message back to the tunnel creator,
<a href="tunnel-alt.html#tunnel.operation">just as for any other message</a>.
The tunnel creator then
processes it, as described below.</p>
<p>The reply tunnel was specified by the creator as follows:
<p>The reply tunnel was selected by the creator as follows:
Generally it is an inbound tunnel from the same pool as the new outbound tunnel being built.
If no inbound tunnel is available in that pool, an inbound exploratory tunnel is used.
At startup, when no inbound exploratory tunnel exists yet, a fake 0-hop
@ -191,10 +230,10 @@ inbound tunnel is used.</p>
<p>
For creation of an inbound tunnel,
when the request reaches the inbound endpoint (also known as the
tunnel creator), there is no need to generate an explicit Reply Message, and
tunnel creator), there is no need to generate an explicit Tunnel Build Reply Message, and
the router processes each of the replies, as below.</p>
<h3 id="tunnelCreate.replyProcessing">Reply Processing by the Request Creator</h3>
<h3 id="tunnelCreate.replyProcessing">Tunnel Build Reply Message Processing</h3>
<p>To process the reply records, the creator simply has to AES decrypt
each record individually, using the reply key and IV of each hop in
@ -262,9 +301,12 @@ update</a>
<h2 id="future">Future Work</h2>
<ul>
<li>
It appears that, in the current implementation, the originator leaves one record empty
for itself, which is not necessary. Thus a message of n records can only build a
tunnel of n-1 hops. This is to be researched and verified.
In the current implementation, the originator leaves one record empty
for itself. Thus a message of n records can only build a
tunnel of n-1 hops.
This appears to be necessary for inbound tunnels (where the next-to-last hop
can see the hash prefix for the next hop), but not for outbound tunnels.
This is to be researched and verified.
If it is possible to use the remaining record without compromising anonymity,
we should do so.
<li>
@ -274,7 +316,11 @@ Therefore the request time field is unused.
This should be researched and possibly changed.
<li>
Further analysis of possible tagging and timing attacks described in the above notes.
</ul>
</li><li>
The Bloom filter rotation time should be evaluated.
</li><li>
Use only VTBM; do not select old peers that don't support it.
</li></ul>
{% endblock %}

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

@ -3,18 +3,18 @@
{% block content %}
This page documents the current tunnel implementation.
Updated July 2010 for release 0.8
Updated September 2010 for release 0.8
<h2>1) <a name="tunnel.overview">Tunnel overview</a></h2>
<h2><a name="tunnel.overview">Tunnel overview</a></h2>
<p>Within I2P, messages are passed in one direction through a virtual
tunnel of peers, using whatever means are available to pass the
message on to the next hop. Messages arrive at the tunnel's
gateway, get bundled up and/or fragmented into fixed sizes tunnel messages,
</i>gateway</i>, get bundled up and/or fragmented into fixed-size tunnel messages,
and are forwarded on to the next hop in the tunnel, which processes and verifies
the validity of the message and sends it on to the next hop, and so on, until
it reaches the tunnel endpoint. That endpoint takes the messages
it reaches the tunnel endpoint. That <i>endpoint</i> takes the messages
bundled up by the gateway and forwards them as instructed - either
to another router, to another tunnel on another router, or locally.</p>
@ -27,8 +27,8 @@ out to the remote endpoint.</p>
<p>The tunnel's creator selects exactly which peers will participate
in the tunnel, and provides each with the necessary configuration
data. They may have any number of hops, but may be constrained with various
proof-of-work requests to add on additional steps. It is the intent to make
data. They may have any number of hops.
It is the intent to make
it hard for either participants or third parties to determine the length of
a tunnel, or even for colluding participants to determine whether they are a
part of the same tunnel at all (barring the situation where colluding peers are
@ -48,31 +48,93 @@ the core I2P layer, there is an optional end to end streaming library
available for client applications, exposing TCP-esque operation,
including message reordering, retransmission, congestion control, etc.</p>
<h2>2) <a name="tunnel.operation">Tunnel operation</a></h2>
<p>
An overview of I2P tunnel terminology is
<a href="how_tunnelrouting.html">on the tunnel overview page</a>.
</p>
<p>Tunnel operation has four distinct processes, taken on by various
peers in the tunnel. First, the tunnel gateway accumulates a number
of tunnel messages and preprocesses them into something for tunnel
delivery. Next, that gateway encrypts that preprocessed data, then
forwards it to the first hop. That peer, and subsequent tunnel
<h2><a name="tunnel.operation">Tunnel Operation (Message Processing)</a></h2>
<h3>Overview</h3>
<p>After a tunnel is built, <a href="i2np.html">I2NP messages</a> are processed and passed through it.
Tunnel operation has four distinct processes, taken on by various
peers in the tunnel. <ol><li>First, the tunnel gateway accumulates a number
of I2NP messages and preprocesses them into tunnel messages for
delivery. </li><li>Next, that gateway encrypts that preprocessed data, then
forwards it to the first hop. </li><li>That peer, and subsequent tunnel
participants, unwrap a layer of the encryption, verifying that it isn't
a duplicate, then forward it on to the next peer.
Eventually, the message arrives at the endpoint where the messages
bundled by the gateway are split out again and forwarded on as
requested.</p>
</li><li>Eventually, the tunnel messages arrive at the endpoint where the I2NP messages
originally bundled by the gateway are reassembled and forwarded on as
requested.</li></ol></p>
<p>Tunnel IDs are 4 byte numbers used at each hop - participants know what
tunnel ID to listen for messages with and what tunnel ID they should be forwarded
on as to the next hop, and each hop chooses the tunnel ID which they receive messages
on. Tunnels themselves are short-lived (10 minutes).
Even if subsequent tunnels are built using the same sequence of
peers, each hop's tunnel ID will change.</p>
<p>
Intermediate tunnel participants do not know whether they are in an
inbound or an outbound tunnel; they always "encrypt" for the next hop.
Therefore, we take advantage of symmetric AES encryption
to "decrypt" at the outbound tunnel gateway,
so that the plaintext is revealed at the outbound endpoint.
</p>
<p>
<center>
<img src="/_static/images/tunnels.png" alt="Inbound and outbound tunnel schematic" title="Inbound and outbound tunnel schematic" />
</center>
</p>
<h3>2.1) <a name="tunnel.preprocessing">Message preprocessing</a></h3>
<table><tr>
<th>Role</th>
<th>Preprocessing</th>
<th>Encryption Operation</th>
<th>Postprocessing</th>
</tr>
<tr><td>Outbound Gateway (Creator)</td>
<td>Fragment, Batch, and Pad</td>
<td>Iteratively encrypt (using decryption operations)</td>
<td>Forward to next hop</td>
</tr>
<tr><td>Participant</td>
<td>&nbsp;</td>
<td>Decrypt (using an encryption operation)</td>
<td>Forward to next hop</td>
</tr>
<tr><td>Outbound Endpoint</td>
<td>&nbsp;</td>
<td>Decrypt (using an encryption operation) to reveal plaintext tunnel message</td>
<td>Reassemble Fragments, Forward as instructed to Inbound Gateway or Router</td>
</tr>
<tr><td colspan="4"><hr></td></tr>
<tr><td>Inbound Gateway</td>
<td>Fragment, Batch, and Pad</td>
<td>Encrypt</td>
<td>Forward to next hop</td>
</tr>
<tr><td>Participant</td>
<td>&nbsp;</td>
<td>Encrypt</td>
<td>Forward to next hop</td>
</tr>
<tr><td>Inbound Endpoint (Creator)</td>
<td>&nbsp;</td>
<td>Iteratively decrypt to reveal plaintext tunnel message</td>
<td>Reassemble Fragments, Receive data</td>
</tr>
</table>
<h3><a name="tunnel.gateway">Gateway Processing</a></h3>
<h4><a name="tunnel.preprocessing">Message Preprocessing</a></h4>
<p>A tunnel gateway's function is to fragment and pack
<a href="i2np.html">I2NP messages</a> into fixed-size
<a href="tunnel_message_specification.html">tunnel messages</a>
<a href="tunnel_message_spec.html">tunnel messages</a>
and encrypt the tunnel messages.
Tunnel messages contain the following:
@ -84,14 +146,28 @@ Tunnel messages contain the following:
<li>One or more { delivery instruction, I2NP message fragment } pairs</li>
</ul>
<p>Tunnel IDs are 4 byte numbers used at each hop - participants know what
tunnel ID to listen for messages with and what tunnel ID they should be forwarded
on as to the next hop, and each hop chooses the tunnel ID which they receive messages
on. Tunnels themselves are short-lived (10 minutes).
Even if subsequent tunnels are built using the same sequence of
peers, each hop's tunnel ID will change.</p>
<p>To prevent adversaries from tagging the messages along the path by adjusting
the message size, all tunnel messages are a fixed 1024 bytes in size. To accommodate
larger I2NP messages as well as to support smaller ones more efficiently, the
gateway splits up the larger I2NP messages into fragments contained within each
tunnel message. The endpoint will attempt to rebuild the I2NP message from the
fragments for a short period of time, but will discard them as necessary.</p>
<p>
Details are in the
<a href="tunnel_message_specification.html">tunnel message specification</a>.
<a href="tunnel_message_spec.html">tunnel message specification</a>.
<h3>2.2) <a name="tunnel.gateway">Gateway Processing</a></h3>
<h4>Gateway Encryption</h3>
<p>After the preprocessing of messages into a padded payload, the gateway builds
a random 16 byte IV value, iteratively encrypting it and the tunnel message as
@ -106,7 +182,7 @@ data with the IV and layer keys for all hops in the tunnel. The result of the o
tunnel encryption is that when each peer encrypts it, the endpoint will recover
the initial preprocessed data.</p>
<h3>2.3) <a name="tunnel.participant">Participant Processing</a></h3>
<h3><a name="tunnel.participant">Participant Processing</a></h3>
<p>When a peer receives a tunnel message, it checks that the message came from
the same previous hop as before (initialized when the first message comes through
@ -129,7 +205,7 @@ false positive. The unique value fed into the Bloom filter is the XOR of the IV
and the first block so as to prevent nonsequential colluding peers in the tunnel
from tagging a message by resending it with the IV and first block switched.</p>
<h3>2.4) <a name="tunnel.endpoint">Endpoint Processing</a></h3>
<h3><a name="tunnel.endpoint">Endpoint Processing</a></h3>
<p>After receiving and validating a tunnel message at the last hop in the tunnel,
how the endpoint recovers the data encoded by the gateway depends upon whether
@ -143,23 +219,6 @@ layer and IV keys of each step in reverse order.</p>
which it may then parse out into the included I2NP messages and forwards them as
requested in their delivery instructions.</p>
<p>These padding strategies can be used on a variety of levels, addressing the
exposure of message size information to different adversaries. After gathering
and reviewing some <a href="http://dev.i2p.net/~jrandom/messageSizes/">statistics</a>
from the 0.4 network, as well as exploring the anonymity tradeoffs, we're starting
with a fixed tunnel message size of 1024 bytes. Within this however, the fragmented
messages themselves are not padded by the tunnel at all (though for end to end
messages, they may be padded as part of the garlic wrapping).</p>
<h3>2.6) <a name="tunnel.fragmentation">Tunnel Fragmentation</a></h3>
<p>To prevent adversaries from tagging the messages along the path by adjusting
the message size, all tunnel messages are a fixed 1024 bytes in size. To accommodate
larger I2NP messages as well as to support smaller ones more efficiently, the
gateway splits up the larger I2NP messages into fragments contained within each
tunnel message. The endpoint will attempt to rebuild the I2NP message from the
fragments for a short period of time, but will discard them as necessary.</p>
<h2><a name="tunnel.building">Tunnel Building</a></h2>
@ -172,7 +231,7 @@ reply. There are three important dimensions to keep in mind when producing
the tunnels: what peers are used (and where), how the requests are sent (and
replies received), and how they are maintained.</p>
<h3>3.1) <a name="tunnel.peerselection">Peer Selection</a></h3>
<h3><a name="tunnel.peerselection">Peer Selection</a></h3>
<p>Beyond the two types of tunnels - inbound and outbound - there are two styles
of peer selection used for different tunnels - exploratory and client.
@ -235,7 +294,7 @@ within a single pool but not between different pools.
New keys are generated at each router restart.
<h3>3.2) <a name="tunnel.request">Request delivery</a></h3>
<h3><a name="tunnel.request">Request delivery</a></h3>
<p>
A multi-hop tunnel is built using a single build message which is repeatedly
@ -267,7 +326,7 @@ the router in question.
For more information on peer profiling, see the
<a href="how_peerselection.html">Peer Profiling and Selection page</a>.
<h3>3.3) <a name="tunnel.pooling">Tunnel Pools</a></h3>
<h3><a name="tunnel.pooling">Tunnel Pools</a></h3>
<p>To allow efficient operation, the router maintains a series of tunnel pools,
each managing a group of tunnels used for a specific purpose with their own
@ -286,9 +345,9 @@ lengths should be randomized, as
well as any of the other settings allowed when configuring individual tunnels.
Configuration options are specified on the <a href="i2cp.html">I2CP page</a>.
<h3 id="length">Default Tunnel Lengths</h3>
<h3 id="length">Tunnel Lengths and Defaults</h3>
TODO
<a href="how_tunnelrouting.html#length">On the tunnel overview page</a>.
<h3 id="strategy">Anticipatory Build Strategy and Priority</h3>
@ -322,4 +381,14 @@ automatically, how much should be configured as a per tunnel or per hop setting,
and how should the tunnel's creator (and in turn, user) control this operation?
All of this is left as unknown, to be worked out for a distant future release.
<h3>Padding</h3>
<p>The padding strategies can be used on a variety of levels, addressing the
exposure of message size information to different adversaries.
The current fixed tunnel message size is 1024 bytes. Within this however, the fragmented
messages themselves are not padded by the tunnel at all, though for end to end
messages, they may be padded as part of the garlic wrapping.</p>
{% endblock %}

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

@ -276,7 +276,7 @@ Total length: 7 bytes
{% endfilter %}
</pre>
<h3><a href="http://docs.i2p2.de/router/net/i2p/data/i2np/DeliveryInstructions.html">Delivery Instructions Javadoc</a></h3>
<h3><a href="http://docs.i2p2.de/javadoc/net/i2p/data/i2np/DeliveryInstructions.html">Delivery Instructions Javadoc</a></h3>
<h2 id="notes">Notes</h2>
<h3>I2NP Message Maximum Size</h3>

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

@ -13,9 +13,6 @@ The other is <a href="ntcp.html">NTCP</a>.
SSU is the newer of the two transports,
introduced in I2P release 0.6.
In a standard I2P installation, the router uses both NTCP and SSU for outbound connections.
A router
The selection of a transport for a connection.
<h2>SSU Services</h2>

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

@ -46,7 +46,7 @@ The header contains:
<li>
A 40-byte <a href="common_structures_spec.html#type_signature">DSA signature</a>
</li><li>
A 16-byte plugin version in UTF-8, padded with trailing zeroes if necessary
A 16-byte I2P version in UTF-8, padded with trailing zeroes if necessary
</li></ul>
</p><p>
The signature covers only the zip archive - not the prepended version.

BIN
www.i2p2/static/images/I2PTunnel-streamr.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 4.6 KiB

BIN
www.i2p2/static/images/cz.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 476 B

BIN
www.i2p2/static/images/garliccloves.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 68 KiB

BIN
www.i2p2/static/images/i2ptunnel_peertopeer.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 15 KiB

BIN
www.i2p2/static/images/i2ptunnel_serverclient.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 6.0 KiB

BIN
www.i2p2/static/images/netdb_get_leaseset.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 21 KiB

BIN
www.i2p2/static/images/netdb_get_routerinfo_1.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 15 KiB

BIN
www.i2p2/static/images/netdb_get_routerinfo_2.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 12 KiB

BIN
www.i2p2/static/images/protocol_stack.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 21 KiB