Menu
▾
▴
dcplusplus-commit — SVN commit log
You can subscribe to this list here.
| 2006 |
Jan
|
Feb
(24) |
Mar
(9) |
Apr
(4) |
May
(7) |
Jun
(13) |
Jul
(19) |
Aug
(1) |
Sep
(12) |
Oct
(20) |
Nov
(1) |
Dec
(15) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
|
Feb
(6) |
Mar
(24) |
Apr
(1) |
May
(10) |
Jun
(30) |
Jul
(46) |
Aug
(20) |
Sep
(12) |
Oct
(27) |
Nov
(51) |
Dec
(58) |
| 2008 |
Jan
(40) |
Feb
(40) |
Mar
(78) |
Apr
(138) |
May
(4) |
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(5) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
(3) |
May
|
Jun
(2) |
Jul
(10) |
Aug
(1) |
Sep
(11) |
Oct
(31) |
Nov
(7) |
Dec
(1) |
| 2011 |
Jan
(1) |
Feb
|
Mar
(3) |
Apr
|
May
(1) |
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
(2) |
Sep
|
Oct
|
Nov
(2) |
Dec
(2) |
| 2013 |
Jan
(3) |
Feb
(5) |
Mar
(1) |
Apr
|
May
|
Jun
(11) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(4) |
| 2014 |
Jan
(2) |
Feb
(3) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2025 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(4) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: <em...@us...> - 2025-05-07 13:45:42
|
Revision: 132
http://sourceforge.net/p/adc/code/132
Author: emtee
Date: 2025-05-07 13:45:18 +0000 (Wed, 07 May 2025)
Log Message:
-----------
Generated HTML documents for respective TXT document
Modified Paths:
--------------
trunk/ADC-EXT.html
trunk/ADC.html
trunk/readme.txt
Modified: trunk/ADC-EXT.html
===================================================================
--- trunk/ADC-EXT.html 2025-05-07 13:39:24 UTC (rev 131)
+++ trunk/ADC-EXT.html 2025-05-07 13:45:18 UTC (rev 132)
@@ -734,9 +734,10 @@
<body class="article">
<div id="header">
<h1>ADC Extensions</h1>
-<span id="author">Fredrik Ullner, ul...@gm...</span><br />
-<span id="revnumber">version 1.0.8,</span>
-<span id="revdate">February 2014</span>
+<span id="author">DC++ Team</span><br />
+<span id="email"><code><<a href="mailto:dcp...@li...">dcp...@li...</a>></code></span><br />
+<span id="revnumber">version 1.0.9,</span>
+<span id="revdate">May 2025</span>
<div id="toc">
<div id="toctitle">Table of Contents</div>
<noscript><p><b>JavaScript must be enabled in your browser to display the table of contents.</b></p></noscript>
@@ -757,9 +758,37 @@
<div class="paragraph"><p>The latest draft of the next version of this document as well as intermediate
and older versions can be downloaded from
$URL: <a href="https://svn.code.sf.net/p/adc/code/trunk/ADC-EXT.txt">https://svn.code.sf.net/p/adc/code/trunk/ADC-EXT.txt</a> $.</p></div>
-<div class="paragraph"><p>This version corresponds to $Revision: 121 $.</p></div>
+<div class="paragraph"><p>This version corresponds to $Revision: 131 $.</p></div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_version_1_0_9_2025_05_07">3. Version 1.0.9, 2025-05-07</h2>
+<div class="sectionbody">
+<div class="paragraph"><p>DC++ Team <<a href="mailto:dcp...@li...">dcp...@li...</a>></p></div>
+<div class="ulist"><ul>
+<li>
+<p>
+Added implementation notes to BLOM
+</p>
+</li>
+<li>
+<p>
+Added <em>CCPM</em> extension for client to client private messages
+</p>
+</li>
+<li>
+<p>
+Editorial updates
+</p>
+</li>
+<li>
+<p>
+Clarified HH field in PING to be an ADC URL
+</p>
+</li>
+</ul></div>
<div class="sect2">
-<h3 id="_version_1_0_8">2.1. Version 1.0.8</h3>
+<h3 id="_version_1_0_8">3.1. Version 1.0.8</h3>
<div class="paragraph"><p>Fredrik Ullner <<a href="mailto:ul...@gm...">ul...@gm...</a>>, 2014-02-11</p></div>
<div class="ulist"><ul>
<li>
@@ -815,7 +844,7 @@
</ul></div>
</div>
<div class="sect2">
-<h3 id="_version_1_0_7">2.2. Version 1.0.7</h3>
+<h3 id="_version_1_0_7">3.2. Version 1.0.7</h3>
<div class="paragraph"><p>Fredrik Ullner <<a href="mailto:ul...@gm...">ul...@gm...</a>>, 2012-11-22</p></div>
<div class="ulist"><ul>
<li>
@@ -831,7 +860,7 @@
</ul></div>
</div>
<div class="sect2">
-<h3 id="_version_1_0_6">2.3. Version 1.0.6</h3>
+<h3 id="_version_1_0_6">3.3. Version 1.0.6</h3>
<div class="paragraph"><p>Fredrik Ullner <<a href="mailto:ul...@gm...">ul...@gm...</a>>, 2010-09-29</p></div>
<div class="ulist"><ul>
<li>
@@ -882,7 +911,7 @@
</ul></div>
</div>
<div class="sect2">
-<h3 id="_version_1_0_5">2.4. Version 1.0.5</h3>
+<h3 id="_version_1_0_5">3.4. Version 1.0.5</h3>
<div class="paragraph"><p>Fredrik Ullner <<a href="mailto:ul...@gm...">ul...@gm...</a>>, 2010-09-16</p></div>
<div class="ulist"><ul>
<li>
@@ -908,7 +937,7 @@
</ul></div>
</div>
<div class="sect2">
-<h3 id="_version_1_0_4">2.5. Version 1.0.4</h3>
+<h3 id="_version_1_0_4">3.5. Version 1.0.4</h3>
<div class="paragraph"><p>Fredrik Ullner <<a href="mailto:ul...@gm...">ul...@gm...</a>>, 2010-06-29</p></div>
<div class="ulist"><ul>
<li>
@@ -939,7 +968,7 @@
</ul></div>
</div>
<div class="sect2">
-<h3 id="_version_1_0_3">2.6. Version 1.0.3</h3>
+<h3 id="_version_1_0_3">3.6. Version 1.0.3</h3>
<div class="paragraph"><p>Fredrik Ullner <<a href="mailto:ul...@gm...">ul...@gm...</a>>, 2010-05-26</p></div>
<div class="ulist"><ul>
<li>
@@ -955,7 +984,7 @@
</ul></div>
</div>
<div class="sect2">
-<h3 id="_version_1_0_2">2.7. Version 1.0.2</h3>
+<h3 id="_version_1_0_2">3.7. Version 1.0.2</h3>
<div class="paragraph"><p>Fredrik Ullner <<a href="mailto:ul...@gm...">ul...@gm...</a>>, 2010-04-04</p></div>
<div class="ulist"><ul>
<li>
@@ -966,7 +995,7 @@
</ul></div>
</div>
<div class="sect2">
-<h3 id="_version_1_0_1">2.8. Version 1.0.1</h3>
+<h3 id="_version_1_0_1">3.8. Version 1.0.1</h3>
<div class="paragraph"><p>Fredrik Ullner <<a href="mailto:ul...@gm...">ul...@gm...</a>>, 2009-08-04</p></div>
<div class="ulist"><ul>
<li>
@@ -982,7 +1011,7 @@
</ul></div>
</div>
<div class="sect2">
-<h3 id="_version_1_0">2.9. Version 1.0</h3>
+<h3 id="_version_1_0">3.9. Version 1.0</h3>
<div class="paragraph"><p>Jacek Sieka <<a href="mailto:arn...@gm...">arn...@gm...</a>>, 2008-05-02</p></div>
<div class="ulist"><ul>
<li>
@@ -1000,23 +1029,23 @@
</div>
</div>
<div class="sect1">
-<h2 id="_extensions">3. Extensions</h2>
+<h2 id="_extensions">4. Extensions</h2>
<div class="sectionbody">
<div class="sect2">
-<h3 id="_tigr_tiger_tree_hash_support">3.1. TIGR - Tiger tree hash support</h3>
+<h3 id="_tigr_tiger_tree_hash_support">4.1. TIGR - Tiger tree hash support</h3>
<div class="sect3">
-<h4 id="_general">3.1.1. General</h4>
+<h4 id="_general">4.1.1. General</h4>
<div class="paragraph"><p>This extension adds Tiger tree hash support to the base protocol. It is
intended to be used both for identifying files and for purposes such as CID
-generation and password negotiation</p></div>
+generation and password negotiation.</p></div>
</div>
<div class="sect3">
-<h4 id="_tigr_for_shared_files">3.1.2. TIGR for shared files</h4>
+<h4 id="_tigr_for_shared_files">4.1.2. TIGR for shared files</h4>
<div class="paragraph"><p>All files shared by TIGR supporting clients must have been hashed using Merkle
Hash trees, as defined by
-<a href="http://web.archive.org/web/20080316033726/http://www.open-content.net/specs/draft-jchapweske-thex-02.html">http://web.archive.org/web/20080316033726/http://www.open-content.net/specs/draft-jchapweske-thex-02.html</a>.
+<a href="https://web.archive.org/web/20080316033726/http://www.open-content.net/specs/draft-jchapweske-thex-02.html">https://web.archive.org/web/20080316033726/http://www.open-content.net/specs/draft-jchapweske-thex-02.html</a>.
The Tiger
-algorithm, as specified by <a href="http://www.cs.technion.ac.il/~biham/Reports/Tiger/">http://www.cs.technion.ac.il/~biham/Reports/Tiger/</a>,
+algorithm, as specified by <a href="https://biham.cs.technion.ac.il/Reports/Tiger/">https://biham.cs.technion.ac.il/Reports/Tiger/</a>,
functions as the hash algorithm. A base segment size of 1024 bytes must be
used when generating the tree, but clients may then discard parts of the tree
as long as at least 7 levels are kept or a block granularity of 64 KiB is
@@ -1030,7 +1059,7 @@
<div class="paragraph"><p>In the file list, each File element carries an additional attribute "TTH"
containing the base32-encoded value of the Tiger tree root.</p></div>
<div class="paragraph"><p>In the GET/GFI type, the full tree may be accessed using the "tthl" type.</p></div>
-<div class="paragraph"><p>"tthl" transfers send the largest set of leaves available) as a binary stream
+<div class="paragraph"><p>"tthl" transfers send the largest set of leaves available as a binary stream
of leaf data, right-to-left, with no spacing in between them. <start_pos>
must be set to 0 and <bytes> to -1 when requesting the data. <bytes> must
contain the total binary size of the leaf stream in SND; by dividing this
@@ -1079,16 +1108,16 @@
</div>
</div>
<div class="sect2">
-<h3 id="_bzip_file_list_compressed_with_bzip2">3.2. BZIP - File list compressed with bzip2</h3>
+<h3 id="_bzip_file_list_compressed_with_bzip2">4.2. BZIP - File list compressed with bzip2</h3>
<div class="paragraph"><p>This extension adds a special file "files.xml.bz2" in the unnamed root of the
share which contains "files.xml" compressed with bzip2 1.0.3+ (www.bzip.org).</p></div>
</div>
<div class="sect2">
-<h3 id="_zlib_compressed_communication">3.3. ZLIB - Compressed communication</h3>
+<h3 id="_zlib_compressed_communication">4.3. ZLIB - Compressed communication</h3>
<div class="paragraph"><p>There are two variants of zlib support, FULL and GET, and only one should be
-used on a each communications channel set up.</p></div>
+used on each communications channel set up.</p></div>
<div class="sect3">
-<h4 id="_zlib_full">3.3.1. ZLIB-FULL</h4>
+<h4 id="_zlib_full">4.3.1. ZLIB-FULL</h4>
<div class="paragraph"><p>If, during SUP negotiation, a peer sends "ZLIF" in its support string, it must
accept two additional commands, ZON and ZOF. Upon reception of ZON the peer
must start decompressing the incoming stream of data with zlib before
@@ -1097,7 +1126,7 @@
chunk of data to allow for decompression by the peer.</p></div>
</div>
<div class="sect3">
-<h4 id="_zlib_get">3.3.2. ZLIB-GET</h4>
+<h4 id="_zlib_get">4.3.2. ZLIB-GET</h4>
<div class="paragraph"><p>The alternative is to send "ZLIG" to indicate that zlib is supported for
binary transfers using the GET command, but not otherwise. A flag "ZL1" is
added to the to the SND command to indicate that the data will come
@@ -1109,7 +1138,7 @@
</div>
</div>
<div class="sect2">
-<h3 id="_ping_pinger_extension">3.4. PING - Pinger extension</h3>
+<h3 id="_ping_pinger_extension">4.4. PING - Pinger extension</h3>
<div class="paragraph"><p>This extension can be supported by both clients and hubs, and when present, if hub
supports it, it must send additional information to the client ( otherwise normal
base client).</p></div>
@@ -1117,7 +1146,7 @@
that otherwise it would be impossible to get as a normal user (eg. minimum share,
maximum user count, etc).</p></div>
<div class="sect3">
-<h4 id="_inf">3.4.1. INF</h4>
+<h4 id="_inf">4.4.1. INF</h4>
<div class="paragraph"><p>Contexts : F</p></div>
<div class="paragraph"><p>When the client supporting the PING extension connects, the hub must send its
normal INF along with the following added fields ( none mandatory, if not present,
@@ -1139,8 +1168,8 @@
<tbody>
<tr>
<td align="left" valign="top"><p class="table">HH</p></td>
-<td align="left" valign="top"><p class="table">string</p></td>
-<td align="left" valign="top"><p class="table">Hub Host address ( DNS or IP )</p></td>
+<td align="left" valign="top"><p class="table">url</p></td>
+<td align="left" valign="top"><p class="table">Hub Host address (ADC/ADCS URL address form)</p></td>
</tr>
<tr>
<td align="left" valign="top"><p class="table">WS</p></td>
@@ -1262,7 +1291,7 @@
<pre><code>-pinger- HSUP ADBASE ADPING AD..
-hub- ISUP ADBASE ADPING AD..
-hub- ISID ..
--hub- IINF NIhubname DEcurrent\stopic VE.. HHexample.org:555 WShttp://example.org/ OWmyname UC2231 SS.. SF.. MS0 ML0 MC5000
+-hub- IINF NIhubname DEcurrent\stopic VE.. HHadc://example.org:555 WShttp://example.org/ OWmyname UC2231 SS.. SF.. MS0 ML0 MC5000
- (pinger may disconnect)</code></pre>
</div></div>
</div></div>
@@ -1269,7 +1298,7 @@
</div>
</div>
<div class="sect3">
-<h4 id="_hub_hublist_communication">3.4.2. Hub - Hublist communication</h4>
+<h4 id="_hub_hublist_communication">4.4.2. Hub - Hublist communication</h4>
<div class="paragraph"><p>The same extension goes for hub- hublist communication. This way, the hub
takes the role of the client and the hublist of the server.</p></div>
<div class="paragraph"><p>The hublist may send INF about itself with NI field which would become hublist
@@ -1291,15 +1320,15 @@
</div>
</div>
<div class="sect2">
-<h3 id="_ts_timestamp_in_msg">3.5. TS - Timestamp in MSG</h3>
+<h3 id="_ts_timestamp_in_msg">4.5. TS - Timestamp in MSG</h3>
<div class="paragraph"><p>Timestamp of the moment when the message was sent, expressed in seconds since the Unix Epoch (January 1 1970 00:00:00 GMT).</p></div>
</div>
<div class="sect2">
-<h3 id="_dfav_distributed_favorites">3.6. DFAV - Distributed Favorites</h3>
+<h3 id="_dfav_distributed_favorites">4.6. DFAV - Distributed Favorites</h3>
<div class="paragraph"><p>The idea behind this extension is to generate a public hublist from the users favorite hublist. Implementations should separate between public and private hubs in the favorite hublist of an user, in order not to distribute private hubs where one can not connect to anyway.</p></div>
<div class="paragraph"><p>Signal DFAV in SUP and the INF’s SU field.</p></div>
<div class="sect3">
-<h4 id="_gfa">3.6.1. GFA</h4>
+<h4 id="_gfa">4.6.1. GFA</h4>
<div class="literalblock">
<div class="content">
<pre><code>GFA</code></pre>
@@ -1308,7 +1337,7 @@
<div class="paragraph"><p>Asks all users within the same hub with the correct feature to send all publicly available hubs, in their favorite hub list to the requesting client.</p></div>
</div>
<div class="sect3">
-<h4 id="_rfa">3.6.2. RFA</h4>
+<h4 id="_rfa">4.6.2. RFA</h4>
<div class="literalblock">
<div class="content">
<pre><code>RFA</code></pre>
@@ -1337,7 +1366,7 @@
</div>
</div>
<div class="sect2">
-<h3 id="_ucmd_user_commands">3.7. UCMD - User commands</h3>
+<h3 id="_ucmd_user_commands">4.7. UCMD - User commands</h3>
<div class="literalblock">
<div class="content">
<pre><code>CMD name</code></pre>
@@ -1377,7 +1406,7 @@
</table>
</div>
<div class="sect3">
-<h4 id="_keywords">3.7.1. Keywords</h4>
+<h4 id="_keywords">4.7.1. Keywords</h4>
<div class="paragraph"><p>Keywords are specified using "%[keyword]". Unknown keywords must be replaced by the empty string. Additionally, all %-substitutions of the C function "strftime" must be supported.</p></div>
<div class="paragraph"><p>The following tables specify the keywords that must be supported.</p></div>
<div class="paragraph"><p>Client parameters</p></div>
@@ -1444,7 +1473,7 @@
</tr>
<tr>
<td align="left" valign="top"><p class="table">fileMN</p></td>
-<td align="left" valign="top"><p class="table">Specify magnet link. <a href="http://en.wikipedia.org/wiki/Magnet_link">Magnet links</a> are used to reference files across networks and applications. Clients may ignore parameters it does not understand, but are free to pass on the parameters to other programs.</p></td>
+<td align="left" valign="top"><p class="table">Specify magnet link. <a href="https://en.wikipedia.org/wiki/Magnet_link">Magnet links</a> are used to reference files across networks and applications. Clients may ignore parameters it does not understand, but are free to pass on the parameters to other programs.</p></td>
</tr>
</tbody>
</table>
@@ -1466,7 +1495,7 @@
</div>
</div>
<div class="sect3">
-<h4 id="_example_3">3.7.2. Example</h4>
+<h4 id="_example_3">4.7.2. Example</h4>
<div class="exampleblock">
<div class="content">
<div class="paragraph"><p>ICMD ADCH++/Hub\smanagement/Register\snick TTHMSG\s+regnick\s%[userNI]\s%[line:Password\s(leave\sempty\sto\sun-reg)]\s%[line:Level\s(facultative;\sdefaults\sto\syour\sown\slevel\sminus\sone)]\n CT2</p></div>
@@ -1478,10 +1507,10 @@
</div>
</div>
<div class="sect2">
-<h3 id="_blom_bloom_filter">3.8. BLOM- Bloom filter</h3>
+<h3 id="_blom_bloom_filter">4.8. BLOM - Bloom filter</h3>
<div class="paragraph"><p>Bloom filters allow the hub to filter certain searches using bitmap that represents the hashes of the files in the users share. BLOM is an extension that allows hub software to create a map (bloom filter) of the shared files on the hub, but with minimal effort, e.g. the hub doesn’t keep a list of files, but a filter that never produces false negatives but only possible false positives. This can potentially save bandwidth and effort on the client side. When the user updates the share, the client must send an INF containing the flag SF. The hub may at any time request that the client sends an updated version of its bloom filter by sending a GET command to the client. The client will then respond using SND and send the bloom filter binary data.</p></div>
<div class="sect3">
-<h4 id="_legend">3.8.1. Legend</h4>
+<h4 id="_legend">4.8.1. Legend</h4>
<div class="tableblock">
<table rules="all"
frame="border"
@@ -1511,7 +1540,7 @@
</tr>
<tr>
<td align="left" valign="top"><p class="table">p</p></td>
-<td align="left" valign="top"><p class="table">Propability of a false positive</p></td>
+<td align="left" valign="top"><p class="table">Probability of a false positive</p></td>
</tr>
</tbody>
</table>
@@ -1519,7 +1548,7 @@
<div class="paragraph"><p>The hub chooses k, h and m.</p></div>
</div>
<div class="sect3">
-<h4 id="_restrictions">3.8.2. Restrictions</h4>
+<h4 id="_restrictions">4.8.2. Restrictions</h4>
<div class="tableblock">
<table rules="all"
frame="border"
@@ -1543,7 +1572,7 @@
</div>
</div>
<div class="sect3">
-<h4 id="_probability">3.8.3. Probability</h4>
+<h4 id="_probability">4.8.3. Probability</h4>
<div class="tableblock">
<table rules="all"
frame="border"
@@ -1564,7 +1593,7 @@
</div>
</div>
<div class="sect3">
-<h4 id="_protocol_changes">3.8.4. Protocol changes</h4>
+<h4 id="_protocol_changes">4.8.4. Protocol changes</h4>
<div class="paragraph"><p>Signal BLOM in SUP.</p></div>
<div class="paragraph"><p>For the SND type, adds H as message type.</p></div>
<div class="paragraph"><p>For the GET type, adds I as message type.</p></div>
@@ -1593,35 +1622,40 @@
</div>
</div>
<div class="sect3">
-<h4 id="_algorithm">3.8.5. Algorithm</h4>
+<h4 id="_algorithm">4.8.5. Algorithm</h4>
<div class="paragraph"><p>The client constructs the bloom filter by creating a bit array of m bits set to 0 (zero). For each file it then sets to "1" k positions constructed from the file hash. Seeing the file hash as a stream of bits (starting from the lowest bit of the first byte, ending at the highest bit of the last byte), the client should use h bits starting at the first bit of the first byte to create an integer and apply modulo m to get the position in the bit array, then redo the process k times advancing the starting position by h each time.</p></div>
<div class="paragraph"><p>Once the hub has received the bloom filter bit array, for each search command it processes, if it contains a hash search term, it can skip broadcasting the search to a particular client if at least one of the k bits in that clients bit array is "0", calculating positions as the client does when setting bits to "1". The hub has to evaluate the filter for each client that it has a bloom filter for, for each search.</p></div>
</div>
<div class="sect3">
-<h4 id="_probability_calculations">3.8.6. Probability calculations</h4>
+<h4 id="_probability_calculations">4.8.6. Probability calculations</h4>
<div class="paragraph"><p>p = (1 - (1 - 1 / m)<sup>(k * n)</sup>)<sup>k</sup>, thus p becomes smaller as m grows and larger as n grows. Larger m means more bits to transfer but also fewer false positives. The optimum value for k given m and n is (m / n) * ln 2. The largest k supported by a hash of a certain size is b / h, so if the hub wants the smallest p possible, it should choose the smallest possible h which gives the largest k, and then calculate m = k * n/ln 2, checking that the resulting m < 2<sup>h</sup>. 2<sup>h</sup> should much be larger than m (at least 3-4 times), because of how the modulo operator works. Also, with m grows the required bandwidth to transfer the bloom filter, so the hub may wish to cap m. In that case, it should still choose k according to m / n * ln 2, but send an h as big as possible to alleviate biasing problems.</p></div>
</div>
<div class="sect3">
-<h4 id="_sample_implementations">3.8.7. Sample implementations</h4>
+<h4 id="_sample_implementations">4.8.7. Sample implementations</h4>
<div class="sect4">
<h5 id="_tiger">Tiger</h5>
<div class="paragraph"><p>For TTH roots, b is 192 and a reasonable value for h is 24, giving a maximum k = 8 which means that m = 8 * n / ln 2 ≈ 11.5 * n. The required bandwidth then becomes 11.5 * n / 8 bytes, so approximately 1.44 bytes per file in the users share. For 20000 files, m should then be 230016 (taking into account the modulo 64 requirement), giving a p = 0.004, in other words ~99.6% of all searches that don’t match a users share would not be sent, saving valuable upload bandwidth for the hub. The client calculates i valid positions, if x is an array of bytes containing the hash of the file, on a little-endian machine, by doing pos = x[0+i*h/8] | (x[1+i*h/8] << 8) | (x[2+i*h/8] << 16) for i = [0;k). This is of course a special case where h % 8 = 0, the actual algorithm has to take into consideration values for h where the integer crosses byte boundaries.</p></div>
-<div class="paragraph"><p>For test vectors, see the <a href="http://www.adcportal.com/wiki/index.php/Talk:BLOM">ADC wiki talk page</a>.</p></div>
+<div class="paragraph"><p>For test vectors, see the <a href="https://adc.sourceforge.io/wiki/index.php/Talk:BLOM">ADC wiki talk page</a>.</p></div>
</div>
</div>
+<div class="sect3">
+<h4 id="_implementation_notes">4.8.8. Implementation notes</h4>
+<div class="paragraph"><p>Clients do not signal each atomic user update of the share using the SF flag. Instead, they tend to send a cumulative result of multiple updates in a timely fashion. However, an unambiguous summary of the number of hash additions and removals may result in a lack of an update signal. Therefore, hubs are recommended to look for and process INFs containing the SS flag as well, since an incoming SS flag (especially when not accompanied by an SF) may also indicate an update in the hashes, one that occurs without a change in the total number of files shared.</p></div>
+<div class="paragraph"><p>Clients shall strive to signal multiple share updates in an unambiguous manner, thus enabling hubs to request the most accurate and up-to-date version of the client’s bloom filter.</p></div>
</div>
+</div>
<div class="sect2">
-<h3 id="_natt_nat_traversal">3.9. NATT - NAT traversal</h3>
-<div class="paragraph"><p>NAT traversal allow two passive clients to connect to each other. This specification is based on the TCP hole punching algorithm described in <span class="footnote" id="_footnote_Peer-to-Peer Communication Across Network Address Translators"><br />[B. Ford and P. Srisuresh and and D. Kegel. "Peer-to-Peer Communication Across Network Address Translators". In USENIX Technical Conference 2005 - pages 179–192. Online version: <a href="http://www.brynosaurus.com/pub/net/p2pnat/">http://www.brynosaurus.com/pub/net/p2pnat/</a>]<br /></span>.</p></div>
+<h3 id="_natt_nat_traversal">4.9. NATT - NAT traversal</h3>
+<div class="paragraph"><p>NAT traversal allow two passive clients to connect to each other. This specification is based on the TCP hole punching algorithm described in <span class="footnote" id="_footnote_Peer-to-Peer Communication Across Network Address Translators"><br />[B. Ford and P. Srisuresh and and D. Kegel. "Peer-to-Peer Communication Across Network Address Translators". In USENIX Technical Conference 2005 - pages 179–192. Online version: <a href="https://bford.info/pub/net/p2pnat/">https://bford.info/pub/net/p2pnat/</a>]<br /></span>.</p></div>
<div class="paragraph"><p>If a client does not support TCP4 or TCP6, it will send an RCM to the client it is trying to connect to. If the other client also doesn’t support TCP4 (or TCP6 correspondingly), NAT traversal may instead be used. Signal NATT in the INF’s SU field.</p></div>
<div class="paragraph"><p>Do note that the hub must forward I4 or I6 for respective clients' INF.</p></div>
<div class="paragraph"><p>An endpoint is the tuple of IP and port. The "private endpoint port" refers to the outbound port to the connected hub, as seen by the client. Each client must listen for incoming connections on this port. Note that this protocol extension uses only this port for the TCP hole punching, the use of the "public endpoint port" as specified in <span class="footnoteref"><br /><a href="#_footnote_Peer-to-Peer Communication Across Network Address Translators">[Peer-to-Peer Communication Across Network Address Translators]</a><br /></span> is not supported.</p></div>
<div class="sect3">
-<h4 id="_base_rcm_updates">3.9.1. BASE RCM updates</h4>
+<h4 id="_base_rcm_updates">4.9.1. BASE RCM updates</h4>
<div class="paragraph"><p>When receiving an RCM and the client does not support TCP4 or TCP6, and if NAT-T is supported in the remote client, a NAT command should be sent repeating the protocol and token. The port shall be the private endpoint port to the connected hub.</p></div>
</div>
<div class="sect3">
-<h4 id="_nat">3.9.2. NAT</h4>
+<h4 id="_nat">4.9.2. NAT</h4>
<div class="literalblock">
<div class="content">
<pre><code>NAT protocol separator port separator token</code></pre>
@@ -1631,7 +1665,7 @@
<div class="paragraph"><p>Upon receiving this, try and connect to the specified port. An RNT command should be sent repeating the protocol and token. The port shall be the private endpoint. Upon receiving this, try and connect to the specified port.</p></div>
</div>
<div class="sect3">
-<h4 id="_rnt">3.9.3. RNT</h4>
+<h4 id="_rnt">4.9.3. RNT</h4>
<div class="literalblock">
<div class="content">
<pre><code>RNT protocol separator port separator token</code></pre>
@@ -1641,7 +1675,7 @@
<div class="paragraph"><p>Upon receiving this, try and connect to the specified port.</p></div>
</div>
<div class="sect3">
-<h4 id="_example_4">3.9.4. Example</h4>
+<h4 id="_example_4">4.9.4. Example</h4>
<div class="paragraph"><p>Client A is connected to hub A with the private endpoint 1000 and client B is connected to hub A with the private endpoint 2000. Client A has the SID AAAA and client B has the SID BBBB.</p></div>
<div class="exampleblock">
<div class="content">
@@ -1654,7 +1688,7 @@
</div>
</div>
<div class="sect2">
-<h3 id="_rf_referrer_notification">3.10. RF - Referrer notification</h3>
+<h3 id="_rf_referrer_notification">4.10. RF - Referrer notification</h3>
<div class="paragraph"><p>Extends the RF field of the INF to STA, allowing a client to notify clients and hubs upon SUP-negotiation from where the C-C or C-H originated from.</p></div>
<div class="tableblock">
<table rules="all"
@@ -1671,7 +1705,7 @@
</table>
</div>
<div class="sect3">
-<h4 id="_example_5">3.10.1. Example</h4>
+<h4 id="_example_5">4.10.1. Example</h4>
<div class="exampleblock">
<div class="content">
<div class="paragraph"><p>CSUP ADBASE (…)</p></div>
@@ -1680,7 +1714,7 @@
</div>
</div>
<div class="sect2">
-<h3 id="_qp_upload_queue_notification">3.11. QP - Upload queue notification</h3>
+<h3 id="_qp_upload_queue_notification">4.11. QP - Upload queue notification</h3>
<div class="paragraph"><p>This extension’s purpose is creating a queue on a client, when multiple other clients want to download from it, but they have no slots. Currently, when a slot is being freed, the first connecting client gets it. Other clients that don’t have the luck of getting in time to attempt to download, have to wait again. The client who creates a queue must have a ticket number for each connecting client, which must be kept internally , and a difference between current connecting client’s queue number and the currently uploading client’s be provided to the connecting client, so that the clients are being deserved in the order they originally connected. The client could have a ticket incrementing starting from 1 for each session. Connecting clients must use the same token as they used when originally connected.</p></div>
<div class="tableblock">
<table rules="all"
@@ -1697,7 +1731,7 @@
</table>
</div>
<div class="sect3">
-<h4 id="_example_6">3.11.1. Example</h4>
+<h4 id="_example_6">4.11.1. Example</h4>
<div class="paragraph"><p>The following example will notify that the client’s slots are full and that there are three uploads in the queue.</p></div>
<div class="exampleblock">
<div class="content">
@@ -1706,12 +1740,12 @@
</div>
</div>
<div class="sect2">
-<h3 id="_pfsr_partial_file_sharing">3.12. PFSR - Partial file sharing</h3>
+<h3 id="_pfsr_partial_file_sharing">4.12. PFSR - Partial file sharing</h3>
<div class="paragraph"><p>Partial File Sharing allows sharing of files which are available in user’s download queue or in finished downloads list. As a result of this, new files will be spread much faster over whole network.</p></div>
<div class="paragraph"><p>When client receives search request (SCH), it looks into shared list to see whether requested hash is available between shared files. If it’s found, everything is processed as normally. In other case, it looks into download queue (then, into finished downloads list) and receives a list of available chunks for requested hash. It mustn’t take every chunk, but only that ones which are fully downloaded and has already been verified (e.g. against TTH leaves).</p></div>
<div class="paragraph"><p>The feature should be signalled in SUP as PFSR.</p></div>
<div class="sect3">
-<h4 id="_psr">3.12.1. PSR</h4>
+<h4 id="_psr">4.12.1. PSR</h4>
<div class="literalblock">
<div class="content">
<pre><code>PSR</code></pre>
@@ -1752,9 +1786,9 @@
</div>
</div>
<div class="sect2">
-<h3 id="_lc_locale_specification">3.13. LC - Locale specification</h3>
+<h3 id="_lc_locale_specification">4.13. LC - Locale specification</h3>
<div class="paragraph"><p>This extension’s purpose is to notify the hub which user locale the client is using as well as the default locale for the hub. This allows hubs to customize text sent to clients, depending on language, left-to-right or right-to-left and more. If the hub does not directly support the client’s locale, it should attempt to fall back to the same language group (e.g. hub supports en-US but not en-AU, so falls back to en-US), and if this is not available, then fall back to the hub’s own locale.</p></div>
-<div class="paragraph"><p><a href="http://tools.ietf.org/html/bcp47">BCP47</a> should be used as reference for locale structure.</p></div>
+<div class="paragraph"><p><a href="https://www.rfc-editor.org/info/bcp47">BCP47</a> should be used as reference for locale structure.</p></div>
<div class="tableblock">
<table rules="all"
frame="border"
@@ -1772,7 +1806,7 @@
<div class="paragraph"><p>Note that the standard suggest that the language should be in lowercase and the country in upper case. Note that the country code may be more than two characters. Additionally, dash (<em>-</em>) and underscore (<em>_</em>) are acceptable seperators.</p></div>
</div>
<div class="sect2">
-<h3 id="_hidden_status_for_client_type">3.14. Hidden status for client type</h3>
+<h3 id="_hidden_status_for_client_type">4.14. Hidden status for client type</h3>
<div class="paragraph"><p>This extension will add to the CT field enumeration in the INF to denote a user as "hidden". Other clients shall as appropriate not display the user in user lists etc.</p></div>
<div class="tableblock">
<table rules="all"
@@ -1805,7 +1839,7 @@
</div>
</div>
<div class="sect2">
-<h3 id="_invalid_feature_error_code">3.15. "Invalid feature" error code</h3>
+<h3 id="_invalid_feature_error_code">4.15. "Invalid feature" error code</h3>
<div class="paragraph"><p>This extension will add "Invalid feature" as error code in STA. Invalid features are features the hub or client deem inappropriate or simply not welcome. The error code should not be used for features the hub or client does not know of.</p></div>
<div class="tableblock">
<table rules="all"
@@ -1823,7 +1857,7 @@
</div>
</div>
<div class="sect2">
-<h3 id="_keyp_certificate_substitution_protection_in_conjunction_with_adcs">3.16. KEYP - Certificate substitution protection in conjunction with ADCS</h3>
+<h3 id="_keyp_certificate_substitution_protection_in_conjunction_with_adcs">4.16. KEYP - Certificate substitution protection in conjunction with ADCS</h3>
<div class="paragraph"><p>This extension adds a simple, but secure way to protect against man-in-the-middle attacks against ADC when wrapped with TLS (1.0 or later). It does not require setting up a CA or signing keys, but that is still possible if desired.</p></div>
<div class="paragraph"><p>The extension introduces a keyprint parameter to the ADCS URI. The keyprint parameter is a hash of the server certificate.</p></div>
<div class="paragraph"><p>The extension also requires clients to publish their own certificates' keyprint in the KP field in the INF. Assuming one trusts the hub enough not to maliciously change the keyprints en route (a reasonable assumption given the hub’s existing position of trust), and given that the connection to the hub has been similarly authenticated (either as above or via a directly downloaded trusted certificate), client-client connections are also protected against attempted man-in-the-middle attacks - without messing around with having to get everyone’s certificates signed in advance.</p></div>
@@ -1845,11 +1879,11 @@
</table>
</div>
<div class="sect3">
-<h4 id="_keyprint_replacement_behaviour">3.16.1. Keyprint replacement behaviour</h4>
+<h4 id="_keyprint_replacement_behaviour">4.16.1. Keyprint replacement behaviour</h4>
<div class="paragraph"><p>If a client receives a KP field in an FINF broadcast via a hub it is connected to using ADCS and a trusted key as above (or otherwise), it should be regarded as the valid and correct keyprint for that client’s IP/port/hub combination, replacing any earlier keyprint for that IP/port/hub combination.</p></div>
</div>
<div class="sect3">
-<h4 id="_keyprint_verification">3.16.2. Keyprint verification</h4>
+<h4 id="_keyprint_verification">4.16.2. Keyprint verification</h4>
<div class="paragraph"><p>When initiating a TLS handshake with a remote host where the keyprint is known, the client can verify that a man-in-the-middle attack is not occurring by checking if the hash given in the keyprint exactly matches that of the certificate presented during the handshake by the remote host.</p></div>
<div class="paragraph"><p>Suppose the client is aware of a remote host’s keyprint and is in the process of connecting to that host. A certificate substitution attack is in place if the hub presents itself with a certificate that does not match and where the certificate is not the root of the valid signature chain covering the certificate.
If the client detects such an attack, the client should abort the connection and notify the user with a message stating, for example, "Crypto error: Detected attempted man-in-the-middle attack, aborting". (This error quite possibly represents a real attempted attack that has been foiled; we may try auto-reconnecting but we should NEVER ignore it, or it will succeed. We may wish to avoid stating the keyprint of the certificate that was actually received.)</p></div>
@@ -1856,7 +1890,7 @@
<div class="paragraph"><p>Optionally, when receiving a TLS handshake, if the client knows what the remote host’s keyprint ought to be, the client could also verify this. However, note that only the initiating side needs to check this for the man-in-the-middle protection to be valid; specifically the hub doesn’t need to remember, or even understand, clients' keyprints.</p></div>
</div>
<div class="sect3">
-<h4 id="_security_considerations">3.16.3. Security Considerations</h4>
+<h4 id="_security_considerations">4.16.3. Security Considerations</h4>
<div class="sect4">
<h5 id="_general_2">General</h5>
<div class="paragraph"><p>The certificates, including the name fields, are sent in the clear during the initial handshake. Therefore it is recommended to avoid identifying marks in the certificates CommonName fields (for example) that would clearly single them out as being TLS keys used by ADCS:, and the CID field most definitely should not appear. Quite possibly no name fields should appear, or they should be blank.</p></div>
@@ -1907,7 +1941,7 @@
</div>
</div>
<div class="sect3">
-<h4 id="_example_7">3.16.4. Example</h4>
+<h4 id="_example_7">4.16.4. Example</h4>
<div class="exampleblock">
<div class="content">
<div class="paragraph"><p>adcs://example.com:1234/?kp=SHA256/G3PJC4F4MQ5KOXGE2MPYJW5EW63IC6M7RN7OS663JLLWN2M5I6FQ</p></div>
@@ -1915,7 +1949,7 @@
</div>
</div>
<div class="sect2">
-<h3 id="_sudp_encrypting_udp_traffic">3.17. SUDP - Encrypting UDP traffic</h3>
+<h3 id="_sudp_encrypting_udp_traffic">4.17. SUDP - Encrypting UDP traffic</h3>
<div class="paragraph"><p>This is an extension that allows UDP traffic to be encrypted.</p></div>
<div class="paragraph"><p>While assymetric encryption may be optimal in sense of security, a symmetric cipher will protect perfectly against outside adversaries given the hub-client connections is also running ADCS. New is that senders now create a random IV for their "request command" (e.g. searches) and send it along the "response command" (e.g. search result).</p></div>
<div class="paragraph"><p>Signal SUDP in SUP and in the INF’s SU field.</p></div>
@@ -1938,7 +1972,7 @@
<div class="paragraph"><p>A client that has a response for the command can now encrypt the response message by prepending 16 bytes of random data and afterwards encrypting it with AES/CBC/PKCS5Padding (Cipher/Blockmode/Padding) using 16 zero bytes as IV for CBC.</p></div>
<div class="paragraph"><p>In above scenario, the response would be a RES command.</p></div>
<div class="sect3">
-<h4 id="_decryption_notes">3.17.1. Decryption notes</h4>
+<h4 id="_decryption_notes">4.17.1. Decryption notes</h4>
<div class="paragraph"><p>In the case of searching, the searching client in return for decryption first has to guess which commands it receives are encrypted and which are not. It can do so for example by simply trying decryption with all currently active keys. If a key is wrong or the message was not encrypted, padding will fail and decryption is unsuccessful!</p></div>
<div class="paragraph"><p>Client may otherwise verify if the message is a U-type message, followed by a known command (and a space). If that is not the case, the client takes the most recent key and decrypts. If that succeed, the message is valid.</p></div>
<div class="paragraph"><p>There is a potential chance that decryption succeed with what is a bad key. If that is the case, the client should verify that the data is not garbled.</p></div>
@@ -1946,11 +1980,11 @@
</div>
</div>
<div class="sect2">
-<h3 id="_type_typing_notification">3.18. TYPE - Typing notification</h3>
-<div class="paragraph"><p>This extension adds a typing similar to Jabber’s <a href="http://www.xmpp.org/extensions/xep-0085.html">"Chat state notifications"</a>.</p></div>
+<h3 id="_type_typing_notification">4.18. TYPE - Typing notification</h3>
+<div class="paragraph"><p>This extension adds a typing similar to Jabber’s <a href="https://xmpp.org/extensions/xep-0085.html">"Chat state notifications"</a>.</p></div>
<div class="paragraph"><p>Signal TYPE in SUP and the INF’s SU field.</p></div>
<div class="sect3">
-<h4 id="_tpn">3.18.1. TPN</h4>
+<h4 id="_tpn">4.18.1. TPN</h4>
<div class="literalblock">
<div class="content">
<pre><code>TPN code</code></pre>
@@ -2004,11 +2038,11 @@
</div>
</div>
<div class="sect2">
-<h3 id="_feed_rss_feeds">3.19. FEED - RSS feeds</h3>
-<div class="paragraph"><p>The extension adds <a href="http://en.wikipedia.org/wiki/RSS">RSS feed</a> support.</p></div>
+<h3 id="_feed_rss_feeds">4.19. FEED - RSS feeds</h3>
+<div class="paragraph"><p>The extension adds <a href="https://en.wikipedia.org/wiki/RSS">RSS feed</a> support.</p></div>
<div class="paragraph"><p>Signal FEED in SUP and the INF’s SU field.</p></div>
<div class="sect3">
-<h4 id="_rss">3.19.1. RSS</h4>
+<h4 id="_rss">4.19.1. RSS</h4>
<div class="literalblock">
<div class="content">
<pre><code>RSS url</code></pre>
@@ -2061,7 +2095,7 @@
</div>
</div>
<div class="sect3">
-<h4 id="_examples">3.19.2. Examples</h4>
+<h4 id="_examples">4.19.2. Examples</h4>
<div class="paragraph"><p>Publish a new feed called <em>Example_feed</em> and with a description <em>description_of_feed</em>:</p></div>
<div class="exampleblock">
<div class="content">
@@ -2080,7 +2114,7 @@
</div>
</div>
<div class="sect2">
-<h3 id="_sega_grouping_of_file_extensions_in_sch">3.20. SEGA - Grouping of file extensions in SCH</h3>
+<h3 id="_sega_grouping_of_file_extensions_in_sch">4.20. SEGA - Grouping of file extensions in SCH</h3>
<div class="paragraph"><p>In BASE, clients add EX fields to SCH to denote which extension files should have. This can lead to a situation where the large bulk of extensions are of similar "type", e.g. audio files or documents. This extension intend to add a field GR which groups multiple extensions. In addition, the field RX shall be used for group-exclusion; if all extensions in a group but two are desired, field RX will be used to exclude those group items.</p></div>
<div class="paragraph"><p>Signal SEGA in the INF’s SU field for support of this extension.</p></div>
<div class="paragraph"><p>Field GR values, where multiple groups are specified by adding the numbers together:</p></div>
@@ -2142,7 +2176,7 @@
</div>
</div>
<div class="sect2">
-<h3 id="_fo_failover_hub_addresses">3.21. FO - Failover hub addresses</h3>
+<h3 id="_fo_failover_hub_addresses">4.21. FO - Failover hub addresses</h3>
<div class="paragraph"><p>If a hub goes down, the client’s only option is to keep re-trying the last known hub address. This extension will add a list of failover hub addresses, field FO, that the client can try to connect to, if the main hub address fail.</p></div>
<div class="paragraph"><p>Clients should decide the frequency of connection attempts (for the main hub as well as the failover addresses). The client should try connecting in the specified order. The client may decide what to do after the FO-list is exhausted, but recommended is to try to connect to the main hub and continue with the list as before.</p></div>
<div class="paragraph"><p>The client should display an appropriate message to the user that it has connected to a failover address.</p></div>
@@ -2164,7 +2198,7 @@
</div>
</div>
<div class="sect2">
-<h3 id="_fs_free_slots_in_client">3.22. FS - Free slots in client</h3>
+<h3 id="_fs_free_slots_in_client">4.22. FS - Free slots in client</h3>
<div class="paragraph"><p>This is an extension that will broadcast the amount of free slots the client has available.</p></div>
<div class="paragraph"><p>Field FS in the client’s INF:</p></div>
<div class="tableblock">
@@ -2183,20 +2217,20 @@
</div>
</div>
<div class="sect2">
-<h3 id="_adcs_symmetrical_encryption_in_adc">3.23. ADCS - Symmetrical Encryption in ADC</h3>
+<h3 id="_adcs_symmetrical_encryption_in_adc">4.23. ADCS - Symmetrical Encryption in ADC</h3>
<div class="paragraph"><p>ADCS is an extension that has the goal of adding the TLS/SSL layer just over the TCP layer and beneath the application layer (where ADC runs). This way, the ADC protocol remains unchanged while the connections are encrypted. The connecting party performs a TLS handshake immediately after the TCP connection is established. The ADC handshake is performed and once the TLS connection is established the ADC handshake proceeds as usual.</p></div>
<div class="paragraph"><p>Encrypted ADC connections can be established using a TLS tunnel, both for hub and for client connections. Certificates can be used to authenticate both hub and user, for example by making the hub the root CA, and only allow clients signed by the hub to connect. Ephemeral keys should be use to ensure forward secrecy when possible. A future extension or revision of this extension will provide ways to handle certificate based logins, who creates which certificates and who signs what, and all that is not specified in this revision.</p></div>
<div class="sect3">
-<h4 id="_client_hub_encryption">3.23.1. Client-Hub encryption</h4>
+<h4 id="_client_hub_encryption">4.23.1. Client-Hub encryption</h4>
<div class="paragraph"><p>TLS client-hub connections can be initiated either by negotiating the feature "ADCS" on connection or by using the protocol adcs:// when initiating the connection.</p></div>
</div>
<div class="sect3">
-<h4 id="_client_client_encryption">3.23.2. Client-Client encryption</h4>
+<h4 id="_client_client_encryption">4.23.2. Client-Client encryption</h4>
<div class="paragraph"><p>TLS client-client connections can be established either by negotiating the feature "ADCS" on connection or by specifying "ADCS/1.0" in the CTM protocol field. Clients supporting encrypted connections must indicate this in the INF SU field with "ADCS".</p></div>
</div>
</div>
<div class="sect2">
-<h3 id="_application_and_version_separation_in_inf">3.24. Application and version separation in INF</h3>
+<h3 id="_application_and_version_separation_in_inf">4.24. Application and version separation in INF</h3>
<div class="paragraph"><p>This extension adds the parameter <em>AP</em> to the INF to signal application. The current parameter in BASE, VE, will be used for version signalling.</p></div>
<div class="paragraph"><p>Example:</p></div>
<div class="exampleblock">
@@ -2205,7 +2239,7 @@
</div></div>
</div>
<div class="sect2">
-<h3 id="_onid_online_identification">3.25. ONID - Online identification</h3>
+<h3 id="_onid_online_identification">4.25. ONID - Online identification</h3>
<div class="paragraph"><p>The purpose of the OID and OIR commands is to allow users to exchange information about their accounts on various online services. The OID name has been intentionally chosen to be similar to OpenID, although its spread is broader.</p></div>
<div class="paragraph"><p>New commands are preferrable here over new INF fields to avoid clogging up its 2-letter identifiers. They also allow for more flexibility: multiple profiles of the same type (OIR only); multiple identification parameters.</p></div>
<div class="paragraph"><p>The OID command is similar to INF, guaranteeing up-to-date information, whereas OIR follows a request/response scheme. OIR parties are therefore not required to keep their OIR information up-to-date.</p></div>
@@ -2225,7 +2259,7 @@
</ul></div>
<div class="paragraph"><p>OID and OIR commands support all contexts (hub-client, client-client). They are allowed in client-client contexts were users to want to avoid their OID/OIR information travelling through hubs. Both clients and hubs MAY provide each other with OID/OIR information.</p></div>
<div class="sect3">
-<h4 id="_oid">3.25.1. OID</h4>
+<h4 id="_oid">4.25.1. OID</h4>
<div class="literalblock">
<div class="content">
<pre><code>OID service</code></pre>
@@ -2236,7 +2270,7 @@
<div class="paragraph"><p>Clients MAY send OID commands to other clients on hubs that do not advertise ONID support.</p></div>
</div>
<div class="sect3">
-<h4 id="_oir">3.25.2. OIR</h4>
+<h4 id="_oir">4.25.2. OIR</h4>
<div class="literalblock">
<div class="content">
<pre><code>OIR service</code></pre>
@@ -2247,7 +2281,7 @@
<div class="paragraph"><p>Any party MAY at any time send an OIR response without any prior request.</p></div>
</div>
<div class="sect3">
-<h4 id="_examples_2">3.25.3. Examples</h4>
+<h4 id="_examples_2">4.25.3. Examples</h4>
<div class="tableblock">
<table rules="all"
frame="border"
@@ -2291,7 +2325,7 @@
</div>
</div>
<div class="sect2">
-<h3 id="_adcs_transfers_are_required_error_code">3.26. "ADCS transfers are required" error code</h3>
+<h3 id="_adcs_transfers_are_required_error_code">4.26. "ADCS transfers are required" error code</h3>
<div class="paragraph"><p>This extension will add "ADCS transfers are required" as error code in STA. A client that has chosen to only allow encrypted transfers (with ADCS) should send this when a user without ADCS support tries to initiate a connection (via CTM/RCM etc).</p></div>
<div class="tableblock">
<table rules="all"
@@ -2309,7 +2343,7 @@
</div>
</div>
<div class="sect2">
-<h3 id="_asch_extended_searching_capability">3.27. ASCH - Extended searching capability</h3>
+<h3 id="_asch_extended_searching_capability">4.27. ASCH - Extended searching capability</h3>
<div class="paragraph"><p>This extension will increase searching capability in BASE. The extension also imply that searching in partial file lists are now easier.</p></div>
<div class="paragraph"><p>Signal ASCH in the INF’s SU field.</p></div>
<div class="paragraph"><p>The SCH command is extended to request a response (STA) indicating how many search results were sent. This will allow clients to indicate that all search results have been received (and can aptly indicate as such to the user). STA severity 0 and code 00 should be used.</p></div>
@@ -2453,7 +2487,7 @@
</div>
</div>
<div class="sect2">
-<h3 id="_em_date_em_attribute_in_file_list_for_files_and_directories">3.28. <em>Date</em> attribute in file list for files and directories</h3>
+<h3 id="_em_date_em_attribute_in_file_list_for_files_and_directories">4.28. <em>Date</em> attribute in file list for files and directories</h3>
<div class="paragraph"><p>This extension adds a <em>Date</em> attribute to files and directories in a file list. The attribute is the last modified date of the file or directory. Time specified is seconds since the Unix epoch.</p></div>
<div class="paragraph"><p>Implementations should be conservative when it includes the Date attribute. Only including the attribute in partial file lists can decrease overall network load requirements.</p></div>
<div class="paragraph"><p>The following changes are done to the file list XML schema:</p></div>
@@ -2469,7 +2503,7 @@
</div></div>
</div>
<div class="sect2">
-<h3 id="_em_size_em_attribute_in_file_list_for_directories">3.29. <em>Size</em> attribute in file list for directories</h3>
+<h3 id="_em_size_em_attribute_in_file_list_for_directories">4.29. <em>Size</em> attribute in file list for directories</h3>
<div class="paragraph"><p>This extension adds a <em>Size</em> attribute to directories in a file list. The attribute is the size of the directory as indicated in a RES.</p></div>
<div class="paragraph"><p>Implementations should be conservative when it includes the Size attribute.</p></div>
<div class="paragraph"><p>This attribute only makes sense in partial file lists (as it can be calculated in full lists).</p></div>
@@ -2481,7 +2515,7 @@
</div></div>
</div>
<div class="sect2">
-<h3 id="_em_children_em_attribute_in_file_list_for_directories">3.30. <em>Children</em> attribute in file list for directories</h3>
+<h3 id="_em_children_em_attribute_in_file_list_for_directories">4.30. <em>Children</em> attribute in file list for directories</h3>
<div class="paragraph"><p>This extension adds a <em>Children</em> attribute to directories in a file list. The attribute indicates whether there are additional sub-directories.</p></div>
<div class="paragraph"><p>Value <em>1</em> indicate that there are children.</p></div>
<div class="paragraph"><p>This attribute only makes sense in partial file lists.</p></div>
@@ -2498,7 +2532,7 @@
</div></div>
</div>
<div class="sect2">
-<h3 id="_downloaded_progress_report_for_uploaders_in_get">3.31. Downloaded progress report for uploaders in GET</h3>
+<h3 id="_downloaded_progress_report_for_uploaders_in_get">4.31. Downloaded progress report for uploaders in GET</h3>
<div class="paragraph"><p>The info in the current GET command does not permit displaying relative upload progress for the uploading party (for the whole file).</p></div>
<div class="paragraph"><p>To address this, this extension will add an additional field to the GET command for current downloaded (and verified) bytes before the request has been sent. While still not entirely accurate with this information, the uploader can see how much of the file the requesting party actually has instead of either assuming that the requester has the file up to the start position of the request or being forced to only show the progress of the currently requested part of the file. There is potentially a slight delay in the reporting of this info in scenarios where more than one segment of a file is simultaneously requested (by the downloader) and the uploader still lacks information about how many other sources the file is being downloaded from.</p></div>
<div class="tableblock">
@@ -2517,16 +2551,16 @@
</div>
</div>
<div class="sect2">
-<h3 id="_rdex_redirects_extended">3.32. RDEX - Redirects Extended</h3>
+<h3 id="_rdex_redirects_extended">4.32. RDEX - Redirects Extended</h3>
<div class="paragraph"><p>The goal of this extension is to enhance the redirect capabilities provided by BASE by adding support for two new redirect operations and a way for hubs and clients to communicate accepted redirect protocols. It also attempts to make the concept of redirects more unambiguous and less implementation defined. The two new types of redirects added are a multiple choice redirect and so-called permanent redirect as outlined below. These new redirect types are not necessarily mutually exclusive.</p></div>
<div class="sect3">
-<h4 id="_redirect_security">3.32.1. Redirect Security</h4>
+<h4 id="_redirect_security">4.32.1. Redirect Security</h4>
<div class="paragraph"><p>Hubs should always aim to include as much information pertaining to a redirect as possible using other fields defined in BASE. Clients may, for example, rely on the availability of such information to check the origin of a redirect before making irreversible decisions, such as accepting a redirect as permanent as defined below.</p></div>
<div class="paragraph"><p>Clients should not attempt to connect to an unreachable or otherwise invalid destination resources indefinitely or in otherwise abusive manner when responding to redirects. Whether clients respond to redirects using default user information or the same information as used on the hub that initiated the redirect is implementation defined, however, in the case that the same information is used careful consideration should be taken when it comes to automatically sending sensitive information such as passwords to other hubs especially if it provides less security to the user than the original hub.</p></div>
<div class="paragraph"><p>Both clients and hubs should also take note that the TL field, as defined by BASE, should only impact the current hub and its connection (if re-established) thus it should not be relied on to trigger a delayed response to a redirect.</p></div>
</div>
<div class="sect3">
-<h4 id="_accepted_redirect_protocols">3.32.2. Accepted Redirect Protocols</h4>
+<h4 id="_accepted_redirect_protocols">4.32.2. Accepted Redirect Protocols</h4>
<div class="paragraph"><p>Support for this extension is indicated by the presence of an RP field in the INF, which defines the accepted redirect protocols for the hub or a client as a bitmask using any combination of following values. Additional compatible values may be defined by other extensions.</p></div>
<div class="tableblock">
<table rules="all"
@@ -2571,17 +2605,17 @@
<div class="paragraph"><p>Clients should refrain from removing support of a previously signalled redirect protocol from their RP field. It is up to the hub to decide a corresponding course of action should the client do so. Additionally a special case is defined for clients as an RP field with the value of zero to indicate that the client may not react to redirects as defined by BASE or this extension at all or may do so only as a result of user action. As such clients defining a non-zero RP field should follow redirects to accepted protocols automatically and conversely any attempts to redirect clients that define RP as zero should result in normal disconnection as per BASE.</p></div>
</div>
<div class="sect3">
-<h4 id="_multiple_choice_redirect">3.32.3. Multiple Choice Redirect</h4>
+<h4 id="_multiple_choice_redirect">4.32.3. Multiple Choice Redirect</h4>
<div class="paragraph"><p>Multiple choice redirect is defined as a redirect where instead of a single destination resource a set of resource identifiers is provided. The methodology that is used to select the final destination resource for a multiple choice redirect is implementation defined. However, only one final destination resource may be chosen. For example a particular implementation may prefer one protocol over another, encrypted connection over an unencrypted one or even simply choose one at random.</p></div>
<div class="paragraph"><p>This type of redirect is signalled by the presence of an additional RX field in the QUI as defined for redirects by BASE. The value of the RX field is a comma separated list of resource identifiers to use in the redirect. The RD field should be defined for maximum compatibility and clients should add its value to the list of identifiers defined in RX when selecting the final destination resource.</p></div>
</div>
<div class="sect3">
-<h4 id="_permanent_redirect">3.32.4. Permanent Redirect</h4>
+<h4 id="_permanent_redirect">4.32.4. Permanent Redirect</h4>
<div class="paragraph"><p>Permanent redirect is defined as a redirect with reference updating. In the case of a permanent redirect, if and only if a successful connection is made to the destination resource, the connecting party will then update all relevant references of the original resource to the destination resource. Examples of such references may be hublist records for pingers or favorite entries for clients.</p></div>
<div class="paragraph"><p>This type of redirect is signalled by the presence of an additional PT field in the QUI, as defined for redirects by BASE, with the value of one. Upon receiving such redirect clients will proceed to update references as outlined above provided the conditions are met.</p></div>
</div>
<div class="sect3">
-<h4 id="_examples_3">3.32.5. Examples</h4>
+<h4 id="_examples_3">4.32.5. Examples</h4>
<div class="paragraph"><p>Multiple Choice Redirect (BASE compliant)</p></div>
<div class="tableblock">
<table rules="all"
@@ -2672,14 +2706,40 @@
</div>
</div>
</div>
+<div class="sect2">
+<h3 id="_ccpm_client_to_client_private_messages">4.33. CCPM - Client to client private messages</h3>
+<div class="paragraph"><p>This extension adds support for private messages in a client to client context. The extension adds support for the C-type for MSG, and uses the field "PM" in the (C-type) INF to signal that the connection should be used for private messages. Implementations supporting this extension must signal "CCPM" in the SU field of their hub-targeted INF.</p></div>
+<div class="paragraph"><p>Implementations should differentiate between a C-C transfer connection and a C-C private message connection, so as to allow transfers and chat at the same time. The initiating client should issue a secondary CTM/RCM sequence to deal with the other connection. Implementations shall disallow GET (and other file transfer commands) in the private message connection.</p></div>
+<div class="paragraph"><p>Implementations are strongly discouraged but may choose to allow private messages in unencrypted connections.</p></div>
+<div class="paragraph"><p>Implementations may choose for which users that are allowed to send them private messages, so as to avoid spam (e.g., only trusted users, hub operators etc may initiate a C-C private message).</p></div>
+<div class="paragraph"><p>Absence of the "PM" field from the (C-type) INF shall cause a disconnect of the connection (with an appropriate STA).</p></div>
+<div class="paragraph"><p>Implementations may decide what to do when the hub connection is lost during a private message connection.</p></div>
+<div class="paragraph"><p>Implementations should adhere to any requirements the DI field in the QUI command in BASE poses regarding non-file transfer connections. Further actions beyond that are up to implementations.</p></div>
+<div class="paragraph"><p>The same port may, but needn’t be, reused for a file transfer connection and a private message connection. Concurrent connections may be rendered unfeasible with extensions such as NATT.</p></div>
+<div class="paragraph"><p>The "PM" field of the MSG command should not be used in C-C private messages.</p></div>
+<div class="tableblock">
+<table rules="all"
+frame="border"
+cellspacing="0" cellpadding="4">
+<col />
+<col />
+<tbody>
+<tr>
+<td align="left" vali...
[truncated message content] |
|
From: <em...@us...> - 2025-05-07 13:39:44
|
Revision: 131
http://sourceforge.net/p/adc/code/131
Author: emtee
Date: 2025-05-07 13:39:24 +0000 (Wed, 07 May 2025)
Log Message:
-----------
Release of ADC-EXT.txt, now at 1.0.9
Modified Paths:
--------------
trunk/ADC-EXT.txt
Modified: trunk/ADC-EXT.txt
===================================================================
--- trunk/ADC-EXT.txt 2025-05-07 13:30:39 UTC (rev 130)
+++ trunk/ADC-EXT.txt 2025-05-07 13:39:24 UTC (rev 131)
@@ -1,5 +1,6 @@
= ADC Extensions
-1.0.9, UNRELEASED
+DC++ Team <dcp...@li...>
+version 1.0.9, May 2025
== Abstract
These are the official extensions to ADC. This document is based on the
@@ -13,7 +14,8 @@
This version corresponds to $Revision$.
-== Version 1.0.9, UNRELEASED
+== Version 1.0.9, 2025-05-07
+DC++ Team <dcp...@li...>
* Added implementation notes to BLOM
* Added 'CCPM' extension for client to client private messages
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
|
From: <em...@us...> - 2025-05-07 13:31:00
|
Revision: 130
http://sourceforge.net/p/adc/code/130
Author: emtee
Date: 2025-05-07 13:30:39 +0000 (Wed, 07 May 2025)
Log Message:
-----------
Release of ADC.txt, now at 1.0.4
Modified Paths:
--------------
trunk/ADC.txt
Modified: trunk/ADC.txt
===================================================================
--- trunk/ADC.txt 2025-05-07 11:11:26 UTC (rev 129)
+++ trunk/ADC.txt 2025-05-07 13:30:39 UTC (rev 130)
@@ -1,5 +1,6 @@
= ADC Protocol
-version 1.0.4, UNRELEASED
+DC++ Team <dcp...@li...>
+version 1.0.4, May 2025
== Abstract
ADC is a text protocol for a client-server network similar to Neo-Modus'
@@ -24,7 +25,8 @@
$URL$.
This version corresponds to $Revision$.
-=== Version 1.0.4, UNRELEASED
+=== Version 1.0.4, 2025-05-07
+DC++ Team <dcp...@li...>
* Editorial updates
* Separators in the command description for GET, GFI and SND are now explicit.
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
|
From: <em...@us...> - 2025-05-07 11:11:45
|
Revision: 129
http://sourceforge.net/p/adc/code/129
Author: emtee
Date: 2025-05-07 11:11:26 +0000 (Wed, 07 May 2025)
Log Message:
-----------
Add implementation notes to BLOM
Modified Paths:
--------------
trunk/ADC-EXT.txt
Modified: trunk/ADC-EXT.txt
===================================================================
--- trunk/ADC-EXT.txt 2025-05-06 13:44:39 UTC (rev 128)
+++ trunk/ADC-EXT.txt 2025-05-07 11:11:26 UTC (rev 129)
@@ -15,6 +15,7 @@
== Version 1.0.9, UNRELEASED
+* Added implementation notes to BLOM
* Added 'CCPM' extension for client to client private messages
* Editorial updates
* Clarified HH field in PING to be an ADC URL
@@ -374,7 +375,7 @@
|m |Size of the bloom filter in bits
|k |Number of sub-hashes constructed from the file hash
|h |Number of bits to use for each sub-hash
-|p |Propability of a false positive
+|p |Probability of a false positive
|=====
The hub chooses k, h and m.
@@ -431,6 +432,11 @@
For test vectors, see the https://adc.sourceforge.io/wiki/index.php/Talk:BLOM[ADC wiki talk page].
+==== Implementation notes
+Clients do not signal each atomic user update of the share using the SF flag. Instead, they tend to send a cumulative result of multiple updates in a timely fashion. However, an unambiguous summary of the number of hash additions and removals may result in a lack of an update signal. Therefore, hubs are recommended to look for and process INFs containing the SS flag as well, since an incoming SS flag (especially when not accompanied by an SF) may also indicate an update in the hashes, one that occurs without a change in the total number of files shared.
+
+Clients shall strive to signal multiple share updates in an unambiguous manner, thus enabling hubs to request the most accurate and up-to-date version of the client's bloom filter.
+
=== NATT - NAT traversal
NAT traversal allow two passive clients to connect to each other. This specification is based on the TCP hole punching algorithm described in footnoteref:[Peer-to-Peer Communication Across Network Address Translators, B. Ford and P. Srisuresh and and D. Kegel. "Peer-to-Peer Communication Across Network Address Translators". In USENIX Technical Conference 2005 - pages 179–192. Online version: https://bford.info/pub/net/p2pnat/].
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
|
From: <ul...@us...> - 2015-02-21 16:56:31
|
Revision: 126
http://sourceforge.net/p/adc/code/126
Author: ullner
Date: 2015-02-21 16:56:23 +0000 (Sat, 21 Feb 2015)
Log Message:
-----------
Clarified UTF-8 encoding note.
Modified Paths:
--------------
trunk/ADC-Recommendation.html
trunk/ADC-Recommendation.txt
trunk/ADC.txt
Modified: trunk/ADC-Recommendation.html
===================================================================
--- trunk/ADC-Recommendation.html 2015-02-19 20:21:48 UTC (rev 125)
+++ trunk/ADC-Recommendation.html 2015-02-21 16:56:23 UTC (rev 126)
@@ -1339,50 +1339,232 @@
</ol></div>
</div>
</div>
+<div class="sect2">
+<h3 id="_chat">7.2. Chat</h3>
+<div class="paragraph"><p>.</p></div>
</div>
+<div class="sect2">
+<h3 id="_downloading">7.3. Downloading</h3>
+<div class="paragraph"><p>.</p></div>
</div>
+<div class="sect2">
+<h3 id="_sharing">7.4. Sharing</h3>
+<div class="paragraph"><p>.</p></div>
+</div>
+<div class="sect2">
+<h3 id="_search">7.5. Search</h3>
+<div class="paragraph"><p>.</p></div>
+</div>
+<div class="sect2">
+<h3 id="_other">7.6. Other</h3>
+<div class="paragraph"><p>.</p></div>
+</div>
+</div>
+</div>
<div class="sect1">
<h2 id="_hub_implementation">8. Hub implementation</h2>
<div class="sectionbody">
-<div class="paragraph"><p>1) Hub accepts network connection.
-- [client state = new]</p></div>
-<div class="paragraph"><p>2) Hub waits for handshake from client.
-Client: HSUP ADBASE …</p></div>
-<div class="paragraph"><p>3) Hub checks support line responds
-Server: ISUP ADBASE …</p></div>
-<div class="paragraph"><p>4) Hub allocates a SID, and sends it to the client.
-Server: ISID …</p></div>
-<div class="paragraph"><p>5) Hub sends the hub information to the client.
-Server: IINF …</p></div>
-<div class="paragraph"><p>6) Hub waits for client to send info:
-- [client state = identify]
-Client: BINF …</p></div>
-<div class="paragraph"><p>7) Hub validates info from client
- If password verification is needed, then go to 7.1, otherwise 8.</p></div>
-<div class="paragraph"><p>7.1) If user needs to log in, request password
-- [client state = verify]
-Server: IGPA …</p></div>
-<div class="paragraph"><p>7.2) Wait for and verify password from
-Client: HPAS …</p></div>
-<div class="paragraph"><p>8) Hub transmits the userlist of all existing users to the client.
-Server: BINF …
-Server: BINF …
-…
-Server: BINF …</p></div>
-<div class="paragraph"><p>9) Hub broadcasts the client’s info (BINF) to all users, including the client.
-- [client state = NORMAL]
-Server: BINF …</p></div>
-<div class="paragraph"><p>10) At this point the client is considered logged in, and will receive all
+<div class="paragraph"><p>A client can be implemented by following this rough outline. The outline may not specify everything to full detail and will not cover the actual application that shall employ the mechanisms.</p></div>
+<div class="sect2">
+<h3 id="_steps_2">8.1. Steps</h3>
+<div class="olist arabic"><ol class="arabic">
+<li>
+<p>
+Hub accepts network connection.
+</p>
+<div class="ulist"><ul>
+<li>
+<p>
+Set client state to NEW.
+</p>
+</li>
+</ul></div>
+</li>
+<li>
+<p>
+Hub waits for handshake from client.
+</p>
+<div class="ulist"><ul>
+<li>
+<p>
+Client will send:
+</p>
+<div class="ulist"><ul>
+<li>
+<p>
+HSUP ADBASE …
+</p>
+</li>
+</ul></div>
+</li>
+</ul></div>
+</li>
+<li>
+<p>
+Hub checks support line responds.
+</p>
+</li>
+<li>
+<p>
+Server sends:
+</p>
+<div class="ulist"><ul>
+<li>
+<p>
+ISUP ADBASE …
+</p>
+</li>
+</ul></div>
+</li>
+<li>
+<p>
+Hub allocates a SID, and sends it to the client:
+</p>
+<div class="ulist"><ul>
+<li>
+<p>
+ISID …
+</p>
+</li>
+</ul></div>
+</li>
+<li>
+<p>
+Hub sends the hub information to the client:
+</p>
+<div class="ulist"><ul>
+<li>
+<p>
+IINF …
+</p>
+</li>
+</ul></div>
+</li>
+<li>
+<p>
+Hub waits for client to send info:
+</p>
+<div class="ulist"><ul>
+<li>
+<p>
+Client will send:
+</p>
+<div class="ulist"><ul>
+<li>
+<p>
+BINF …
+</p>
+</li>
+</ul></div>
+</li>
+<li>
+<p>
+Set client state to IDENTIFY.
+</p>
+</li>
+</ul></div>
+</li>
+<li>
+<p>
+Hub validates info from client
+</p>
+<div class="ulist"><ul>
+<li>
+<p>
+If password verification is needed, then go to 9, otherwise 11.
+</p>
+</li>
+</ul></div>
+</li>
+<li>
+<p>
+If user needs to log in, request password
+</p>
+<div class="ulist"><ul>
+<li>
+<p>
+Set client state to VERIFY
+</p>
+</li>
+<li>
+<p>
+Hub sends:
+</p>
+<div class="ulist"><ul>
+<li>
+<p>
+IGPA …
+</p>
+</li>
+</ul></div>
+</li>
+</ul></div>
+</li>
+<li>
+<p>
+Wait for and verify password from client:
+</p>
+<div class="ulist"><ul>
+<li>
+<p>
+HPAS …
+</p>
+</li>
+</ul></div>
+</li>
+<li>
+<p>
+Hub transmits the userlist of all existing users to the client.
+</p>
+<div class="literalblock">
+<div class="content">
+<pre><code>BINF ...
+BINF ...
+...
+BINF ...</code></pre>
+</div></div>
+</li>
+<li>
+<p>
+Hub broadcasts the client’s info (BINF) to all users, including the client.
+</p>
+<div class="ulist"><ul>
+<li>
+<p>
+Set client state to NORMAL.
+</p>
+</li>
+<li>
+<p>
+Server sends:
+</p>
+<div class="ulist"><ul>
+<li>
+<p>
+BINF …
+</p>
+</li>
+</ul></div>
+</li>
+</ul></div>
+</li>
+<li>
+<p>
+At this point the client is considered logged in, and will receive all
broadcast messages and all direct messages from other clients.
It will also forward messages originating from this client to others, if the
-messages are correct (syntax, formatting, source SID, etc).</p></div>
+messages are correct (syntax, formatting, source SID, etc).
+</p>
+</li>
+</ol></div>
</div>
</div>
</div>
+</div>
<div id="footnotes"><hr /></div>
<div id="footer">
<div id="footer-text">
-Last updated 2014-08-05 14:38:44 W. Europe Daylight Time
+Last updated 2014-08-05 15:14:11 W. Europe Daylight Time
</div>
</div>
</body>
Modified: trunk/ADC-Recommendation.txt
===================================================================
--- trunk/ADC-Recommendation.txt 2015-02-19 20:21:48 UTC (rev 125)
+++ trunk/ADC-Recommendation.txt 2015-02-21 16:56:23 UTC (rev 126)
@@ -179,73 +179,106 @@
==== Steps
1. Create a network connection to a hub on the appropriate port.
+
2. The client shall send the following message:
* HSUP ADBASE ADTIGR
** This indicates that the client is notifying the hub about supporting the base protocol (BASE) and the extension hash method Tiger (TIGR). If the protocol base version is changed, send that instead of BASE. Similarly, if another hash method is preferred, send that instead.
+
3. The hub will send:
* ISUP ADBASE ADTIGR
** The hub may include other things it "AD"s, but none of these are interesting.
+
4. The hub will send:
* ISID ABCD
** ABCD is the SID that shall be used in any further communication from the client (where applicable). Store this value.
+
5. Optionally, a hub may send the following but is not required:
* IINF CT32 NIhub_name
** None of these parameters are needed for continuing the connectivity, although may come in handy in the future. The value in the NI parameter can be used for e.g. the application or tab name.
+
6. The client shall send the following message
* BINF ABCD ID<CID> PD<PID> NImy_name
** ABCD here is the SID as previously mentioned. The CID and PID are complementary information and are specified in the "Client identification section". The client should generate an internal CID (and associated PID). The CID and PID that the client sends to the hub have been run through a Base32 conversion.
+
7. If the hub did not send its "IINF" before, it may do so now. Again, the information shouldn't be deemed as required.
+
8. The hub may send a password request, see section "Other".
+
9. The hub will send all other users that are logged in:
* BINF sid ID<CID> NI<nick>
** Where SID and CID is the client information. The SID is used to create a mapping between client -> user. Note that the PID is never broadcast.
+
10. The last BINF to arrive will be the information you connected with:
* BINF ABCD ID<your-CID> NImy_name
+
11. The client will now be fully logged in.
+=== Chat
+.
+
+=== Downloading
+.
+
+=== Sharing
+.
+
+=== Search
+.
+
+=== Other
+.
+
== Hub implementation
+A client can be implemented by following this rough outline. The outline may not specify everything to full detail and will not cover the actual application that shall employ the mechanisms.
-1) Hub accepts network connection.
-- [client state = new]
+=== Steps
+1. Hub accepts network connection.
+* Set client state to NEW.
-2) Hub waits for handshake from client.
-Client: HSUP ADBASE ...
+2. Hub waits for handshake from client.
+* Client will send:
+** HSUP ADBASE ...
-3) Hub checks support line responds
-Server: ISUP ADBASE ...
+3. Hub checks support line responds.
-4) Hub allocates a SID, and sends it to the client.
-Server: ISID ...
+4. Server sends:
+* ISUP ADBASE ...
-5) Hub sends the hub information to the client.
-Server: IINF ...
+5. Hub allocates a SID, and sends it to the client:
+* ISID ...
-6) Hub waits for client to send info:
-- [client state = identify]
-Client: BINF ...
+6. Hub sends the hub information to the client:
+* IINF ...
-7) Hub validates info from client
- If password verification is needed, then go to 7.1, otherwise 8.
+7. Hub waits for client to send info:
+* Client will send:
+** BINF ...
+* Set client state to IDENTIFY.
-7.1) If user needs to log in, request password
-- [client state = verify]
-Server: IGPA ...
+8. Hub validates info from client
+* If password verification is needed, then go to 9, otherwise 11.
-7.2) Wait for and verify password from
-Client: HPAS ...
+9. If user needs to log in, request password
+* Set client state to VERIFY
+* Hub sends:
+** IGPA ...
-8) Hub transmits the userlist of all existing users to the client.
-Server: BINF ...
-Server: BINF ...
-...
-Server: BINF ...
+10. Wait for and verify password from client:
+* HPAS ...
+11. Hub transmits the userlist of all existing users to the client.
-9) Hub broadcasts the client's info (BINF) to all users, including the client.
-- [client state = NORMAL]
-Server: BINF ...
+ BINF ...
+ BINF ...
+ ...
+ BINF ...
-10) At this point the client is considered logged in, and will receive all
+12. Hub broadcasts the client's info (BINF) to all users, including the client.
+* Set client state to NORMAL.
+* Server sends:
+** BINF ...
+
+13. At this point the client is considered logged in, and will receive all
broadcast messages and all direct messages from other clients.
It will also forward messages originating from this client to others, if the
messages are correct (syntax, formatting, source SID, etc).
Modified: trunk/ADC.txt
===================================================================
--- trunk/ADC.txt 2015-02-19 20:21:48 UTC (rev 125)
+++ trunk/ADC.txt 2015-02-21 16:56:23 UTC (rev 126)
@@ -27,6 +27,7 @@
=== Version 1.0.4, UNRELEASED
* Separators in the command description for GET, GFI and SND are now explicit.
+* Clarified UTF-8 encoding note.
=== Version 1.0.3, 2013-06-30
Fredrik Ullner <ul...@gm...>
@@ -64,7 +65,8 @@
message. The string "\s" escapes space, "\n" newline and "\\" backslash.
This version of the protocol reserves all other escapes for future use; any
message containing unknown escapes must be discarded.
-* All text must be sent as UTF-8 encoded Unicode in normalization form C.
+* All text must be sent as 1-to-4 byte, RFC 3629-compliant UTF-8 encoded Unicode
+ in normalization form C.
* Clients must ignore unknown/badly formatted messages. Hubs must ignore
invalid messages and should dispatch unknown messages according to their
type.
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
|
From: <ul...@us...> - 2015-02-19 20:21:50
|
Revision: 125
http://sourceforge.net/p/adc/code/125
Author: ullner
Date: 2015-02-19 20:21:48 +0000 (Thu, 19 Feb 2015)
Log Message:
-----------
Clarified HH field in PING
Modified Paths:
--------------
trunk/ADC-EXT.txt
Modified: trunk/ADC-EXT.txt
===================================================================
--- trunk/ADC-EXT.txt 2014-08-05 12:42:42 UTC (rev 124)
+++ trunk/ADC-EXT.txt 2015-02-19 20:21:48 UTC (rev 125)
@@ -1,6 +1,5 @@
= ADC Extensions
-Fredrik Ullner, ul...@gm...
-1.0.8, February 2014
+1.0.9, UNRELEASED
== Abstract
These are the official extensions to ADC. This document is based on the
@@ -14,6 +13,10 @@
This version corresponds to $Revision$.
+== Version 1.0.9, UNRELEASED
+
+* Clarified HH field in PING to be an ADC URL
+
=== Version 1.0.8
Fredrik Ullner <ul...@gm...>, 2014-02-11
@@ -204,7 +207,7 @@
[options="header, autowidth"]
|=====
|Code | Type | Description
-|HH |string |Hub Host address ( DNS or IP )
+|HH |url |Hub Host address (ADC/ADCS URL address form)
|WS |url |Hub Website
|NE |string |Hub Network
|OW |string |Hub Owner name
@@ -237,7 +240,7 @@
-pinger- HSUP ADBASE ADPING AD..
-hub- ISUP ADBASE ADPING AD..
-hub- ISID ..
- -hub- IINF NIhubname DEcurrent\stopic VE.. HHexample.org:555 WShttp://example.org/ OWmyname UC2231 SS.. SF.. MS0 ML0 MC5000
+ -hub- IINF NIhubname DEcurrent\stopic VE.. HHadc://example.org:555 WShttp://example.org/ OWmyname UC2231 SS.. SF.. MS0 ML0 MC5000
- (pinger may disconnect)
====
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
|
From: <ul...@us...> - 2014-08-05 12:42:47
|
Revision: 124
http://sourceforge.net/p/adc/code/124
Author: ullner
Date: 2014-08-05 12:42:42 +0000 (Tue, 05 Aug 2014)
Log Message:
-----------
Updated recommendations to include a partial client/hub implementation
Modified Paths:
--------------
trunk/ADC-Recommendation.html
trunk/ADC-Recommendation.txt
Modified: trunk/ADC-Recommendation.html
===================================================================
--- trunk/ADC-Recommendation.html 2014-07-03 19:29:18 UTC (rev 123)
+++ trunk/ADC-Recommendation.html 2014-08-05 12:42:42 UTC (rev 124)
@@ -734,10 +734,7 @@
<body class="article">
<div id="header">
<h1>ADC Recommendations</h1>
-<span id="author">Fredrik Ullner</span><br />
-<span id="email"><code><<a href="mailto:ul...@gm...">ul...@gm...</a>></code></span><br />
-<span id="revnumber">version 1.1.0,</span>
-<span id="revdate">December 2013</span>
+<span id="author">version 1.2.0, UNRELEASED</span><br />
<div id="toc">
<div id="toctitle">Table of Contents</div>
<noscript><p><b>JavaScript must be enabled in your browser to display the table of contents.</b></p></noscript>
@@ -758,7 +755,17 @@
$URL: <a href="https://svn.code.sf.net/p/adc/code/trunk/ADC-Recommendation.txt">https://svn.code.sf.net/p/adc/code/trunk/ADC-Recommendation.txt</a> $.</p></div>
<div class="paragraph"><p>This version corresponds to $Revision: 1 $.</p></div>
<div class="sect2">
-<h3 id="_version_1_1_0_2013_12_21">2.1. Version 1.1.0, 2013-12-21</h3>
+<h3 id="_version_1_2_0_unreleased">2.1. Version 1.2.0, UNRELEASED</h3>
+<div class="ulist"><ul>
+<li>
+<p>
+Added client and hub implementation outlines
+</p>
+</li>
+</ul></div>
+</div>
+<div class="sect2">
+<h3 id="_version_1_1_0_2013_12_21">2.2. Version 1.1.0, 2013-12-21</h3>
<div class="paragraph"><p>Fredrik Ullner, <<a href="mailto:ul...@gm...">ul...@gm...</a>></p></div>
<div class="ulist"><ul>
<li>
@@ -774,7 +781,7 @@
</ul></div>
</div>
<div class="sect2">
-<h3 id="_version_1_0_0_2010_07_01">2.2. Version 1.0.0, 2010-07-01</h3>
+<h3 id="_version_1_0_0_2010_07_01">2.3. Version 1.0.0, 2010-07-01</h3>
<div class="paragraph"><p>Fredrik Ullner, <<a href="mailto:ul...@gm...">ul...@gm...</a>></p></div>
<div class="ulist"><ul>
<li>
@@ -1169,12 +1176,213 @@
</div>
</div>
</div>
+<div class="sect1">
+<h2 id="_client_implementation">7. Client implementation</h2>
+<div class="sectionbody">
+<div class="paragraph"><p>A client can be implemented by following this rough outline. The outline may not specify everything to full detail and will not cover the actual application that shall employ the mechanisms.</p></div>
+<div class="paragraph"><p>There are six sections that need to be implemented to support the major parts of the protocol. They are, in order: connectivity, chatting, downloading, sharing/uploading, search/response. The left out section ("other") is strict protocol compatibility, for additional items that are not necessary to support at first: these things should be implemented alongside basic support for each section.</p></div>
+<div class="paragraph"><p>This outline assumes that there is a hub available and (for the relevant sections) that another client is present.</p></div>
+<div class="paragraph"><p>No part of this outline requires a particular programming language.</p></div>
+<div class="paragraph"><p>Note that all messages end with a newline, which are excluded from this description.</p></div>
+<div class="sect2">
+<h3 id="_connectivity">7.1. Connectivity</h3>
+<div class="paragraph"><p>This section describes the necessary parts to implement basic connectivity to a hub. The client will, after this stage, be able to continue on with chatting or file sharing. Without basic connectivity, obviously nothing can done in the client.</p></div>
+<div class="sect3">
+<h4 id="_steps">7.1.1. Steps</h4>
+<div class="olist arabic"><ol class="arabic">
+<li>
+<p>
+Create a network connection to a hub on the appropriate port.
+</p>
+</li>
+<li>
+<p>
+The client shall send the following message:
+</p>
+<div class="ulist"><ul>
+<li>
+<p>
+HSUP ADBASE ADTIGR
+</p>
+<div class="ulist"><ul>
+<li>
+<p>
+This indicates that the client is notifying the hub about supporting the base protocol (BASE) and the extension hash method Tiger (TIGR). If the protocol base version is changed, send that instead of BASE. Similarly, if another hash method is preferred, send that instead.
+</p>
+</li>
+</ul></div>
+</li>
+</ul></div>
+</li>
+<li>
+<p>
+The hub will send:
+</p>
+<div class="ulist"><ul>
+<li>
+<p>
+ISUP ADBASE ADTIGR
+</p>
+<div class="ulist"><ul>
+<li>
+<p>
+The hub may include other things it "AD"s, but none of these are interesting.
+</p>
+</li>
+</ul></div>
+</li>
+</ul></div>
+</li>
+<li>
+<p>
+The hub will send:
+</p>
+<div class="ulist"><ul>
+<li>
+<p>
+ISID ABCD
+</p>
+<div class="ulist"><ul>
+<li>
+<p>
+ABCD is the SID that shall be used in any further communication from the client (where applicable). Store this value.
+</p>
+</li>
+</ul></div>
+</li>
+</ul></div>
+</li>
+<li>
+<p>
+Optionally, a hub may send the following but is not required:
+</p>
+<div class="ulist"><ul>
+<li>
+<p>
+IINF CT32 NIhub_name
+</p>
+<div class="ulist"><ul>
+<li>
+<p>
+None of these parameters are needed for continuing the connectivity, although may come in handy in the future. The value in the NI parameter can be used for e.g. the application or tab name.
+</p>
+</li>
+</ul></div>
+</li>
+</ul></div>
+</li>
+<li>
+<p>
+The client shall send the following message
+</p>
+<div class="ulist"><ul>
+<li>
+<p>
+BINF ABCD ID<CID> PD<PID> NImy_name
+</p>
+<div class="ulist"><ul>
+<li>
+<p>
+ABCD here is the SID as previously mentioned. The CID and PID are complementary information and are specified in the "Client identification section". The client should generate an internal CID (and associated PID). The CID and PID that the client sends to the hub have been run through a Base32 conversion.
+</p>
+</li>
+</ul></div>
+</li>
+</ul></div>
+</li>
+<li>
+<p>
+If the hub did not send its "IINF" before, it may do so now. Again, the information shouldn’t be deemed as required.
+</p>
+</li>
+<li>
+<p>
+The hub may send a password request, see section "Other".
+</p>
+</li>
+<li>
+<p>
+The hub will send all other users that are logged in:
+</p>
+<div class="ulist"><ul>
+<li>
+<p>
+BINF sid ID<CID> NI<nick>
+</p>
+<div class="ulist"><ul>
+<li>
+<p>
+Where SID and CID is the client information. The SID is used to create a mapping between client → user. Note that the PID is never broadcast.
+</p>
+</li>
+</ul></div>
+</li>
+</ul></div>
+</li>
+<li>
+<p>
+The last BINF to arrive will be the information you connected with:
+</p>
+<div class="ulist"><ul>
+<li>
+<p>
+BINF ABCD ID<your-CID> NImy_name
+</p>
+</li>
+</ul></div>
+</li>
+<li>
+<p>
+The client will now be fully logged in.
+</p>
+</li>
+</ol></div>
</div>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_hub_implementation">8. Hub implementation</h2>
+<div class="sectionbody">
+<div class="paragraph"><p>1) Hub accepts network connection.
+- [client state = new]</p></div>
+<div class="paragraph"><p>2) Hub waits for handshake from client.
+Client: HSUP ADBASE …</p></div>
+<div class="paragraph"><p>3) Hub checks support line responds
+Server: ISUP ADBASE …</p></div>
+<div class="paragraph"><p>4) Hub allocates a SID, and sends it to the client.
+Server: ISID …</p></div>
+<div class="paragraph"><p>5) Hub sends the hub information to the client.
+Server: IINF …</p></div>
+<div class="paragraph"><p>6) Hub waits for client to send info:
+- [client state = identify]
+Client: BINF …</p></div>
+<div class="paragraph"><p>7) Hub validates info from client
+ If password verification is needed, then go to 7.1, otherwise 8.</p></div>
+<div class="paragraph"><p>7.1) If user needs to log in, request password
+- [client state = verify]
+Server: IGPA …</p></div>
+<div class="paragraph"><p>7.2) Wait for and verify password from
+Client: HPAS …</p></div>
+<div class="paragraph"><p>8) Hub transmits the userlist of all existing users to the client.
+Server: BINF …
+Server: BINF …
+…
+Server: BINF …</p></div>
+<div class="paragraph"><p>9) Hub broadcasts the client’s info (BINF) to all users, including the client.
+- [client state = NORMAL]
+Server: BINF …</p></div>
+<div class="paragraph"><p>10) At this point the client is considered logged in, and will receive all
+broadcast messages and all direct messages from other clients.
+It will also forward messages originating from this client to others, if the
+messages are correct (syntax, formatting, source SID, etc).</p></div>
+</div>
+</div>
+</div>
<div id="footnotes"><hr /></div>
<div id="footer">
<div id="footer-text">
-Version 1.1.0<br />
-Last updated 2014-01-19 17:26:27 W. Europe Standard Time
+Last updated 2014-08-05 14:38:44 W. Europe Daylight Time
</div>
</div>
</body>
Modified: trunk/ADC-Recommendation.txt
===================================================================
--- trunk/ADC-Recommendation.txt 2014-07-03 19:29:18 UTC (rev 123)
+++ trunk/ADC-Recommendation.txt 2014-08-05 12:42:42 UTC (rev 124)
@@ -1,6 +1,5 @@
= ADC Recommendations
-Fredrik Ullner <ul...@gm...>
-1.1.0, December 2013
+version 1.2.0, UNRELEASED
== Abstract
These are the official recommendations to ADC. This document is based on the information contained in the ADC documents, ADC wiki and ADC blog. Information is this document should be taken as guide lines to implementations.
@@ -12,6 +11,10 @@
This version corresponds to $Revision: 1 $.
+=== Version 1.2.0, UNRELEASED
+
+* Added client and hub implementation outlines
+
=== Version 1.1.0, 2013-12-21
Fredrik Ullner, <ul...@gm...>
@@ -160,4 +163,92 @@
* Information leak: you can find out the max user peak of the hub in a session.
* The SID array grows when more clients logout then login; in worst case, the hub is empty and the array contains all created SIDs of the session.
+== Client implementation
+A client can be implemented by following this rough outline. The outline may not specify everything to full detail and will not cover the actual application that shall employ the mechanisms.
+
+There are six sections that need to be implemented to support the major parts of the protocol. They are, in order: connectivity, chatting, downloading, sharing/uploading, search/response. The left out section ("other") is strict protocol compatibility, for additional items that are not necessary to support at first: these things should be implemented alongside basic support for each section.
+
+This outline assumes that there is a hub available and (for the relevant sections) that another client is present.
+
+No part of this outline requires a particular programming language.
+
+Note that all messages end with a newline, which are excluded from this description.
+
+=== Connectivity
+This section describes the necessary parts to implement basic connectivity to a hub. The client will, after this stage, be able to continue on with chatting or file sharing. Without basic connectivity, obviously nothing can done in the client.
+
+==== Steps
+1. Create a network connection to a hub on the appropriate port.
+2. The client shall send the following message:
+* HSUP ADBASE ADTIGR
+** This indicates that the client is notifying the hub about supporting the base protocol (BASE) and the extension hash method Tiger (TIGR). If the protocol base version is changed, send that instead of BASE. Similarly, if another hash method is preferred, send that instead.
+3. The hub will send:
+* ISUP ADBASE ADTIGR
+** The hub may include other things it "AD"s, but none of these are interesting.
+4. The hub will send:
+* ISID ABCD
+** ABCD is the SID that shall be used in any further communication from the client (where applicable). Store this value.
+5. Optionally, a hub may send the following but is not required:
+* IINF CT32 NIhub_name
+** None of these parameters are needed for continuing the connectivity, although may come in handy in the future. The value in the NI parameter can be used for e.g. the application or tab name.
+6. The client shall send the following message
+* BINF ABCD ID<CID> PD<PID> NImy_name
+** ABCD here is the SID as previously mentioned. The CID and PID are complementary information and are specified in the "Client identification section". The client should generate an internal CID (and associated PID). The CID and PID that the client sends to the hub have been run through a Base32 conversion.
+7. If the hub did not send its "IINF" before, it may do so now. Again, the information shouldn't be deemed as required.
+8. The hub may send a password request, see section "Other".
+9. The hub will send all other users that are logged in:
+* BINF sid ID<CID> NI<nick>
+** Where SID and CID is the client information. The SID is used to create a mapping between client -> user. Note that the PID is never broadcast.
+10. The last BINF to arrive will be the information you connected with:
+* BINF ABCD ID<your-CID> NImy_name
+11. The client will now be fully logged in.
+
+== Hub implementation
+
+1) Hub accepts network connection.
+- [client state = new]
+
+2) Hub waits for handshake from client.
+Client: HSUP ADBASE ...
+
+3) Hub checks support line responds
+Server: ISUP ADBASE ...
+
+4) Hub allocates a SID, and sends it to the client.
+Server: ISID ...
+
+5) Hub sends the hub information to the client.
+Server: IINF ...
+
+6) Hub waits for client to send info:
+- [client state = identify]
+Client: BINF ...
+
+7) Hub validates info from client
+ If password verification is needed, then go to 7.1, otherwise 8.
+
+7.1) If user needs to log in, request password
+- [client state = verify]
+Server: IGPA ...
+
+7.2) Wait for and verify password from
+Client: HPAS ...
+
+8) Hub transmits the userlist of all existing users to the client.
+Server: BINF ...
+Server: BINF ...
+...
+Server: BINF ...
+
+
+9) Hub broadcasts the client's info (BINF) to all users, including the client.
+- [client state = NORMAL]
+Server: BINF ...
+
+10) At this point the client is considered logged in, and will receive all
+broadcast messages and all direct messages from other clients.
+It will also forward messages originating from this client to others, if the
+messages are correct (syntax, formatting, source SID, etc).
+
+
// vim: set syntax=asciidoc:
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
|
From: <ul...@us...> - 2014-07-03 19:29:30
|
Revision: 123
http://sourceforge.net/p/adc/code/123
Author: ullner
Date: 2014-07-03 19:29:18 +0000 (Thu, 03 Jul 2014)
Log Message:
-----------
Update ONID services for LoL regions
Modified Paths:
--------------
trunk/ADC-ONIDServices.txt
Modified: trunk/ADC-ONIDServices.txt
===================================================================
--- trunk/ADC-ONIDServices.txt 2014-02-11 22:21:52 UTC (rev 122)
+++ trunk/ADC-ONIDServices.txt 2014-07-03 19:29:18 UTC (rev 123)
@@ -19,6 +19,7 @@
=== Version 1.0.1, UNRELEASED
* Added TrackMania
+* Updated LoL regions
== Services
The service names are all case-insensitive. They are written here as lower-case.
@@ -74,7 +75,10 @@
|eune |EU Nordic and East
|euw |EU West
|kr |Korea
+|lan |Latin America North
+|las |Latin America South
|na |North America
+|oce |Oceania
|tr |Turkey
|ru |Russia
|=====
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
|
From: <ul...@us...> - 2014-02-11 22:21:55
|
Revision: 122
http://sourceforge.net/p/adc/code/122
Author: ullner
Date: 2014-02-11 22:21:52 +0000 (Tue, 11 Feb 2014)
Log Message:
-----------
Generated HTML documents for respective TXT document
Added Paths:
-----------
trunk/ADC-EXT.html
trunk/ADC-PRD.html
trunk/ADC-Recommendation.html
trunk/ADC-Test.html
trunk/ADC.html
Added: trunk/ADC-EXT.html
===================================================================
--- trunk/ADC-EXT.html (rev 0)
+++ trunk/ADC-EXT.html 2014-02-11 22:21:52 UTC (rev 122)
@@ -0,0 +1,2686 @@
+<!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="en">
+<head>
+<meta http-equiv="Content-Type" content="application/xhtml+xml; charset=UTF-8" />
+<meta name="generator" content="AsciiDoc 8.6.9" />
+<title>ADC Extensions</title>
+<style type="text/css">
+/* Shared CSS for AsciiDoc xhtml11 and html5 backends */
+
+/* Default font. */
+body {
+ font-family: Georgia,serif;
+}
+
+/* Title font. */
+h1, h2, h3, h4, h5, h6,
+div.title, caption.title,
+thead, p.table.header,
+#toctitle,
+#author, #revnumber, #revdate, #revremark,
+#footer {
+ font-family: Arial,Helvetica,sans-serif;
+}
+
+body {
+ margin: 1em 5% 1em 5%;
+}
+
+a {
+ color: blue;
+ text-decoration: underline;
+}
+a:visited {
+ color: fuchsia;
+}
+
+em {
+ font-style: italic;
+ color: navy;
+}
+
+strong {
+ font-weight: bold;
+ color: #083194;
+}
+
+h1, h2, h3, h4, h5, h6 {
+ color: #527bbd;
+ margin-top: 1.2em;
+ margin-bottom: 0.5em;
+ line-height: 1.3;
+}
+
+h1, h2, h3 {
+ border-bottom: 2px solid silver;
+}
+h2 {
+ padding-top: 0.5em;
+}
+h3 {
+ float: left;
+}
+h3 + * {
+ clear: left;
+}
+h5 {
+ font-size: 1.0em;
+}
+
+div.sectionbody {
+ margin-left: 0;
+}
+
+hr {
+ border: 1px solid silver;
+}
+
+p {
+ margin-top: 0.5em;
+ margin-bottom: 0.5em;
+}
+
+ul, ol, li > p {
+ margin-top: 0;
+}
+ul > li { color: #aaa; }
+ul > li > * { color: black; }
+
+.monospaced, code, pre {
+ font-family: "Courier New", Courier, monospace;
+ font-size: inherit;
+ color: navy;
+ padding: 0;
+ margin: 0;
+}
+pre {
+ white-space: pre-wrap;
+}
+
+#author {
+ color: #527bbd;
+ font-weight: bold;
+ font-size: 1.1em;
+}
+#email {
+}
+#revnumber, #revdate, #revremark {
+}
+
+#footer {
+ font-size: small;
+ border-top: 2px solid silver;
+ padding-top: 0.5em;
+ margin-top: 4.0em;
+}
+#footer-text {
+ float: left;
+ padding-bottom: 0.5em;
+}
+#footer-badges {
+ float: right;
+ padding-bottom: 0.5em;
+}
+
+#preamble {
+ margin-top: 1.5em;
+ margin-bottom: 1.5em;
+}
+div.imageblock, div.exampleblock, div.verseblock,
+div.quoteblock, div.literalblock, div.listingblock, div.sidebarblock,
+div.admonitionblock {
+ margin-top: 1.0em;
+ margin-bottom: 1.5em;
+}
+div.admonitionblock {
+ margin-top: 2.0em;
+ margin-bottom: 2.0em;
+ margin-right: 10%;
+ color: #606060;
+}
+
+div.content { /* Block element content. */
+ padding: 0;
+}
+
+/* Block element titles. */
+div.title, caption.title {
+ color: #527bbd;
+ font-weight: bold;
+ text-align: left;
+ margin-top: 1.0em;
+ margin-bottom: 0.5em;
+}
+div.title + * {
+ margin-top: 0;
+}
+
+td div.title:first-child {
+ margin-top: 0.0em;
+}
+div.content div.title:first-child {
+ margin-top: 0.0em;
+}
+div.content + div.title {
+ margin-top: 0.0em;
+}
+
+div.sidebarblock > div.content {
+ background: #ffffee;
+ border: 1px solid #dddddd;
+ border-left: 4px solid #f0f0f0;
+ padding: 0.5em;
+}
+
+div.listingblock > div.content {
+ border: 1px solid #dddddd;
+ border-left: 5px solid #f0f0f0;
+ background: #f8f8f8;
+ padding: 0.5em;
+}
+
+div.quoteblock, div.verseblock {
+ padding-left: 1.0em;
+ margin-left: 1.0em;
+ margin-right: 10%;
+ border-left: 5px solid #f0f0f0;
+ color: #888;
+}
+
+div.quoteblock > div.attribution {
+ padding-top: 0.5em;
+ text-align: right;
+}
+
+div.verseblock > pre.content {
+ font-family: inherit;
+ font-size: inherit;
+}
+div.verseblock > div.attribution {
+ padding-top: 0.75em;
+ text-align: left;
+}
+/* DEPRECATED: Pre version 8.2.7 verse style literal block. */
+div.verseblock + div.attribution {
+ text-align: left;
+}
+
+div.admonitionblock .icon {
+ vertical-align: top;
+ font-size: 1.1em;
+ font-weight: bold;
+ text-decoration: underline;
+ color: #527bbd;
+ padding-right: 0.5em;
+}
+div.admonitionblock td.content {
+ padding-left: 0.5em;
+ border-left: 3px solid #dddddd;
+}
+
+div.exampleblock > div.content {
+ border-left: 3px solid #dddddd;
+ padding-left: 0.5em;
+}
+
+div.imageblock div.content { padding-left: 0; }
+span.image img { border-style: none; vertical-align: text-bottom; }
+a.image:visited { color: white; }
+
+dl {
+ margin-top: 0.8em;
+ margin-bottom: 0.8em;
+}
+dt {
+ margin-top: 0.5em;
+ margin-bottom: 0;
+ font-style: normal;
+ color: navy;
+}
+dd > *:first-child {
+ margin-top: 0.1em;
+}
+
+ul, ol {
+ list-style-position: outside;
+}
+ol.arabic {
+ list-style-type: decimal;
+}
+ol.loweralpha {
+ list-style-type: lower-alpha;
+}
+ol.upperalpha {
+ list-style-type: upper-alpha;
+}
+ol.lowerroman {
+ list-style-type: lower-roman;
+}
+ol.upperroman {
+ list-style-type: upper-roman;
+}
+
+div.compact ul, div.compact ol,
+div.compact p, div.compact p,
+div.compact div, div.compact div {
+ margin-top: 0.1em;
+ margin-bottom: 0.1em;
+}
+
+tfoot {
+ font-weight: bold;
+}
+td > div.verse {
+ white-space: pre;
+}
+
+div.hdlist {
+ margin-top: 0.8em;
+ margin-bottom: 0.8em;
+}
+div.hdlist tr {
+ padding-bottom: 15px;
+}
+dt.hdlist1.strong, td.hdlist1.strong {
+ font-weight: bold;
+}
+td.hdlist1 {
+ vertical-align: top;
+ font-style: normal;
+ padding-right: 0.8em;
+ color: navy;
+}
+td.hdlist2 {
+ vertical-align: top;
+}
+div.hdlist.compact tr {
+ margin: 0;
+ padding-bottom: 0;
+}
+
+.comment {
+ background: yellow;
+}
+
+.footnote, .footnoteref {
+ font-size: 0.8em;
+}
+
+span.footnote, span.footnoteref {
+ vertical-align: super;
+}
+
+#footnotes {
+ margin: 20px 0 20px 0;
+ padding: 7px 0 0 0;
+}
+
+#footnotes div.footnote {
+ margin: 0 0 5px 0;
+}
+
+#footnotes hr {
+ border: none;
+ border-top: 1px solid silver;
+ height: 1px;
+ text-align: left;
+ margin-left: 0;
+ width: 20%;
+ min-width: 100px;
+}
+
+div.colist td {
+ padding-right: 0.5em;
+ padding-bottom: 0.3em;
+ vertical-align: top;
+}
+div.colist td img {
+ margin-top: 0.3em;
+}
+
+@media print {
+ #footer-badges { display: none; }
+}
+
+#toc {
+ margin-bottom: 2.5em;
+}
+
+#toctitle {
+ color: #527bbd;
+ font-size: 1.1em;
+ font-weight: bold;
+ margin-top: 1.0em;
+ margin-bottom: 0.1em;
+}
+
+div.toclevel0, div.toclevel1, div.toclevel2, div.toclevel3, div.toclevel4 {
+ margin-top: 0;
+ margin-bottom: 0;
+}
+div.toclevel2 {
+ margin-left: 2em;
+ font-size: 0.9em;
+}
+div.toclevel3 {
+ margin-left: 4em;
+ font-size: 0.9em;
+}
+div.toclevel4 {
+ margin-left: 6em;
+ font-size: 0.9em;
+}
+
+span.aqua { color: aqua; }
+span.black { color: black; }
+span.blue { color: blue; }
+span.fuchsia { color: fuchsia; }
+span.gray { color: gray; }
+span.green { color: green; }
+span.lime { color: lime; }
+span.maroon { color: maroon; }
+span.navy { color: navy; }
+span.olive { color: olive; }
+span.purple { color: purple; }
+span.red { color: red; }
+span.silver { color: silver; }
+span.teal { color: teal; }
+span.white { color: white; }
+span.yellow { color: yellow; }
+
+span.aqua-background { background: aqua; }
+span.black-background { background: black; }
+span.blue-background { background: blue; }
+span.fuchsia-background { background: fuchsia; }
+span.gray-background { background: gray; }
+span.green-background { background: green; }
+span.lime-background { background: lime; }
+span.maroon-background { background: maroon; }
+span.navy-background { background: navy; }
+span.olive-background { background: olive; }
+span.purple-background { background: purple; }
+span.red-background { background: red; }
+span.silver-background { background: silver; }
+span.teal-background { background: teal; }
+span.white-background { background: white; }
+span.yellow-background { background: yellow; }
+
+span.big { font-size: 2em; }
+span.small { font-size: 0.6em; }
+
+span.underline { text-decoration: underline; }
+span.overline { text-decoration: overline; }
+span.line-through { text-decoration: line-through; }
+
+div.unbreakable { page-break-inside: avoid; }
+
+
+/*
+ * xhtml11 specific
+ *
+ * */
+
+div.tableblock {
+ margin-top: 1.0em;
+ margin-bottom: 1.5em;
+}
+div.tableblock > table {
+ border: 3px solid #527bbd;
+}
+thead, p.table.header {
+ font-weight: bold;
+ color: #527bbd;
+}
+p.table {
+ margin-top: 0;
+}
+/* Because the table frame attribute is overriden by CSS in most browsers. */
+div.tableblock > table[frame="void"] {
+ border-style: none;
+}
+div.tableblock > table[frame="hsides"] {
+ border-left-style: none;
+ border-right-style: none;
+}
+div.tableblock > table[frame="vsides"] {
+ border-top-style: none;
+ border-bottom-style: none;
+}
+
+
+/*
+ * html5 specific
+ *
+ * */
+
+table.tableblock {
+ margin-top: 1.0em;
+ margin-bottom: 1.5em;
+}
+thead, p.tableblock.header {
+ font-weight: bold;
+ color: #527bbd;
+}
+p.tableblock {
+ margin-top: 0;
+}
+table.tableblock {
+ border-width: 3px;
+ border-spacing: 0px;
+ border-style: solid;
+ border-color: #527bbd;
+ border-collapse: collapse;
+}
+th.tableblock, td.tableblock {
+ border-width: 1px;
+ padding: 4px;
+ border-style: solid;
+ border-color: #527bbd;
+}
+
+table.tableblock.frame-topbot {
+ border-left-style: hidden;
+ border-right-style: hidden;
+}
+table.tableblock.frame-sides {
+ border-top-style: hidden;
+ border-bottom-style: hidden;
+}
+table.tableblock.frame-none {
+ border-style: hidden;
+}
+
+th.tableblock.halign-left, td.tableblock.halign-left {
+ text-align: left;
+}
+th.tableblock.halign-center, td.tableblock.halign-center {
+ text-align: center;
+}
+th.tableblock.halign-right, td.tableblock.halign-right {
+ text-align: right;
+}
+
+th.tableblock.valign-top, td.tableblock.valign-top {
+ vertical-align: top;
+}
+th.tableblock.valign-middle, td.tableblock.valign-middle {
+ vertical-align: middle;
+}
+th.tableblock.valign-bottom, td.tableblock.valign-bottom {
+ vertical-align: bottom;
+}
+
+
+/*
+ * manpage specific
+ *
+ * */
+
+body.manpage h1 {
+ padding-top: 0.5em;
+ padding-bottom: 0.5em;
+ border-top: 2px solid silver;
+ border-bottom: 2px solid silver;
+}
+body.manpage h2 {
+ border-style: none;
+}
+body.manpage div.sectionbody {
+ margin-left: 3em;
+}
+
+@media print {
+ body.manpage div#toc { display: none; }
+}
+
+
+</style>
+<script type="text/javascript">
+/*<+'])');
+ // Function that scans the DOM tree for header elements (the DOM2
+ // nodeIterator API would be a better technique but not supported by all
+ // browsers).
+ var iterate = function (el) {
+ for (var i = el.firstChild; i != null; i = i.nextSibling) {
+ if (i.nodeType == 1 /* Node.ELEMENT_NODE */) {
+ var mo = re.exec(i.tagName);
+ if (mo && (i.getAttribute("class") || i.getAttribute("className")) != "float") {
+ result[result.length] = new TocEntry(i, getText(i), mo[1]-1);
+ }
+ iterate(i);
+ }
+ }
+ }
+ iterate(el);
+ return result;
+ }
+
+ var toc = document.getElementById("toc");
+ if (!toc) {
+ return;
+ }
+
+ // Delete existing TOC entries in case we're reloading the TOC.
+ var tocEntriesToRemove = [];
+ var i;
+ for (i = 0; i < toc.childNodes.length; i++) {
+ var entry = toc.childNodes[i];
+ if (entry.nodeName.toLowerCase() == 'div'
+ && entry.getAttribute("class")
+ && entry.getAttribute("class").match(/^toclevel/))
+ tocEntriesToRemove.push(entry);
+ }
+ for (i = 0; i < tocEntriesToRemove.length; i++) {
+ toc.removeChild(tocEntriesToRemove[i]);
+ }
+
+ // Rebuild TOC entries.
+ var entries = tocEntries(document.getElementById("content"), toclevels);
+ for (var i = 0; i < entries.length; ++i) {
+ var entry = entries[i];
+ if (entry.element.id == "")
+ entry.element.id = "_toc_" + i;
+ var a = document.createElement("a");
+ a.href = "#" + entry.element.id;
+ a.appendChild(document.createTextNode(entry.text));
+ var div = document.createElement("div");
+ div.appendChild(a);
+ div.className = "toclevel" + entry.toclevel;
+ toc.appendChild(div);
+ }
+ if (entries.length == 0)
+ toc.parentNode.removeChild(toc);
+},
+
+
+/////////////////////////////////////////////////////////////////////
+// Footnotes generator
+/////////////////////////////////////////////////////////////////////
+
+/* Based on footnote generation code from:
+ * http://www.brandspankingnew.net/archive/2005/07/format_footnote.html
+ */
+
+footnotes: function () {
+ // Delete existing footnote entries in case we're reloading the footnodes.
+ var i;
+ var noteholder = document.getElementById("footnotes");
+ if (!noteholder) {
+ return;
+ }
+ var entriesToRemove = [];
+ for (i = 0; i < noteholder.childNodes.length; i++) {
+ var entry = noteholder.childNodes[i];
+ if (entry.nodeName.toLowerCase() == 'div' && entry.getAttribute("class") == "footnote")
+ entriesToRemove.push(entry);
+ }
+ for (i = 0; i < entriesToRemove.length; i++) {
+ noteholder.removeChild(entriesToRemove[i]);
+ }
+
+ // Rebuild footnote entries.
+ var cont = document.getElementById("content");
+ var spans = cont.getElementsByTagName("span");
+ var refs = {};
+ var n = 0;
+ for (i=0; i<spans.length; i++) {
+ if (spans[i].className == "footnote") {
+ n++;
+ var note = spans[i].getAttribute("data-note");
+ if (!note) {
+ // Use [\s\S] in place of . so multi-line matches work.
+ // Because JavaScript has no s (dotall) regex flag.
+ note = spans[i].innerHTML.match(/\s*\[([\s\S]*)]\s*/)[1];
+ spans[i].innerHTML =
+ "[<a id='_footnoteref_" + n + "' href='#_footnote_" + n +
+ "' title='View footnote' class='footnote'>" + n + "</a>]";
+ spans[i].setAttribute("data-note", note);
+ }
+ noteholder.innerHTML +=
+ "<div class='footnote' id='_footnote_" + n + "'>" +
+ "<a href='#_footnoteref_" + n + "' title='Return to text'>" +
+ n + "</a>. " + note + "</div>";
+ var id =spans[i].getAttribute("id");
+ if (id != null) refs["#"+id] = n;
+ }
+ }
+ if (n == 0)
+ noteholder.parentNode.removeChild(noteholder);
+ else {
+ // Process footnoterefs.
+ for (i=0; i<spans.length; i++) {
+ if (spans[i].className == "footnoteref") {
+ var href = spans[i].getElementsByTagName("a")[0].getAttribute("href");
+ href = href.match(/#.*/)[0]; // Because IE return full URL.
+ n = refs[href];
+ spans[i].innerHTML =
+ "[<a href='#_footnote_" + n +
+ "' title='View footnote' class='footnote'>" + n + "</a>]";
+ }
+ }
+ }
+},
+
+install: function(toclevels) {
+ var timerId;
+
+ function reinstall() {
+ asciidoc.footnotes();
+ if (toclevels) {
+ asciidoc.toc(toclevels);
+ }
+ }
+
+ function reinstallAndRemoveTimer() {
+ clearInterval(timerId);
+ reinstall();
+ }
+
+ timerId = setInterval(reinstall, 500);
+ if (document.addEventListener)
+ document.addEventListener("DOMContentLoaded", reinstallAndRemoveTimer, false);
+ else
+ window.onload = reinstallAndRemoveTimer;
+}
+
+}
+asciidoc.install(4);
+/*]]>*/
+</script>
+</head>
+<body class="article">
+<div id="header">
+<h1>ADC Extensions</h1>
+<span id="author">Fredrik Ullner, ul...@gm...</span><br />
+<span id="revnumber">version 1.0.8,</span>
+<span id="revdate">February 2014</span>
+<div id="toc">
+ <div id="toctitle">Table of Contents</div>
+ <noscript><p><b>JavaScript must be enabled in your browser to display the table of contents.</b></p></noscript>
+</div>
+</div>
+<div id="content">
+<div class="sect1">
+<h2 id="_abstract">1. Abstract</h2>
+<div class="sectionbody">
+<div class="paragraph"><p>These are the official extensions to ADC. This document is based on the
+information contained in the ADC wiki and ADC forum - spefications from there are moved here
+when they are mature and stable enough.</p></div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_version_history">2. Version history</h2>
+<div class="sectionbody">
+<div class="paragraph"><p>The latest draft of the next version of this document as well as intermediate
+and older versions can be downloaded from
+$URL: <a href="https://svn.code.sf.net/p/adc/code/trunk/ADC-EXT.txt">https://svn.code.sf.net/p/adc/code/trunk/ADC-EXT.txt</a> $.</p></div>
+<div class="paragraph"><p>This version corresponds to $Revision: 121 $.</p></div>
+<div class="sect2">
+<h3 id="_version_1_0_8">2.1. Version 1.0.8</h3>
+<div class="paragraph"><p>Fredrik Ullner <<a href="mailto:ul...@gm...">ul...@gm...</a>>, 2014-02-11</p></div>
+<div class="ulist"><ul>
+<li>
+<p>
+Improved <em>NATT</em> documentation, as according to the original paper.
+</p>
+</li>
+<li>
+<p>
+Added <em>ONID</em> extension to provide online service integration.
+</p>
+</li>
+<li>
+<p>
+TIGR now specifies the changes done to the file list.
+</p>
+</li>
+<li>
+<p>
+Added error code <em>ADCS transfers are required</em> in STA.
+</p>
+</li>
+<li>
+<p>
+Added <em>ASCH</em> extension for extended searching capability.
+</p>
+</li>
+<li>
+<p>
+Added <em>Date</em> attribute in file list for files and directories.
+</p>
+</li>
+<li>
+<p>
+Added <em>Size</em> attribute in file list for directories.
+</p>
+</li>
+<li>
+<p>
+Added <em>Children</em> attribute in file list for directories.
+</p>
+</li>
+<li>
+<p>
+Added downloaded progress report for uploaders in GET.
+</p>
+</li>
+<li>
+<p>
+Added <em>RDEX</em> for extended redirecting capabilities.
+</p>
+</li>
+</ul></div>
+</div>
+<div class="sect2">
+<h3 id="_version_1_0_7">2.2. Version 1.0.7</h3>
+<div class="paragraph"><p>Fredrik Ullner <<a href="mailto:ul...@gm...">ul...@gm...</a>>, 2012-11-22</p></div>
+<div class="ulist"><ul>
+<li>
+<p>
+Added application and version separation in INF
+</p>
+</li>
+<li>
+<p>
+TIGR should now correctly reference SCH and RES
+</p>
+</li>
+</ul></div>
+</div>
+<div class="sect2">
+<h3 id="_version_1_0_6">2.3. Version 1.0.6</h3>
+<div class="paragraph"><p>Fredrik Ullner <<a href="mailto:ul...@gm...">ul...@gm...</a>>, 2010-09-29</p></div>
+<div class="ulist"><ul>
+<li>
+<p>
+Added <em>KEYP</em> extension for providing certificate substitution protection in ADCS.
+</p>
+</li>
+<li>
+<p>
+Added note to signal DFAV.
+</p>
+</li>
+<li>
+<p>
+Added <em>SUDP</em> extension for encryption of UDP traffic.
+</p>
+</li>
+<li>
+<p>
+Added <em>TYPE</em> extension for chat state notifications.
+</p>
+</li>
+<li>
+<p>
+Added <em>FEED</em> extension for RSS feeds.
+</p>
+</li>
+<li>
+<p>
+Added <em>SEGA</em> extension for grouping of file extensions in SCH.
+</p>
+</li>
+<li>
+<p>
+Added failover hub addresses to the hub’s INF.
+</p>
+</li>
+<li>
+<p>
+Added free slots to the client’s INF.
+</p>
+</li>
+<li>
+<p>
+Added <em>ADCS</em> extension for encryption in ADC.
+</p>
+</li>
+</ul></div>
+</div>
+<div class="sect2">
+<h3 id="_version_1_0_5">2.4. Version 1.0.5</h3>
+<div class="paragraph"><p>Fredrik Ullner <<a href="mailto:ul...@gm...">ul...@gm...</a>>, 2010-09-16</p></div>
+<div class="ulist"><ul>
+<li>
+<p>
+Added locale field to INF.
+</p>
+</li>
+<li>
+<p>
+Modified user parameter <em>line</em> in UCMD to handle multiple inputs.
+</p>
+</li>
+<li>
+<p>
+Added hidden in enumeration of CT field in INF.
+</p>
+</li>
+<li>
+<p>
+Added error code Invalid feature in STA.
+</p>
+</li>
+</ul></div>
+</div>
+<div class="sect2">
+<h3 id="_version_1_0_4">2.5. Version 1.0.4</h3>
+<div class="paragraph"><p>Fredrik Ullner <<a href="mailto:ul...@gm...">ul...@gm...</a>>, 2010-06-29</p></div>
+<div class="ulist"><ul>
+<li>
+<p>
+Added magnet link extension to UCMD.
+</p>
+</li>
+<li>
+<p>
+Added NAT traversal extension <em>NATT</em>.
+</p>
+</li>
+<li>
+<p>
+Added referral field to STA.
+</p>
+</li>
+<li>
+<p>
+Added upload queue field to STA.
+</p>
+</li>
+<li>
+<p>
+Added partial file sharing extension <em>PFSR</em>.
+</p>
+</li>
+</ul></div>
+</div>
+<div class="sect2">
+<h3 id="_version_1_0_3">2.6. Version 1.0.3</h3>
+<div class="paragraph"><p>Fredrik Ullner <<a href="mailto:ul...@gm...">ul...@gm...</a>>, 2010-05-26</p></div>
+<div class="ulist"><ul>
+<li>
+<p>
+Removed optional keywords from UCMD.
+</p>
+</li>
+<li>
+<p>
+Added <em>BLOM</em> extension for bloom filters.
+</p>
+</li>
+</ul></div>
+</div>
+<div class="sect2">
+<h3 id="_version_1_0_2">2.7. Version 1.0.2</h3>
+<div class="paragraph"><p>Fredrik Ullner <<a href="mailto:ul...@gm...">ul...@gm...</a>>, 2010-04-04</p></div>
+<div class="ulist"><ul>
+<li>
+<p>
+Added <em>UCMD</em> extension for user commands.
+</p>
+</li>
+</ul></div>
+</div>
+<div class="sect2">
+<h3 id="_version_1_0_1">2.8. Version 1.0.1</h3>
+<div class="paragraph"><p>Fredrik Ullner <<a href="mailto:ul...@gm...">ul...@gm...</a>>, 2009-08-04</p></div>
+<div class="ulist"><ul>
+<li>
+<p>
+Added timestamp field to MSG.
+</p>
+</li>
+<li>
+<p>
+Added <em>DFAV</em> extension for distributing hub addresses.
+</p>
+</li>
+</ul></div>
+</div>
+<div class="sect2">
+<h3 id="_version_1_0">2.9. Version 1.0</h3>
+<div class="paragraph"><p>Jacek Sieka <<a href="mailto:arn...@gm...">arn...@gm...</a>>, 2008-05-02</p></div>
+<div class="ulist"><ul>
+<li>
+<p>
+Initial release created from original ADC 1.0 text.
+</p>
+</li>
+<li>
+<p>
+Added <em>PING</em> extension for hub pingers.
+</p>
+</li>
+</ul></div>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_extensions">3. Extensions</h2>
+<div class="sectionbody">
+<div class="sect2">
+<h3 id="_tigr_tiger_tree_hash_support">3.1. TIGR - Tiger tree hash support</h3>
+<div class="sect3">
+<h4 id="_general">3.1.1. General</h4>
+<div class="paragraph"><p>This extension adds Tiger tree hash support to the base protocol. It is
+intended to be used both for identifying files and for purposes such as CID
+generation and password negotiation</p></div>
+</div>
+<div class="sect3">
+<h4 id="_tigr_for_shared_files">3.1.2. TIGR for shared files</h4>
+<div class="paragraph"><p>All files shared by TIGR supporting clients must have been hashed using Merkle
+Hash trees, as defined by
+<a href="http://web.archive.org/web/20080316033726/http://www.open-content.net/specs/draft-jchapweske-thex-02.html">http://web.archive.org/web/20080316033726/http://www.open-content.net/specs/draft-jchapweske-thex-02.html</a>.
+The Tiger
+algorithm, as specified by <a href="http://www.cs.technion.ac.il/~biham/Reports/Tiger/">http://www.cs.technion.ac.il/~biham/Reports/Tiger/</a>,
+functions as the hash algorithm. A base segment size of 1024 bytes must be
+used when generating the tree, but clients may then discard parts of the tree
+as long as at least 7 levels are kept or a block granularity of 64 KiB is
+achieved.</p></div>
+<div class="paragraph"><p>Generally, the root of the tree (TTH) serves to identify a file uniquely.
+Searches use it and it must be present in the file list. Further, the root of
+the file list must also be available and discoverable via GFI. A client may
+also request the rest of the tree using the normal client-client transfer
+procedure. The root must be encoded using base32 encoding when converted to
+text.</p></div>
+<div class="paragraph"><p>In the file list, each File element carries an additional attribute "TTH"
+containing the base32-encoded value of the Tiger tree root.</p></div>
+<div class="paragraph"><p>In the GET/GFI type, the full tree may be accessed using the "tthl" type.</p></div>
+<div class="paragraph"><p>"tthl" transfers send the largest set of leaves available) as a binary stream
+of leaf data, right-to-left, with no spacing in between them. <start_pos>
+must be set to 0 and <bytes> to -1 when requesting the data. <bytes> must
+contain the total binary size of the leaf stream in SND; by dividing this
+length by the individual hash length, the number of leaves, and thus the leaf
+level, can be deducted. The received leaves can then be used to reconstruct
+the entire tree, and the resulting root must match the root of the file (this
+verifies the integrity of the tree itself). Identifier must be a TTH root
+value from the "TTH/" root.</p></div>
+<div class="paragraph"><p>In the GET/GFI namespace, files are identified by
+"TTH/<base32-encoded tree root>".</p></div>
+<div class="paragraph"><p>In SCH and RES, the following attributes are added:</p></div>
+<div class="tableblock">
+<table rules="all"
+frame="border"
+cellspacing="0" cellpadding="4">
+<col />
+<col />
+<tbody>
+<tr>
+<td align="left" valign="top"><p class="table">TR</p></td>
+<td align="left" valign="top"><p class="table">Tiger tree Hash root, encoded with base32.</p></td>
+</tr>
+<tr>
+<td align="left" valign="top"><p class="table">TD</p></td>
+<td align="left" valign="top"><p class="table">Tree depth, index of the highest level of tree data available, root-only = 0, first level (2 leaves) = 1, second level = 2, etc…</p></td>
+</tr>
+</tbody>
+</table>
+</div>
+<div class="paragraph"><p>The following changes are done to the file list XML schema:</p></div>
+<div class="paragraph"><p>A new type is defined with an appropriate attribute:</p></div>
+<div class="listingblock">
+<div class="content">
+<pre><code><xs:simpleType name="tthType">
+ <xs:restriction base="xs:string">
+ <xs:pattern value="[A-Za-z2-7]{39}" />
+ </xs:restriction>
+</xs:simpleType>
+<xs:attribute name="TTH" type="tthType" /></code></pre>
+</div></div>
+<div class="paragraph"><p>The attribute is then referenced in the File element:</p></div>
+<div class="listingblock">
+<div class="content">
+<pre><code><xs:attribute ref="TTH" use="required" /></code></pre>
+</div></div>
+</div>
+</div>
+<div class="sect2">
+<h3 id="_bzip_file_list_compressed_with_bzip2">3.2. BZIP - File list compressed with bzip2</h3>
+<div class="paragraph"><p>This extension adds a special file "files.xml.bz2" in the unnamed root of the
+share which contains "files.xml" compressed with bzip2 1.0.3+ (www.bzip.org).</p></div>
+</div>
+<div class="sect2">
+<h3 id="_zlib_compressed_communication">3.3. ZLIB - Compressed communication</h3>
+<div class="paragraph"><p>There are two variants of zlib support, FULL and GET, and only one should be
+used on a each communications channel set up.</p></div>
+<div class="sect3">
+<h4 id="_zlib_full">3.3.1. ZLIB-FULL</h4>
+<div class="paragraph"><p>If, during SUP negotiation, a peer sends "ZLIF" in its support string, it must
+accept two additional commands, ZON and ZOF. Upon reception of ZON the peer
+must start decompressing the incoming stream of data with zlib before
+interpreting it, and stop doing so after ZOF is received (in the compressed
+stream). The compressing end must partially flush the zlib buffer after each
+chunk of data to allow for decompression by the peer.</p></div>
+</div>
+<div class="sect3">
+<h4 id="_zlib_get">3.3.2. ZLIB-GET</h4>
+<div class="paragraph"><p>The alternative is to send "ZLIG" to indicate that zlib is supported for
+binary transfers using the GET command, but not otherwise. A flag "ZL1" is
+added to the to the SND command to indicate that the data will come
+compressed, and the client receiving requests it by adding the same flag to
+GET (the sending client may ignore a request for a compressed transfer, but
+may also use it even when not requested by the receiver). The <bytes>
+parameter of the GET and SND commands is to be interpreted as the number of
+uncompressed bytes to be transferred.</p></div>
+</div>
+</div>
+<div class="sect2">
+<h3 id="_ping_pinger_extension">3.4. PING - Pinger extension</h3>
+<div class="paragraph"><p>This extension can be supported by both clients and hubs, and when present, if hub
+supports it, it must send additional information to the client ( otherwise normal
+base client).</p></div>
+<div class="paragraph"><p>It’s purpose is to send to hublist pingers additional information about the hub
+ that otherwise it would be impossible to get as a normal user (eg. minimum share,
+ maximum user count, etc).</p></div>
+<div class="sect3">
+<h4 id="_inf">3.4.1. INF</h4>
+<div class="paragraph"><p>Contexts : F</p></div>
+<div class="paragraph"><p>When the client supporting the PING extension connects, the hub must send its
+normal INF along with the following added fields ( none mandatory, if not present,
+it means hub has no restrictions in that matter, or non existent):</p></div>
+<div class="tableblock">
+<table rules="all"
+frame="border"
+cellspacing="0" cellpadding="4">
+<col />
+<col />
+<col />
+<thead>
+<tr>
+<th align="left" valign="top">Code </th>
+<th align="left" valign="top"> Type </th>
+<th align="left" valign="top"> Description</th>
+</tr>
+</thead>
+<tbody>
+<tr>
+<td align="left" valign="top"><p class="table">HH</p></td>
+<td align="left" valign="top"><p class="table">string</p></td>
+<td align="left" valign="top"><p class="table">Hub Host address ( DNS or IP )</p></td>
+</tr>
+<tr>
+<td align="left" valign="top"><p class="table">WS</p></td>
+<td align="left" valign="top"><p class="table">url</p></td>
+<td align="left" valign="top"><p class="table">Hub Website</p></td>
+</tr>
+<tr>
+<td align="left" valign="top"><p class="table">NE</p></td>
+<td align="left" valign="top"><p class="table">string</p></td>
+<td align="left" valign="top"><p class="table">Hub Network</p></td>
+</tr>
+<tr>
+<td align="left" valign="top"><p class="table">OW</p></td>
+<td align="left" valign="top"><p class="table">string</p></td>
+<td align="left" valign="top"><p class="table">Hub Owner name</p></td>
+</tr>
+<tr>
+<td align="left" valign="top"><p class="table">UC</p></td>
+<td align="left" valign="top"><p class="table">integer</p></td>
+<td align="left" valign="top"><p class="table">Current User count</p></td>
+</tr>
+<tr>
+<td align="left" valign="top"><p class="table">SS</p></td>
+<td align="left" valign="top"><p class="table">integer</p></td>
+<td align="left" valign="top"><p class="table">Total share size</p></td>
+</tr>
+<tr>
+<td align="left" valign="top"><p class="table">SF</p></td>
+<td align="left" valign="top"><p class="table">integer</p></td>
+<td align="left" valign="top"><p class="table">Total files shared</p></td>
+</tr>
+<tr>
+<td align="left" valign="top"><p class="table">MS</p></td>
+<td align="left" valign="top"><p class="table">integer</p></td>
+<td align="left" valign="top"><p class="table">Minimum share required to enter hub ( bytes )</p></td>
+</tr>
+<tr>
+<td align="left" valign="top"><p class="table">XS</p></td>
+<td align="left" valign="top"><p class="table">integer</p></td>
+<td align="left" valign="top"><p class="table">Maximum share for entering hub ( bytes )</p></td>
+</tr>
+<tr>
+<td align="left" valign="top"><p class="table">ML</p></td>
+<td align="left" valign="top"><p class="table">integer</p></td>
+<td align="left" valign="top"><p class="table">Minimum slots required to enter hub</p></td>
+</tr>
+<tr>
+<td align="left" valign="top"><p class="table">XL</p></td>
+<td align="left" valign="top"><p class="table">integer</p></td>
+<td align="left" valign="top"><p class="table">Maximum slots for entering hub</p></td>
+</tr>
+<tr>
+<td align="left" valign="top"><p class="table">MU</p></td>
+<td align="left" valign="top"><p class="table">integer</p></td>
+<td align="left" valign="top"><p class="table">Minimum hubs connected where clients can be users</p></td>
+</tr>
+<tr>
+<td align="left" valign="top"><p class="table">MR</p></td>
+<td align="left" valign="top"><p class="table">integer</p></td>
+<td align="left" valign="top"><p class="table">Minimum hubs connected where client can be registered</p></td>
+</tr>
+<tr>
+<td align="left" valign="top"><p class="table">MO</p></td>
+<td align="left" valign="top"><p class="table">integer</p></td>
+<td align="left" valign="top"><p class="table">Minimum hubs connected where client can be operators</p></td>
+</tr>
+<tr>
+<td align="left" valign="top"><p class="table">XU</p></td>
+<td align="left" valign="top"><p class="table">integer</p></td>
+<td align="left" valign="top"><p class="table">Maximum hubs connected where clients can be users</p></td>
+</tr>
+<tr>
+<td align="left" valign="top"><p class="table">XR</p></td>
+<td align="left" valign="top"><p class="table">integer</p></td>
+<td align="left" valign="top"><p class="table">Maximum hubs connected where client can be registered</p></td>
+</tr>
+<tr>
+<td align="left" valign="top"><p class="table">XO</p></td>
+<td align="left" valign="top"><p class="table">integer</p></td>
+<td align="left" valign="top"><p class="table">Maximum hubs connected where client can be operators</p></td>
+</tr>
+<tr>
+<td align="left" valign="top"><p class="table">MC</p></td>
+<td align="left" valign="top"><p class="table">integer</p></td>
+<td align="left" valign="top"><p class="table">Maximum possible clients ( users ) who can connect</p></td>
+</tr>
+<tr>
+<td align="left" valign="top"><p class="table">UP</p></td>
+<td align="left" valign="top"><p class="table">integer</p></td>
+<td align="left" valign="top"><p class="table">Hub uptime (seconds)</p></td>
+</tr>
+<tr>
+<td align="left" valign="top"><p class="table">NI</p></td>
+<td align="left" valign="top"><p class="table">string</p></td>
+<td align="left" valign="top"><p class="table">Hub name (from BASE)</p></td>
+</tr>
+<tr>
+<td align="left" valign="top"><p class="table">DE</p></td>
+<td align="left" valign="top"><p class="table">string</p></td>
+<td align="left" valign="top"><p class="table">Hub description (from BASE)</p></td>
+</tr>
+<tr>
+<td align="left" valign="top"><p class="table">VE</p></td>
+<td align="left" valign="top"><p class="table">string</p></td>
+<td align="left" valign="top"><p class="table">Hub software version (from BASE)</p></td>
+</tr>
+</tbody>
+</table>
+</div>
+<div class="paragraph"><p>The hub must continue to send the user list as for a normal user (move to
+NORMAL state). The pinger may decide to go through or disconnect (eg. if it
+doesn’t require additional information about the users).</p></div>
+<div class="sect4">
+<h5 id="_example">Example</h5>
+<div class="exampleblock">
+<div class="content">
+<div class="literalblock">
+<div class="content">
+<pre><code>-pinger- HSUP ADBASE ADPING AD..
+-hub- ISUP ADBASE ADPING AD..
+-hub- ISID ..
+-hub- IINF NIhubname DEcurrent\stopic VE.. HHexample.org:555 WShttp://example.org/ OWmyname UC2231 SS.. SF.. MS0 ML0 MC5000
+- (pinger may disconnect)</code></pre>
+</div></div>
+</div></div>
+</div>
+</div>
+<div class="sect3">
+<h4 id="_hub_hublist_communication">3.4.2. Hub - Hublist communication</h4>
+<div class="paragraph"><p>The same extension goes for hub- hublist communication. This way, the hub
+takes the role of the client and the hublist of the server.</p></div>
+<div class="paragraph"><p>The hublist may send INF about itself with NI field which would become hublist
+name and WS hublist web address.</p></div>
+<div class="sect4">
+<h5 id="_example_2">Example</h5>
+<div class="exampleblock">
+<div class="content">
+<div class="literalblock">
+<div class="content">
+<pre><code>-hub- HSUP ADBASE ADPING AD..
+-hublist- ISUP ADBASE ADPING AD..
+-hublist- IINF NIhublist_name WShublist_address
+-hub- HINF NIhubname DEcurrent\stopic VE.. HHexample.org:555 WShttp://example.org/ OWmyname UC2231 SS.. SF.. MS0 ML0 MC5000
+-( disconnect )</code></pre>
+</div></div>
+</div></div>
+</div>
+</div>
+</div>
+<div class="sect2">
+<h3 id="_ts_timestamp_in_msg">3.5. TS - Timestamp in MSG</h3>
+<div class="paragraph"><p>Timestamp of the moment when the message was sent, expressed in seconds since the Unix Epoch (January 1 1970 00:00:00 GMT).</p></div>
+</div>
+<div class="sect2">
+<h3 id="_dfav_distributed_favorites">3.6. DFAV - Distributed Favorites</h3>
+<div class="paragraph"><p>The idea behind this extension is to generate a public hublist from the users favorite hublist. Implementations should separate between public and private hubs in the favorite hublist of an user, in order not to distribute private hubs where one can not connect to anyway.</p></div>
+<div class="paragraph"><p>Signal DFAV in SUP and the INF’s SU field.</p></div>
+<div class="sect3">
+<h4 id="_gfa">3.6.1. GFA</h4>
+<div class="literalblock">
+<div class="content">
+<pre><code>GFA</code></pre>
+</div></div>
+<div class="paragraph"><p>Contexts: T, C</p></div>
+<div class="paragraph"><p>Asks all users within the same hub with the correct feature to send all publicly available hubs, in their favorite hub list to the requesting client.</p></div>
+</div>
+<div class="sect3">
+<h4 id="_rfa">3.6.2. RFA</h4>
+<div class="literalblock">
+<div class="content">
+<pre><code>RFA</code></pre>
+</div></div>
+<div class="paragraph"><p>Contexts: C</p></div>
+<div class="paragraph"><p>Response of a client.</p></div>
+<div class="tableblock">
+<table rules="all"
+frame="border"
+cellspacing="0" cellpadding="4">
+<col />
+<col />
+<tbody>
+<tr>
+<td align="left" valign="top"><p class="table">HA</p></td>
+<td align="left" valign="top"><p class="table">Hub address</p></td>
+</tr>
+<tr>
+<td align="left" valign="top"><p class="table">LG</p></td>
+<td align="left" valign="top"><p class="table">Last succesfull login time ( number of seconds since the epoch (1970), (UTC) )</p></td>
+</tr>
+</tbody>
+</table>
+</div>
+<div class="paragraph"><p>All INF fields from BASE are inherited. All INF fields from PING extension are inherited.</p></div>
+</div>
+</div>
+<div class="sect2">
+<h3 id="_ucmd_user_commands">3.7. UCMD - User commands</h3>
+<div class="literalblock">
+<div class="content">
+<pre><code>CMD name</code></pre>
+</div></div>
+<div class="paragraph"><p>Contexts: F</p></div>
+<div class="paragraph"><p>States: NORMAL</p></div>
+<div class="paragraph"><p>User commands are used to send hub-specific commands to the client which provide useful shortcuts for the user. These commands contain strings which must be sent back to the hub and keyword substitutions in the strings. Each user command has a display name, a string to be sent to the hub, and one or more categories where it may appear. The strings passed to the hub must first be passed through a dictionary replacement that replaces all keywords in the string and then through the equivalent of the C standard function "strftime", with the current time.</p></div>
+<div class="paragraph"><p>Name uniquely (per hub) identifies a particular user command. The name may contain "/" to indicate a logical structure on the viewing client, where each "/" introduces a new submenu level. Other than name, the command also has a number of flags that further detail what to do with it.</p></div>
+<div class="tableblock">
+<table rules="all"
+frame="border"
+cellspacing="0" cellpadding="4">
+<col />
+<col />
+<tbody>
+<tr>
+<td align="left" valign="top"><p class="table">RM</p></td>
+<td align="left" valign="top"><p class="table">1 = Remove Command</p></td>
+</tr>
+<tr>
+<td align="left" valign="top"><p class="table">CT</p></td>
+<td align="left" valign="top"><p class="table">Message Category, 1 = Hub command, client parameters only, 2 = User list command, client and user parameters, 4 = Search result command, client, user and file parameters, 8 = File list command, client, user and file parameters. Multiple types are specified by adding the numbers together.</p></td>
+</tr>
+<tr>
+<td align="left" valign="top"><p class="table">TT</p></td>
+<td align="left" valign="top"><p class="table">The full text to be sent to hub, including FOURCC, parameters and keywords.</p></td>
+</tr>
+<tr>
+<td align="left" valign="top"><p class="table">CO</p></td>
+<td align="left" valign="top"><p class="table">1 = Constrained, when sending this command on multiple users (for example in search results), constrain it to once per CID only</p></td>
+</tr>
+<tr>
+<td align="left" valign="top"><p class="table">SP</p></td>
+<td align="left" valign="top"><p class="table">1 = Insert separator instead of command name (name must still be present to uniquely identify the command).</p></td>
+</tr>
+</tbody>
+</table>
+</div>
+<div class="sect3">
+<h4 id="_keywords">3.7.1. Keywords</h4>
+<div class="paragraph"><p>Keywords are specified using "%[keyword]". Unknown keywords must be replaced by the empty string. Additionally, all %-substitutions of the C function "strftime" must be supported.</p></div>
+<div class="paragraph"><p>The following tables specify the keywords that must be supported.</p></div>
+<div class="paragraph"><p>Client parameters</p></div>
+<div class="tableblock">
+<table rules="all"
+frame="border"
+cellspacing="0" cellpadding="4">
+<col />
+<col />
+<tbody>
+<tr>
+<td align="left" valign="top"><p class="table">myCID</p></td>
+<td align="left" valign="top"><p class="table">Client CID</p></td>
+</tr>
+<tr>
+<td align="left" valign="top"><p class="table">mySID</p></td>
+<td align="left" valign="top"><p class="table">ClientSID</p></td>
+</tr>
+<tr>
+<td align="left" valign="top"><p class="table">myXX</p></td>
+<td align="left" valign="top"><p class="table">One for each flag on that particular hub; for example, myI4 and myNI</p></td>
+</tr>
+</tbody>
+</table>
+</div>
+<div class="paragraph"><p>User parameters</p></div>
+<div class="tableblock">
+<table rules="all"
+frame="border"
+cellspacing="0" cellpadding="4">
+<col />
+<col />
+<tbody>
+<tr>
+<td align="left" valign="top"><p class="table">userCID</p></td>
+<td align="left" valign="top"><p class="table">User CID</p></td>
+</tr>
+<tr>
+<td align="left" valign="top"><p class="table">userSID</p></td>
+<td align="left" valign="top"><p class="table">User SID</p></td>
+</tr>
+<tr>
+<td align="left" valign="top"><p class="table">userXX</p></td>
+<td align="left" valign="top"><p class="table">One for each flag on the user sent; for example, userI4 and userNI</p></td>
+</tr>
+<tr>
+<td align="left" valign="top"><p class="table">line:info</p></td>
+<td align="left" valign="top"><p class="table">Prompts the user for input where <em>info</em> is the displayed text description for the user input. <em>info</em> can be used for multiple values (combobox etc), and should be structured as "general info/default selection/value0/value1/…/valueN". The general info can be viewed as the caption of the user input dialog. Default selection is an integer k which signifies the default value to be used. Note that N >= k >= 0 and N >= 1. Note that values are 0-index based. Values are separated with a forward slash (<em>/</em>). If a forward slash is part of a value, it should be escaped by using an additional forward slash (<em>//</em>).</p></td>
+</tr>
+</tbody>
+</table>
+</div>
+<div class="paragraph"><p>File parameters</p></div>
+<div class="tableblock">
+<table rules="all"
+frame="border"
+cellspacing="0" cellpadding="4">
+<col />
+<col />
+<tbody>
+<tr>
+<td align="left" valign="top"><p class="table">fileXX</p></td>
+<td align="left" valign="top"><p class="table">One for each flag contained within a search result or file list entry (see RES)</p></td>
+</tr>
+<tr>
+<td align="left" valign="top"><p class="table">fileMN</p></td>
+<td align="left" valign="top"><p class="table">Specify magnet link. <a href="http://en.wikipedia.org/wiki/Magnet_link">Magnet links</a> are used to reference files across networks and applications. Clients may ignore parameters it does not understand, but are free to pass on the parameters to other programs.</p></td>
+</tr>
+</tbody>
+</table>
+</div>
+<div class="paragraph"><p>Hub parameters</p></div>
+<div class="tableblock">
+<table rules="all"
+frame="border"
+cellspacing="0" cellpadding="4">
+<col />
+<col />
+<tbody>
+<tr>
+<td align="left" valign="top"><p class="table">hubXX</p></td>
+<td align="left" valign="top"><p class="table">One for each flag of the hub; for example, hubNI and hubVE</p></td>
+</tr>
+</tbody>
+</table>
+</div>
+</div>
+<div class="sect3">
+<h4 id="_example_3">3.7.2. Example</h4>
+<div class="exampleblock">
+<div class="content">
+<div class="paragraph"><p>ICMD ADCH++/Hub\smanagement/Register\snick TTHMSG\s+regnick\s%[userNI]\s%[line:Password\s(leave\sempty\sto\sun-reg)]\s%[line:Level\s(facultative;\sdefaults\sto\syour\sown\slevel\sminus\sone)]\n CT2</p></div>
+<div class="paragraph"><p>ICMD ADCH++/Hub\smanagement/Reload\sbans TTHMSG\s+loadbans\n CT3</p></div>
+<div class="paragraph"><p>ICMD ADCH++/Hub\smanagement/Reload\sscripts TTHMSG\s+reload\n CT3</p></div>
+<div class="paragraph"><p>ICMD ADCH++/Info TTHMSG\s+info\s%[userNI]\n CT2</p></div>
+<div class="paragraph"><p>ICMD ADCH++/Info TTHMSG\s+info\n CT1</p></div>
+</div></div>
+</div>
+</div>
+<div class="sect2">
+<h3 id="_blom_bloom_filter">3.8. BLOM- Bloom filter</h3>
+<div class="paragraph"><p>Bloom filters allow the hub to filter certain searches using bitmap that represents the hashes of the files in the users share. BLOM is an extension that allows hub software to create a map (bloom filter) of the shared files on the hub, but with minimal effort, e.g. the hub doesn’t keep a list of files, but a filter that never produces false negatives but only possible false positives. This can potentially save bandwidth and effort on the client side. When the user updates the share, the client must send an INF containing the flag SF. The hub may at any time request that the client sends an updated version of its bloom filter by sending a GET command to the client. The client will then respond using SND and send the bloom filter binary data.</p></div>
+<div class="sect3">
+<h4 id="_legend">3.8.1. Legend</h4>
+<div class="tableblock">
+<table rules="all"
+frame="border"
+cellspacing="0" cellpadding="4">
+<col />
+<col />
+<tbody>
+<tr>
+<td align="left" valign="top"><p class="table">b</p></td>
+<td align="left" valign="top"><p class="table">Number of bits used for file hashes</p></td>
+</tr>
+<tr>
+<td align="left" valign="top"><p class="table">n</p></td>
+<td align="left" valign="top"><p class="table">Number of files in the user’s share</p></td>
+</tr>
+<tr>
+<td align="left" valign="top"><p class="table">m</p></td>
+<td align="left" valign="top"><p class="table">Size of the bloom filter in bits</p></td>
+</tr>
+<tr>
+<td align="left" valign="top"><p class="table">k</p></td>
+<td align="left" valign="top"><p class="table">Number of sub-hashes constructed from the file hash</p></td>
+</tr>
+<tr>
+<td align="left" valign="top"><p class="table">h</p></td>
+<td align="left" valign="top"><p class="table">Number of bits to use for each sub-hash</p></td>
+</tr>
+<tr>
+<td align="left" valign="top"><p class="table">p</p></td>
+<td align="left" valign="top"><p class="table">Propability of a false positive</p></td>
+</tr>
+</tbody>
+</table>
+</div>
+<div class="paragraph"><p>The hub chooses k, h and m.</p></div>
+</div>
+<div class="sect3">
+<h4 id="_restrictions">3.8.2. Restrictions</h4>
+<div class="tableblock">
+<table rules="all"
+frame="border"
+cellspacing="0" cellpadding="4">
+<col />
+<tbody>
+<tr>
+<td align="left" valign="top"><p class="table">k * h < = b</p></td>
+</tr>
+<tr>
+<td align="left" valign="top"><p class="table">h < = 64</p></td>
+</tr>
+<tr>
+<td align="left" valign="top"><p class="table">2<sup>h</sup> > m</p></td>
+</tr>
+<tr>
+<td align="left" valign="top"><p class="table">m mod 64 == 0</p></td>
+</tr>
+</tbody>
+</table>
+</div>
+</div>
+<div class="sect3">
+<h4 id="_probability">3.8.3. Probability</h4>
+<div class="tableblock">
+<table rules="all"
+frame="border"
+cellspacing="0" cellpadding="4">
+<col />
+<col />
+<tbody>
+<tr>
+<td align="left" valign="top"><p class="table">p == (1 - (1 - 1 / m)<sup>(k * n)</sup>)<sup>k</sup></p></td>
+<td align="left" valign="top"><p class="table">False positives</p></td>
+</tr>
+<tr>
+<td align="left" valign="top"><p class="table">p == 0</p></td>
+<td align="left" valign="top"><p class="table">False negatives</p></td>
+</tr>
+</tbody>
+</table>
+</div>
+</div>
+<div class="sect3">
+<h4 id="_protocol_changes">3.8.4. Protocol changes</h4>
+<div class="paragraph"><p>Signal BLOM in SUP.</p></div>
+<div class="paragraph"><p>For the SND type, adds H as message type.</p></div>
+<div class="paragraph"><p>For the GET type, adds I as message type.</p></div>
+<div class="paragraph"><p>For the GET type, adds "blom" as type.</p></div>
+<div class="paragraph"><p>For the GET type, "/" shall be used as namespace.</p></div>
+<div class="paragraph"><p>For the GET type, 0 (zero) shall be used as start position.</p></div>
+<div class="paragraph"><p>For the GET type, m / 8 shall be used as byte amount.</p></div>
+<div class="paragraph"><p>Updates GET with the following flags;</p></div>
+<div class="tableblock">
+<table rules="all"
+frame="border"
+cellspacing="0" cellpadding="4">
+<col />
+<col />
+<tbody>
+<tr>
+<td align="left" valign="top"><p class="table">BK</p></td>
+<td align="left" valign="top"><p class="table">Specify <em>k</em>.</p></td>
+</tr>
+<tr>
+<td align="left" valign="top"><p class="table">BH</p></td>
+<td align="left" valign="top"><p class="table">Specify <em>h</em>.</p></td>
+</tr>
+</tbody>
+</table>
+</div>
+</div>
+<div class="sect3">
+<h4 id="_algorithm">3.8.5. Algorithm</h4>
+<div class="paragraph"><p>The client constructs the bloom filter by creating a bit array of m bits set to 0 (zero). For each file it then sets to "1" k positions constructed from the file hash. Seeing the file hash as a stream of bits (starting from the lowest bit of the first byte, ending at the highest bit of the last byte), the client should use h bits starting at the first bit of the first byte to create an integer and apply modulo m to get the position in the bit array, then redo the process k times advancing the starting position by h each time.</p></div>
+<div class="paragraph"><p>Once the hub has received the bloom filter bit array, for each search command it processes, if it contains a hash search term, it can skip broadcasting the search to a particular client if at least one of the k bits in that clients bit array is "0", calculating positions as the client does when setting bits to "1". The hub has to evaluate the filter for each client that it has a bloom filter for, for each search.</p></div>
+</div>
+<div class="sect3">
+<h4 id="_probability_calculations">3.8.6. Probability calculations</h4>
+<div class="paragraph"><p>p = (1 - (1 - 1 / m)<sup>(k * n)</sup>)<sup>k</sup>, thus p becomes smaller as m grows and larger as n grows. Larger m means more bits to transfer but also fewer false positives. The optimum value for k given m and n is (m / n) * ln 2. The largest k supported by a hash of a certain size is b / h, so if the hub wants the smallest p possible, it should choose the smallest possible h which gives the largest k, and then calculate m = k * n/ln 2, checking that the resulting m < 2<sup>h</sup>. 2<sup>h</sup> should much be larger than m (at least 3-4 times), because of how the modulo operator works. Also, with m grows the required bandwidth to transfer the bloom filter, so the hub may wish to cap m. In that case, it should still choose k according to m / n * ln 2, but send an h as big as possible to alleviate biasing problems.</p></div>
+</div>
+<div class="sect3">
+<h4 id="_sample_implementations">3.8.7. Sample implementations</h4>
+<div class="sect4">
+<h5 id="_tiger">Tiger</h5>
+<div class="paragraph"><p>For TTH roots, b is 192 and a reasonable value for h is 24, giving a maximum k = 8 which means that m = 8 * n / ln 2 ≈ 11.5 * n. The required bandwidth then becomes 11.5 * n / 8 bytes, so approximately 1.44 bytes per file in the users share. For 20000 files, m should then be 230016 (taking into account the modulo 64 requirement), giving a p = 0.004, in other words ~99.6% of all searches that don’t match a users share would not be sent, saving valuable upload bandwidth for the hub. The client calculates i valid positions, if x is an array of bytes containing the hash of the file, on a little-endian machine, by doing pos = x[0+i*h/8] | (x[1+i*h/8] << 8) | (x[2+i*h/8] << 16) for i = [0;k). This is of course a special case where h % 8 = 0, the actual algorithm has to take into consideration values for h where the integer crosses byte boundaries.</p></div>
+<div class="paragraph"><p>For test vectors, see the <a href="http://www.adcportal.com/wiki/index.php/Talk:BLOM">ADC wiki talk page</a>.</p></div>
+</div>
+</div>
+</div>
+<div class="sect2">
+<h3 id="_natt_nat_traversal">3.9. NATT - NAT traversal</h3>
+<div class="paragraph"><p>NAT traversal allow two passive clients to connect to each other. This specification is based on the TCP hole punching algorithm described in <span class="footnote" id="_footnote_Peer-to-Peer Communication Across Network Address Translators"><br />[B. Ford and P. Srisuresh and and D. Kegel. "Peer-to-Peer Communication Across Network Address Translators". In USENIX Technical Conference 2005 - pages 179–192. Online version: <a href="http://www.brynosaurus.com/pub/net/p2pnat/">http://www.brynosaurus.com/pub/net/p2pnat/</a>]<br /></span>.</p></div>
+<div class="paragraph"><p>If a client does not support TCP4 or TCP6, it will send an RCM to the client it is trying to connect to. If the other client also doesn’t support TCP4 (or TCP6 correspondingly), NAT traversal may instead be used. Signal NATT in the INF’s SU field.</p></div>
+<div class="paragraph"><p>Do note that the hub must forward I4 or I6 for respective clients' INF.</p></div>
+<div class="paragraph"><p>An endpoint is the tuple of IP and port. The "private endpoint port" refers to the outbound port to the connected hub, as seen by the client. Each client must listen for incoming connections on this port. Note that this protocol extension uses only this port for the TCP hole punching, the use of the "public endpoint port" as specified in <span class="footnoteref"><br /><a href="#_footnote_Peer-to-Peer Communication Across Network Address Translators">[Peer-to-Peer Communication Across Network Address Translators]</a><br /></span> is not supported.</p></div>
+<div class="sect3">
+<h4 id="_base_rcm_updates">3.9.1. BASE RCM updates</h4>
+<div class="paragraph"><p>When receiving an RCM and the client does not support TCP4 or TCP6, and if NAT-T is supported in the remote client, a NAT command should be sent repeating the protocol and token. The port shall be the private endpoint port to the connected hub.</p></div>
+</div>
+<div class="sect3">
+<h4 id="_nat">3.9.2. NAT</h4>
+<div class="literalblock">
+<div class="content">
+<pre><code>NAT protocol separator port separator token</code></pre>
+</div></div>
+<div class="paragraph"><p>Contexts: T</p></div>
+<div class="paragraph"><p>States: NORMAL</p></div>
+<div class="paragraph"><p>Upon receiving this, try and connect to the specified port. An RNT command should be sent repeating the protocol and token. The port shall be the private endpoint. Upon receiving this, try and connect to the specified port.</p></div>
+</div>
+<div class="sect3">
+<h4 id="_rnt">3.9.3. RNT</h4>
+<div class="literalblock">
+<div class="content">
+<pre><code>RNT protocol separator port separator token</code></pre>
+</div></div>
+<div class="paragraph"><p>Contexts: T</p></div>
+<div class="paragraph"><p>States: NORMAL</p></div>
+<div class="paragraph"><p>Upon receiving this, try and connect to the specified port.</p></div>
+</div>
+<div class="sect3">
+<h4 id="_example_4">3.9.4. Example</h4>
+<div class="paragraph"><p>Client A is connected to hub A with the private endpoint 1000 and client B is connected to hub A with the private endpoint 2000. Client A has the SID AAAA and client B has the SID BBBB.</p></div>
+<div class="exampleblock">
+<div class="content">
+<div class="paragraph"><p>Client A: DRCM AAAA BBBB ADC/1.0 foobar</p></div>
+<div class="paragraph"><p>Client B: DNAT BBBB AAAA ADC/1.0 2000 foobar</p></div>
+<div class="paragraph"><p><Client A connects to client B’s IP address and port 2000></p></div>
+<div class="paragraph"><p>Client A: DRNT AAAA BBBB ADC/1.0 1000 foobar</p></div>
+<div class="paragraph"><p><Client B connects to client A’s IP address and port 1000></p></div>
+</div></div>
+</div>
+</div>
+<div class="sect2">
+<h3 id="_rf_referrer_notification">3.10. RF - Referrer notification</h3>
+<div class="paragraph"><p>Extends the RF field of the INF to STA, allowing a client to notify clients and hubs upon SUP-negotiation from where the C-C or C-H originated from.</p></div>
+<div class="tableblock">
+<table rules="all"
+frame="border"
+cellspacing="0" cellpadding="4">
+<col />
+<col />
+<tbody>
+<tr>
+<td align="left" valign="top"><p class="table">RF</p></td>
+<td align="left" valign="top"><p class="table">URL of referrer</p></td>
+</tr>
+</tbody>
+</table>
+</div>
+<div class="sect3">
+<h4 id="_example_5">3.10.1. Example</h4>
+<div class="exampleblock">
+<div class="content">
+<div class="paragraph"><p>CSUP ADBASE (…)</p></div>
+<div class="paragraph"><p>CSTA 000 referrer RFadc://example.com:1234</p></div>
+</div></div>
+</div>
+</div>
+<div class="sect2">
+<h3 id="_qp_upload_queue_notification">3.11. QP - Upload queue notification</h3>
+<div class="paragraph"><p>This extension’s purpose is creating a queue on a client, when multiple other clients want to download from it, but they have no slots. Currently, when a slot is being freed, the first connecting client gets it. Other clients that don’t have the luck of getting in time to attempt to download, have to wait again. The client who creates a queue must have a ticket number for each connecting client, which must be kept internally , and a difference between current connecting client’s queue number and the currently uploading client’s be provided to the connecting client, so that the clients are being deserved in the order they originally connected. The client could have a ticket incrementing starting from 1 for each session. Connecting clients must use the same token as they used when originally connected.</p></div>
+<div class="tableblock">
+<table rules="all"
+frame="border"
+cellspacing="0" cellpadding="4">
+<col />
+<col />
+<tbody>
+<tr>
+<td align="left" valign="top"><p class="table">QP</p></td>
+<td align="left" valign="top"><p class="table">Queue number, representing how many others are in front in the queue.</p></td>
+</tr>
+</tbody>
+</table>
+</div>
+<div class="sect3">
+<h4 id="_example_6">3.11.1. Example</h4>
+<div class="paragraph"><p>The following example will notify that the client’s slots are full and that there are three uploads in the queue.</p></div>
+<div class="exampleblock">
+<div class="content">
+<div class="paragraph"><p>CSTA 253 No\sslots\savailable QP3</p></div>
+</div></div>
+</div>
+</div>
+<div class="sect2">
+<h3 id="_pfsr_partial_file_sharing">3.12. PFSR - Partial file sharing</h3>
+<div class="paragraph"><p>Partial File Sharing allows sharing of files which are available in user’s download queue or in finished downloads list. As ...
[truncated message content] |
|
From: <ul...@us...> - 2014-02-11 21:28:04
|
Revision: 121
http://sourceforge.net/p/adc/code/121
Author: ullner
Date: 2014-02-11 21:27:46 +0000 (Tue, 11 Feb 2014)
Log Message:
-----------
Release of ADC-EXT.txt, now at 1.0.8
Modified Paths:
--------------
trunk/ADC-EXT.txt
Modified: trunk/ADC-EXT.txt
===================================================================
--- trunk/ADC-EXT.txt 2014-02-05 20:53:35 UTC (rev 120)
+++ trunk/ADC-EXT.txt 2014-02-11 21:27:46 UTC (rev 121)
@@ -1,5 +1,6 @@
= ADC Extensions
-1.0.8, UNRELEASED
+Fredrik Ullner, ul...@gm...
+1.0.8, February 2014
== Abstract
These are the official extensions to ADC. This document is based on the
@@ -13,7 +14,8 @@
This version corresponds to $Revision$.
-=== Version 1.0.8, UNRELEASED
+=== Version 1.0.8
+Fredrik Ullner <ul...@gm...>, 2014-02-11
* Improved 'NATT' documentation, as according to the original paper.
* Added 'ONID' extension to provide online service integration.
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
|
From: <ul...@us...> - 2014-02-05 20:53:39
|
Revision: 120
http://sourceforge.net/p/adc/code/120
Author: ullner
Date: 2014-02-05 20:53:35 +0000 (Wed, 05 Feb 2014)
Log Message:
-----------
Added TrackMania to ONID Services
Modified Paths:
--------------
trunk/ADC-ONIDServices.txt
Modified: trunk/ADC-ONIDServices.txt
===================================================================
--- trunk/ADC-ONIDServices.txt 2014-01-19 16:29:18 UTC (rev 119)
+++ trunk/ADC-ONIDServices.txt 2014-02-05 20:53:35 UTC (rev 120)
@@ -1,6 +1,5 @@
= ADC Recommendations
-Fredrik Ullner <ul...@gm...>
-1.0.0, June 2013
+1.0.1, UNRELEASED
== Abstract
These are the services for the ONID command. See ADC-Ext for the ONID specification.
@@ -13,8 +12,14 @@
This version corresponds to $Revision: 1 $.
=== Version 1.0.0
+Fredrik Ullner <ul...@gm...>
+
* Initial release
+=== Version 1.0.1, UNRELEASED
+
+* Added TrackMania
+
== Services
The service names are all case-insensitive. They are written here as lower-case.
@@ -116,4 +121,13 @@
|EM |The Yahoo! e-mail.
|=====
+=== TrackMania
+Service name: trackmania
+
+Required parameters:
+[options="autowidth"]
+|=====
+|NI |The TrackMania nick name.
+|=====
+
// vim: set syntax=asciidoc:
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
|
From: <ul...@us...> - 2014-01-19 16:29:22
|
Revision: 119
http://sourceforge.net/p/adc/code/119
Author: ullner
Date: 2014-01-19 16:29:18 +0000 (Sun, 19 Jan 2014)
Log Message:
-----------
Add Tiger and Merkle tree papers
Modified Paths:
--------------
trunk/ADC.txt
Added Paths:
-----------
trunk/Hashes/
trunk/Hashes/Tiger/
trunk/Hashes/Tiger/draft-jchapweske-thex-02.html
trunk/Hashes/Tiger/node1.html
trunk/Hashes/Tiger/node2.html
trunk/Hashes/Tiger/node3.html
trunk/Hashes/Tiger/node4.html
trunk/Hashes/Tiger/node5.html
trunk/Hashes/Tiger/node6.html
trunk/Hashes/Tiger/node7.html
trunk/Hashes/Tiger/node8.html
trunk/Hashes/Tiger/tiger.html
Modified: trunk/ADC.txt
===================================================================
--- trunk/ADC.txt 2014-01-19 16:27:04 UTC (rev 118)
+++ trunk/ADC.txt 2014-01-19 16:29:18 UTC (rev 119)
@@ -921,7 +921,7 @@
|=====
|Example |Description
|IQUI BBBB |A QUI that is sent from the hub indicating that the client BBBB has disconnected.
-|IQUI BBBB IDCCCC MSCats\sare\horrible DI1 TL-1 |A QUI that is sent from the hub indicating that the client BBBB has disconnected. The originator of the action is the client with the SID CCCC. The message "Cats are horrible" is included. All clients should terminate their connections with the client BBBB (DI1). The client should never attempt to reconnect (TL-1).
+|IQUI BBBB IDCCCC MSCats\sare\shorrible DI1 TL-1 |A QUI that is sent from the hub indicating that the client BBBB has disconnected. The originator of the action is the client with the SID CCCC. The message "Cats are horrible" is included. All clients should terminate their connections with the client BBBB (DI1). The client should never attempt to reconnect (TL-1).
|=====
==== GET
Added: trunk/Hashes/Tiger/draft-jchapweske-thex-02.html
===================================================================
--- trunk/Hashes/Tiger/draft-jchapweske-thex-02.html (rev 0)
+++ trunk/Hashes/Tiger/draft-jchapweske-thex-02.html 2014-01-19 16:29:18 UTC (rev 119)
@@ -0,0 +1,878 @@
+<html><head>
+
+<script type="text/javascript" src="/static/js/analytics.js" ></script>
+<link type="text/css" rel="stylesheet" href="/static/css/banner-styles.css"/>
+
+
+
+<title>Tree Hash EXchange format (THEX)</title>
+<meta http-equiv="Expires" content="Tue, 04 Mar 2003 22:41:32 +0000">
+<STYLE type='text/css'>
+ .title { color: #990000; font-size: 22px; line-height: 22px; font-weight: bold; text-align: right;
+ font-family: helvetica, arial, sans-serif }
+ .filename { color: #666666; font-size: 18px; line-height: 28px; font-weight: bold; text-align: right;
+ font-family: helvetica, arial, sans-serif }
+ p.copyright { color: #000000; font-size: 10px;
+ font-family: verdana, charcoal, helvetica, arial, sans-serif }
+ p { margin-left: 2em; margin-right: 2em; }
+ li { margin-left: 3em; }
+ ol { margin-left: 2em; margin-right: 2em; }
+ ul.text { margin-left: 2em; margin-right: 2em; }
+ pre { margin-left: 3em; color: #333333 }
+ ul.toc { color: #000000; line-height: 16px;
+ font-family: verdana, charcoal, helvetica, arial, sans-serif }
+ H3 { color: #333333; font-size: 16px; line-height: 16px; font-family: helvetica, arial, sans-serif }
+ H4 { color: #000000; font-size: 14px; font-family: helvetica, arial, sans-serif }
+ TD.header { color: #ffffff; font-size: 10px; font-family: arial, helvetica, san-serif; valign: top }
+ TD.author-text { color: #000000; font-size: 10px;
+ font-family: verdana, charcoal, helvetica, arial, sans-serif }
+ TD.author { color: #000000; font-weight: bold; margin-left: 4em; font-size: 10px; font-family: verdana, charcoal, helvetica, arial, sans-serif }
+ A:link { color: #990000; font-weight: bold;
+ font-family: MS Sans Serif, verdana, charcoal, helvetica, arial, sans-serif }
+ A:visited { color: #333333; font-weight: bold;
+ font-family: MS Sans Serif, verdana, charcoal, helvetica, arial, sans-serif }
+ A:name { color: #333333; font-weight: bold;
+ font-family: MS Sans Serif, verdana, charcoal, helvetica, arial, sans-serif }
+ .link2 { color:#ffffff; font-weight: bold; text-decoration: none;
+ font-family: monaco, charcoal, geneva, MS Sans Serif, helvetica, monotype, verdana, sans-serif;
+ font-size: 9px }
+ .RFC { color:#666666; font-weight: bold; text-decoration: none;
+ font-family: monaco, charcoal, geneva, MS Sans Serif, helvetica, monotype, verdana, sans-serif;
+ font-size: 9px }
+ .hotText { color:#ffffff; font-weight: normal; text-decoration: none;
+ font-family: charcoal, monaco, geneva, MS Sans Serif, helvetica, monotype, verdana, sans-serif;
+ font-size: 9px }
+</style>
+</head>
+<body bgcolor="#ffffff" text="#000000" alink="#000000" vlink="#666666" link="#990000">
+<!-- BEGIN WAYBACK TOOLBAR INSERT -->
+<script> if (window.archive_analytics) { window.archive_analytics.values['server_name']="wwwb-app19.us.archive.org";}; </script>
+
+<script type="text/javascript" src="/static/js/disclaim-element.js" ></script>
+<script type="text/javascript" src="/static/js/graph-calc.js" ></script>
+<script type="text/javascript" src="/static/jflot/jquery.min.js" ></script>
+<script type="text/javascript">
+//<![CDATA[
+var firstDate = 820454400000;
+var lastDate = 1420070399999;
+var wbPrefix = "/web/";
+var wbCurrentUrl = "http:\/\/www.open-content.net\/specs\/draft-jchapweske-thex-02.html";
+
+var curYear = -1;
+var curMonth = -1;
+var yearCount = 18;
+var firstYear = 1996;
+var imgWidth = 475;
+var yearImgWidth = 25;
+var monthImgWidth = 2;
+var trackerVal = "none";
+var displayDay = "16";
+var displayMonth = "mar";
+var displayYear = "2008";
+var prettyMonths = ["Jan","Feb","Mar","Apr","May","Jun","Jul","Aug","Sep","Oct","Nov","Dec"];
+
+function showTrackers(val) {
+ if(val == trackerVal) {
+ return;
+ }
+ if(val == "inline") {
+ document.getElementById("displayYearEl").style.color = "#ec008c";
+ document.getElementById("displayMonthEl").style.color = "#ec008c";
+ document.getElementById("displayDayEl").style.color = "#ec008c";
+ } else {
+ document.getElementById("displayYearEl").innerHTML = displayYear;
+ document.getElementById("displayYearEl").style.color = "#ff0";
+ document.getElementById("displayMonthEl").innerHTML = displayMonth;
+ document.getElementById("displayMonthEl").style.color = "#ff0";
+ document.getElementById("displayDayEl").innerHTML = displayDay;
+ document.getElementById("displayDayEl").style.color = "#ff0";
+ }
+ document.getElementById("wbMouseTrackYearImg").style.display = val;
+ document.getElementById("wbMouseTrackMonthImg").style.display = val;
+ trackerVal = val;
+}
+function getElementX2(obj) {
+ var thing = jQuery(obj);
+ if((thing == undefined)
+ || (typeof thing == "undefined")
+ || (typeof thing.offset == "undefined")) {
+ return getElementX(obj);
+ }
+ return Math.round(thing.offset().left);
+}
+function trackMouseMove(event,element) {
+
+ var eventX = getEventX(event);
+ var elementX = getElementX2(element);
+ var xOff = eventX - elementX;
+ if(xOff < 0) {
+ xOff = 0;
+ } else if(xOff > imgWidth) {
+ xOff = imgWidth;
+ }
+ var monthOff = xOff % yearImgWidth;
+
+ var year = Math.floor(xOff / yearImgWidth);
+ var yearStart = year * yearImgWidth;
+ var monthOfYear = Math.floor(monthOff / monthImgWidth);
+ if(monthOfYear > 11) {
+ monthOfYear = 11;
+ }
+ // 1 extra border pixel at the left edge of the year:
+ var month = (year * 12) + monthOfYear;
+ var day = 1;
+ if(monthOff % 2 == 1) {
+ day = 15;
+ }
+ var dateString =
+ zeroPad(year + firstYear) +
+ zeroPad(monthOfYear+1,2) +
+ zeroPad(day,2) + "000000";
+
+ var monthString = prettyMonths[monthOfYear];
+ document.getElementById("displayYearEl").innerHTML = year + 1996;
+ document.getElementById("displayMonthEl").innerHTML = monthString;
+ // looks too jarring when it changes..
+ //document.getElementById("displayDayEl").innerHTML = zeroPad(day,2);
+
+ var url = wbPrefix + dateString + '/' + wbCurrentUrl;
+ document.getElementById('wm-graph-anchor').href = url;
+
+ //document.getElementById("wmtbURL").value="evX("+eventX+") elX("+elementX+") xO("+xOff+") y("+year+") m("+month+") monthOff("+monthOff+") DS("+dateString+") Moy("+monthOfYear+") ms("+monthString+")";
+ if(curYear != year) {
+ var yrOff = year * yearImgWidth;
+ document.getElementById("wbMouseTrackYearImg").style.left = yrOff + "px";
+ curYear = year;
+ }
+ if(curMonth != month) {
+ var mtOff = year + (month * monthImgWidth) + 1;
+ document.getElementById("wbMouseTrackMonthImg").style.left = mtOff + "px";
+ curMonth = month;
+ }
+}
+//]]>
+</script>
+
+<style type="text/css">body{margin-top:0!important;padding-top:0!important;min-width:800px!important;}#wm-ipp a:hover{text-decoration:underline!important;}</style>
+<div id="wm-ipp" lang="en" class="__wb_banner_div" style="display:none; position:relative;padding:0 5px;min-height:70px;min-width:800px">
+
+
+<div id="wm-ipp-inside" class="__wb_banner_div" style="position:fixed;padding:0!important;margin:0!important;width:97%;min-width:780px;border:5px solid #000;border-top:none;background-image:url(/static/images/toolbar/wm_tb_bk_trns.png);text-align:center;-moz-box-shadow:1px 1px 3px #333;-webkit-box-shadow:1px 1px 3px #333;box-shadow:1px 1px 3px #333;font-size:11px!important;font-family:'Lucida Grande','Arial',sans-serif!important;">
+ <table style="border-collapse:collapse;margin:0;padding:0;width:100%;"><tbody><tr>
+ <td style="padding:10px;vertical-align:top;min-width:110px;">
+ <a href="/web/" title="Wayback Machine home page" style="background-color:transparent;border:none;"><img src="/static/images/toolbar/wayback-toolbar-logo.png" alt="Wayback Machine" width="110" height="39" border="0"/></a>
+ </td>
+ <td style="padding:0!important;text-align:center;vertical-align:top;width:100%;">
+
+ <table style="border-collapse:collapse;margin:0 auto;padding:0;width:570px;"><tbody><tr>
+ <td style="padding:3px 0;" colspan="2">
+ <form target="_top" method="get" action="/web/form-submit.jsp" name="wmtb" id="wmtb" style="margin:0!important;padding:0!important;"><input type="text" name="url" id="wmtbURL" value="http://www.open-content.net/specs/draft-jchapweske-thex-02.html" style="width:400px;font-size:11px;font-family:'Lucida Grande','Arial',sans-serif;" onfocus="javascript:this.focus();this.select();" /><input type="hidden" name="type" value="replay" /><input type="hidden" name="date" value="20080316033726" /><input type="submit" value="Go" style="font-size:11px;font-family:'Lucida Grande','Arial',sans-serif;margin-left:5px;width: inherit !important" /><span id="wm_tb_options" style="display:block;"></span></form>
+ </td>
+ <td style="vertical-align:bottom;padding:5px 0 0 0!important;" rowspan="2">
+ <table style="border-collapse:collapse;width:110px;color:#99a;font-family:'Helvetica','Lucida Grande','Arial',sans-serif;"><tbody>
+
+ <!-- NEXT/PREV MONTH NAV AND MONTH INDICATOR -->
+ <tr style="width:110px;height:16px;font-size:10px!important;">
+ <td style="padding-right:9px;font-size:11px!important;font-weight:bold;text-transform:uppercase;text-align:right;white-space:nowrap;overflow:visible;" nowrap="nowrap">
+
+ <a href="/web/20080214024543/http://open-content.net/specs/draft-jchapweske-thex-02.html" style="text-decoration:none;color:#33f;font-weight:bold;background-color:transparent;border:none;" title="14 feb 2008"><strong>FEB</strong></a>
+
+ </td>
+ <td id="displayMonthEl" style="background:#000;color:#ff0;font-size:11px!important;font-weight:bold;text-transform:uppercase;width:34px;height:15px;padding-top:1px;text-align:center;" title="You are here: 3:37:26 mar 16, 2008">MAR</td>
+ <td style="padding-left:9px;font-size:11px!important;font-weight:bold;text-transform:uppercase;white-space:nowrap;overflow:visible;" nowrap="nowrap">
+
+ <a href="/web/20080517043137/http://open-content.net/specs/draft-jchapweske-thex-02.html" style="text-decoration:none;color:#33f;font-weight:bold;background-color:transparent;border:none;" title="17 maj 2008"><strong>MAJ</strong></a>
+
+ </td>
+ </tr>
+
+ <!-- NEXT/PREV CAPTURE NAV AND DAY OF MONTH INDICATOR -->
+ <tr>
+ <td style="padding-right:9px;white-space:nowrap;overflow:visible;text-align:right!important;vertical-align:middle!important;" nowrap="nowrap">
+
+ <a href="/web/20080302051813/http://open-content.net/specs/draft-jchapweske-thex-02.html" title="5:18:13 mar 2, 2008" style="background-color:transparent;border:none;"><img src="/static/images/toolbar/wm_tb_prv_on.png" alt="Previous capture" width="14" height="16" border="0" /></a>
+
+ </td>
+ <td id="displayDayEl" style="background:#000;color:#ff0;width:34px;height:24px;padding:2px 0 0 0;text-align:center;font-size:24px;font-weight: bold;" title="You are here: 3:37:26 mar 16, 2008">16</td>
+ <td style="padding-left:9px;white-space:nowrap;overflow:visible;text-align:left!important;vertical-align:middle!important;" nowrap="nowrap">
+
+ <a href="/web/20080517043137/http://open-content.net/specs/draft-jchapweske-thex-02.html" title="4:31:37 maj 17, 2008" style="background-color:transparent;border:none;"><img src="/static/images/toolbar/wm_tb_nxt_on.png" alt="Next capture" width="14" height="16" border="0"/></a>
+
+ </td>
+ </tr>
+
+ <!-- NEXT/PREV YEAR NAV AND YEAR INDICATOR -->
+ <tr style="width:110px;height:13px;font-size:9px!important;">
+ <td style="padding-right:9px;font-size:11px!important;font-weight: bold;text-align:right;white-space:nowrap;overflow:visible;" nowrap="nowrap">
+
+ <a href="/web/20070310031709/http://www.open-content.net/specs/draft-jchapweske-thex-02.html" style="text-decoration:none;color:#33f;font-weight:bold;background-color:transparent;border:none;" title="10 mar 2007"><strong>2007</strong></a>
+
+ </td>
+ <td id="displayYearEl" style="background:#000;color:#ff0;font-size:11px!important;font-weight: bold;padding-top:1px;width:34px;height:13px;text-align:center;" title="You are here: 3:37:26 mar 16, 2008">2008</td>
+ <td style="padding-left:9px;font-size:11px!important;font-weight: bold;white-space:nowrap;overflow:visible;" nowrap="nowrap">
+
+ <a href="/web/20090415152844/http://www.open-content.net/specs/draft-jchapweske-thex-02.html" style="text-decoration:none;color:#33f;font-weight:bold;background-color:transparent;border:none;" title="15 apr 2009"><strong>2009</strong></a>
+
+ </td>
+ </tr>
+ </tbody></table>
+ </td>
+
+ </tr>
+ <tr>
+ <td style="vertical-align:middle;padding:0!important;">
+ <a href="/web/20080316033726*/http://www.open-content.net/specs/draft-jchapweske-thex-02.html" style="color:#33f;font-size:11px;font-weight:bold;background-color:transparent;border:none;" title="See a list of every capture for this URL"><strong>99 captures</strong></a>
+ <div class="__wb_banner_div" style="margin:0!important;padding:0!important;color:#666;font-size:9px;padding-top:2px!important;white-space:nowrap;" title="Timespan for captures of this URL">13 apr 03 - 28 jun 13</div>
+ </td>
+ <td style="padding:0!important;">
+ <a style="position:relative; white-space:nowrap; width:475px;height:27px;" href="" id="wm-graph-anchor">
+ <div class="__wb_banner_div" id="wm-ipp-sparkline" style="position:relative; white-space:nowrap; width:475px;height:27px;background-color:#fff;cursor:pointer;border-right:1px solid #ccc;" title="Explore captures for this URL">
+ <img id="sparklineImgId" style="position:absolute; z-index:9012; top:0px; left:0px;"
+ onmouseover="showTrackers('inline');"
+ onmouseout="showTrackers('none');"
+ onmousemove="trackMouseMove(event,this)"
+ alt="sparklines"
+ width="475"
+ height="27"
+ border="0"
+ src="/web/jsp/graph.jsp?graphdata=475_27_1996:-1:000000000000_1997:-1:000000000000_1998:-1:000000000000_1999:-1:000000000000_2000:-1:000000000000_2001:-1:000000000000_2002:-1:000000000000_2003:-1:000101000101_2004:-1:010100011201_2005:-1:222102141122_2006:-1:310301140001_2007:-1:023021303311_2008:2:112010001102_2009:-1:111110010001_2010:-1:000000000000_2011:-1:000000202020_2012:-1:110100100010_2013:-1:003302000000_2014:-1:000000000000"></img>
+ <img id="wbMouseTrackYearImg"
+ style="display:none; position:absolute; z-index:9010;"
+ width="25"
+ height="27"
+ border="0"
+ src="/static/images/toolbar/transp-yellow-pixel.png"></img>
+ <img id="wbMouseTrackMonthImg"
+ style="display:none; position:absolute; z-index:9011; "
+ width="2"
+ height="27"
+ border="0"
+ src="/static/images/toolbar/transp-red-pixel.png"></img>
+ </div>
+ </a>
+
+ </td>
+ </tr></tbody></table>
+ </td>
+ <td style="text-align:right;padding:5px;width:65px;font-size:11px!important;">
+ <a href="javascript:;" onclick="document.getElementById('wm-ipp').style.display='none';" style="display:block;padding-right:18px;background:url(/static/images/toolbar/wm_tb_close.png) no-repeat 100% 0;color:#33f;font-family:'Lucida Grande','Arial',sans-serif;margin-bottom:23px;background-color:transparent;border:none;" title="Close the toolbar">Close</a>
+ <a href="http://faq.web.archive.org/" style="display:block;padding-right:18px;background:url(/static/images/toolbar/wm_tb_help.png) no-repeat 100% 0;color:#33f;font-family:'Lucida Grande','Arial',sans-serif;background-color:transparent;border:none;" title="Get some help using the Wayback Machine">Help</a>
+ </td>
+ </tr></tbody></table>
+
+</div>
+</div>
+<script type="text/javascript">
+ var wmDisclaimBanner = document.getElementById("wm-ipp");
+ if(wmDisclaimBanner != null) {
+ disclaimElement(wmDisclaimBanner);
+ }
+</script>
+<!-- END WAYBACK TOOLBAR INSERT -->
+
+<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="/web/20080316033726/http://www.open-content.net/specs/draft-jchapweske-thex-02.html#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table>
+<table width="66%" border="0" cellpadding="0" cellspacing="0"><tr><td><table width="100%" border="0" cellpadding="2" cellspacing="1">
+<tr valign="top"><td width="33%" bgcolor="#666666" class="header"> </td><td width="33%" bgcolor="#666666" class="header">J. Chapweske</td></tr>
+<tr valign="top"><td width="33%" bgcolor="#666666" class="header"> </td><td width="33%" bgcolor="#666666" class="header">Onion Networks, Inc.</td></tr>
+<tr valign="top"><td width="33%" bgcolor="#666666" class="header"> </td><td width="33%" bgcolor="#666666" class="header">G. Mohr</td></tr>
+<tr valign="top"><td width="33%" bgcolor="#666666" class="header"> </td><td width="33%" bgcolor="#666666" class="header">Bitzi, Inc.</td></tr>
+<tr valign="top"><td width="33%" bgcolor="#666666" class="header"> </td><td width="33%" bgcolor="#666666" class="header">March 4, 2003</td></tr>
+</table></td></tr></table>
+<div align="right"><font face="monaco, MS Sans Serif" color="#990000" size="+3"><b><br><span class="title">Tree Hash EXchange format (THEX)</span></b></font></div>
+<font face="verdana, helvetica, arial, sans-serif" size="2">
+
+<h3>Abstract</h3>
+
+<p>
+This memo presents the Tree Hash Exchange (THEX) format, for
+exchanging Merkle Hash Trees built up from the subrange hashes of discrete
+digital files. Such tree hash data structures assist in file integrity
+verification, allowing arbitrary subranges of bytes to be verified before the
+entire file has been received.
+</p>
+<a name="toc"><br><hr size="1" shade="0"></a>
+<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="/web/20080316033726/http://www.open-content.net/specs/draft-jchapweske-thex-02.html#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table>
+<h3>Table of Contents</h3>
+<ul compact class="toc">
+<b><a href="/web/20080316033726/http://www.open-content.net/specs/draft-jchapweske-thex-02.html#anchor1">1.</a>
+Introduction<br></b>
+<b><a href="/web/20080316033726/http://www.open-content.net/specs/draft-jchapweske-thex-02.html#anchor2">2.</a>
+Merkle Hash Trees<br></b>
+<b><a href="/web/20080316033726/http://www.open-content.net/specs/draft-jchapweske-thex-02.html#anchor3">2.1</a>
+Hash Functions<br></b>
+<b><a href="/web/20080316033726/http://www.open-content.net/specs/draft-jchapweske-thex-02.html#anchor4">2.2</a>
+Unbalanced Trees<br></b>
+<b><a href="/web/20080316033726/http://www.open-content.net/specs/draft-jchapweske-thex-02.html#choice_of_segment_size">2.3</a>
+Choice Of Segment Size<br></b>
+<b><a href="/web/20080316033726/http://www.open-content.net/specs/draft-jchapweske-thex-02.html#anchor5">3.</a>
+Serialization Format<br></b>
+<b><a href="/web/20080316033726/http://www.open-content.net/specs/draft-jchapweske-thex-02.html#anchor6">3.1</a>
+DIME Encapsulation<br></b>
+<b><a href="/web/20080316033726/http://www.open-content.net/specs/draft-jchapweske-thex-02.html#anchor7">3.2</a>
+XML Tree Description<br></b>
+<b><a href="/web/20080316033726/http://www.open-content.net/specs/draft-jchapweske-thex-02.html#anchor8">3.2.1</a>
+File Size<br></b>
+<b><a href="/web/20080316033726/http://www.open-content.net/specs/draft-jchapweske-thex-02.html#anchor9">3.2.2</a>
+File Segment Size<br></b>
+<b><a href="/web/20080316033726/http://www.open-content.net/specs/draft-jchapweske-thex-02.html#anchor10">3.2.3</a>
+Digest Algorithm<br></b>
+<b><a href="/web/20080316033726/http://www.open-content.net/specs/draft-jchapweske-thex-02.html#anchor11">3.2.4</a>
+Digest Output Size<br></b>
+<b><a href="/web/20080316033726/http://www.open-content.net/specs/draft-jchapweske-thex-02.html#anchor12">3.2.5</a>
+Serialized Tree Depth<br></b>
+<b><a href="/web/20080316033726/http://www.open-content.net/specs/draft-jchapweske-thex-02.html#anchor13">3.2.6</a>
+Serialized Tree Type<br></b>
+<b><a href="/web/20080316033726/http://www.open-content.net/specs/draft-jchapweske-thex-02.html#anchor14">3.2.7</a>
+Serialized Tree URI<br></b>
+<b><a href="/web/20080316033726/http://www.open-content.net/specs/draft-jchapweske-thex-02.html#anchor15">3.3</a>
+Breadth-First Serialization<br></b>
+<b><a href="/web/20080316033726/http://www.open-content.net/specs/draft-jchapweske-thex-02.html#anchor16">3.3.1</a>
+Serialization Type URI<br></b>
+<b><a href="/web/20080316033726/http://www.open-content.net/specs/draft-jchapweske-thex-02.html#rfc.authors">§</a>
+Authors' Addresses<br></b>
+<b><a href="/web/20080316033726/http://www.open-content.net/specs/draft-jchapweske-thex-02.html#anchor17">A.</a>
+Test Vectors<br></b>
+</ul>
+<br clear="all">
+
+<a name="anchor1"><br><hr size="1" shade="0"></a>
+<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="/web/20080316033726/http://www.open-content.net/specs/draft-jchapweske-thex-02.html#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table>
+<a name="rfc.section.1"></a><h3>1. Introduction</h3>
+
+<p>
+The Merkle Hash Tree, invented by Ralph Merkle, is a hash construct that
+exhibits desirable properties for verifying the integrity of files and file subranges
+in an incremental or out-of-order fashion. This document describes a binary
+serialization format for hash trees that is compact and optimized for both
+sequential and random access.
+This memo has two goals:
+
+<ol class="text">
+
+<li>
+To describe Merkle Hash Trees and how they are used for file integrity
+verification.
+</li>
+
+<li>
+To describe a serialization format for storage and transmission of hash
+trees.
+</li>
+
+</ol>
+<p>
+
+</p>
+
+<a name="anchor2"><br><hr size="1" shade="0"></a>
+<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="/web/20080316033726/http://www.open-content.net/specs/draft-jchapweske-thex-02.html#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table>
+<a name="rfc.section.2"></a><h3>2. Merkle Hash Trees</h3>
+
+<p>
+
+It is common practice in distributed systems to use secure hash algorithms to
+verify the integrity of content. The employment of secure hash algorithms
+enables systems to retreive content from completely untrusted hosts with only
+a small amount of trusted metadata.
+
+</p>
+
+<p>
+
+Typically, algorithms such as SHA-1 and MD5 have been used to check the content
+integrity after retrieving the entire file. These full file hash techniques
+work fine in an environment where the content is received from a single host
+and there are no streaming requirements. However, there are an increasing
+number of systems that retrieve a single piece of content from multiple
+untrusted hosts, and require content verification well in advance of retrieving
+the entire file.
+
+</p>
+
+<p>
+
+Many modern peer-to-peer content delivery systems employ fixed size "block
+hashes" to provide a finer level of granularity in their integrity checking.
+This approach is still limited in the verification resolution it can attain.
+Additionally, all of the hash information must be retrieved from a trusted host,
+which can limit the scalability and reliability of the system.
+
+</p>
+
+<p>
+
+Another way to verify content is to use the hash tree approach. This approach
+has the desired characteristics missing from the full file hash approach and
+works well for very large files. The idea is to break the file up into a number
+of small pieces, hash those pieces, and then iteratively combine and rehash the
+resulting hashes in a tree-like fashion until a single "root hash" is created.
+
+</p>
+
+<p>
+
+The root hash by itself behaves exactly the same way that full file hashes do.
+If the root hash is retrieved from a trusted source, it can be used to verify
+the integrity of the entire content. More importantly, the root hash can be
+combined with a small number of other hashes to verify the integrity of any of
+the file segments.
+
+<p>
+
+For example, consider a file made up of four segments,
+S1, S2, S3, and S4. Let H() be the hash function, and '+'
+indicate concatenation. You could take the traditional
+hash value:
+
+</p>
+</font><pre>
+ VALUE=H(S1+S2+S3+S4)
+</pre><font face="verdana, helvetica, arial, sans-serif" size="2">
+
+<p>
+
+Or, you could employ a tree approach. The tree hash utilizes two hash algorithms - one for leaf hashes and one for internal hashes. Let LH() be the leaf hash function and IH() be the internal hash function:
+
+</p>
+</font><pre>
+
+ ROOT=IH(E+F)
+ / \
+ / \
+ E=IH(A+B) F=IH(C+D)
+ / \ / \
+ / \ / \
+ A=LH(S1) B=LH(S2) C=LH(S3) D=LH(S4)
+
+</pre><font face="verdana, helvetica, arial, sans-serif" size="2">
+
+<p>
+
+Now, assuming that the ROOT is retrieved from a trusted source, the integrity
+of a file segment coming from an untrusted source can be checked with a small
+amount of hash data. For instance, if S1 is received from an untrusted host,
+the integrity of S1 can be verified with just B and F.
+
+With these, it can be verified that, yes: S1 can be combined up to
+equal the ROOT hash, even without seeing the other
+segments. (It is just as impractical to create falsified values
+of B and F as it is to manipulate any good hash function to
+give desired results -- so B and F can come from untrusted sources
+as well.)
+
+Similarly, if some other untrusted source provides segments
+S3 and S4, their integrity can be easily checked when combined with hash E.
+From segments S3 and S4, the values of C and D and then F can be calculated.
+
+With these, you can verify that S3 and S4 can combine up
+to create the ROOT -- even if other sources are providing bogus S1 and S2
+segments. Bad info can be immediately recognized and discarded, and
+good info retained, even in situations where you could not even begin
+to calculate a traditional full-file hash.
+
+</p>
+
+</p>
+
+<p>
+
+Another interesting property of the tree approach is that it can be used to
+verify (tree-aligned) subranges whose size is any multiple of the base segment
+size.
+
+</p>
+
+<p>
+Consider for example an initial segment size of 1,024 bytes, and
+a file of 32GB. You could verify a single 1,024-byte block, with
+about 25 proof-assist values, or a block of size 16GB, with a single
+proof-assist value -- or anything in between.
+
+</p>
+
+<a name="rfc.section.2.1"></a><h4><a name="anchor3">2.1</a> Hash Functions</h4>
+
+<p>
+
+The strength of the hash tree construct is only as strong as the underlying hash algorithm. Thus, it is RECOMMENDED that a secure hash algorithm such as SHA-1 be used as the basis of the hash tree.
+
+</p>
+
+<p>
+
+In order to protect against collisions between leaf hashes and internal hashes, different hash constructs are used to hash the leaf nodes and the internal nodes. The same hash algorithm is used as the basis of each construct, but a single '1' byte in network byte order, or 0x01 is prepended to the input of the internal node hashes, and a single '0' byte, or 0x00 is prepended to the input of the leaf node hashes.
+
+</p>
+
+<p>
+
+<p>
+
+Let H() be the secure hash algorithm, for example SHA-1.
+
+</p>
+</font><pre>
+internal hash function = IH(X) = H(0x01, X)
+
+leaf hash function = LH(X) = H(0x00, X)
+</pre><font face="verdana, helvetica, arial, sans-serif" size="2">
+
+</p>
+
+<a name="rfc.section.2.2"></a><h4><a name="anchor4">2.2</a> Unbalanced Trees</h4>
+
+<p>
+
+For trees that are unbalanced -- that is, they have a number of leaves which
+is not a power of 2 -- interim hash values which do not have a sibling value
+to which they may be concatenated are promoted, unchanged, up the tree until
+a sibling is found.
+
+<p>
+
+For example, consider a file made up of 5 segments, S1, S2, S3, S4, and S5.
+
+</p>
+</font><pre>
+ ROOT=IH(H+E)
+ / \
+ / \
+ H=IH(F+G) E
+ / \ \
+ / \ \
+ F=IH(A+B) G=IH(C+D) E
+ / \ / \ \
+ / \ / \ \
+ A=LH(S1) B=LH(S2) C=LH(S3) D=LH(S4) E=LH(S5)
+
+</pre><font face="verdana, helvetica, arial, sans-serif" size="2">
+
+<p>
+
+In the above example, E does not have any immediate siblings with which
+to be combined to calculate the next generation. So, E is promoted up
+the tree, without being rehashed, until it can be paired with value H.
+The values H and E are then concatenated, and hashed, to produce the
+ROOT hash.
+
+</p>
+
+</p>
+
+<a name="rfc.section.2.3"></a><h4><a name="choice_of_segment_size">2.3</a> Choice Of Segment Size</h4>
+
+<p>
+ Any segment size is possible, but the choice of base segment
+size establishes the smallest possible unit of verification.
+</p>
+
+<p>
+If the the segment size is equal to or larger than the file to be hashed, the
+tree hash value is the value of the single segment's value, which is
+the same as the underlying hash algorithm value for the whole file.
+</p>
+
+<p>
+A segment size equal to the digest algorithm output size would
+more than double the total amount of data to be hashed, and thus more
+than double the time required to calculate the tree hash structure, as
+compared to a simple full-file hash. However, once the segment size
+reaches several multiples of the digest size, calculating the tree
+adds only a small fractional time overhead beyond what a traditional
+full-file hash would cost.
+
+</p>
+
+<p>
+Otherwise, smaller segments are better. Smaller segments allow, but
+do not require, the retention and use of fine-grained verification info,
+(A stack-based tree calculation procedure need never retain more
+than one pending internal node value per generation before it can be
+combined with a sibling, and all interim values below a certain
+generation size of interest can be discarded.) Further, it is
+beneficial for multiple application domains and even files of wildly
+different sizes to share the same base segment size, so that tree
+structures can be shared and used to discover correlated subranges.
+
+</p>
+
+<p>
+Thus the authors recommend a segment size of 1,024 bytes for most
+applications, as a sort of "smallest common denominator", even for
+applications involving multi-gigabyte or terabyte files. This segment
+size is 40-50 times larger than common secure hash digest lengths
+(20-24 bytes), and thus adds no more than 5-10% in running time as
+compared to the "infinite segment" size case -- the traditional
+full-file hash.
+
+</p>
+
+<p>
+Considering a 1 terabyte file, the maximum dynamic
+state required during the calculation of the tree root value is
+29 interim node values -- less than 1KB assuming a 20-byte digest
+algorithm like SHA-1. Only interim values in generations of
+interest for range verification need to be remembered for tree
+exchange, so if only 8GB ranges ever need to be verified, all
+but the top 8 generations of internal values (255 hashes) can
+be discarded.
+
+</p>
+
+<a name="anchor5"><br><hr size="1" shade="0"></a>
+<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="/web/20080316033726/http://www.open-content.net/specs/draft-jchapweske-thex-02.html#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table>
+<a name="rfc.section.3"></a><h3>3. Serialization Format</h3>
+
+<p>
+
+This section presents a serialization format for Merkle Hash Trees that utilizes the Direct Internet Message Encapsulation (DIME) format. DIME is a generic message format that allows for multiple payloads, either text or binary. The Merkle Hash Tree serialization format consists of two different payloads. The first is XML encoded meta-data about the hash tree, and the second is binary serialization of the tree itself. The binary serialization is required for two important reasons:
+
+<ol class="text">
+
+<li>
+
+Compactness of Representation - A key virtue of the hash tree approach is that it provides considerable integrity checking power with a relatively small amount of data. A typical hash tree consists of a large number of small hashes. Thus a text encoding, such as XML, could easily double the storage and transmission requirements of the hash tree, negating one of its key benefits.
+
+</li>
+
+<li>
+
+Random Access - In order to take full advantage of the hash tree construct, it is often necessary to read the elements of the hash tree in a random access fashion. A common usage of this serialization format will be to access hash data over the HTTP protocol using "Range Requests". This will allow implementors to retrieve small bits of hash information on-demand, even requesting different parts of the tree from different hosts on the network.
+
+</li>
+
+</ol>
+<p>
+
+</p>
+
+<a name="rfc.section.3.1"></a><h4><a name="anchor6">3.1</a> DIME Encapsulation</h4>
+
+<p>
+
+It is RECOMMENDED that DIME be used to encapsulate the payloads described in this specification. The current version of DIME is "draft-nielsen-dime-01" at (http://gotdotnet.com/team/xml_wsspecs/dime/default.aspx).
+
+</p>
+
+<p>
+
+It is RECOMMENDED that the first payload in the DIME Message be the XML
+Tree Description. The XML Tree description payload MUST be before the the
+binary serialized tree.
+
+</p>
+
+<p>
+
+It is RECOMMENDED that the binary serialized tree be stored in a single
+payload rather than using chunked payloads. This will allow implementations
+to read the tree hash data in a random access fashion within the payload.
+
+</p>
+
+<a name="rfc.section.3.2"></a><h4><a name="anchor7">3.2</a> XML Tree Description</h4>
+
+<p>
+
+The XML Tree Description contains metadata about the hash tree and file that is
+necessary to interpret the binary serialized tree. An important consideration in the design of THEX is the intention for it to be received from untrusted sources within a distributed network. The only information that needs to be obtained from a trusted source is the root hash and the segment size. The root hash by itself can be used to verify the integrity of the serialized tree and of the file itself.
+
+</p>
+
+<p>
+
+It is RECOMMENDED that implementers assume that the serialized file was obtained from an untrusted source, thus the use of this format to store non-verifiable information, such as general file metadata, is highly discouraged. For instance, a malicious party could easily forge metadata, such as the author or file name.
+
+</p>
+
+<p>
+</font><pre>
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE hashtree system "http://open-content.net/spec/thex/thex.dtd">
+<hashtree>
+ <file size='1146045066' segmentsize='1024'/>
+ <digest algorithm='http://www.w3.org/2000/09/xmldsig#sha1'
+ outputsize='20'/>
+ <serializedtree depth='22'
+ type='http://open-content.net/spec/thex/breadthfirst'
+ uri='uuid:09233523-345b-4351-b623-5dsf35sgs5d6'/>
+</hashtree>
+</pre><font face="verdana, helvetica, arial, sans-serif" size="2">
+
+</p>
+
+<a name="rfc.section.3.2.1"></a><h4><a name="anchor8">3.2.1</a> File Size</h4>
+
+<p>
+
+The file size attribute refers to the size, in bytes, of the file that the
+hash tree was generated from.
+
+</p>
+
+<a name="rfc.section.3.2.2"></a><h4><a name="anchor9">3.2.2</a> File Segment Size</h4>
+
+<p>
+
+The file segment size identifies the size, in bytes, of the file segments that were used to create the hash tree. As noted in <a href="/web/20080316033726/http://www.open-content.net/specs/draft-jchapweske-thex-02.html#choice_of_segment_size">Choice Of Segment Size</a>, it is recommended that applications use a small, common segment size such as 1,024 bytes in order to retain maximum flexibility and interoperability.
+
+</p>
+
+<a name="rfc.section.3.2.3"></a><h4><a name="anchor10">3.2.3</a> Digest Algorithm</h4>
+
+<p>
+
+This attribute provides the identifier URI for the digest algorithm. A URI is used here as an identifier instead of a regular string to avoid the overhead of IANA-style registration. By using URIs, new types can be created without having to consult any other entity. The URIs are only to be used for type identification purposes, but it is RECOMMENDED that the URIs point to information about the given digest function. This convention is inspired by RFC 3275, the XML Signature Specification.
+For instance, the SHA-1 algorithm is identified by "http://www.w3.org/2000/09/xmldsig#sha1". All digest algorithms defined in RFC 3275 are supported. The Tiger algorithm is also supported and is identified by "http://open-content.net/spec/digest/tiger".
+
+</p>
+
+<a name="rfc.section.3.2.4"></a><h4><a name="anchor11">3.2.4</a> Digest Output Size</h4>
+
+<p>
+
+This attribute specifies the size of the output of the hash function, in bytes.
+
+</p>
+
+<a name="rfc.section.3.2.5"></a><h4><a name="anchor12">3.2.5</a> Serialized Tree Depth</h4>
+
+<p>
+
+This attribute specifies the number of levels of the tree that have been serialized. This value allows control over the amount of storage space required by the serialized tree. In general, each row added to the tree will double the storage requirements while also doubling the verification resolution.
+
+</p>
+
+<a name="rfc.section.3.2.6"></a><h4><a name="anchor13">3.2.6</a> Serialized Tree Type</h4>
+
+<p>
+
+This attribute provides the identifier URI for the serialization type. Just as with the Digest Algorithm, new serialization types can be added and described without going through a formal IANA-style process. One serialization type is defined for "Breadth-First Serialization" later in this document.
+
+</p>
+
+<a name="rfc.section.3.2.7"></a><h4><a name="anchor14">3.2.7</a> Serialized Tree URI</h4>
+
+<p>
+
+This attribute provides the URI of the binary serialized tree payload. If used within a DIME payload, it is recommended that this URI be location independant, such as the "uuid:" URI's used in the SOAP in DIME specification or SHA-1 URNs.
+
+</p>
+
+<a name="rfc.section.3.3"></a><h4><a name="anchor15">3.3</a> Breadth-First Serialization</h4>
+
+<p>
+
+Normal breadth-first serialization is the recommended manner in which to serialize the hash tree. This format includes the root hash first, and then each "row" of hashes is serialized until the tree has been serialized to the lowest level as specified by the "Serialized Tree Depth" field.
+
+<p>
+
+For example, consider a file made up of 5 segments, S1, S2, S3, S4, and S5.
+
+</p>
+</font><pre>
+ ROOT=IH(H+E)
+ / \
+ / \
+ H=IH(F+G) E
+ / \ \
+ / \ \
+ F=IH(A+B) G=IH(C+D) E
+ / \ / \ \
+ / \ / \ \
+ A=LH(S1) B=LH(S2) C=LH(S3) D=LH(S4) E=LH(S5)
+</pre><font face="verdana, helvetica, arial, sans-serif" size="2">
+
+<p>
+
+The hashes would be serialized in the following order: ROOT, H, E, F, G, E, A, B, C, D, E. Notice that E is serialized as a part of the each row. This is due to its promotion as there are no available siblings in the lower rows. If we choose to serialize the entire tree, the serialized tree depth would be 4, and for a 20 byte digest output, the entire tree payload would occupy 11*20 = 220 bytes.
+
+</p>
+
+</p>
+
+<a name="rfc.section.3.3.1"></a><h4><a name="anchor16">3.3.1</a> Serialization Type URI</h4>
+
+<p>
+
+The serialization type URI for a Merkle Hash Tree serialized in normal breadth-first form is "http://open-content.net/spec/thex/breadthfirst".
+
+</p>
+
+<a name="rfc.authors"><br><hr size="1" shade="0"></a>
+<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="/web/20080316033726/http://www.open-content.net/specs/draft-jchapweske-thex-02.html#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table>
+<h3>Authors' Addresses</h3>
+<table width="99%" border="0" cellpadding="0" cellspacing="0">
+<tr><td class="author-text"> </td>
+<td class="author-text">Justin Chapweske</td></tr>
+<tr><td class="author-text"> </td>
+<td class="author-text">Onion Networks, Inc.</td></tr>
+<tr><td class="author-text"> </td>
+<td class="author-text">1668 Rosehill Circle</td></tr>
+<tr><td class="author-text"> </td>
+<td class="author-text">Lauderdale, MN 55108</td></tr>
+<tr><td class="author-text"> </td>
+<td class="author-text">US</td></tr>
+<tr><td class="author" align="right">EMail: </td>
+<td class="author-text"><a href="mailto:ju...@on...">ju...@on...</a></td></tr>
+<tr><td class="author" align="right">URI: </td>
+<td class="author-text"><a href="/web/20080316033726/http://onionnetworks.com/">http://onionnetworks.com/</a></td></tr>
+<tr cellpadding="3"><td> </td><td> </td></tr>
+<tr><td class="author-text"> </td>
+<td class="author-text">Gordon Mohr</td></tr>
+<tr><td class="author-text"> </td>
+<td class="author-text">Bitzi, Inc.</td></tr>
+<tr><td class="author-text"> </td>
+<td class="author-text"></td></tr>
+<tr><td class="author-text"> </td>
+<td class="author-text"></td></tr>
+<tr><td class="author" align="right">EMail: </td>
+<td class="author-text"><a href="mailto:go...@bi...">go...@bi...</a></td></tr>
+<tr><td class="author" align="right">URI: </td>
+<td class="author-text"><a href="/web/20080316033726/http://bitzi.com/">http://bitzi.com/</a></td></tr>
+</table>
+
+<a name="anchor17"><br><hr size="1" shade="0"></a>
+<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="/web/20080316033726/http://www.open-content.net/specs/draft-jchapweske-thex-02.html#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table>
+<a name="rfc.section.A"></a><h3>Appendix A. Test Vectors</h3>
+
+<p>
+
+The following are test vectors for producing THEX hash trees using the Tiger hash algorithm. The 'urn:sha1' entries specify the full file SHA-1 of the data, while the 'urn:tree:tiger' entries specify the root of the THEX hash tree of the data.
+</font><pre>
+The empty (zero-length) file:
+
+ urn:sha1:3I42H3S6NNFQ2MSVX7XZKYAYSCX5QBYJ
+ urn:tree:tiger:LWPNACQDBZRYXW3VHJVCJ64QBZNGHOHHHZWCLNQ
+
+A file with a single zero byte:
+
+ urn:sha1:LOUTZHNQZ74T6UVVEHLUEDSD63W2E6CP
+ urn:tree:tiger:VK54ZIEEVTWNAUI5D5RDFIL37LX2IQNSTAXFKSA
+
+A file with 1024 'A' characters:
+
+ urn:sha1:ORWD6TJINRJR4BS6RL3W4CWAQ2EDDRVU
+ urn:tree:tiger:L66Q4YVNAFWVS23X2HJIRA5ZJ7WXR3F26RSASFA
+
+A file with 1025 'A' characters:
+
+ urn:sha1:UUHHSQPHQXN5X6EMYK6CD7IJ7BHZTE77
+ urn:tree:tiger:PZMRYHGY6LTBEH63ZWAHDORHSYTLO4LEFUIKHWY
+</pre><font face="verdana, helvetica, arial, sans-serif" size="2">
+
+</p>
+</font></body></html>
+
+
+
+
+
+<!--
+ FILE ARCHIVED ON 3:37:26 mar 16, 2008 AND RETRIEVED FROM THE
+ INTERNET ARCHIVE ON 13:19:56 jan 19, 2014.
+ JAVASCRIPT APPENDED BY WAYBACK MACHINE, COPYRIGHT INTERNET ARCHIVE.
+
+ ALL OTHER CONTENT MAY ALSO BE PROTECTED BY COPYRIGHT (17 U.S.C.
+ SECTION 108(a)(3)).
+-->
Added: trunk/Hashes/Tiger/node1.html
===================================================================
--- trunk/Hashes/Tiger/node1.html (rev 0)
+++ trunk/Hashes/Tiger/node1.html 2014-01-19 16:29:18 UTC (rev 119)
@@ -0,0 +1,71 @@
+<!DOCTYPE HTML PUBLIC "-//W3O//DTD W3 HTML 2.0//EN">
+<!Converted with LaTeX2HTML 95.1 (Fri Jan 20 1995) by Nikos Drakos (ni...@cb...), CBLU, University of Leeds >
+<HEAD>
+<TITLE> Motivation and Design Requirements</TITLE>
+</HEAD>
+<BODY>
+<meta name="description" value=" Motivation and Design Requirements">
+<meta name="keywords" value="tiger">
+<meta name="resource-type" value="document">
+<meta name="distribution" value="global">
+<P>
+ <BR> <HR><A NAME=tex2html20 HREF="node2.html"><IMG ALIGN=BOTTOM ALT="next" SRC="http://cbl.leeds.ac.uk/nikos/figs//next_motif.gif"></A> <A NAME=tex2html18 HREF="tiger.html"><IMG ALIGN=BOTTOM ALT="up" SRC="http://cbl.leeds.ac.uk/nikos/figs//up_motif.gif"></A> <A NAME=tex2html12 HREF="tiger.html"><IMG ALIGN=BOTTOM ALT="previous" SRC="http://cbl.leeds.ac.uk/nikos/figs//previous_motif.gif"></A> <BR>
+<B> Next:</B> <A NAME=tex2html21 HREF="node2.html"> Our Proposal</A>
+<B>Up:</B> <A NAME=tex2html19 HREF="tiger.html">Tiger: A Fast New </A>
+<B> Previous:</B> <A NAME=tex2html13 HREF="tiger.html">Tiger: A Fast New </A>
+<BR> <HR> <P>
+<H1><A NAME=SECTION00010000000000000000> Motivation and Design Requirements</A></H1>
+<P>
+Cryptographic hash functions are very important for cryptographic protocols.
+When used with signature schemes, their role is to reduce the amount of data
+which must be signed [Pre93] and to break up any properties such as
+multiplicative homomorphism which might be exploited by an opponent [And93]. In
+short, they need to be both efficient and secure; and in most commercial
+applications, they need to run quickly in software on all the common hardware
+platforms.
+<P>
+Some hash functions are based on feedforward modes of block ciphers [Pre93],
+but the main contenders have been the functions based on MD4 [Riv90], which
+include MD5 [Riv92], RIPE-MD [RACE95], SHA [NIST92] and SHA-1 [NIST95]. Another
+family was Snefru, and its derivative Snefru-8 [Mer90].
+<P>
+However, collisions for Snefru were found in 1990 [BS91] [BS93], and recently a
+collision of MD4 has also been found [Dob95]. These attacks cast doubt on the
+security of the other members of these families. One may only speculate at how
+long each function will remain unbroken; however it seems prudent to start work
+now on replacements.
+<P>
+From the performance point of view, all the functions mentioned above were
+designed for 32-bit processors. The next generation of processors has 64-bit
+words, and includes the DEC Alpha series as well as forthcoming processors from
+Intel, HP and IBM. It seems reasonable to assume that, with the exception of
+microcontrollers used in embedded applications, the majority of systems will
+use 64-bit processors within five years or so. However, on such processors, the
+above families of hash functions cannot be implemented efficiently.
+<P>
+For example, the MD family uses many 32-bit rotations and additions, so a
+64-bit register can only handle one 32-bit value at a time, which decreases the
+potential speed by a factor of about two. Moreover, the Alpha architecture does
+not have any rotation operations, whether 64-bit or 32-bit.
+<P>
+From these considerations, we believe that a next generation hash function:
+<P>
+<UL><LI> should be secure. At the very least it must be one-way, collision-free
+and multiplication-free;
+<P>
+<LI> should run quickly on 64-bit processors, and yet not run too slowly on
+the already fielded 32-bit machines such as Intel's 80486;
+<P>
+<LI> should, insofar as possible, be usable as a drop-in replacement for MD4,
+MD5, SHA and SHA-1.
+</UL><BR> <HR><A NAME=tex2html20 HREF="node2.html"><IMG ALIGN=BOTTOM ALT="next" SRC="http://cbl.leeds.ac.uk/nikos/figs//next_motif.gif"></A> <A NAME=tex2html18 HREF="tiger.html"><IMG ALIGN=BOTTOM ALT="up" SRC="http://cbl.leeds.ac.uk/nikos/figs//up_motif.gif"></A> <A NAME=tex2html12 HREF="tiger.html"><IMG ALIGN=BOTTOM ALT="previous" SRC="http://cbl.leeds.ac.uk/nikos/figs//previous_motif.gif"></A> <BR>
+<B> Next:</B> <A NAME=tex2html21 HREF="node2.html"> Our Proposal</A>
+<B>Up:</B> <A NAME=tex2html19 HREF="tiger.html">Tiger: A Fast New </A>
+<B> Previous:</B> <A NAME=tex2html13 HREF="tiger.html">Tiger: A Fast New </A>
+<BR> <HR> <P>
+<BR> <HR>
+<P><ADDRESS>
+<I>Eli Biham <BR>
+Thu Feb 8 15:00:23 IST 1996</I>
+</ADDRESS>
+</BODY>
Added: trunk/Hashes/Tiger/node2.html
===================================================================
--- trunk/Hashes/Tiger/node2.html (rev 0)
+++ trunk/Hashes/Tiger/node2.html 2014-01-19 16:29:18 UTC (rev 119)
@@ -0,0 +1,93 @@
+<!DOCTYPE HTML PUBLIC "-//W3O//DTD W3 HTML 2.0//EN">
+<!Converted with LaTeX2HTML 95.1 (Fri Jan 20 1995) by Nikos Drakos (ni...@cb...), CBLU, University of Leeds >
+<HEAD>
+<TITLE> Our Proposal</TITLE>
+</HEAD>
+<BODY>
+<meta name="description" value=" Our Proposal">
+<meta name="keywords" value="tiger">
+<meta name="resource-type" value="document">
+<meta name="distribution" value="global">
+<P>
+ <BR> <HR><A NAME=tex2html30 HREF="node3.html"><IMG ALIGN=BOTTOM ALT="next" SRC="http://cbl.leeds.ac.uk/nikos/figs//next_motif.gif"></A> <A NAME=tex2html28 HREF="tiger.html"><IMG ALIGN=BOTTOM ALT="up" SRC="http://cbl.leeds.ac.uk/nikos/figs//up_motif.gif"></A> <A NAME=tex2html22 HREF="node1.html"><IMG ALIGN=BOTTOM ALT="previous" SRC="http://cbl.leeds.ac.uk/nikos/figs//previous_motif.gif"></A> <BR>
+<B> Next:</B> <A NAME=tex2html31 HREF="node3.html"> Specification</A>
+<B>Up:</B> <A NAME=tex2html29 HREF="tiger.html">Tiger: A Fast New </A>
+<B> Previous:</B> <A NAME=tex2html23 HREF="node1.html"> Motivation and Design </A>
+<BR> <HR> <P>
+<H1><A NAME=SECTION00020000000000000000> Our Proposal</A></H1>
+<P>
+In this paper we propose a new hash function, which is called Tiger, as it is
+strong and fast: as fast as SHA-1 on 32-bit processors, and about three times
+faster on 64-bit (DEC Alpha) processors. It is also expected to be faster than
+SHA-1 on 16-bit processors, since SHA-1 is optimized for 32-bit machines, while
+our proposal is designed to work adequately on many word sizes.
+<P>
+Its main operation is table lookup into four S-boxes, each from eight bits to
+64 bits. On 32-bit machines this can be implemented as a pair of table lookups,
+with the offset computation done only once. The other operations are 64-bit
+additions and subtractions, 64-bit multiplication by small constants (5, 7 and
+9), 64-bit shifts and logical operations such as XOR and NOT. All these
+operations are at most twice as slow on 32-bit machines, with the exception of
+the shifts and the multiplications by small constants which are four or five
+times slower (Alpha processors have special instructions which multiply by
+constants of the form <IMG ALIGN=MIDDLE ALT="" SRC="img1.gif"> and <IMG ALIGN=MIDDLE ALT="" SRC="img2.gif">).
+<P>
+For drop-in compatibility, we adopt the outer structure of the MD4 family: the
+message is padded by a single `1' bit followed by a string of `0's and finally
+the message length as a 64-bit word. The result is divided into <b>n</b> 512-bit
+blocks.
+<P>
+The size of the hash value, and of the intermediate state, is three words, or
+192 bits. This value was chosen for the following reasons:
+<P>
+<OL><LI> Since we use 64-bit words, the size should be a multiple of 64;
+<LI> To be compatible with applications using SHA-1, the hash size should be
+at least 160 bits;
+<LI> All the successful shortcut attacks on existing hash functions attack the
+intermediate state, rather than the final hash value. The attacker typically
+chooses two colliding values for an intermediate block, and this propagates to
+a collision of the full function. However, these attacks would not work if the
+intermediate hash values were larger.
+</OL>
+<P>
+Tiger with the full 192 bits of output in use may be called Tiger/192, and we
+recommend its use in all new applications. When replacing other functions in
+existing applications, we suggest two shorter variants:
+<P>
+<OL><LI> Tiger/160: the hash value is the first 160 bits of the result of
+Tiger/192, and is used for compatibility with SHA and SHA-1;
+<LI> Tiger/128: the hash value is the first 128 bits of the result of
+Tiger/192, and is used for compatibility with MD4, MD5, RIPE-MD, the Snefru
+variants and some hash functions based on block ciphers.
+</OL>
+<P>
+We conjecture that all the three variants of Tiger are collision-free, in that
+collisions for Tiger/<b>N</b> cannot be found with substantially less effort than
+<IMG ALIGN=MIDDLE ALT="" SRC="img3.gif">. We also believe that they are one-way and multiplication-free
+[And93].
+<P>
+The efficiency of this function is partially based on the potential parallelism
+in its design. In the MD and Snefru families, each operation depends directly
+on the result of the previous operation, and thus RISC processors cannot be
+used efficiently due to pipeline stalls. In each round of Tiger, the eight
+table lookup operations can be done in parallel, so compilers can make best use
+of pipelining. The design also allows efficient hardware implementation.
+<P>
+The memory size required by Tiger is only slightly more than the size of the
+four S boxes. If this can be accommodated within the cache of the processor,
+the computation runs about twice as fast (measured on DEC Alpha). The size of
+the four S boxes is <IMG ALIGN=BOTTOM ALT="" SRC="img4.gif"> Kbytes, which is about the size
+of the cache on most machines. If eight S boxes were used, 16 Kbytes would be
+required, which is twice as the size of the cache on Alpha.
+<P>
+<BR> <HR><A NAME=tex2html30 HREF="node3.html"><IMG ALIGN=BOTTOM ALT="next" SRC="http://cbl.leeds.ac.uk/nikos/figs//next_motif.gif"></A> <A NAME=tex2html28 HREF="tiger.html"><IMG ALIGN=BOTTOM ALT="up" SRC="http://cbl.leeds.ac.uk/nikos/figs//up_motif.gif"></A> <A NAME=tex2html22 HREF="node1.html"><IMG ALIGN=BOTTOM ALT="previous" SRC="http://cbl.leeds.ac.uk/nikos/figs//previous_motif.gif"></A> <BR>
+<B> Next:</B> <A NAME=tex2html31 HREF="node3.html"> Specification</A>
+<B>Up:</B> <A NAME=tex2html29 HREF="tiger.html">Tiger: A Fast New </A>
+<B> Previous:</B> <A NAME=tex2html23 HREF="node1.html"> Motivation and Design </A>
+<BR> <HR> <P>
+<BR> <HR>
+<P><ADDRESS>
+<I>Eli Biham <BR>
+Thu Feb 8 15:00:23 IST 1996</I>
+</ADDRESS>
+</BODY>
Added: trunk/Hashes/Tiger/node3.html
===================================================================
--- trunk/Hashes/Tiger/node3.html (rev 0)
+++ trunk/Hashes/Tiger/node3.html 2014-01-19 16:29:18 UTC (rev 119)
@@ -0,0 +1,144 @@
+<!DOCTYPE HTML PUBLIC "-//W3O//DTD W3 HTML 2.0//EN">
+<!Converted with LaTeX2HTML 95.1 (Fri Jan 20 1995) by Nikos Drakos (ni...@cb...), CBLU, University of Leeds >
+<HEAD>
+<TITLE> Specification</TITLE>
+</HEAD>
+<BODY>
+<meta name="description" value=" Specification">
+<meta name="keywords" value="tiger">
+<meta name="resource-type" value="document">
+<meta name="distribution" value="global">
+<P>
+ <BR> <HR><A NAME=tex2html40 HREF="node4.html"><IMG ALIGN=BOTTOM ALT="next" SRC="http://cbl.leeds.ac.uk/nikos/figs//next_motif.gif"></A> <A NAME=tex2html38 HREF="tiger.html"><IMG ALIGN=BOTTOM ALT="up" SRC="http://cbl.leeds.ac.uk/nikos/figs//up_motif.gif"></A> <A NAME=tex2html32 HREF="node2.html"><IMG ALIGN=BOTTOM ALT="previous" SRC="http://cbl.leeds.ac.uk/nikos/figs//previous_motif.gif"></A> <BR>
+<B> Next:</B> <A NAME=tex2html41 HREF="node4.html"> Security</A>
+<B>Up:</B> <A NAME=tex2html39 HREF="tiger.html">Tiger: A Fast New </A>
+<B> Previous:</B> <A NAME=tex2html33 HREF="node2.html"> Our Proposal</A>
+<BR> <HR> <P>
+<H1><A NAME=SECTION00030000000000000000> Specification</A></H1>
+<P>
+In Tiger all the computations are on 64-bit words, in
+little-endian/2-complement representation. We use three 64-bit
+registers called a, b, and c as the intermediate hash values. These
+registers are initialized to <IMG ALIGN=MIDDLE ALT="" SRC="img5.gif"> which is:
+<P>
+<PRE> a = 0x0123456789ABCDEF
+ b = 0xFEDCBA9876543210
+ c = 0xF096A5B4C3B2E187
+</PRE>
+<P>
+Each successive 512-bit message block is divided into eight 64-bit words x0,
+x1, ..., x7, and the following computation is performed to update <IMG ALIGN=MIDDLE ALT="" SRC="img6.gif"> to
+<IMG ALIGN=MIDDLE ALT="" SRC="img7.gif">.
+<P>
+This computation consists of three passes, and between each of them there is a
+<i> key schedule</i> --- an invertible transformation of the input data which
+prevents an attacker forcing sparse inputs in all three rounds. Finally there
+is a feedforward stage in which the new values of a, b, and c are combined with
+their initial values to give <IMG ALIGN=MIDDLE ALT="" SRC="img8.gif">:
+<P>
+<PRE> save_abc
+ pass(a,b,c,5)
+ key_schedule
+ pass(c,a,b,7)
+ key_schedule
+ pass(b,c,a,9)
+ feedforward
+</PRE>
+<P>
+where
+<P>
+<OL><LI> <tt> save_abc</tt> saves the value of <IMG ALIGN=MIDDLE ALT="" SRC="img9.gif">
+<P>
+<PRE> aa = a ;
+ bb = b ;
+ cc = c ;
+</PRE>
+<P>
+<LI> <tt> pass(a,b,c,mul)</tt> is
+<P>
+<PRE> round(a,b,c,x0,mul);
+ round(b,c,a,x1,mul);
...
[truncated message content] |
|
From: <ul...@us...> - 2014-01-19 16:27:06
|
Revision: 118
http://sourceforge.net/p/adc/code/118
Author: ullner
Date: 2014-01-19 16:27:04 +0000 (Sun, 19 Jan 2014)
Log Message:
-----------
Added 'RDEX' for extended redirecting capabilities.
Modified Paths:
--------------
trunk/ADC-EXT.txt
Modified: trunk/ADC-EXT.txt
===================================================================
--- trunk/ADC-EXT.txt 2013-12-21 21:48:05 UTC (rev 117)
+++ trunk/ADC-EXT.txt 2014-01-19 16:27:04 UTC (rev 118)
@@ -24,6 +24,7 @@
* Added 'Size' attribute in file list for directories.
* Added 'Children' attribute in file list for directories.
* Added downloaded progress report for uploaders in GET.
+* Added 'RDEX' for extended redirecting capabilities.
=== Version 1.0.7
Fredrik Ullner <ul...@gm...>, 2012-11-22
@@ -948,4 +949,75 @@
|DB |Downloaded (and verified) bytes.
|=====
+=== RDEX - Redirects Extended
+
+The goal of this extension is to enhance the redirect capabilities provided by BASE by adding support for two new redirect operations and a way for hubs and clients to communicate accepted redirect protocols. It also attempts to make the concept of redirects more unambiguous and less implementation defined. The two new types of redirects added are a multiple choice redirect and so-called permanent redirect as outlined below. These new redirect types are not necessarily mutually exclusive.
+
+==== Redirect Security
+
+Hubs should always aim to include as much information pertaining to a redirect as possible using other fields defined in BASE. Clients may, for example, rely on the availability of such information to check the origin of a redirect before making irreversible decisions, such as accepting a redirect as permanent as defined below.
+
+Clients should not attempt to connect to an unreachable or otherwise invalid destination resources indefinitely or in otherwise abusive manner when responding to redirects. Whether clients respond to redirects using default user information or the same information as used on the hub that initiated the redirect is implementation defined, however, in the case that the same information is used careful consideration should be taken when it comes to automatically sending sensitive information such as passwords to other hubs especially if it provides less security to the user than the original hub.
+
+Both clients and hubs should also take note that the TL field, as defined by BASE, should only impact the current hub and its connection (if re-established) thus it should not be relied on to trigger a delayed response to a redirect.
+
+==== Accepted Redirect Protocols
+
+Support for this extension is indicated by the presence of an RP field in the INF, which defines the accepted redirect protocols for the hub or a client as a bitmask using any combination of following values. Additional compatible values may be defined by other extensions.
+
+[options="header"]
+|=====
+|Protocol |URI Syntax |Flag
+|User action (exclusive) |any supported, as defined below |0
+|ADC (BASE) |adc://adress:port |1
+|<<anchor-ADCS,ADCS Extension>> |adcs://address:port |2
+|http://nmdc.sf.net[NeoModus Direct Connect] |dchub://address[:port] |4
+|=====
+
+Hubs should treat the absence of the RP field in clients INF as the equivalent of RP with the value of one, thus implying support for BASE. If the ADCS feature is included in the clients feature list this may also be amended to include ADCS. If a client does not define an RP field the hub may choose to omit the RDEX syntax from redirects, although this extension retains full backwards compatibility with BASE. If a hub defines an RP field for itself it should prevent its users from redirecting others to protocols it did not define, including redirects to destinations without an explicit protocol handler. Hubs should always aim to use fully qualified resource identifiers for all redirects, regardless of whether an RP field is defined or not, to avoid ambiguous destinations due to implementation defined default handling.
+
+Clients should refrain from removing support of a previously signalled redirect protocol from their RP field. It is up to the hub to decide a corresponding course of action should the client do so. Additionally a special case is defined for clients as an RP field with the value of zero to indicate that the client may not react to redirects as defined by BASE or this extension at all or may do so only as a result of user action. As such clients defining a non-zero RP field should follow redirects to accepted protocols automatically and conversely any attempts to redirect clients that define RP as zero should result in normal disconnection as per BASE.
+
+==== Multiple Choice Redirect
+
+Multiple choice redirect is defined as a redirect where instead of a single destination resource a set of resource identifiers is provided. The methodology that is used to select the final destination resource for a multiple choice redirect is implementation defined. However, only one final destination resource may be chosen. For example a particular implementation may prefer one protocol over another, encrypted connection over an unencrypted one or even simply choose one at random.
+
+This type of redirect is signalled by the presence of an additional RX field in the QUI as defined for redirects by BASE. The value of the RX field is a comma separated list of resource identifiers to use in the redirect. The RD field should be defined for maximum compatibility and clients should add its value to the list of identifiers defined in RX when selecting the final destination resource.
+
+==== Permanent Redirect
+
+Permanent redirect is defined as a redirect with reference updating. In the case of a permanent redirect, if and only if a successful connection is made to the destination resource, the connecting party will then update all relevant references of the original resource to the destination resource. Examples of such references may be hublist records for pingers or favorite entries for clients.
+
+This type of redirect is signalled by the presence of an additional PT field in the QUI, as defined for redirects by BASE, with the value of one. Upon receiving such redirect clients will proceed to update references as outlined above provided the conditions are met.
+
+==== Examples
+
+Multiple Choice Redirect (BASE compliant)
+[options="header"]
+|=====
+|Example |Description
+|IQUI BBBB IDAAAA RDadc://example.com:1001 RXadcs://example.com:1002,adc://example.org:1020 |Here user BBBB is presented with a choice between three destinations Two on example.com and one on example.org. Old and non-supporting clients will be redirected to adc://example.com:1001. User AAAA is the originator for this redirect.
+|=====
+
+Multiple Choice Redirect (RDEX only, not compatible with old clients thus not recommended)
+[options="header"]
+|=====
+|Example |Description
+|IQUI BBBB IDAAAA RXadc://example.com:1001,adcs://example.com:1002,adc://example.org:1020 |For clients supporting RDEX this is the same as sending the first example. Old and non-supporting clients will be disconnected and they might reconnect to the original hub after an implementation defined time.
+|=====
+
+Permanent Redirect
+[options="header"]
+|=====
+|Example |Description
+|IQUI BBBB IDAAAA MSWe're\smoving! RDadc://example.com:1001 PT1 |Here user BBBB will be redirected to adc://example.com:1001 with the message of "We're moving!" and AAAA as the originator. BBBB should (see section Redirect Security) connect directly to adc://example.com:1001 in the future.
+|=====
+
+Permanent Multiple Choice Redirect
+[options="header"]
+|=====
+|Example |Description
+|IQUI BBBB IDAAAA MSWe\shave\sADCS\snow! RDadc://example.com:1001 RXadcs://example.com:1002 PT1 TL0 |Here user BBBB is redirected permanently with a choice between ADC and ADCS URI, if and only if either of the URI's matches the URI of the current hub connection and the matching URI is chosen BBBB will reconnect immediately. Sending a redirect like this to all connected clients (once) can be used to attempt to migrate them to ADCS instance of a hub.
+|=====
+
// vim: set syntax=asciidoc:
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
|
From: <ul...@us...> - 2013-12-21 21:48:08
|
Revision: 117
http://sourceforge.net/p/adc/code/117
Author: ullner
Date: 2013-12-21 21:48:05 +0000 (Sat, 21 Dec 2013)
Log Message:
-----------
Releasing recommendations document
Modified Paths:
--------------
trunk/ADC-Recommendation.txt
Added Paths:
-----------
trunk/ADC-Recommendation.conf
Added: trunk/ADC-Recommendation.conf
===================================================================
--- trunk/ADC-Recommendation.conf (rev 0)
+++ trunk/ADC-Recommendation.conf 2013-12-21 21:48:05 UTC (rev 117)
@@ -0,0 +1,9 @@
+[attributes]
+numbered
+toc
+toclevels=4
+frame="all"
+grid="all"
+
+[tabledef-default]
+colspec=
Modified: trunk/ADC-Recommendation.txt
===================================================================
--- trunk/ADC-Recommendation.txt 2013-12-21 21:38:23 UTC (rev 116)
+++ trunk/ADC-Recommendation.txt 2013-12-21 21:48:05 UTC (rev 117)
@@ -1,5 +1,6 @@
= ADC Recommendations
-1.1.0
+Fredrik Ullner <ul...@gm...>
+1.1.0, December 2013
== Abstract
These are the official recommendations to ADC. This document is based on the information contained in the ADC documents, ADC wiki and ADC blog. Information is this document should be taken as guide lines to implementations.
@@ -11,7 +12,8 @@
This version corresponds to $Revision: 1 $.
-=== Version 1.1.0, UNRELEASED
+=== Version 1.1.0, 2013-12-21
+Fredrik Ullner, <ul...@gm...>
* Added ZLIB recommendation
* Added SID recommendations/considerations.
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
|
From: <ul...@us...> - 2013-12-21 21:38:26
|
Revision: 116
http://sourceforge.net/p/adc/code/116
Author: ullner
Date: 2013-12-21 21:38:23 +0000 (Sat, 21 Dec 2013)
Log Message:
-----------
Make sure that all commands include "separator" so as to conform to how it's written in BASE.
Modified Paths:
--------------
trunk/ADC-EXT.txt
Modified: trunk/ADC-EXT.txt
===================================================================
--- trunk/ADC-EXT.txt 2013-12-20 16:10:22 UTC (rev 115)
+++ trunk/ADC-EXT.txt 2013-12-21 21:38:23 UTC (rev 116)
@@ -436,7 +436,7 @@
When receiving an RCM and the client does not support TCP4 or TCP6, and if NAT-T is supported in the remote client, a NAT command should be sent repeating the protocol and token. The port shall be the private endpoint port to the connected hub.
==== NAT
- NAT protocol port token
+ NAT protocol separator port separator token
Contexts: T
@@ -445,7 +445,7 @@
Upon receiving this, try and connect to the specified port. An RNT command should be sent repeating the protocol and token. The port shall be the private endpoint. Upon receiving this, try and connect to the specified port.
==== RNT
- RNT protocol port token
+ RNT protocol separator port separator token
Contexts: T
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
|
From: <ul...@us...> - 2013-12-20 16:10:26
|
Revision: 115
http://sourceforge.net/p/adc/code/115
Author: ullner
Date: 2013-12-20 16:10:22 +0000 (Fri, 20 Dec 2013)
Log Message:
-----------
Separators in the command description for GET, GFI and SND are now explicit
Modified Paths:
--------------
trunk/ADC.txt
Modified: trunk/ADC.txt
===================================================================
--- trunk/ADC.txt 2013-12-20 16:05:15 UTC (rev 114)
+++ trunk/ADC.txt 2013-12-20 16:10:22 UTC (rev 115)
@@ -26,7 +26,7 @@
=== Version 1.0.4, UNRELEASED
--
+* Separators in the command description for GET, GFI and SND are now explicit.
=== Version 1.0.3, 2013-06-30
Fredrik Ullner <ul...@gm...>
@@ -735,7 +735,7 @@
|=====
==== GET
- GET type identifier start_pos bytes
+ GET type separator identifier separator start_pos separator bytes
Contexts: C
@@ -767,7 +767,7 @@
and client.
==== GFI
- GFI type identifier
+ GFI type separator identifier
Contexts: C
@@ -779,7 +779,7 @@
unnamed root.
==== SND
- SND type identifier start_pos bytes
+ SND type separator identifier separator start_pos separator bytes
Contexts: C
@@ -829,6 +829,7 @@
==== STA
[options="header"]
|=====
+|Example |Description
|ISTA 211 Hub\sfull |A STA sent from a hub with the severity Fatal (2) and the error code Hub full (11). The descriptive text afterward is to preferably be presented to the user.
|CSTA 151 File\snot\savailable |A STA is sent in a client to client connection, indicating that the request for a file failed (error code 51), as the file was not vailable. The severity (Recoverable, 1) indicates that an error occured but that the connection will remain.
|ESTA BBBB CCCC 142 Transfer\sprotocol\sunsupported TO123456789 PRADC/0.5 |A STA is sent from one client to another client in a hub, routed as a E-type message (meaning that the sender should receive it as well), as a response for not supporting transfers of the 'protocol' kind. The token '123456789' is used and the protocol is "ADC/0.5" (see the command CTM for the version that shall be used in this protocol version).
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
|
From: <ul...@us...> - 2013-12-20 16:05:17
|
Revision: 114
http://sourceforge.net/p/adc/code/114
Author: ullner
Date: 2013-12-20 16:05:15 +0000 (Fri, 20 Dec 2013)
Log Message:
-----------
Added downloaded progress report for uploaders in GET.
Modified Paths:
--------------
trunk/ADC-EXT.txt
Modified: trunk/ADC-EXT.txt
===================================================================
--- trunk/ADC-EXT.txt 2013-07-01 20:53:51 UTC (rev 113)
+++ trunk/ADC-EXT.txt 2013-12-20 16:05:15 UTC (rev 114)
@@ -23,6 +23,7 @@
* Added 'Date' attribute in file list for files and directories.
* Added 'Size' attribute in file list for directories.
* Added 'Children' attribute in file list for directories.
+* Added downloaded progress report for uploaders in GET.
=== Version 1.0.7
Fredrik Ullner <ul...@gm...>, 2012-11-22
@@ -938,4 +939,13 @@
<xs:attribute ref="Children" use="optional" />
----
+=== Downloaded progress report for uploaders in GET
+The info in the current GET command does not permit displaying relative upload progress for the uploading party (for the whole file).
+
+To address this, this extension will add an additional field to the GET command for current downloaded (and verified) bytes before the request has been sent. While still not entirely accurate with this information, the uploader can see how much of the file the requesting party actually has instead of either assuming that the requester has the file up to the start position of the request or being forced to only show the progress of the currently requested part of the file. There is potentially a slight delay in the reporting of this info in scenarios where more than one segment of a file is simultaneously requested (by the downloader) and the uploader still lacks information about how many other sources the file is being downloaded from.
+[options="autowidth"]
+|=====
+|DB |Downloaded (and verified) bytes.
+|=====
+
// vim: set syntax=asciidoc:
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
|
From: <ul...@us...> - 2013-07-01 20:53:54
|
Revision: 113
http://sourceforge.net/p/adc/code/113
Author: ullner
Date: 2013-07-01 20:53:51 +0000 (Mon, 01 Jul 2013)
Log Message:
-----------
* Added 'ASCH' extension for extended searching capability.
* Added 'Date' attribute in file list for files and directories.
* Added 'Size' attribute in file list for directories.
* Added 'Children' attribute in file list for directories.
Modified Paths:
--------------
trunk/ADC-EXT.txt
Modified: trunk/ADC-EXT.txt
===================================================================
--- trunk/ADC-EXT.txt 2013-06-30 14:41:43 UTC (rev 112)
+++ trunk/ADC-EXT.txt 2013-07-01 20:53:51 UTC (rev 113)
@@ -19,6 +19,10 @@
* Added 'ONID' extension to provide online service integration.
* TIGR now specifies the changes done to the file list.
* Added error code 'ADCS transfers are required' in STA.
+* Added 'ASCH' extension for extended searching capability.
+* Added 'Date' attribute in file list for files and directories.
+* Added 'Size' attribute in file list for directories.
+* Added 'Children' attribute in file list for directories.
=== Version 1.0.7
Fredrik Ullner <ul...@gm...>, 2012-11-22
@@ -828,4 +832,110 @@
|62 |ADCS transfers are required. Flag "TO" is the token in the transfer request.
|=====
+=== ASCH - Extended searching capability
+
+This extension will increase searching capability in BASE. The extension also imply that searching in partial file lists are now easier.
+
+Signal ASCH in the INF's SU field.
+
+The SCH command is extended to request a response (STA) indicating how many search results were sent. This will allow clients to indicate that all search results have been received (and can aptly indicate as such to the user). STA severity 0 and code 00 should be used.
+
+Additional SCH fields:
+[options="autowidth"]
+|=====
+|MT |Matching options. Only applies to search terms (AD) and not excluded terms (EX).
+|PP |Indicating whether the responding party should send the parent path of the matching item. For files the result should be for the containing files and for directories the result is for the parent directory. The responder should check that only one result is sent for each directory. This is useful when searching in a partial list, so the requester can then download the partial list from a correct path and locate the matching items in the directory by itself (less search results to send).
+|OT |Older than. Newest possible (absolute) time for a responded item. Time specified is seconds since the Unix epoch.
+|NT |Newer than. Oldest possible (absolute) time for a responded item. Time specified is seconds since the Unix epoch.
+|MR |Maximum number of wanted results (implementations should be conservative in which message type). The responder may also choose to send less results if the requested count isn't reasonable.
+|PA |Path in the share where to search from (relative to the unnamed root). This only makes sense for certain message types.
+|RE |Require a STA reply. This only makes sense for certain message types.
+|=====
+
+MT field:
+[options="autowidth"]
+|=====
+|1 |Match full path (partial match).
+|2 |Match file/directory name only (partial match).
+|3 |Match file/directory name only (exact match).
+|=====
+
+PP field:
+[options="autowidth"]
+|=====
+|1 |Send parent path.
+|=====
+
+RE field:
+[options="autowidth"]
+|=====
+|1 |Require a reply.
+|=====
+
+Additional RES fields:
+[options="autowidth"]
+|=====
+|FI |Number of files in a directory (recursive, directory search results only).
+|FO |Numbers of folders in a directory (recursive, directory search results only).
+|DA |Modified date of a file or directory. Time specified is seconds since the Unix epoch.
+|=====
+
+Additional STA fields:
+[options="autowidth"]
+|=====
+|FC |The FCC of the search command (e.g. BSCH, DSCH).
+|TO |Search token.
+|RC |Number of results sent. The client receiving the search should still send the STA with a 0 here, in the event that there were not hits to the aformentioned search.
+|=====
+
+=== 'Date' attribute in file list for files and directories
+This extension adds a 'Date' attribute to files and directories in a file list. The attribute is the last modified date of the file or directory. Time specified is seconds since the Unix epoch.
+
+Implementations should be conservative when it includes the Date attribute. Only including the attribute in partial file lists can decrease overall network load requirements.
+
+The following changes are done to the file list XML schema:
+
+A new attribute is defined:
+----
+<xs:attribute name="Date" type="xs:unsignedLong" />
+----
+
+The attribute is then referenced in the File and Directory element:
+----
+<xs:attribute ref="Date" use="optional" />
+----
+
+=== 'Size' attribute in file list for directories
+This extension adds a 'Size' attribute to directories in a file list. The attribute is the size of the directory as indicated in a RES.
+
+Implementations should be conservative when it includes the Size attribute.
+
+This attribute only makes sense in partial file lists (as it can be calculated in full lists).
+
+The following change is done to the file list XML schema:
+
+The Size attribute from BASE is referenced in the Directory element:
+----
+<xs:attribute ref="Size" use="optional" />
+----
+
+=== 'Children' attribute in file list for directories
+This extension adds a 'Children' attribute to directories in a file list. The attribute indicates whether there are additional sub-directories.
+
+Value '1' indicate that there are children.
+
+This attribute only makes sense in partial file lists.
+
+The following changes are done to the file list XML schema:
+
+A new attribute is defined:
+----
+<xs:attribute name="Children" type="zeroOne" />
+----
+
+The attribute is then referenced in the Directory element:
+----
+<xs:attribute ref="Children" use="optional" />
+----
+
// vim: set syntax=asciidoc:
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
|
From: <ul...@us...> - 2013-06-30 14:41:47
|
Revision: 112
http://sourceforge.net/p/adc/code/112
Author: ullner
Date: 2013-06-30 14:41:43 +0000 (Sun, 30 Jun 2013)
Log Message:
-----------
Changed URL to repository.
Modified Paths:
--------------
trunk/ADC-EXT.txt
trunk/ADC-Recommendation.txt
trunk/ADC.txt
Modified: trunk/ADC-EXT.txt
===================================================================
--- trunk/ADC-EXT.txt 2013-06-30 14:34:06 UTC (rev 111)
+++ trunk/ADC-EXT.txt 2013-06-30 14:41:43 UTC (rev 112)
@@ -13,7 +13,7 @@
This version corresponds to $Revision$.
-=== Version 1.0.8, UNRELEASED
+=== Version 1.0.8, UNRELEASED
* Improved 'NATT' documentation, as according to the original paper.
* Added 'ONID' extension to provide online service integration.
Modified: trunk/ADC-Recommendation.txt
===================================================================
--- trunk/ADC-Recommendation.txt 2013-06-30 14:34:06 UTC (rev 111)
+++ trunk/ADC-Recommendation.txt 2013-06-30 14:41:43 UTC (rev 112)
@@ -7,7 +7,7 @@
== Version history
The latest draft of the next version of this document as well as intermediate
and older versions can be downloaded from
-$URL: https://adc.svn.sourceforge.net/svnroot/adc/trunk/ADC-Recommendation.txt $.
+$URL: https://svn.code.sf.net/p/adc/code/trunk/ADC-Recommendation.txt $.
This version corresponds to $Revision: 1 $.
Modified: trunk/ADC.txt
===================================================================
--- trunk/ADC.txt 2013-06-30 14:34:06 UTC (rev 111)
+++ trunk/ADC.txt 2013-06-30 14:41:43 UTC (rev 112)
@@ -1,6 +1,5 @@
= ADC Protocol
-Fredrik Ullner, <ul...@gm...>
-version 1.0.3, June 2013
+version 1.0.4, UNRELEASED
== Abstract
ADC is a text protocol for a client-server network similar to Neo-Modus'
@@ -25,6 +24,10 @@
$URL$.
This version corresponds to $Revision$.
+=== Version 1.0.4, UNRELEASED
+
+-
+
=== Version 1.0.3, 2013-06-30
Fredrik Ullner <ul...@gm...>
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
|
From: <ul...@us...> - 2013-06-30 14:34:09
|
Revision: 111
http://sourceforge.net/p/adc/code/111
Author: ullner
Date: 2013-06-30 14:34:06 +0000 (Sun, 30 Jun 2013)
Log Message:
-----------
Added SID allocation suggestions.
Modified Paths:
--------------
trunk/ADC-Recommendation.txt
Modified: trunk/ADC-Recommendation.txt
===================================================================
--- trunk/ADC-Recommendation.txt 2013-06-30 13:54:31 UTC (rev 110)
+++ trunk/ADC-Recommendation.txt 2013-06-30 14:34:06 UTC (rev 111)
@@ -1,6 +1,5 @@
= ADC Recommendations
-Fredrik Ullner <ul...@gm...>
-1.0.0, July 2010
+1.1.0
== Abstract
These are the official recommendations to ADC. This document is based on the information contained in the ADC documents, ADC wiki and ADC blog. Information is this document should be taken as guide lines to implementations.
@@ -12,9 +11,16 @@
This version corresponds to $Revision: 1 $.
-=== Version 1.0.0
-* Initialize release
+=== Version 1.1.0, UNRELEASED
+* Added ZLIB recommendation
+* Added SID recommendations/considerations.
+
+=== Version 1.0.0, 2010-07-01
+Fredrik Ullner, <ul...@gm...>
+
+* Initial release
+
== General recommentations
Message length
@@ -26,37 +32,130 @@
While STA messages require a severity to accompany the error code, the severity may not be of importance to some error codes or are simply implied by the actual error code. However, it is important that the severity is sent as appropriate and is accurate. STA messages with 0 (success) for severity can usually be regarded by implementations that the information require little or no counter-action.
The following list include error codes that make no or little sense in one or many severities, and a description why they are best used in one or only some severities. The descriptive text for the error codes can be seen in the STA specification, but may be re-stated as part of the description why they can have severity restriction(s).
-11 | If the hub is full, it makes little sense in keeping the client in some "connected" state. The recommended severity is to use 2 (fatal) to force the client to reconnect at a later time.
-12 | Similar to error code 11.
-21 | While potentially fatal, the client may resend its INF with a new NI field. The recommended severity for hubs is to use 2 (fatal) but they can use 1 (recoverable).
-22 | Similar to error code 21.
-23 | An invalid password depend on whether the hub wish to allow the client to resend its password (say, if the transmission became garbled). However, the recommended severity is to use 2 (fatal) unless under special circumstances, for some clients or for some users.
-24 | The recommended severity is to use 2 (fatal).
-25 | Can be 1 (recoverable) or 2 (fatal) but generally not 0 (sucess).
-26 | If the user is not registered in the hub, it makes little sense to try to reconnect immediately. The recommended severity is to use 2 (fatal).
-27 | Similar to error code 24.
-30 | The recommended severity is to use 2 (fatal).
-31 | Must be 2 (fatal).
-32 | Must be 2 (fatal).
-43 | Information that is missing or is bad is generally grounds for a disconnect but may be recoverable under certain states. The recommended severity is to use 2 (fatal).
-44 | Similar to error code 43.
-45 | Similar to error code 43.
-46 | Similar to error code 43.
-47 | Must be 2 (fatal).
-50 | May be cause for a disconnect but is generally recoverable. The recommended severity is to use 1 (recoverable).
-51 | Similar to error code 50.
-52 | Similar to error code 50.
-53 | Similar to error code 11.
-54 | Must be 2 (fatal).
+[options="autowidth"]
+|=====
+|11 |If the hub is full, it makes little sense in keeping the client in some "connected" state. The recommended severity is to use 2 (fatal) to force the client to reconnect at a later time.
+|12 |Similar to error code 11.
+|21 |While potentially fatal, the client may resend its INF with a new NI field. The recommended severity for hubs is to use 2 (fatal) but they can use 1 (recoverable).
+|22 |Similar to error code 21.
+|23 |An invalid password depend on whether the hub wish to allow the client to resend its password (say, if the transmission became garbled). However, the recommended severity is to use 2 (fatal) unless under special circumstances, for some clients or for some users.
+|24 |The recommended severity is to use 2 (fatal).
+|25 |Can be 1 (recoverable) or 2 (fatal) but generally not 0 (sucess).
+|26 |If the user is not registered in the hub, it makes little sense to try to reconnect immediately. The recommended severity is to use 2 (fatal).
+|27 |Similar to error code 24.
+|30 |The recommended severity is to use 2 (fatal).
+|31 |Must be 2 (fatal).
+|32 |Must be 2 (fatal).
+|43 |Information that is missing or is bad is generally grounds for a disconnect but may be recoverable under certain states. The recommended severity is to use 2 (fatal).
+|44 |Similar to error code 43.
+|45 |Similar to error code 43.
+|46 |Similar to error code 43.
+|47 |Must be 2 (fatal).
+|50 |May be cause for a disconnect but is generally recoverable. The recommended severity is to use 1 (recoverable).
+|51 |Similar to error code 50.
+|52 |Similar to error code 50.
+|53 |Similar to error code 11.
+|54 |Must be 2 (fatal).
+|=====
== ZLIB compression
=== Generic
* Try to keep constant and almost constant named parameters together, that way there is a higher likelyhood for a longer parameter match.
-
* When possible try to keep similar commands no more than a window size (usually 32 bits if highest rate is used) away, that ensures you will benefit from the redundancy provided by these (this may be particularly important when sending large strings like MOTDs or help and configuration values intertwined with other commands).
-
* Syncing is important to keep the clients updated but when you sync some bytes are sent (the sync ones and the ones for the Huffman tree of the new packet if it is a type 2 packet) as such it may make sense to keep in different queues commands depending on how much latency matters for them, for example you may want to keep low latency for MSG commands and send them frequently but may prefer to send searches or passive results together each half second or so. Also latencies matter depending on the type of network, on a LAN users expect most things to happen almost inmediately (especially things like MSGs) whilst clients connecting over a classic DSL line may not care that much for higher latencies.
+== SID generation
+The following are different algorithms for hubs to allocate and assign session IDs (SIDs) to clients.
+
+=== Background
+
+In ADC the Session ID (or SID) uniquely identifies a user while connected to a hub, and the user will be assigned a SID at the time of login. Once assigned, the SID cannot be changed without a reconnect.
+
+The SID is a 4 byte sequence of Base32 characters consisting of 32 possible characters, A-Z and 2-7. This means there can be 32^4 different SIDs (slightly over 1 million).
+
+=== Algorithms
+The following algorithms are ways one can manage the SIDs that are assigned.
+
+==== Random SID allocation
+1. When client logs in: SID = random number between 1 and 1048576.
+2. if (SID in use) go to 1.
+3. Assign SID to user.
+
+Advantages:
+
+* Very simple to implement.
+
+Disadvantages:
+
+* Theoretically, if a hub has close to the maximum allowed users (1 million), the algorithm of generating a unique SID becomes very costly. On a hub consiting of a few thousand users this is negligible if looking up users based on SID is fast.
+
+Notes:
+
+* The algorithm requires that lookup of users must be as cheap as possible.
+
+==== Incremental SID allocation
+1. When hub starts, set: counter = 0
+2. When client logs in: SID = ((++counter) % 1048576)
+3. if (counter > 1048576) and (SID == 0 or in use) go to 2.
+4. Assign SID to user.
+
+Advantages:
+
+* Simple to implement.
+* For the first 1048576 allocated SIDs one does not need to check for SID collisions.
+
+Disadvantages:
+
+* Information leak: Assuming less than 1 million login attempts have been made, one can easily figure out how many users have logged in before.
+
+Notes:
+
+* The algorithm requires that lookup of users must be as cheap as possible.
+
+==== Pre-allocated recyclable SIDs
+1. Allocate a queue large enough to contain SIDs for the maximum users allowed (or dynamically, regarding the user count and the maximum allowed)
+2. Pre-initialize the queue with unique SIDs (for example in ascending order)
+3. When client logs in: Assign the first SID from the end of the queue
+4. When client logs out: push the SID to the beginning of the queue
+
+Advantages:
+
+* No need to check for duplicate SIDs when users log in.
+
+Disadvantages:
+
+* If max_users is too large, a lot of memory is allocated but not used (one can allocate as users come in, the maximum user count would be just a reference)
+
+* If the queue is kept as a linked list of SIDs, even more memory is allocated.
+
+* If the queue is kept as an array, a lot of memory moving needs to be performed when users log out.
+
+* Changing the maximum users limit while the hub is running is slightly more complicated (see below).
+
+* Negligible: While starting up, the hub needs to allocate and fill the queues.
+
+Notes:
+
+* Changing the maximum users limit:
+** if maximum users is increased, another set of unique SIDs needs to be added to the front of the queue.
+** if maximum users is decreased, no change is needed, it just means the queue will still have unused elements in it if the hub becomes full (or remove some elements from the not used end of the queue).
+
+==== Incremental recyclable SID allocation
+1. When hub starts, set counter = 0.
+2. When client logs in: take last element of SID array if exist and delete it or SID = something like ((++counter) % 1048576).
+3. Assign SID to user.
+4. When client logs out: store client SID as last element in SID array.
+
+Advantages:
+
+* Simple to implement.
+* You never need to check collisons.
+
+Disadvantages:
+
+* Information leak: you can find out the max user peak of the hub in a session.
+* The SID array grows when more clients logout then login; in worst case, the hub is empty and the array contains all created SIDs of the session.
+
// vim: set syntax=asciidoc:
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
|
From: <ul...@us...> - 2013-06-30 13:54:33
|
Revision: 110
http://sourceforge.net/p/adc/code/110
Author: ullner
Date: 2013-06-30 13:54:31 +0000 (Sun, 30 Jun 2013)
Log Message:
-----------
Added error code 'ADCS transfers are required' in STA.
Modified Paths:
--------------
trunk/ADC-EXT.txt
Modified: trunk/ADC-EXT.txt
===================================================================
--- trunk/ADC-EXT.txt 2013-06-30 13:47:09 UTC (rev 109)
+++ trunk/ADC-EXT.txt 2013-06-30 13:54:31 UTC (rev 110)
@@ -18,6 +18,7 @@
* Improved 'NATT' documentation, as according to the original paper.
* Added 'ONID' extension to provide online service integration.
* TIGR now specifies the changes done to the file list.
+* Added error code 'ADCS transfers are required' in STA.
=== Version 1.0.7
Fredrik Ullner <ul...@gm...>, 2012-11-22
@@ -819,4 +820,12 @@
|DOIR CCCC BBBB mslive EMe...@li... |A response for the notification request from BBBB.
|=====
+=== "ADCS transfers are required" error code
+This extension will add "ADCS transfers are required" as error code in STA. A client that has chosen to only allow encrypted transfers (with ADCS) should send this when a user without ADCS support tries to initiate a connection (via CTM/RCM etc).
+
+[options="autowidth"]
+|=====
+|62 |ADCS transfers are required. Flag "TO" is the token in the transfer request.
+|=====
+
// vim: set syntax=asciidoc:
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
|
From: <ul...@us...> - 2013-06-30 13:47:12
|
Revision: 109
http://sourceforge.net/p/adc/code/109
Author: ullner
Date: 2013-06-30 13:47:09 +0000 (Sun, 30 Jun 2013)
Log Message:
-----------
Added ZLIB recommendation
Modified Paths:
--------------
trunk/ADC-PRD.txt
trunk/ADC-Recommendation.txt
Modified: trunk/ADC-PRD.txt
===================================================================
--- trunk/ADC-PRD.txt 2013-06-30 13:32:30 UTC (rev 108)
+++ trunk/ADC-PRD.txt 2013-06-30 13:47:09 UTC (rev 109)
@@ -1,5 +1,6 @@
= ADC - Protocol Release Description
-1.0.0, UNRELEASED
+Fredrik Ullner, <ul...@gm...>
+1.0.0, June 2013
== Abstract
New versions of ADC are released on a continuous basis. This document intend to provide a resource for those who are active in the ADC developent process and particularly the release process. This document, Protocol Release Description (PRD), describes the necessary changes and updates to the ADC network and associated resources once a new version of ADC is about to be released and subsequently is released.
Modified: trunk/ADC-Recommendation.txt
===================================================================
--- trunk/ADC-Recommendation.txt 2013-06-30 13:32:30 UTC (rev 108)
+++ trunk/ADC-Recommendation.txt 2013-06-30 13:47:09 UTC (rev 109)
@@ -49,4 +49,14 @@
53 | Similar to error code 11.
54 | Must be 2 (fatal).
+== ZLIB compression
+
+=== Generic
+
+* Try to keep constant and almost constant named parameters together, that way there is a higher likelyhood for a longer parameter match.
+
+* When possible try to keep similar commands no more than a window size (usually 32 bits if highest rate is used) away, that ensures you will benefit from the redundancy provided by these (this may be particularly important when sending large strings like MOTDs or help and configuration values intertwined with other commands).
+
+* Syncing is important to keep the clients updated but when you sync some bytes are sent (the sync ones and the ones for the Huffman tree of the new packet if it is a type 2 packet) as such it may make sense to keep in different queues commands depending on how much latency matters for them, for example you may want to keep low latency for MSG commands and send them frequently but may prefer to send searches or passive results together each half second or so. Also latencies matter depending on the type of network, on a LAN users expect most things to happen almost inmediately (especially things like MSGs) whilst clients connecting over a classic DSL line may not care that much for higher latencies.
+
// vim: set syntax=asciidoc:
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
|
From: <ul...@us...> - 2013-06-30 13:32:34
|
Revision: 108
http://sourceforge.net/p/adc/code/108
Author: ullner
Date: 2013-06-30 13:32:30 +0000 (Sun, 30 Jun 2013)
Log Message:
-----------
Added XML schema information for TIGR.
Modified Paths:
--------------
trunk/ADC-EXT.txt
Modified: trunk/ADC-EXT.txt
===================================================================
--- trunk/ADC-EXT.txt 2013-06-30 13:08:29 UTC (rev 107)
+++ trunk/ADC-EXT.txt 2013-06-30 13:32:30 UTC (rev 108)
@@ -17,6 +17,7 @@
* Improved 'NATT' documentation, as according to the original paper.
* Added 'ONID' extension to provide online service integration.
+* TIGR now specifies the changes done to the file list.
=== Version 1.0.7
Fredrik Ullner <ul...@gm...>, 2012-11-22
@@ -131,6 +132,23 @@
|TD |Tree depth, index of the highest level of tree data available, root-only = 0, first level (2 leaves) = 1, second level = 2, etc...
|=====
+The following changes are done to the file list XML schema:
+
+A new type is defined with an appropriate attribute:
+----
+<xs:simpleType name="tthType">
+ <xs:restriction base="xs:string">
+ <xs:pattern value="[A-Za-z2-7]{39}" />
+ </xs:restriction>
+</xs:simpleType>
+<xs:attribute name="TTH" type="tthType" />
+----
+
+The attribute is then referenced in the File element:
+----
+<xs:attribute ref="TTH" use="required" />
+----
+
=== BZIP - File list compressed with bzip2
This extension adds a special file "files.xml.bz2" in the unnamed root of the
share which contains "files.xml" compressed with bzip2 1.0.3+ (www.bzip.org).
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
|
From: <ul...@us...> - 2013-06-30 13:08:31
|
Revision: 107
http://sourceforge.net/p/adc/code/107
Author: ullner
Date: 2013-06-30 13:08:29 +0000 (Sun, 30 Jun 2013)
Log Message:
-----------
Version 1.0.3 of ADC is now released.
Modified Paths:
--------------
trunk/ADC-PRD.txt
trunk/ADC.txt
Modified: trunk/ADC-PRD.txt
===================================================================
--- trunk/ADC-PRD.txt 2013-06-17 19:55:59 UTC (rev 106)
+++ trunk/ADC-PRD.txt 2013-06-30 13:08:29 UTC (rev 107)
@@ -24,16 +24,12 @@
=== Document version and contact information
The version information provided in the document's top should be in the form of;
-AUTHOR
-
-<MAIL>
-
+AUTHOR, <MAIL>
version XYZ, MONTH YEAR
Example:
====
- John Doe
- <do...@ex...>
+ John Doe, <do...@ex...>
version 0.0.1, January 1970
====
@@ -41,7 +37,7 @@
Version XYZ, YYYY-MM-DD
-AUTHOR, <MAIL>
+AUTHOR <MAIL>
* Change1
@@ -50,7 +46,7 @@
Example:
====
Version 0.0.1, 1970-01-20
- John Doe, <do...@ex...>
+ John Doe <do...@ex...>
* Initial release
* Added history information
====
Modified: trunk/ADC.txt
===================================================================
--- trunk/ADC.txt 2013-06-17 19:55:59 UTC (rev 106)
+++ trunk/ADC.txt 2013-06-30 13:08:29 UTC (rev 107)
@@ -1,5 +1,6 @@
= ADC Protocol
-1.0.3, UNRELEASED
+Fredrik Ullner, <ul...@gm...>
+version 1.0.3, June 2013
== Abstract
ADC is a text protocol for a client-server network similar to Neo-Modus'
@@ -24,7 +25,8 @@
$URL$.
This version corresponds to $Revision$.
-=== Version 1.0.3, UNRELEASED
+=== Version 1.0.3, 2013-06-30
+Fredrik Ullner <ul...@gm...>
* Added examples for each command.
* Features are now described in its own section.
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
|
From: <ul...@us...> - 2013-06-17 19:56:02
|
Revision: 106
http://sourceforge.net/p/adc/code/106
Author: ullner
Date: 2013-06-17 19:55:59 +0000 (Mon, 17 Jun 2013)
Log Message:
-----------
Some more examples for ONID.
Modified Paths:
--------------
trunk/ADC-EXT.txt
Modified: trunk/ADC-EXT.txt
===================================================================
--- trunk/ADC-EXT.txt 2013-06-17 19:32:16 UTC (rev 105)
+++ trunk/ADC-EXT.txt 2013-06-17 19:55:59 UTC (rev 106)
@@ -797,6 +797,8 @@
|BOID BBBB LoL SUtest2 |An updated notification of the League of Legends service with the new summoner name "test2".
|BOIR BBBB Google EMe...@gm... |A notification of the Google service with the e-mail "ex...@gm...".
|BOIR BBBB mslive EMe...@ho... |A notification of the Microsoft Live service with the e-mail "ex...@ho...".
+|BOIR BBBB mslive |A request for notifications of the Microsoft Live service.
+|DOIR CCCC BBBB mslive EMe...@li... |A response for the notification request from BBBB.
|=====
// vim: set syntax=asciidoc:
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
![http://cbl.leeds.ac.uk/nikos/figs//next_motif.gif"></A>](http://cbl.leeds.ac.uk/nikos/figs//next_motif.gif"></A>){kind=link}
![http://cbl.leeds.ac.uk/nikos/figs//up_motif.gif"></A>](http://cbl.leeds.ac.uk/nikos/figs//up_motif.gif"></A>){kind=link}
![http://cbl.leeds.ac.uk/nikos/figs//previous_motif.gif"></A>](http://cbl.leeds.ac.uk/nikos/figs//previous_motif.gif"></A>){kind=link}