Версия для печати темы

Нажмите сюда для просмотра этой темы в обычном формате

MyDC.ru _ ADC _ Описание Протокола ADC

Автор: Setuper 2.6.2009, 22:01

Структурированное описание протокола Advanced Direct Connect (ADC), под управлением которого уже работают некоторые хабы.
Ссылка на оригинальное описание: http://mydc.ru/r/?http://adc.sourceforge.net/ADC.html

По мере написания, в содержании будет появляться ссылка на соответствующий пост.
Делаю тему закрытой, дабы структурировано всё описать.


1. Введение
2. История версий
3. Структура протокола

3.1. Основное
3.2. Синтаксис команд
3.3. Типы команд
3.4. Хеш-функции
3.5. Идентификация клиента
3.5.1. SID
3.5.2. PID
3.5.3. CID

4. Файлы
4.1. Имена файлов и структура
4.2. Файл-лист

5. Команды характеристики BASE
5.1. Клиент – Хаб взаимодействие
5.2. Клиент – Клиент взаимодействие
5.3. Команды
STA
SUP
SID
INF
MSG
SCH
RES
CTM
RCM
GPA
PAS
QUI
GET
GFI
SND

6. Примеры
6.1. Связь Клиент – Хаб
6.2. Связь Клиент – Клиент

7. Стандартные дополнения/расширения
7.1. TIGR - поддержка TTH (Tiger Tree Hash)
7.2. BZIP – сжатие файл-листа пи помощи библиотеки bzip2
7.3. ZLIB - сжатие связи
7.3.1. ZLIB-FULL
7.3.2. ZLIB-GET

Автор: Setuper 2.6.2009, 22:04

1. Введение

ADC - это протокол для клиент-серверных сетей, на подобии Neo-Modus' Direct Connect (NMDC). Целью является создание простого протокола, который не нагружает ни клиент, ни сервер, и который можно расширять. В нём исправлены некоторые неудачные решения протокола NMDC, но не все.

Рассматриваются те же самые взаимодействия: клиент-клиент и клиент-сервер. Данная документация разделена на две части; первая часть описывает структуру протокола, вторая - специфичность системы протокола для использования этой структуры. Advanced Direct Connect - это первая версия, которая будет постепенно улучшаться.

