ADC Extensions

These are the official extensions to ADC. This document is based on the information contained in the ADC wiki - specifications from there are moved here when they are mature and stable enough.

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-EXT.txt $.

This version corresponds to $Revision: 3 $.

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

All files shared by TIGR supporting clients must have been hashed using Merkle Hash trees, as defined by http://www.open-content.net/specs/draft-jchapweske-thex-02.html. The Tiger algorithm, as specified by http://www.cs.technion.ac.il/~biham/Reports/Tiger/, 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.

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.

In the file list, each File element carries an additional attribute "TTH" containing the base32-encoded value of the Tiger tree root.

In the GET/GFI type, the full tree may be accessed using the "tthl" type.

"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.

In the GET/GFI namespace, files are identified by "TTH/<base32-encoded tree root>".

In SCH and GFI, the following attributes are added:

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).

There are two variants of zlib support, FULL and GET, and only one should be used on a each communications channel set up.

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.

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.

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).

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).

Contexts : F

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):

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).

The same extension goes for hub- hublist communication. This way, the hub takes the role of the client and the hublist of the server.

The hublist may send INF about itself with NI field which would become hublist name and WS hublist web address.