Описание протокола ADC

Материал из MyDC's Wiki

Перейти к: навигация, поиск

Структурированное описание протокола Advanced Direct Connect (ADC).

Содержание

Введение

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.

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

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

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

Последующие версии этого документа, а также промежуточные и более старые версии могут быть получены по адресу: https://dcplusplus.svn.sourceforge.net/svnroot/dcplusplus/dcplusplus/trunk/ADC.txt . Эта версия представляется к ревизии:

Версия 1.0.1, 2008-05-02

Версия 1.0, 2007-12-01

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









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

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             ::= ' '

message_header - зарезервировано под возможные дополнительные команды (будем считать эти команды как неизвестные). Команда, которая не содержит message_body, является командой пинга.

Типы команд

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


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.

Хеш-функции

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

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

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

SID

PID

CID

Файлы

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

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

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

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

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

Файл-лист

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

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

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

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

От хаба (хаб-клиент TCP)
К хабу (хаб-клиент TCP)
Между клиентами (клиент-клиент TCP)
Между клиентами (клиент-клиент UDP)

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

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

Вход на хаб имеет определённую последовательность. Непосредственно сам вход осуществляется на стадии под названием 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 протоколе первая команда следует со стороны клиента, а не со стороны хаба.

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

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

Клиент, который первый отослал команду CTM/RCM, будет контролировать соединение, после достижения между клиентами стадии NORMAL.

Команды

STA

SUP

SID

INF

MSG

SCH

RES

CTM

RCM

GPA

PAS

QUI

GET

GFI

SND


Примеры

Связь Клиент – Хаб

Связь Клиент – Клиент

Стандартные дополнения/расширения

TIGR - поддержка TTH (Tiger Tree Hash)

BZIP – сжатие файл-листа пи помощи библиотеки bzip

ZLIB - сжатие данных

Ссылки

Оригинальное описание на английском языке

Источник — «http://wiki.mydc.ru/%D0%9E%D0%BF%D0%B8%D1%81%D0%B0%D0%BD%D0%B8%D0%B5_%D0%BF%D1%80%D0%BE%D1%82%D0%BE%D0%BA%D0%BE%D0%BB%D0%B0_ADC»
Личные инструменты
Пространства имён
Варианты
Действия
Навигация
RusHub
Инструменты
Портал