|
Здравствуйте, гость ( Вход | Регистрация )
|
![]() ![]()
Сообщение
#1
|
|
![]() RusHub team lead ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() Группа: Модераторы Сообщений: 4 030 Регистрация: 20.6.2008 Из: г. Королёв (Моск. обл.) Пользователь №: 46 Спасибо сказали: 1708 раз ![]() |
Структурированное описание протокола Advanced Direct Connect (ADC), под управлением которого уже работают некоторые хабы.
Ссылка на оригинальное описание: По мере написания, в содержании будет появляться ссылка на соответствующий пост. Делаю тему закрытой, дабы структурировано всё описать. 1. Введение 2. История версий 3. Структура протокола 3.1. Основное 4. Файлы 4.1. Имена файлов и структура 5. Команды характеристики BASE 5.1. Клиент – Хаб взаимодействие 6. Примеры 6.1. Связь Клиент – Хаб 7. Стандартные дополнения/расширения 7.1. TIGR - поддержка TTH (Tiger Tree Hash) |
|
|
![]() |
![]()
Сообщение
#2
|
|
![]() RusHub team lead ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() Группа: Модераторы Сообщений: 4 030 Регистрация: 20.6.2008 Из: г. Королёв (Моск. обл.) Пользователь №: 46 Спасибо сказали: 1708 раз ![]() |
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. Преимущества протокола:
Недостатки протокола:
|
|
|
![]()
Сообщение
#3
|
|
![]() RusHub team lead ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() Группа: Модераторы Сообщений: 4 030 Регистрация: 20.6.2008 Из: г. Королёв (Моск. обл.) Пользователь №: 46 Спасибо сказали: 1708 раз ![]() |
2. История версий
Последующие версии этого документа, а также промежуточные и более старые версии могут быть получены по адресу: Данная версия: 1.0, 2007-12-01 (Первый релиз) |
|
|
![]()
Сообщение
#4
|
|
![]() RusHub team lead ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() Группа: Модераторы Сообщений: 4 030 Регистрация: 20.6.2008 Из: г. Королёв (Моск. обл.) Пользователь №: 46 Спасибо сказали: 1708 раз ![]() |
3. Структура протокола
3.1. Основное
|
|
|
![]()
Сообщение
#5
|
|
![]() RusHub team lead ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() Группа: Модераторы Сообщений: 4 030 Регистрация: 20.6.2008 Из: г. Королёв (Моск. обл.) Пользователь №: 46 Спасибо сказали: 1708 раз ![]() |
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 ::= ' ' |
|
|
![]()
Сообщение
#6
|
|
![]() RusHub team lead ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() Группа: Модераторы Сообщений: 4 030 Регистрация: 20.6.2008 Из: г. Королёв (Моск. обл.) Пользователь №: 46 Спасибо сказали: 1708 раз ![]() |
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. |
|
|
![]()
Сообщение
#7
|
|
![]() RusHub team lead ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() Группа: Модераторы Сообщений: 4 030 Регистрация: 20.6.2008 Из: г. Королёв (Моск. обл.) Пользователь №: 46 Спасибо сказали: 1708 раз ![]() |
3.4. Хеш-функции
Некоторые команды используются для определяния хеш-функций. При установке каждого нового соединения по команде SUP происходит обмен хеш-функциями. При коннекте клиент передаёт серверу несколько хеш-функций посредствам параметров команды SUP. Сервер вбирает одну из них и передаёт её клиенту, поставив её до любой другой хеш-функции в команде SUP, которая отправится с сервера. Клиент и хаб должны иметь по крайней мере одну одинаковую хеш-функцию, которая будет использоваться в протоколе и в файловой идентификации. |
|
|
![]()
Сообщение
#8
|
|
![]() RusHub team lead ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() Группа: Модераторы Сообщений: 4 030 Регистрация: 20.6.2008 Из: г. Королёв (Моск. обл.) Пользователь №: 46 Спасибо сказали: 1708 раз ![]() |
3.5. Идентификация клиента
Каждый клиент идентифицируется по трём различным идентификаторам: идентификатор сессии - Session ID (SID), личный идентификатор - Private ID (PID) и идентификатор клиента - Client ID (CID). |
|
|
![]()
Сообщение
#9
|
|
![]() RusHub team lead ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() Группа: Модераторы Сообщений: 4 030 Регистрация: 20.6.2008 Из: г. Королёв (Моск. обл.) Пользователь №: 46 Спасибо сказали: 1708 раз ![]() |
3.5.1. SID
Идентификатор сессии даётся клиенту на сессию, в течение которой он находится на хабе. Это идентификатор уникального пользователя на хабе, который назначается при входе на хаб. SID - 20-битный код, закодированный 4-байтной base32 строкой. |
|
|
![]()
Сообщение
#10
|
|
![]() RusHub team lead ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() Группа: Модераторы Сообщений: 4 030 Регистрация: 20.6.2008 Из: г. Королёв (Моск. обл.) Пользователь №: 46 Спасибо сказали: 1708 раз ![]() |
3.5.2. PID
Приватный идентификатор глобально идентифицирует уникальных клиентов. Он используется при коннекте для генерации CID и не виден другим клиентам. PID генерируется для того, чтобы избежать конфузов. При генерации PID (при первом запуске клиента) используется текущее время и MAC адрес сетевой карты. Хабы и клиенты не должны раскрывать приватные идентификаторы другим клиентам, так как это нарушает безопасность ADC сетей. Клиенты должны иметь один и тот же PID в течение всей сессии на хабе. Клиент отсылает на хаб данный идентификатор в команде INF. Хаб удаляет из команды INF этот идентификатор перед тем как отослать команду INF всем пользователям хаба. |
|
|
![]()
Сообщение
#11
|
|
![]() RusHub team lead ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() Группа: Модераторы Сообщений: 4 030 Регистрация: 20.6.2008 Из: г. Королёв (Моск. обл.) Пользователь №: 46 Спасибо сказали: 1708 раз ![]() |
3.5.3. CID
Идентификатор клиента глобально и публично идентифицирует уникальные клиенты и лежит в основе связи между клиентами. Он генерируется по PID по определённому алгоритму. Хаб должен регистрировать клиентов по CID-у. CID должен оставаться неизменным в течении сессии. Клиенты должны уметь оперировать с CID-ми переменной длины. |
|
|
![]()
Сообщение
#12
|
|
![]() RusHub team lead ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() Группа: Модераторы Сообщений: 4 030 Регистрация: 20.6.2008 Из: г. Королёв (Моск. обл.) Пользователь №: 46 Спасибо сказали: 1708 раз ![]() |
4. Файлы
4.1. Имена файлов и структура Имена файлов отсчитываются от относительного (вымышленного) корня в шаре пользователя. "/" - разделитель директорий; каждый файл или имя директории должно быть уникальным в регистро-независимом контексте. Все печатные символы, включая пробел, допустимы в имени файла, символы "/" и "\" экранируются символом "\". Клиенты должны использовать фильтры для имён под свои файловые системы, имена файлов, полученные от других клиентов, должны также подчиняться этим правилам. Специальные имена "." и ".." не могут содержаться в директории или имени файла; любой полученный файл-лист, содержащий эти имена должен быть проигнорирован. Все имена директорий должны оканчиваться на "/". Расшаренные файлы идентифицируются относительно безымянного корня "/" ("/dir/subdir/filename.ext"), тогда как дополнения могут добавить имя корня. Например, "TTH/…" для TIGR дополнения используют имя корня "TTH" для идентификации файлов по их "Tiger Tree Hash". Это недопустимо для имён из безымянного корня, которые попали в шару с идентификатором по контрольной сумме. Без корневое имя файла "files.xml" определяет полный файл-лист, в формате XML в кодировке UTF-8. Клиентам рекомендуется использовать дополнения чтобы сжимать данный файл-лист. Дополнения могут добавлять к имени файла свои расширения, обычно это делается для того, чтобы избежать повторения имён. Специальный тип "list" используется для просмотра списков файлов. Частичный файловый список имеет ту же структуру, что и нормальный список, но директории могут быть теговыми с атрибутом Incomplete="1", который показывает на частичность. Только директории без корневых файлов могут начинаться с символа "/". Содержимое такой директории в последствии будет послано просящему клиенту на глубину, выбранную им (это нужно для отправки только того уровня, который требуется пользователю). Атрибут "Base" для поля "FileListing" определяет к какой конкретной директории принадлежит данный файл. |
|
|
![]()
Сообщение
#13
|
|
![]() RusHub team lead ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() Группа: Модераторы Сообщений: 4 030 Регистрация: 20.6.2008 Из: г. Королёв (Моск. обл.) Пользователь №: 46 Спасибо сказали: 1708 раз ![]() |
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" - по умолчанию и таким образом может быть опущено. Дополнительная информация может быть добавлена в файл расширениями/дополнениями, но не гарантировано, что эта информация будет прочитана другими клиентами. |
|
|
![]()
Сообщение
#14
|
|
![]() RusHub team lead ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() Группа: Модераторы Сообщений: 4 030 Регистрация: 20.6.2008 Из: г. Королёв (Моск. обл.) Пользователь №: 46 Спасибо сказали: 1708 раз ![]() |
5. Команды характеристики BASE
ADC клиенты/хабы, которые поддерживают основные команды должны отсылать характеристику "BASE" на стадии PROTOCOL. Версия данной характеристики должна быть известны как клиенту, так и серверу. Сервер постоянно проверяет тип передачи. Для каждой команды определены возможные направления её передачи. Направления передачи определяет то, каким образом команда может быть получена/послана. Хабы и клиенты могут поддерживать в дополнениях и другие направления передачи, однако, для характеристики BASE определены следующие направления:
Далее, в описаниях команд, первый символ, который отвечает за направление, будет опускаться. |
|
|
![]()
Сообщение
#15
|
|
![]() RusHub team lead ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() Группа: Модераторы Сообщений: 4 030 Регистрация: 20.6.2008 Из: г. Королёв (Моск. обл.) Пользователь №: 46 Спасибо сказали: 1708 раз ![]() |
5.1. Клиент – Хаб взаимодействие
Вход на хаб имеет определённую последовательность. Непосредственно сам вход осуществляется на стадии под названием NORMAL. Последовательность входа на хаб (стадии):
Последовательность входа на хаб: Код Клиент -> Хаб: 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 протоколе первая команда следует со стороны клиента, а не со стороны хаба. |
|
|
![]()
Сообщение
#16
|
|
![]() RusHub team lead ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() Группа: Модераторы Сообщений: 4 030 Регистрация: 20.6.2008 Из: г. Королёв (Моск. обл.) Пользователь №: 46 Спасибо сказали: 1708 раз ![]() |
5.2. Клиент – Клиент взаимодействие
Клиент - клиент соединение использует ту же самую последовательность входа, что и клиент - хаб соединение, исключая стадию VERIFY и команды GPA/PAS. Поддержка VERIFY/GPA/PAS должны объявляться дополнениями. Клиент, который первый отослал команду CTM/RCM, будет контролировать соединение, после достижения между клиентами стадии NORMAL. |
|
|
![]()
Сообщение
#17
|
|
![]() RusHub team lead ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() Группа: Модераторы Сообщений: 4 030 Регистрация: 20.6.2008 Из: г. Королёв (Моск. обл.) Пользователь №: 46 Спасибо сказали: 1708 раз ![]() |
|
|
|
![]()
Сообщение
#18
|
|
![]() RusHub team lead ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() Группа: Модераторы Сообщений: 4 030 Регистрация: 20.6.2008 Из: г. Королёв (Моск. обл.) Пользователь №: 46 Спасибо сказали: 1708 раз ![]() |
STA
Синтаксис: Код STA separator code separator description Направления: F, T, C, U Стадии: Все Описание: Параметр code имеет формат "xyy", где x - это уровень ошибки, а yy - это код ошибки. Уровень и код ошибки обрабатываются отдельно, один о тот же код может быть на разных уровнях. Уровни:
Коды ошибок:
Замечания: Параметр "description" содержит описание ошибки, для просмотра этого описания пользователем. Даже если код ошибки неизвестен клиенту, он должен отображать текстовое сообщение. Коды ошибок используются для того, чтобы клиенты могли использовать различные действия на различные ошибки. Большинство кодов не содержат никаких параметров и могут использоваться только с типами команд C и I. |
|
|
![]()
Сообщение
#19
|
|
![]() RusHub team lead ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() Группа: Модераторы Сообщений: 4 030 Регистрация: 20.6.2008 Из: г. Королёв (Моск. обл.) Пользователь №: 46 Спасибо сказали: 1708 раз ![]() |
SUP
Синтаксис: Код SUP (separator ('AD' | 'RM') feature)+ Направления: F, T, C Стадии: PROTOCOL, NORMAL Описание: Данная команда определяет какие характеристики будут использоваться со стороны хаба и со стороны клиента. Название характеристики должно состоять из четырёх латинских букв верхнего регистра, при этом последним символом может быть цифра, которая указывает на версию характеристики. Первые же три символа должны быть исключительно латинскими буквами в верхнем регистре, дабы избежать каких-либо конфузов между различными ПО. Все без исключения ADC клиенты должны поддерживать BASE характеристику (или какую-либо её версию). Как сервер, так и клиент могут использовать любую характеристику, указанною другой стороной в команде SUP. Указанная команда также может использоваться для динамического добавления или удаления характеристик. Префикс AD перед характеристикой указывает на то, что характеристика добавляется, префикс RM - указывает на удаление характеристики. Когда хаб получает данную команду на стадии входа PROTOCOL, он должен ответить клиенту такой же командой со своими характеристиками, а также назначить клиенту SID и опционально отослать командой INF информацию о себе, и далее перейти на стадию IDENTIFY. Когда при взаимодействии клиент-клиент один из клиентов получает данную команду на стадии PROTOCOL, он должен ответит такой же командой со своими характеристиками, отправить команду INF о себе и перейти на стадию IDENTIFY. |
|
|
![]()
Сообщение
#20
|
|
![]() RusHub team lead ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() Группа: Модераторы Сообщений: 4 030 Регистрация: 20.6.2008 Из: г. Королёв (Моск. обл.) Пользователь №: 46 Спасибо сказали: 1708 раз ![]() |
SID
Синтаксис: Код SID separator sid Направления: F Стадии: PROTOCOL Описание: Данная команда назначает SID пользователю, который входит на хаб. Хаб должен отослать эту команду после команды SUP, но до команды INF на стадии PROTOCOL. Клиент, получивший эту команду, должен отослать на хаб информацию о себе командой INF. |
|
|
![]() ![]() |
Похожие темы
![]() |
Сейчас: 8.9.2024, 2:35 |