merge of '59cf1b1968ac77a087cf7258bf9848616c2d93f5'
and 'ce2408e69f1ee97df4901d3c3dbec587a6c6badb'
This commit is contained in:
952
www.i2p2/image_design/netdb_get_leaseset.svg
Normal file
952
www.i2p2/image_design/netdb_get_leaseset.svg
Normal 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>
|
||||
|
After Width: | Height: | Size: 36 KiB |
509
www.i2p2/image_design/netdb_get_routerinfo_1.svg
Normal file
509
www.i2p2/image_design/netdb_get_routerinfo_1.svg
Normal 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>
|
||||
|
After Width: | Height: | Size: 19 KiB |
516
www.i2p2/image_design/netdb_get_routerinfo_2.svg
Normal file
516
www.i2p2/image_design/netdb_get_routerinfo_2.svg
Normal 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>
|
||||
|
After Width: | Height: | Size: 20 KiB |
@@ -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>
|
||||
|
||||
|
Before Width: | Height: | Size: 31 KiB After Width: | Height: | Size: 32 KiB |
28
www.i2p2/pages/_layout_cs.html
Normal file
28
www.i2p2/pages/_layout_cs.html
Normal 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>
|
||||
@@ -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>
|
||||
@@ -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" /> <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" /> <a href="announcements.html">Poznámky k vydání</a><br />
|
||||
<!-- <img src="/_static/images/sqbullet.png" /> <a href="http://dev.i2p.net/pipermail/i2p/">Mailinglist</a><br /> -->
|
||||
<img src="/_static/images/sqbullet.png" /> <a href="meetings.html">Projektové schůzky</a><br />
|
||||
<img src="/_static/images/sqbullet.png" /> <a href="roadmap.html">Plán rozvoje</a><br />
|
||||
<img src="/_static/images/sqbullet.png" /> <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" /> <a href="faq.html">FAQ</a><br />
|
||||
<img src="/_static/images/sqbullet.png" /> <a href="http://forum.i2p2.de/">Diskuzní fóra</a><br />
|
||||
<img src="/_static/images/sqbullet.png" /> <a href="bounties.html">Projektové odměny</a><br />
|
||||
<img src="/_static/images/sqbullet.png" /> <a href="getinvolved.html">Zapojte se</a><br />
|
||||
<img src="/_static/images/sqbullet.png" /> <a href="donate.html">Dotace!</a><br />
|
||||
|
||||
<img src="/_static/images/sqbullet.png" /> <a href="team.html">Tým I2P</a><br />
|
||||
<img src="/_static/images/sqbullet.png" /> <a href="halloffame.html">Síň slávy</a><br />
|
||||
|
||||
<br /><b>Dokumentace</b><br />
|
||||
<img src="/_static/images/sqbullet.png" /> <a href="how.html">Jak to funguje?</a><br />
|
||||
<img src="/_static/images/sqbullet.png" /> <a href="techintro.html">Technický úvod</a><br />
|
||||
<img src="/_static/images/sqbullet.png" /> <a href="applications.html">Aplikace</a><br />
|
||||
|
||||
<br /><b>Vývoj</b><br />
|
||||
<img src="/_static/images/sqbullet.png" /> <a href="api.html">API</a><br />
|
||||
<img src="/_static/images/sqbullet.png" /> <a href="licenses.html">Licence</a><br />
|
||||
<img src="/_static/images/sqbullet.png" /> <a href="http://trac.i2p2.i2p/">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 />
|
||||
|
||||
@@ -54,7 +54,8 @@ 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>
|
||||
@@ -66,7 +67,8 @@ Deprecated - unused
|
||||
<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>
|
||||
@@ -150,7 +152,7 @@ Deprecated - unused
|
||||
<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>
|
||||
@@ -191,6 +193,19 @@ payload :: data
|
||||
{% endfilter %}
|
||||
</pre>
|
||||
|
||||
<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/core/net/i2p/data/Certificate.html">Javadoc</a></h4>
|
||||
|
||||
|
||||
@@ -456,7 +471,7 @@ end_date :: Date
|
||||
+----+----+----+----+----+----+----+----+
|
||||
|
||||
destination :: Destination
|
||||
length -> >= 397 bytes
|
||||
length -> >= 387 bytes
|
||||
|
||||
encryption_key :: PublicKey
|
||||
length -> 256 bytes
|
||||
@@ -466,6 +481,7 @@ signing_key :: SigningPublicKey
|
||||
|
||||
num :: Integer
|
||||
length -> 1 byte
|
||||
value: 0 <= num <= 6
|
||||
|
||||
leases :: [Lease]
|
||||
length -> >= $num*399 bytes
|
||||
|
||||
@@ -71,6 +71,12 @@ as implemented in
|
||||
<a href="http://docs.i2p2.de/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.
|
||||
|
||||
|
||||
<h2 id="spec">Specification</h2>
|
||||
|
||||
<h3 id="raw">Non-Repliable Datagrams</h3>
|
||||
|
||||
106
www.i2p2/pages/download_cs.html
Normal file
106
www.i2p2/pages/download_cs.html
Normal 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 %}
|
||||
11
www.i2p2/pages/glossary.html
Normal file
11
www.i2p2/pages/glossary.html
Normal 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 %}
|
||||
@@ -13,11 +13,6 @@
|
||||
<tr><td>Welterde</td><td>8 €/mo, since January, 2008 - i2p2.de</td></tr>
|
||||
<tr><td>eche|on</td><td>32 €/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 €</td><td>General fund</td></tr>
|
||||
<tr><td>Jan, 2010</td><td>bernerbaer</td><td>50 €</td><td>General fund</td></tr>
|
||||
<tr><td>Jan, 2010</td><td>anonymous</td><td>15 €</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 €/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 €</td><td>General fund</td></tr>
|
||||
<tr><td>Jan, 2010</td><td>anonymous</td><td>10 €</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 €</td><td>General fund</td></tr>
|
||||
<tr><td>Feb, 2009</td><td>[anonymous]</td><td>30 €</td><td>General fund</td></tr>
|
||||
<tr><td>Feb, 2009</td><td>DVT</td><td>20 €</td><td>General fund</td></tr>
|
||||
<tr></tr>
|
||||
<tr><td>Oct, 2008</td><td>eche|on</td><td>500.0 €</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>
|
||||
|
||||
@@ -118,10 +118,10 @@ I2P is a message-oriented router. The messages sent between routers are defined
|
||||
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>
|
||||
@@ -151,7 +151,11 @@ The protocols for direct (point-to-point) router to router communication.
|
||||
|
||||
<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.i2p/">Javadocs</a>
|
||||
</li><li>
|
||||
<a href="todo.html">To Do List</a>
|
||||
</li></ul>
|
||||
|
||||
|
||||
|
||||
@@ -26,12 +26,17 @@ block is formatted (in network byte order):
|
||||
<p>
|
||||
<p>
|
||||
<PRE>
|
||||
|_______1_______2_______3_______4_______5_______6_______7_______8
|
||||
|nonzero|H(data)
|
||||
|
|
||||
|
|
||||
|
|
||||
| | data ... |
|
||||
+----+----+----+----+----+----+----+----+
|
||||
|nonz| H(data) |
|
||||
+----+ +
|
||||
| |
|
||||
+ +
|
||||
| |
|
||||
+ +
|
||||
| |
|
||||
+ +----+----+----+----+----+----+----+
|
||||
| | data...
|
||||
+----+----+----+--//
|
||||
|
||||
</PRE>
|
||||
<p>
|
||||
@@ -266,11 +271,12 @@ 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.
|
||||
</p>
|
||||
|
||||
<H3><a name="tcp">NTCP connections</a></H3>
|
||||
@@ -280,8 +286,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 +311,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>
|
||||
|
||||
@@ -132,7 +132,7 @@ Auswahl von Knoten (Gegenstellen), Aufbauen von Tunneln durch die Knoten sowie d
|
||||
<h3>Transportschicht</h3>
|
||||
Protokolle zur direkten Kommunikation zwischen zwei Routern.
|
||||
<ul><li>
|
||||
<a href="transports.html">Überblick über die Transportschicht</a> <i>(englisch)</i>
|
||||
<a href="transport.html">Überblick über die Transportschicht</a> <i>(englisch)</i>
|
||||
</li><li>
|
||||
<a href="ntcp.html">NTCP</a> Überblick über den TCP-Transport <i>(englisch)</i>
|
||||
</li><li>
|
||||
|
||||
@@ -1,53 +1,258 @@
|
||||
{% 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 with I2P's bundling
|
||||
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, and we require two tunnels
|
||||
(one outbound and one inbound) for end-to-end communication in each direction.
|
||||
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:
|
||||
|
||||
<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 %}
|
||||
|
||||
@@ -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>
|
||||
@@ -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>
|
||||
@@ -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>
|
||||
|
||||
|
||||
@@ -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
|
||||
@@ -411,7 +421,7 @@
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Queries are sent through<i>multiple routes simultaneously</i>
|
||||
Queries are sent through <i>multiple routes simultaneously</i>
|
||||
to <i>reduce the chance of query failure</i>.
|
||||
</p>
|
||||
|
||||
@@ -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
|
||||
@@ -611,11 +621,11 @@ This attack becomes more difficult as the network size grows.
|
||||
<p>
|
||||
As a partial defense against this attack,
|
||||
the algorithm used to determine Kademlia "closeness" varies over time.
|
||||
Rather than using the Hash of the key (i.e. H(k))to determine closeness,
|
||||
Rather than using the Hash of the key (i.e. H(k)) to determine closeness,
|
||||
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>
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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>
|
||||
<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>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><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.
|
||||
|
||||
|
||||
<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>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.
|
||||
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 %}
|
||||
|
||||
@@ -249,5 +249,9 @@ 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>
|
||||
|
||||
{% endblock %}
|
||||
|
||||
@@ -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 %}
|
||||
|
||||
@@ -197,7 +197,7 @@ total length: 222
|
||||
|
||||
encrypted:
|
||||
|
||||
toPeer :: Hash
|
||||
toPeer :: First 16 bytes of the SHA-256 Hash of the peer's router identity
|
||||
length -> 16 bytes
|
||||
|
||||
encrypted_data :: ElGamal-2048 encrypted data
|
||||
|
||||
80
www.i2p2/pages/index_cs.html
Normal file
80
www.i2p2/pages/index_cs.html
Normal 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 %}
|
||||
@@ -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)
|
||||
|
||||
118
www.i2p2/pages/performance-history.html
Normal file
118
www.i2p2/pages/performance-history.html
Normal 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 %}
|
||||
@@ -11,50 +11,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
|
||||
@@ -87,6 +45,28 @@ 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>
|
||||
|
||||
<h2>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
|
||||
it "feels okay". Once we've got tunnel healing code and more effective failure
|
||||
@@ -119,62 +99,22 @@ 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>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 %}
|
||||
|
||||
@@ -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,7 +23,306 @@ 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>
|
||||
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
|
||||
the small HTTP request payload, and the reply bundles the SYN,
|
||||
FIN, ACK, and the HTTP response payload. While an additional
|
||||
ACK must be transmitted to tell the HTTP server that the SYN/FIN/ACK has been
|
||||
received, the local HTTP proxy can often deliver the full response to the browser
|
||||
immediately.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
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>
|
||||
|
||||
<p>
|
||||
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/core/net/i2p/client/streaming/I2PSocketManagerFactory.html">I2PSocketManagerFactory</a>
|
||||
to create an
|
||||
<a href="http://docs.i2p2.de/core/net/i2p/client/streaming/I2PSocketManager.html">I2PSocketManager</a>.
|
||||
The application then asks the socket manager for an
|
||||
<a href="http://docs.i2p2.de/core/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/core/net/i2p/client/streaming/I2PSocket.html">I2PSocket</a>
|
||||
or receive connections with an
|
||||
<a href="http://docs.i2p2.de/core/net/i2p/client/streaming/I2PServerSocket.html">I2PServerSocket</a>.
|
||||
</p>
|
||||
<p>
|
||||
Here are the
|
||||
<a href="http://docs.i2p2.de/core/net/i2p/client/streaming/package-summary.html">full streaming library Javadocs</a>.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
For a good example of usage, see the i2psnark code.
|
||||
</p>
|
||||
|
||||
|
||||
<h3 id="options">Default Parameters</h3>
|
||||
<p>
|
||||
The current default values are listed below.
|
||||
Lower case values are streaming lib parameters that can changed on a
|
||||
per-connection basis.
|
||||
These 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
|
||||
<a href="http://docs.i2p2.de/core/net/i2p/client/streaming/I2PSocketManagerFactory.html">I2PSocketManagerFactory</a>.createManager(_i2cpHost, _i2cpPort, opts).
|
||||
Time values are in ms.
|
||||
</p>
|
||||
<p>
|
||||
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.
|
||||
</p>
|
||||
|
||||
|
||||
<table>
|
||||
<tr><th>Option</th><th>Default</th>
|
||||
</tr><tr><td>i2p.streaming.connectTimeout</td><td>5*60*1000
|
||||
</td></tr><tr><td>i2p.streaming.initialReceiveWindow</td><td>1
|
||||
</td></tr><tr><td>i2p.streaming.initialWindowSize</td><td>12 (if no <a href="#sharing">sharing data</a> available)
|
||||
</td></tr><tr><td>i2p.streaming.maxWindowSize</td><td>128
|
||||
</td></tr><tr><td>i2p.streaming.maxResends</td><td>8
|
||||
</td></tr><tr><td>i2p.streaming.profile</td><td>1 (bulk) (2=interactive not supported)
|
||||
</td></tr><tr><td>i2p.streaming.maxMessageSize</td><td>1730
|
||||
</td></tr><tr><td>i2p.streaming.initialRTT</td><td>10*1000 (if no <a href="#sharing">sharing data</a> available)
|
||||
</td></tr><tr><td>i2p.streaming.initialResendDelay</td><td>1000
|
||||
</td></tr><tr><td>i2p.streaming.initialAckDelay</td><td>2000
|
||||
</td></tr><tr><td>i2p.streaming.inactivityTimeout</td><td>90*1000
|
||||
</td></tr><tr><td>i2p.streaming.inactivityAction</td><td>2 (send) (0=noop, 1=disconnect)
|
||||
</td></tr><tr><td>i2p.streaming.congestionAvoidanceGrowthRateFactor</td><td>1
|
||||
</td></tr><tr><td>i2p.streaming.slowStartGrowthRateFactor</td><td>1
|
||||
</td></tr><tr><td>i2p.streaming.answerPings</td><td>true
|
||||
</td></tr><tr><td>i2p.streaming.maxConcurrentStreams</td><td>-1 (0 or negative value means unlimited)
|
||||
</td></tr><tr><td>i2p.streaming.maxConnsPerMinute</td><td>0 (per peer; 0 means disabled)
|
||||
</td></tr><tr><td>i2p.streaming.maxConnsPerHour</td><td>0 (per peer; 0 means disabled)
|
||||
</td></tr><tr><td>i2p.streaming.maxConnsPerDay</td><td>0 (per peer; 0 means disabled)
|
||||
</td></tr><tr><td>i2p.streaming.maxTotalConnsPerMinute</td><td>0 (all peers; 0 means disabled)
|
||||
</td></tr><tr><td>i2p.streaming.maxTotalConnsPerHour</td><td>0 (all peers; 0 means disabled)
|
||||
</td></tr><tr><td>i2p.streaming.maxTotalConnsPerDay</td><td>0 (all peers; 0 means disabled)
|
||||
</td></tr>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
|
||||
<h2>Protocol Specification</h2>
|
||||
<h3>Packet Format</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 <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 Field</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 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.
|
||||
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>
|
||||
|
||||
<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>Windowing</h3>
|
||||
<p>
|
||||
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>
|
||||
|
||||
|
||||
<h3>Close</h3>
|
||||
<p>
|
||||
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>
|
||||
|
||||
|
||||
<h3 id="sharing">Control Block Sharing</h3>
|
||||
<p>
|
||||
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
|
||||
<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>
|
||||
|
||||
<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
|
||||
<li>MAX_RESEND_DELAY = 45*1000
|
||||
<li>MIN_WINDOW_SIZE = 1
|
||||
<li>TREND_COUNT = 3
|
||||
<li>RTT_DAMPENING = 0.875
|
||||
<li>MIN_MESSAGE_SIZE = 512
|
||||
<li>INBOUND_BUFFER_SIZE = maxMessageSize * (maxWindowSize + 2)
|
||||
<li>INITIAL_TIMEOUT = 1.5 * initialRTT
|
||||
<li>PASSIVE_FLUSH_DELAY = 250
|
||||
</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
|
||||
@@ -34,253 +336,51 @@ 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
|
||||
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
|
||||
the small HTTP request payload, and the reply bundles the SYN,
|
||||
FIN, ACK, and the HTTP response payload. While an additional
|
||||
ACK must be transmitted to tell the HTTP server that the SYN/FIN/ACK has been
|
||||
received, the local HTTP proxy can often deliver the full response to the browser
|
||||
immediately.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
On the whole, however, 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.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
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>
|
||||
|
||||
<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
|
||||
per-connection basis.
|
||||
These 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).
|
||||
Time values are in ms.
|
||||
<h2>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>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.
|
||||
</p>
|
||||
|
||||
<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,
|
||||
including overhead for the typical case.
|
||||
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.
|
||||
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>
|
||||
|
||||
<p>
|
||||
<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.html">the NTCP page</a> for a discussion.
|
||||
</p>
|
||||
|
||||
|
||||
<h2>Packet Format</h2>
|
||||
<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 & 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>
|
||||
|
||||
|
||||
|
||||
<h2>Control Block Sharing</h2>
|
||||
<p>
|
||||
As of release 0.7.1, 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).
|
||||
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.
|
||||
</p>
|
||||
|
||||
<h2>Future Work and Proposals</h2>
|
||||
<p>
|
||||
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 deli>very 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>
|
||||
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 %}
|
||||
|
||||
@@ -168,7 +168,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 +192,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:
|
||||
</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>
|
||||
We can combine the above concepts to build successful connections in the network.
|
||||
</p>
|
||||
<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" />
|
||||
|
||||
<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 +235,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 +261,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 +284,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 +308,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 +325,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,10 +356,11 @@ 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>
|
||||
|
||||
@@ -31,11 +31,7 @@
|
||||
<li><a href="#batching">Advanced tunnel operation (batching/mixing/throttling/padding)</a></li>
|
||||
<li><a href="#stop">Stop & go mix w/ garlics & 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>
|
||||
</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>
|
||||
<p>
|
||||
Performance related improvements are listed on the
|
||||
<a href="performance.html">Performance</a> page.
|
||||
</p>
|
||||
{% endblock %}
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -48,6 +48,11 @@ 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>
|
||||
|
||||
<p>
|
||||
An overview of I2P terminology is
|
||||
<a href="how_tunnelrouting.html">on the tunnel overview page</a>.
|
||||
</p>
|
||||
|
||||
<h2>2) <a name="tunnel.operation">Tunnel operation</a></h2>
|
||||
|
||||
<p>Tunnel operation has four distinct processes, taken on by various
|
||||
@@ -72,7 +77,7 @@ peers, each hop's tunnel ID will change.</p>
|
||||
|
||||
<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:
|
||||
|
||||
@@ -87,7 +92,7 @@ Tunnel messages contain the following:
|
||||
<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>.
|
||||
|
||||
|
||||
|
||||
@@ -286,9 +291,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>
|
||||
|
||||
|
||||
BIN
www.i2p2/static/images/cz.png
Normal file
BIN
www.i2p2/static/images/cz.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 476 B |
BIN
www.i2p2/static/images/netdb_get_leaseset.png
Normal file
BIN
www.i2p2/static/images/netdb_get_leaseset.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 21 KiB |
BIN
www.i2p2/static/images/netdb_get_routerinfo_1.png
Normal file
BIN
www.i2p2/static/images/netdb_get_routerinfo_1.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 15 KiB |
BIN
www.i2p2/static/images/netdb_get_routerinfo_2.png
Normal file
BIN
www.i2p2/static/images/netdb_get_routerinfo_2.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 12 KiB |
Reference in New Issue
Block a user