Большинство идей для протокола пришли из проекта DCTNG (Jan Vidar Krey's). Основные участники разработки: Dustin Brody, Walter Doekes, Timmo Stange, Fredrik Ullner, Fredrik Stenberg и другие. Jon Hess посодействовал как создатель протокола NMDC.

Преимущества протокола:



Недостатки протокола:

Автор: Setuper 2.6.2009, 22:07

2. История версий

Последующие версии этого документа, а также промежуточные и более старые версии могут быть получены по адресу: http://mydc.ru/r/?https://dcplusplus.svn.sourceforge.net/svnroot/dcplusplus/dcplusplus/trunk/ADC.txt. Эта версия представляется к ревизии: 923.
Данная версия: 1.0, 2007-12-01 (Первый релиз)

Автор: Setuper 2.6.2009, 22:11

3. Структура протокола

3.1. Основное


Автор: Setuper 2.6.2009, 22:17

3.2. Синтаксис команд

Код
message               ::= message_body? eol
message_body          ::= (b_message_header | cih_message_header | de_message_header | f_message_header | u_message_header | message_header)
                          (separator positional_parameter)* (separator named_parameter)*
b_message_header      ::= 'B' command_name separator my_sid
cih_message_header    ::= ('C' | 'I' | 'H') command_name
de_message_header     ::= ('D' | 'E') command_name separator my_sid separator target_sid
f_message_header      ::= 'F' command_name separator my_sid separator (('+'|'-') feature_name)+
u_message_header      ::= 'U' command_name separator my_cid
command_name          ::= simple_alpha simple_alphanum simple_alphanum
positional_parameter  ::= parameter_value
named_parameter       ::= parameter_name parameter_value?
parameter_name        ::= simple_alpha simple_alphanum
parameter_value       ::= escaped_letter+
target_sid            ::= encoded_sid
my_sid                ::= encoded_sid
encoded_sid           ::= base32_character{4}
my_cid                ::= encoded_cid
encoded_cid           ::= base32_character+
base32_character      ::= simple_alpha | [2-7]
feature_name          ::= simple_alpha simple_alphanum{3}
escaped_letter        ::= [^ \#x0a] | escape 's' | escape 'n' | escape escape
escape                ::= '\'
simple_alpha          ::= [A-Z]
simple_alphanum       ::= [A-Z0-9]
eol                   ::= #x0a
separator             ::= ' '

Автор: Setuper 2.6.2009, 22:23

3.3. Типы команд

Тип команды (определяющий символ, находящийся в начале команды) определяет то, каким образом отсылать эту команду. Клиенты, как получатели, используют ограниченный набор типов для рассылки. Клиенты должны использовать типы только для того, чтобы помочь себе распарсить команду, иначе команда должна игнорироваться. Итак, определены следующие типы (префиксы) команд:

B (Broadcast)
Хаб должен отослать команду всем подключенным клиентам, включая и самого отправителя.

C (Client message)
Клиенты должны использовать эту команду только для прямого соединения по протоколу TCP.

D (Direct message)
Хаб должен отправить эту команду для пользователя с указанным sid.

E (Echo message)
Хаб должен отправить команду для пользователей с sid и my_sid.

F (Feature broadcast)
Хаб должен отослать эту команду всем клиентам, которые поддерживают(+)/не поддерживают(-) данную характеристику. Поддержка клиентом той или иной характеристики определяется из поля SU, которое содержится в команде INF, отсылаемой клиентом.

H (Hub message)
Клиенты должны использовать данный тип для отсылки команды, которая предназначена только хабу.

I (Info message)
Хабы должны использовать данный тип для отсылки команды, которая не была отослана другим клиентом.

U (UDP message)
Клиенты должны использовать эту команду только для прямого соединения по протоколу UDP.

Автор: Setuper 2.6.2009, 22:27

3.4. Хеш-функции

Некоторые команды используются для определяния хеш-функций. При установке каждого нового соединения по команде SUP происходит обмен хеш-функциями. При коннекте клиент передаёт серверу несколько хеш-функций посредствам параметров команды SUP. Сервер вбирает одну из них и передаёт её клиенту, поставив её до любой другой хеш-функции в команде SUP, которая отправится с сервера. Клиент и хаб должны иметь по крайней мере одну одинаковую хеш-функцию, которая будет использоваться в протоколе и в файловой идентификации.

Автор: Setuper 2.6.2009, 22:29

3.5. Идентификация клиента

Каждый клиент идентифицируется по трём различным идентификаторам: идентификатор сессии - Session ID (SID), личный идентификатор - Private ID (PID) и идентификатор клиента - Client ID (CID).

Автор: Setuper 2.6.2009, 22:33

3.5.1. SID

Идентификатор сессии даётся клиенту на сессию, в течение которой он находится на хабе. Это идентификатор уникального пользователя на хабе, который назначается при входе на хаб. SID - 20-битный код, закодированный 4-байтной base32 строкой.

Автор: Setuper 2.6.2009, 22:35

3.5.2. PID

Приватный идентификатор глобально идентифицирует уникальных клиентов. Он используется при коннекте для генерации CID и не виден другим клиентам. PID генерируется для того, чтобы избежать конфузов. При генерации PID (при первом запуске клиента) используется текущее время и MAC адрес сетевой карты. Хабы и клиенты не должны раскрывать приватные идентификаторы другим клиентам, так как это нарушает безопасность ADC сетей. Клиенты должны иметь один и тот же PID в течение всей сессии на хабе.

Клиент отсылает на хаб данный идентификатор в команде INF. Хаб удаляет из команды INF этот идентификатор перед тем как отослать команду INF всем пользователям хаба.

Автор: Setuper 2.6.2009, 22:39

3.5.3. CID

Идентификатор клиента глобально и публично идентифицирует уникальные клиенты и лежит в основе связи между клиентами. Он генерируется по PID по определённому алгоритму. Хаб должен регистрировать клиентов по CID-у. CID должен оставаться неизменным в течении сессии. Клиенты должны уметь оперировать с CID-ми переменной длины.

Автор: Setuper 2.6.2009, 22:44

4. Файлы

4.1. Имена файлов и структура

Имена файлов отсчитываются от относительного (вымышленного) корня в шаре пользователя. "/" - разделитель директорий; каждый файл или имя директории должно быть уникальным в регистро-независимом контексте. Все печатные символы, включая пробел, допустимы в имени файла, символы "/" и "\" экранируются символом "\". Клиенты должны использовать фильтры для имён под свои файловые системы, имена файлов, полученные от других клиентов, должны также подчиняться этим правилам. Специальные имена "." и ".." не могут содержаться в директории или имени файла; любой полученный файл-лист, содержащий эти имена должен быть проигнорирован. Все имена директорий должны оканчиваться на "/".

Расшаренные файлы идентифицируются относительно безымянного корня "/" ("/dir/subdir/filename.ext"), тогда как дополнения могут добавить имя корня. Например, "TTH/…" для TIGR дополнения используют имя корня "TTH" для идентификации файлов по их "Tiger Tree Hash". Это недопустимо для имён из безымянного корня, которые попали в шару с идентификатором по контрольной сумме.

Без корневое имя файла "files.xml" определяет полный файл-лист, в формате XML в кодировке UTF-8. Клиентам рекомендуется использовать дополнения чтобы сжимать данный файл-лист.

Дополнения могут добавлять к имени файла свои расширения, обычно это делается для того, чтобы избежать повторения имён.

Специальный тип "list" используется для просмотра списков файлов. Частичный файловый список имеет ту же структуру, что и нормальный список, но директории могут быть теговыми с атрибутом Incomplete="1", который показывает на частичность. Только директории без корневых файлов могут начинаться с символа "/". Содержимое такой директории в последствии будет послано просящему клиенту на глубину, выбранную им (это нужно для отправки только того уровня, который требуется пользователю). Атрибут "Base" для поля "FileListing" определяет к какой конкретной директории принадлежит данный файл.

Автор: Setuper 2.6.2009, 23:01

4.2. Файл-лист

files.xml - список файлов, предназначенных для просмотра. Этот список должен удовлетворять следующей XML схеме:

HTML
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:simpleType name="base32Binary">
<xs:restriction base="xs:string">
<xs:pattern value="[A-Za-z2-7]+"></xs:pattern>
</xs:restriction>
</xs:simpleType>

<xs:simpleType name="zeroOne">
<xs:restriction base="xs:int">
<xs:enumeration value="0"></xs:enumeration>
<xs:enumeration value="1"></xs:enumeration>
</xs:restriction>
</xs:simpleType>

<xs:complexType name="ContainerType">
<xs:sequence minOccurs="0" maxOccurs="unbounded">
<xs:choice>
<xs:element ref="Directory"></xs:element>
<xs:element ref="File"></xs:element>
<xs:any processContents="lax"></xs:any>
</xs:choice>
</xs:sequence>
</xs:complexType>

<xs:attribute name="Base" type="xs:string"></xs:attribute>
<xs:attribute name="CID" type="base32Binary"></xs:attribute>
<xs:attribute name="Generator" type="xs:string"></xs:attribute>
<xs:attribute name="Incomplete" type="zeroOne" default="0"></xs:attribute>
<xs:attribute name="Name" type="xs:string"></xs:attribute>
<xs:attribute name="Size" type="xs:int"></xs:attribute>
<xs:attribute name="Version" type="xs:int"></xs:attribute>

<xs:element name="FileListing">
<xs:complexType>
<xs:complexContent>
<xs:extension base="ContainerType">
<xs:attribute ref="CID" use="required"></xs:attribute>
<xs:attribute ref="Version" use="required"></xs:attribute>
<xs:attribute ref="Generator" use="optional"></xs:attribute>
<xs:attribute ref="Base" use="required"></xs:attribute>
<xs:anyAttribute processContents="lax"></xs:anyAttribute>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:element>

<xs:element name="Directory">
<xs:complexType>
<xs:complexContent>
<xs:extension base="ContainerType">
<xs:attribute ref="Name" use="required"></xs:attribute>
<xs:anyAttribute processContents="lax"></xs:anyAttribute>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:element>

<xs:element name="File">
<xs:complexType>
<xs:sequence>
<xs:any minOccurs="0" maxOccurs="unbounded"></xs:any>
</xs:sequence>
<xs:attribute ref="Name" use="required"></xs:attribute>
<xs:attribute ref="Size" use="required"></xs:attribute>
<xs:anyAttribute processContents="lax"></xs:anyAttribute>
</xs:complexType>
</xs:element>

</xs:schema>


Пример файл-листа:

HTML
<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<FileListing Version="1" CID="mycid" Generator="DC++ 0.701" Base="/">
<Directory Name="share">
<Directory Name="DC++ Prerelease">
<File Name="DCPlusPlus.pdb" Size="17648640" TTH="xxx" />
<File Name="DCPlusPlus.exe" Size="946176" TTH="yyy" />
</Directory>
<File Name="ADC.txt" Size="154112" TTH="zzz" />
</Directory>
<!-- Только при использовании частичного файл-листа -->
<Directory Name="share2" Incomplete="1"/>
</FileListing>


"encoding" должен быть всегда установлен в UTF-8. Клиенты должны иметь возможность оперировать с XML фалами как с BOM (byte order mark) так и без такового.

"Version" не изменяется, если не изменяется структура файла.

"CID" - это CID клиента, который генерирует файл-лист.

"Generator" - это опция для информативной цели.

"Base" - используется в частичных файл-листах, но также должно присутствовать и в простых файл-листах.

"Incomplete" - сигнализирует о том, что в частичном файл-листе содержатся не включённые в список пункты. "1" - означает, что директория содержит не включённые в список пункты, "0" - не содержит таковых. Incomplete="0" - по умолчанию и таким образом может быть опущено.

Дополнительная информация может быть добавлена в файл расширениями/дополнениями, но не гарантировано, что эта информация будет прочитана другими клиентами.

Автор: Setuper 13.6.2009, 15:11

5. Команды характеристики BASE

ADC клиенты/хабы, которые поддерживают основные команды должны отсылать характеристику "BASE" на стадии PROTOCOL.

Версия данной характеристики должна быть известны как клиенту, так и серверу. Сервер постоянно проверяет тип передачи. Для каждой команды определены возможные направления её передачи.

Направления передачи определяет то, каким образом команда может быть получена/послана. Хабы и клиенты могут поддерживать в дополнениях и другие направления передачи, однако, для характеристики BASE определены следующие направления:



Далее, в описаниях команд, первый символ, который отвечает за направление, будет опускаться.

Автор: Setuper 13.6.2009, 15:31

5.1. Клиент – Хаб взаимодействие

Вход на хаб имеет определённую последовательность.
Непосредственно сам вход осуществляется на стадии под названием NORMAL.

Последовательность входа на хаб (стадии):

  1. PROTOCOL - отсылка поддерживаемых характеристик
  2. IDENTIFY - идентификация пользователя, статические проверки
  3. VERIFY - проверка пароля
  4. NORMAL - нормальная операция
  5. DATA - для двоичных передач



Последовательность входа на хаб:

Код
Клиент -> Хаб: HSUP ADBASE ADTIGR ...
Хаб -> Клиент: ISUP ADBASE ADTIGR ...
Хаб -> Клиент: ISID <Client-SID> ...
Хаб -> Клиент: IINF HU1 HI1 ...
Клиент -> Хаб: BINF <My-SID> ID... PD...
Хаб -> Клиент: IGPA ...
Клиент -> Хаб: HPAS ...
Хаб -> Клиент: BINF <To All Clients>
Хаб -> Клиент: BINF <Client-SID>


В отличие от NMDC протокола, в ADC протоколе первая команда следует со стороны клиента, а не со стороны хаба.

Автор: Setuper 13.6.2009, 15:33

5.2. Клиент – Клиент взаимодействие

Клиент - клиент соединение использует ту же самую последовательность входа, что и клиент - хаб соединение, исключая стадию VERIFY и команды GPA/PAS.
Поддержка VERIFY/GPA/PAS должны объявляться дополнениями.
Клиент, который первый отослал команду CTM/RCM, будет контролировать соединение, после достижения между клиентами стадии NORMAL.

Автор: Setuper 13.6.2009, 15:41

5.3. Команды
Основные команды протокола ADC


Автор: Setuper 14.3.2011, 15:06

STA

Синтаксис:

Код
STA separator code separator description



Направления:

F, T, C, U


Стадии:

Все


Описание:

Параметр code имеет формат "xyy", где x - это уровень ошибки, а yy - это код ошибки. Уровень и код ошибки обрабатываются отдельно, один о тот же код может быть на разных уровнях.


Уровни:
  • 0 - успешное выполнение (используется для подтверждения команд), код ошибки должен быть "00", а дополнительный флаг "FC" содержит в себе подтверждение команды FOURCC, если это необходимо;
  • 1 - исправимая ошибка (ошибка, но не дисконнект);
  • 2 - критическая ошибка (дисконнект).



Коды ошибок:
  • 00 - основная ошибка, показ описания;
  • x0 - то же самое, что и 00, но распределенное согласно грубой структуре установленной ниже;
  • 10 - основная ошибка хаба;
  • 11 - хаб переполнен;
  • 12 - хаб отключен (не принимает новые входящие соединения);
  • 20 - основная ошибка входа/доступа;
  • 21 - недопустимый ник;
  • 22 - ник занят;
  • 23 - недопустимый пароль;
  • 24 - CID занят;
  • 25 - доступ запрещён, флаг "FC" - это FOURCC последней команды. Отсылается когда пользователю не разрешается выполнить конкретную команду;
  • 26 - только для зарегистрированных пользователей;
  • 27 - недопустимый PID;
  • 30 - кик/бан/дисконнект;
  • 31 - постоянный бан;
  • 32 - временный бан, флаг "TL" показывает число оставшихся секунд (Также используется при кике);
  • 40 - ошибка протокола;
  • 41 - не поддерживаемый протокол передачи, флаг "TO" - признак, флаг "PR" - строка протокола. Клиент, отсылающий команду CTM или RCM, должен отослать эту ошибку, если нет поддержки;
  • 42 - ошибка направленного соединения, флаг "TO" - признак, флаг "PR" - строка протокола. Клиент, отсылающий команду CTM или RCM, должен отослать эту ошибку, если нет соединения;
  • 43 - команда INF содержит ошибки, флаг "FM" - поле команды, "FB" - ошибочное поле;
  • 44 - неправильное состояние, флаг "FC" показывает последнюю FOURCC команду;
  • 45 - ошибка в характеристике, флаг "FC" показывает FOURCC ошибку характеристики;
  • 46 - указан неверный IP в команде INF, флаг "I4" или "I6" показывает правильный IP;
  • 47 - нет одинаковых характеристик в командах SUP хаба и клиента;
  • 50 - клиент-клиент / ошибка передачи файла;
  • 51 - файл недоступен;
  • 52 - часть файла недоступна;
  • 53 - нет свободного слота;
  • 54 - нет одинаковых характеристик в командах SUP связываемых клиентов.



Замечания:

Параметр "description" содержит описание ошибки, для просмотра этого описания пользователем.

Даже если код ошибки неизвестен клиенту, он должен отображать текстовое сообщение. Коды ошибок используются для того, чтобы клиенты могли использовать различные действия на различные ошибки. Большинство кодов не содержат никаких параметров и могут использоваться только с типами команд C и I.

Автор: Setuper 14.3.2011, 15:08

SUP

Синтаксис:

Код
SUP (separator ('AD' | 'RM') feature)+



Направления:

F, T, C


Стадии:

PROTOCOL, NORMAL


Описание:

Данная команда определяет какие характеристики будут использоваться со стороны хаба и со стороны клиента. Название характеристики должно состоять из четырёх латинских букв верхнего регистра, при этом последним символом может быть цифра, которая указывает на версию характеристики. Первые же три символа должны быть исключительно латинскими буквами в верхнем регистре, дабы избежать каких-либо конфузов между различными ПО. Все без исключения ADC клиенты должны поддерживать BASE характеристику (или какую-либо её версию). Как сервер, так и клиент могут использовать любую характеристику, указанною другой стороной в команде SUP.

Указанная команда также может использоваться для динамического добавления или удаления характеристик. Префикс AD перед характеристикой указывает на то, что характеристика добавляется, префикс RM - указывает на удаление характеристики.

Когда хаб получает данную команду на стадии входа PROTOCOL, он должен ответить клиенту такой же командой со своими характеристиками, а также назначить клиенту SID и опционально отослать командой INF информацию о себе, и далее перейти на стадию IDENTIFY.

Когда при взаимодействии клиент-клиент один из клиентов получает данную команду на стадии PROTOCOL, он должен ответит такой же командой со своими характеристиками, отправить команду INF о себе и перейти на стадию IDENTIFY.

Автор: Setuper 14.3.2011, 15:09

SID

Синтаксис:

Код
SID separator sid



Направления:

F


Стадии:

PROTOCOL


Описание:

Данная команда назначает SID пользователю, который входит на хаб. Хаб должен отослать эту команду после команды SUP, но до команды INF на стадии PROTOCOL. Клиент, получивший эту команду, должен отослать на хаб информацию о себе командой INF.

Автор: Setuper 14.3.2011, 15:10

INF

Синтаксис:

Код
INF separator sid (separator param)+



Направления:

F, T, C


Стадии:

IDENTIFY, NORMAL


Описание:

Данная команда призвана помочь получить обновлённую информацию о клиенте. При её получении, соответствующие параметры добавляются или обновляются. Имя каждого параметра определяется при помощи двух символов, за которыми следуют данные, определяющие значение этого параметра. Значение того или иного параметра может быть стёрто путём отсылки одного только названия параметра (без данных). Клиенты должны игнорировать неизвестные им параметры. Большинство из параметров данной команды интересны только при клиент-хаб соединении. При соединении клиент-клиент данная команда в основном используется только для идентификации. Хабы могут требовать или игнорировать какие-либо или все параметры. Многие из параметров, такие как шара и версия клиента, носят чисто информативный характер и должны быть взяты как есть, ибо их очень легко можно подделать.
Однако, клиенты должны стремиться отсылать точные данные о себе для обеспечения общей целостности всей системы, так как неверная информация может раздражать некоторых людей. Для обновления каких-то параметров достаточно отослать только эти изменения, а не все параметры.


Параметры:

Параметры
Имя: ID
Тип: base32
Описание: CID клиента (необходим для соединения клиент-клиент).


Имя: PD
Тип: base32
Описание: PID клиента. Хабы должны проверять, что TigerHash(PID) == CID и удалять это поле прежде чем рассылать остальным клиентам. Данный параметр не должен отсылаться при соединении клиент-клиент.


Имя: I4
Тип: IPv4
Описание: IPv4 адрес без порта. Пустой адрес (0.0.0.0) означает, что хаб должен заменить его реальным IP адресом клиента. Хабы должны проверять соответствие между IP адресом в данном параметре и реальным IP адресом клиента чтобы избегать DDoS атак. Клиенты могут отсылать пустой адрес, а могут отсылать правильный IP адрес. Каждый клиент, который поддерживает прямое соединение TCPv4 (актив) должен отослать TCP4 в параметре SU.


Имя: I6
Тип: IPv6
Описание: IPv6 адрес без порта. Пустой адрес (:big_smile.gif означает, что хаб должен заменить его реальным IP адресом клиента. Каждый клиент, который поддерживает прямое соединение TCPv6 (актив) должен отослать TCP6 в параметре SU.


Имя: U4
Тип: целое число
Описание: UDP порт клиента. Все клиенты, которые поддерживают входящие UDPv4 пакеты должны отсылать UDP4 в параметре SU.


Имя: U6
Тип: целое число
Описание: UDP порт клиента. Все клиенты, которые поддерживают входящие UDPv6 пакеты должны отсылать UDP6 в параметре SU.


Имя: SS
Тип: целое число
Описание: размер расшаренных данных в байтах


Имя: SF
Тип: целое число
Описание: число расшаренных файлов


Имя: VE
Тип: строка
Описание: идентификатор клиента и версии (рекомендуется короткий идентификатор и точный номер версии)


Имя: AP
Тип: строка
Описание: идентификатор клиента (application)


Имя: US
Тип: целое число
Описание: максимальная скорость закачки (байт/сек)


Имя: DS
Тип: целое число
Описание: максимальная скорость скачки (байт/сек)


Имя: SL
Тип: целое число
Описание: максимальное число одновременных закачек (слоты)


Имя: AS
Тип: целое число
Описание: автоматический скоростной предел слота (байт/сек). Клиент держит открытым слот до тех пор, пока скорось загрузки не превысит указанную величину


Имя: AM
Тип: целое число
Описание: минимальное количество одновременных загрузок (автоматических режим)


Имя: EM
Тип: строка
Описание: E-mail адрес


Имя: NI
Тип: строка
Описание: ник (или имя хаба). Хаб должен гарантировать, что указанный ник уникален на хабе вплоть до регистра. Правильным считается ник, в котором все символы с юникодами больше 32, хотя хабы могут сами регулировать запрещённые символы в нике и выдавать соответствующее сообщение


Имя: DE
Тип: строка
Описание: описание. Правильным считается описание, в котором все символы с юникодами больше либо равны 32


Имя: HN
Тип: целое число
Описание: число хабов, на которых клиент является незарегистрированным пользователем в NORMAL состоянии


Имя: HR
Тип: целое число
Описание: число хабов, на которых клиент является зарегистрированным (должен отправить пароль) пользователем в NORMAL состоянии


Имя: HO
Тип: целое число
Описание: число хабов, на которых клиент является оператором в NORMAL состоянии


Имя: TO
Тип: строка
Описание: признак получения RCM/CTM команд при установке связи клиент-клиент


Имя: CT
Тип: целое число
Описание: Тип клиента. 1 - бот, 2 - зарегистрированный, 4 - оператор, 8 - супер юзер, 16 - владелец хаба, 32 - сам хаб (используется при отсылке INF команды самим хабом)


Имя: AW
Тип: целое число
Описание: состояние клиента. 1 - away, 2 - расширенный away - не заинтересован в чате хаба (хабы могут не рассылать массовые сообщения клиентам с таким флагом)


Имя: SU
Тип: строка
Описание: список характеристик, разделённых запятой. Данный параметр служит для уведомления о характеристиках соединенного клиента


Имя: RF
Тип: строка
Описание: URL для перенаправления (хаб или веб страница)



Замечание:

Обычно только один IP адрес (I4 or I6) используется для всех соединений. Нужно проявлять осторожность при приёме соединений с неизвестного IP. Только проверенным пользователям можно разрешать использовать различные IP адреса. Если пренебречь проверкой соответствия IP, то хаб может быть использован для организации DDoS атак.


Когда хаб получает данную команду на стадии IDENTIFY, он должен проверить параметры PD и ID, и либо перейти на стадию VERIFY, отослав команду PAS, либо перейти на стадию NORMAL, отослав собственную информацию командой INF (если это не было сделано раньше), затем отослать команды INF всех подключенных клиентов на стадии NORMAL, и в последнюю очередь отослать всем команду INF соединенного клиента. После того как хаб отослал свою команду INF, в параметре NI будет название хаба, в параметре VE - название платформы хаба и версия, и в параметре DE - топик хаба (описание хаба).

Когда клиент получает данную команду при соединении клиент-клиент на стадии IDENTIFY, он должен сопоставить параметры ID и TO, отосланные в команде INF и перейти на стадию NORMAL.


Примеры:
Код
IINF AAAA VEверсия\sхаба NIназвание\sхаба DEописание\sхаба

Код
BINF AAB3 IDWYCH3RE46Z3JX3J3P3P33NYMVQSSBNVERQTNFVA NIник SL5 SS184304078130 SF1339 HO0 VEApexDC++\s1.3.6 US65536 SUNAT0 I410.10.10.10 HN7 HR1 FS4

Автор: Setuper 14.3.2011, 15:10

MSG

Синтаксис:

Код
MSG separator sid (separator pm-sid)? separator text (separator ME1)? (separator PM sid)?



Направления:

F, T


Описание:

Сообщение чата. Клиент, который получает сообщение должен заключить ник в символы <>, для однотипного отображения.


Параметры:

Для отсылки личного сообщения указывается параметр pm-sid - это SID клиента, которому предназначено сообщение. Это поле должно содержать реальный SID если это нормальный личный разговор.

ME1 - сообщение должно быть отображено как /me в IRC ("*nick text")

TS1234567890 - unix время отправки сообщения


Примеры:

Сообщение чата:
Код
BMSG AAAA Всем\sпривет

Сообщение от третьего лица в чат:
Код
BMSG AAAA слушает\sхорошую\sмузыку ME1

Сообщение в личку:
Код
EMSG AAAA AAAB привет PMAAAA

Сообщение от третьего лица в личку:
Код
EMSG AAAA AAAB слушает\sхорошую\sмузыку ME1 PMAAAA

Автор: Setuper 14.3.2011, 15:11

SCH

Синтаксис:

Код
SCH separator sid (separator param)+



Направления:

F, T, C, (U)


Описание:

Команда поиска. Каждый параметр данной команды состоит из имени и значения, следующего за именем. Имя параметра состоит из 2 символов (арабские буквы верхнего регистра и/или цифры). Клиенты должны игнорировать неизвестные параметры и производить поиск так, как будто они не передавались. Если все параметры для клиента являются неизветсными, то клиент должен проигнорировать команду и не искать ничего.


Параметры:

Параметры
Имя: AN, NO, EX
Описание: поисковый запрос, где AN - означает "и" т.е. включать (and), NO - не включать (and not), EX - расширение.
Поиск указанного файла (а также пути к нему) должен осуществляться регистронезависимым образом по подстроке, которая указана в параметре AN, при этом из результатов поиска нужно удалить результаты, которые содержат подстроку, указанную в параметре NO, и в конце оставить результаты с указанным в параметре EX расширением (если этот параметр указан). Параметр EX должен быть без символа '.' спереди


Имя: LE
Описание: верхняя граница размера файла (в байтах)


Имя: GE
Описание: нижняя граница размера файла (в байтах)


Имя: EQ
Описание: точный размер файла (в байтах)


Имя: TO
Описание: метка. Используется клиентом для того чтобы отличать один поиск от другого. Если этот параметр присутствует с команде поиска, то клиент, получивший эту команду, должен скопировать этот параметр в свою команду с ответом (результатом поиска)


Имя: TY
Описание: тип поиска. Если этот параметр не указан, то любой тип поиска, иначе 1 - поиск файла, 2 - поиск директории



Замечание:

Поиск по UDP может подменять IP адрес, и поэтому может быть средством для DDoS атаки. Поиск по UDP следует разрешать только для проверенных клиентов.


Примеры:

Пассивный поисковый запрос:
Код
FSCH AABO +TCP4-NAT0 TOauto TRI5YBDRKG6KEDTVZ6ABZDYSVURSSRUHKUHWZILGA


Активные поисковые запросы:
Код
BSCH AAAA TRTVHBXNPAJVRUDNCTJQ5CEACEG2JDEJNAYMH343Y TO3179684286
BSCH AACG TOauto TRQQHYGSUGZ5TWAOJWQNJ6RNA34T6LOSZSBHQ7V4Y
BSCH AACQ TRGTVC3IRS6J6QI2DXPFFAPFC6IQ7UAZ6AISSUEQY TOauto

Автор: Setuper 14.3.2011, 15:11

RES

Синтаксис:

Код
RES separator sid (separator param)+



Направления:

F, T, C, U


Описание:

Команда для отсылки результатов поиска. Команда построена по подобию команды INF. Клиенты должны отдавать в этой команде имя файла, sid, размер и метку, а также могут отдавать какие-то дополнительные параметры если таковые доступны. На пассивный поиск каждый клиент в ответ может отсылать до пяти результатов, на активный - до десяти. При пассивном поиске команда отсылается клиенту через хаб, при активном - напрямую. Пассивность клиента определяется из параметра SU команды INF.


Параметры:

Параметры
Имя: FN
Описание: полное имя файла в шаре (включая путь к файлу)


Имя: SI
Описание: размер в байтах


Имя: SL
Описание: текущее доступное число слотов


Имя: TO
Описание: метка

Автор: Setuper 14.3.2011, 15:12

CTM

Синтаксис:

Код
CTM protocol separator port separator token



Направления:

F, T


Описание:

Запрос на активное соединение (ConnectToMe). Используется активными клиентами для соединения с такими же активными клиентами или для ответа на RCM команду. Только активные TCP клиенты могут отсылать эту команду. token - это строка, которая идентифицирует входящее соединение и должна присутствовать в команде INF соединяемого клиента. Клиенты не должны принимать входящие соединения, если до этого не была послана данная команда. protocol - это произвольная строка, которая указывает на протокол для соединения. В случае соединения по протоколу ADC 1.0 эта строка должна иметь вид "ADC/1.0". Если протокол поддерживается клиентом, то в ответ на RCM должны быть скопированы параметры token и protocol. Если протокол не поддерживается, то должна быть отправлена команда DSTA, которая указывает на возникшую ошибку.

Автор: Setuper 14.3.2011, 15:12

RCM

Синтаксис:

Код
RCM protocol separator token



Направления:

F, T


Описание:

Команда на пассивное соединение (Reverse CTM). Пассивный клиент запрашивает соединение с активным клиентом.

Автор: Setuper 14.3.2011, 15:13

GPA

Синтаксис:

Код
GPA data



Направления:

F


Стадии:

VERIFY


Описание:

Команда на запрос пароля. Параметр data - это не менее 24 случайных символов (в base32 кодировке)

Автор: Setuper 14.3.2011, 15:13

PAS

Синтаксис:

Код
PAS password



Направления:

T


Стадии:

VERIFY


Описание:

Команда для отсылки пароля. Пароль (в кодировке utf-8) следует за случайными данными, которые получены при помощи SID и конвертированы в base32. Если проверка пароля прошла успешно, хаб переводит клиента на стадию NORMAL.

Автор: Setuper 14.3.2011, 15:14

QUI

Синтаксис:

Код
QUI sid



Направления:

F


Стадии:

IDENTIFY, VERIFY, NORMAL


Описание:

Команда, которая указывает на то, что клиент с указанным sid ушёл с хаба. Если SID принадлежит клиенту, которому отсылается данная команда, то это должно означать, что к данному клиенту были приняты какие-то меры (дроп, кик, бан, перенаправление). Хаб не должен посылать клиенту какие-либо данные после того как он отослал ему команду QUI.

Команда может содержать следующие параметры:

ID - SID палача (например того, кто кикнул)
TL - время бана в секундах (Time Left). -1 - постоянный бан
MS - причина
RD - адрес перенаправления
DI - любой клиент который имеет этот параметр в QUI должен закрыть все соединения с другими клиентами


Примеры:
Код
IQUI AAAA

Автор: Setuper 14.3.2011, 15:14

GET

Автор: Setuper 14.3.2011, 15:15

GFI

Автор: Setuper 14.3.2011, 15:15

SND