Обзор протоколов работы

DMconnect

Ознакомительный документ

Автор: Сухарь Сухаревич
DMC: PredoK_CyXaR
Помощь: BitByByte, Octavian.

• Спецификация DMC протокола
  • Версия v3
    Обмен между сервером и клиентом
    •    Доставка сообщения серверу
    •    Доставка сообщения клиенту
    Обмен данными напрямую
• Заключение

Протокол DMconnect (DMC в сокращении) подразумевает обмен сообщений между клиентом и сервером с помощью "сырых" данных, т. е. лишь закодированных в определённую кодировку - UTF-8. По сути, это позволяет читать сообщения DMC хоть из Telnet-программ.

Версия v3 - самая новая на данный момент версия, имеющая уйму возможностей. Ниже приведён краткий справочник по основным возможностям данной ветки протокола.

Как можно понять из вышеприведённой таблицы, все команды, отправляемые клиентом серверу через сеть, начинаются с HEX-символа 2F. Согласно данному символу сервер определяет, что перед ним - команда, а не просто какое-либо сообщение. Для ответа на команду сервер использует определённый массив вариантов, отдаёт их также в кодировке UTF-8, однако, начинающий HEX-символ у всех ответов отличается. Вот лишь некоторые примеры:

Поэтому обычно ответы от севера не обрабатываются какими-то специальными методами, а отправляются в "сыром" виде. Отметим, что при работе клиента по TCP, системные сообщения приходят с завершающим символом 0x0D. Пример:

53 65 6C 65 63 
74 20 61 20 73 
65 72 76 65 72
20 75 73 69 6E 
67 20 2F 6A 6F 
69 6E 5F 73 65 
72 76 65 72 20 
3C 73 65 72 76 
65 72 5F 6E 61 
6D 65 3E 2E 00 (0x0D)

Поэтому клиенты DMconnect используют обработчик, который автоматически удаляет символы 0x0D и 00 из серверных ответов. Пример работы клиента без обработчика:

Enter command (/login /register):

Login successful.

Available servers: general, narod_discussion
Select a server using /join_server <server_name>.

Это всё, что можно было сказать по поводу спецификации протокола.

Рассмотрим метод обмена сообщениями более подробно. Как вы уже читали выше, все служебные команды отправляются пользователем с начинающим HEX-символом 2F, но что делать с обычными сообщениями? Здесь всё предельно просто: клиент отправляет серверу своё сообщение, закодированное в UTF-8, а сервер - ретранслирует сообщение отправителя всем пользователям на подсервере, попутно редактируя структуру сообщения. Пример:

\xd0\x9f\xd1\x80\xd0\xb8\xd0\xb2\xd0\xb5\xd1\x82
(сообщение "Привет" в кодировке UTF-8, представлено в байтах)

D0 9F D1 80 D0 B8 D0 B2 D0 B5 D1 82 
(это же сообщение в кодировке UTF-8, но в HEX)

TestAcc: \xd0\x9f\xd1\x80\xd0\xb8\xd0\xb2\xd0\xb5\xd1\x82
(сервер сформирует такое сообщение, при условии, что имя нашего аккаунта - TestAcc)

TestAcc: Привет
(сообщение после декодирования в обычный текст, делается с помощью обработчика в клиенте)

При отправке сообщения на сервер, клиент должен указать начинающий HEX-символ (см. выше), для команд являющийся 2F. Для обычных сообщений данный символ не нужен, ибо приведёт только к ответу:

Unkown command.

Почему? Ещё раз перечитайте начало раздела. Для доставки все сообщения клиента кодируются в UTF-8, но что делать серверу, если клиент этого не сделал? Севрер повторно переведёт приходящее сообщение клиента в UTF-8, а оптравит уже свой результат перевода. Таким образом, никаких конфликтов кодировок не возникает.

Доставка сообщения клиенту

Все свои сообщения сервер, как вы могли догадаться, представляет также в UTF-8. Варианты с любыми другими кодировками - исключены. Отправка сообщения сервером будет выглядеть примерно так:

TestAcc: \xd0\x9f\xd1\x80\xd0\xb8\xd0\xb2\xd0\xb5\xd1\x82 --> TestAcc: Привет
(сервер отправит такое сообщение в UTF-8)                     (так должна пройти декодировка
                                                                сообщения сервера клиентом)

Тем не менее, процесс обработки латиницы куда проще:

TestAcc: Hello --> TestAcc: Hello <- результат декодировки. Обычно в клиентах для кириллицы / латиницы используется один обработчик.
  ^^^
(сервер отправит такое сообщение в UTF-8)

В DMconnect не поддерживается, однако некоторые клиенты могут иметь данную функцию в виде дополнительной. Чаще всего, в таких случаях происходит обмен в формате P2P (из точки в точку).

Надеюсь, данный документ помог вам в ознакомлении с протоколом DMconnet. Документ был сделан Российским Содружеством Даунгрейдеров при поддержке Сухаря Сухаревича (DMC: PredoK_CyXaR). Спасибо за внимание!