Прямой клиент-клиент

Прямое соединение клиент-клиент ( DCC ) (первоначально прямое соединение клиента ^{[ 1 ]}^{[ 2 ]}^{[ 3 ]}) — это IRC подпротокол, связанный с , позволяющий узлам соединяться с использованием IRC-сервера для установления связи с целью обмена файлами или выполнения чатов без ретрансляции. После установления типичный сеанс DCC запускается независимо от IRC-сервера. Первоначально разработанный для использования с ircII , теперь он поддерживается многими клиентами IRC . Некоторые одноранговые клиенты на серверах протокола Napster также имеют возможность отправки/получения DCC, включая TekNap, SunshineUN и Lopster. Вариант протокола DCC, называемый SDCC (Secure Direct Client-to-Client), также известный как DCC SCHAT, поддерживает зашифрованные соединения. Спецификация RFC по использованию DCC не существует.

Соединения DCC могут быть инициированы двумя различными способами:

Самый распространенный способ — использовать CTCP для инициирования сеанса DCC. CTCP отправляется от одного пользователя по сети IRC другому пользователю.
Другой способ инициировать сеанс DCC — это подключение клиента напрямую к серверу DCC. При использовании этого метода трафик не будет проходить через сеть IRC (участвующим сторонам не требуется подключение к сети IRC, чтобы инициировать соединение DCC).

История

ircII был первым клиентом IRC, реализовавшим протоколы CTCP и DCC. ^{[ 4 ]} Протокол CTCP был реализован Майклом Сандрофом в 1990 году для ircII версии 2.1. ^{[ 5 ]} Протокол DCC был реализован Троем Ролло в 1991 году для версии 2.1.2. ^{[ 6 ]} но никогда не предназначался для переноса на другие клиенты IRC. ^{[ 7 ]}^{[ 8 ]}

Общие приложения DCC

ЧАТ DCC

Служба CHAT позволяет пользователям общаться друг с другом через соединение DCC. ^{[ 9 ]} Трафик будет идти напрямую между пользователями, а не по сети IRC. По сравнению с обычной отправкой сообщений это снижает нагрузку на сеть IRC, позволяет отправлять большие объемы текста за один раз из-за отсутствия контроля флуда и делает связь более безопасной, не раскрывая сообщение серверам IRC (однако сообщение все еще находится в открытом тексте ).

DCC CHAT обычно инициируется с помощью подтверждения связи CTCP . Пользователь, желающий установить соединение, отправляет адресату следующий CTCP: DCC CHAT protocol ip port, где ip и port — это IP-адрес и номер порта отправителя, выраженные в виде целых чисел. протокол чат для стандартного DCC CHAT. Принимающая сторона может затем подключиться к данному порту и IP-адресу.

После установления соединения протокол, используемый для DCC CHAT, очень прост: пользователи обмениваются сообщениями, завершающимися CRLF . Сообщения, начинающиеся с ASCII 001 (контроль-A, представленный ниже [^A] ) и слово ACTION и завершаются другим ASCII-кодом. 001 интерпретируются как эмоции: [^A]ACTION waves goodbye[^A].

Доска DCC

Это расширение DCC CHAT, позволяющее отправлять простые команды рисования, а также строки текста. DCC Whiteboard запускается рукопожатием, аналогичным DCC CHAT, с протоколом чат заменен на доска : DCC CHAT wboard ip port.

Как только соединение установлено, два клиента обмениваются сообщениями, завершающимися CRLF . Сообщения, начинающиеся (и, возможно, заканчивающиеся) с ASCII. 001 интерпретируются как специальные команды; команда ДЕЙСТВИЕ представляет собой эмоцию, в то время как другие вызывают рисование линий на поверхности доски пользователя или позволяют двум клиентам согласовывать набор функций.

DCC ОТПРАВИТЬ

Служба SEND позволяет пользователям отправлять файлы друг другу. Исходная спецификация рукопожатия не позволяла получателю узнать общий размер файла и возобновить передачу. Это заставило клиентов представить свои собственные расширения рукопожатия, многие из которых получили широкую поддержку.

Первоначальное рукопожатие заключалось в отправке отправителем получателю следующего CTCP: DCC SEND filename ip port.

Как и в случае с DCC CHAT, ip и порт — это IP-адрес и порт, где отправляющая машина будет прослушивать входящее соединение. Некоторые клиенты заключают имена файлов с пробелами в двойные кавычки. Обычно в качестве последнего аргумента добавляют размер файла: DCC SEND filename ip port filesize.

На этом этапе исходная спецификация предписывала получателю либо подключаться к заданному адресу и порту и ждать данных, либо игнорировать запрос, но для клиентов, поддерживающих расширение DCC RESUME, третья альтернатива — попросить отправителя пропустить часть запроса. файл, отправив ответ CTCP: DCC RESUME filename port position.

Если клиент-отправитель поддерживает DCC RESUME, он ответит: DCC ACCEPT filename port position, и получатель может подключиться к заданному адресу и порту и прослушивать данные для добавления в уже существующий файл.

Данные отправляются клиенту блоками, каждый из которых клиент должен подтвердить, отправив общее количество полученных байтов в виде 32-битного целого числа сетевого порядка байтов . Это замедляет соединения и является избыточным из-за TCP . Расширение упреждающей отправки несколько облегчает эту проблему, не дожидаясь подтверждений, но поскольку получателю все равно приходится отправлять их для каждого полученного блока, в случае, если отправитель их ожидает, это не решается полностью.

Другое расширение, TDCC или турбо DCC, удаляет подтверждения, но требует слегка измененного рукопожатия и не получило широкой поддержки. В более старых версиях TDCC слово SEND в рукопожатии заменялось на TSEND; более поздние версии используют слово SEND, но добавляют T после рукопожатия, что делает эту версию TSEND совместимой с другими клиентами (при условии, что они могут анализировать измененное рукопожатие).

Эксплойт DCC SEND

«Эксплойт отправки DCC» может относиться к двум ошибкам: варианту переполнения буфера ошибки в mIRC, вызванному именами файлов длиной более 14 символов, ^{[ 10 ]} и ошибка проверки ввода в некоторых маршрутизаторах производства Netgear , D-Link и Linksys , вызванная использованием порта 0 . ^{[ 11 ]}^{[ 12 ]} В частности, эксплойт маршрутизатора может сработать, когда фраза « DCC SEND ', за которым следуют не менее 6 символов без пробелов и новых строк, появляется в любом месте TCP- потока на порту 6667, а не только тогда, когда был сделан фактический запрос DCC SEND. В 2000-х годах можно было объединить несколько эксплойтов в одну строку. DCC SEND startkeylogger 0 0 0 , который, если его опубликовать в общедоступном канале, может привести к отключению нескольких пользователей (либо из-за сбоя IRC-клиентов, сбоя маршрутизаторов, либо из-за слишком строгих настроек по умолчанию в антивирусном программном обеспечении). ^{[ нужна ссылка ]}

DCC XMIT

Служба XMIT представляет собой модифицированную версию DCC SEND, которая позволяет возобновлять работу с файлами и сокращает непроизводительный трафик от длинных ACK. XMIT не получил широкой поддержки.

Подтверждение XMIT несколько отличается от рукопожатия SEND. Отправитель отправляет CTCP, предлагая файл получателю: DCC XMIT protocol ip port[ name[ size[ MIME-type]]]

Квадратные скобки здесь заключают в себе дополнительные детали. протокол — протокол , используемый для передачи; только ясно определено в настоящее время. В отличие от стандартного DCC SEND, ip может иметь дополнительную форму стандартной точечной записи для IPv4 или шестнадцатеричную или смешанную запись для IPv6. Чтобы оставить ранний параметр пустым, но при этом указать более поздний, можно указать более ранний параметр как - . Если получатель не реализует используемый протокол, он отправит обратно ответ CTCP в формате: ERRMSG DCC CHAT protocol unavailable.

CHAT используется здесь для обеспечения совместимости с сообщениями об ошибках, отправляемыми расширенным CHAT DCC. Если получатель отклоняет передачу, он отправляет следующий ответ CTCP: ERRMSG DCC CHAT protocol declined.

Остальные ошибки сообщаются таким же образом. Если получатель желает и способен получить файл, он подключится к заданному адресу и порту. Что произойдет дальше, зависит от используемого протокола.

В случае ясного протокола, сервер XMIT при получении соединения отправит 32-битный time t в сетевом порядке байтов , представляющем время модификации файла. Предположительно, в зависимости от времени изменения локального файла, клиент затем отправит другой сетевой порядок байтов. long, смещение, к которому сервер должен стремиться при отправке файла. Это значение должно быть установлено равным нулю, если требуется весь файл, или размеру локального файла, если клиент желает возобновить предыдущую загрузку.

Несмотря на то, что XMIT быстрее, чем SEND, он имеет одно из тех же ограничений: невозможно определить размер файла, если только его размер не указан в согласовании CTCP или не известен заранее. Более того, невозможно возобновить воспроизведение файла после отметки в два гигабайта из-за 32-битного смещения.

Пассивный DCC

В обычном соединении DCC инициатор выступает в роли сервера , а цель — клиента . Из-за широко распространенного межсетевого экрана и снижения сквозной прозрачности из-за NAT инициатор может не иметь возможности действовать как сервер. Были разработаны различные способы попросить цель действовать в качестве сервера:

DCC-сервер

Это расширение обычных DCC SEND и CHAT было введено IRC-клиентом mIRC . DCC Server имеет умеренную поддержку, но не является стандартной для всех клиентов (см. Сравнение клиентов Internet Relay Chat ).

Это позволяет инициировать соединение DCC по IP-адресу без необходимости использования IRC-сервера. Это достигается за счет того, что клиент-получатель действует как сервер (отсюда и название), прослушивая (обычно через порт 59) рукопожатие от отправителя.

Для ЧАТа инициатор отправляет 1000 initiator nick. Затем цель отвечает: 1000 target nick, а все остальное происходит по стандартному протоколу DCC CHAT.

Для SEND инициатор отправляет 1200 initiator nick filesize filename. Цель отвечает: 1210 target nick resume position, где позиция возобновления — это смещение в файле, с которого следует начать. Отсюда передача продолжается как обычная отправка DCC.

DCC Server также поддерживает файловые серверы в стиле mIRC и DCC GET.

ДРКК

Сервер DCC не предоставляет возможности указать используемый порт, поэтому его приходится согласовывать вручную, что не всегда возможно, поскольку одна из сторон может не быть человеком. RDCC — это механизм установления связи для сервера DCC, который помимо порта также предоставляет IP-адрес сервера, который в противном случае клиент не сможет найти из-за маскировки хоста. Он не получил широкой поддержки.

Инициатор запрашивает порт, который прослушивает цель, отправляя запрос CTCP. RDCC function comment, функция где в для чата, s для отправки или f для файлового сервера.

Цель может затем ответить CTCP: RDCC 0 ip port, где IP и порт имеют те же значения, что и для обычных DCC SEND и CHAT. После этого инициатор подключается к IP и порту , после чего следует рукопожатие сервера DCC.

ДКК РЕВЕРС

В отличие от сервера DCC, где подтверждение связи обрабатывается через прямое IP-соединение, DCC REVERSE имеет обычное подтверждение связи CTCP, аналогичное тому, которое используется DCC SEND. Это не получило широкого распространения. Отправитель предлагает файл получателю, отправив сообщение CTCP: DCC REVERSE filename filesize key. Ключ представляет собой строку символов ASCII длиной 1–50 символов в диапазоне 33–126, которая действует как идентификатор передачи.

Если получатель принимает, он отправляет ответ CTCP. DCC REVERSE key start ip port

Здесь start — позиция в файле, с которой следует начать отправку, ip — IP-адрес получателя в стандартной точечной записи для IPv4 или шестнадцатеричной записи для IPv6 . Затем отправитель подключается к IP-адресу и порту, указанным получателем, после чего следует обычная отправка DCC. И отправитель, и получатель могут отменить рукопожатие, отправив ответ CTCP. DCC REJECT REVERSE key.

DCC RSEND

Это альтернатива DCC REVERSE клиента KVIrc. Отправитель предлагает файл, отправив CTCP: DCC RSEND filename filesize. Затем получатель может принять ответ, ответив CTCP: DCC RECV filename ip port start, а отправитель подключается к получателю и отправляет, как при обычной отправке DCC.

Реверс/Брандмауэр DCC

Этот пассивный механизм DCC поддерживается как минимум mIRC , Visual IRC , HexChat , KVIrc, DMDirc , Klient , Konversation и PhibianIRC . Отправитель предлагает файл, отправив сообщение CTCP. DCC SEND filename ip 0 filesize token. ip — это IP-адрес отправителя в сетевом порядке байтов, выраженный одним целым числом (как в стандартном DCC). Вместо допустимого порта отправляется число 0, сигнализирующее о том, что это запрос обратного DCC. токен — уникальное целое число; если используется TSEND (клиентом, который его поддерживает), буква T К токену добавляется , давая получателю понять, что ему не нужно отправлять подтверждения.

Получатель может принять файл, открыв сокет прослушивания и ответив сообщением CTCP. DCC SEND filename ip port filesize token. Оно идентично исходному сообщению Reverse DCC, за исключением того, что IP-адрес и порт идентифицируют сокет, который прослушивает получатель. токен такой же, как и в исходном запросе, позволяя отправителю узнать, какой запрос принимается. (Поскольку это сообщение имеет тот же формат, что и обычный запрос на отправку DCC, некоторые серверы, фильтрующие запросы DCC, могут потребовать от отправителя добавить получателя в свой список разрешенных DCC.)

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

Когда используется расширение RESUME протокола SEND, последовательность команд становится (с >> указывая исходящее сообщение на инициирующей стороне, и << ответ партнера):

>> DCC SEND filename ip 0 filesize token << DCC RESUME filename 0 position token >> DCC ACCEPT filename 0 position token << DCC SEND filename peer-ip port filesize token

После чего протокол работает как обычно (т.е. отправитель подключается к сокету получателя).

Файловые серверы (FSERV)

DCC fserve или файловый сервер позволяет пользователю просматривать, читать и загружать файлы, расположенные на сервере DCC.

Обычно это реализуется с помощью сеанса DCC CHAT (который предоставляет пользователю командную строку) или специальных команд CTCP для запроса файла. Файлы отправляются через DCC SEND или DCC XMIT. Существует множество реализаций файловых серверов DCC, среди них — команда FSERV в популярном клиенте mIRC .

См. также

CTCP (протокол клиент-клиент)
XDCC (расширенный DCC)

Ссылки

^ «Открытый исходный код и свободное программное обеспечение» . Трой.ролло.имя . Архивировано из оригинала 16 ноября 2018 г. Проверено 15 ноября 2018 г.
^ «Переговоры и подключение DCC» . kvric.net .
^ «IRCHelp.org — Протокол клиент-клиент (CTCP)» . www.irchelp.org .
^ Пиккар, Пол; Брайан Баскин; Джордж Спиллман; Маркус Сакс (1 мая 2005 г.). «IRC-сети и безопасность». Защита приложений обмена мгновенными сообщениями и P2P на предприятии (1-е изд.). Сингресс. п. 386. ИСБН 1-59749-017-2 . Авторы программного пакета ircII изначально впервые использовали передачу файлов через IRC.
^ См. файлы «ПРИМЕЧАНИЯ» и «source/ctcp.c», включенные в состав ircii-2.1.4e.tar.gz. ^{[ постоянная мертвая ссылка ]}
^ См. файлы «ОБНОВЛЕНИЯ» и «source/dcc.c», включенные в состав ircii-2.1.4e.tar.gz. ^{[ постоянная мертвая ссылка ]}
^ Трой Ролло (20 января 1993 г.). "/дкк" . Группа новостей : alt.irc . Usenet: [электронная почта защищена] . Проверено 10 ноября 2010 г.
^ Ролло, Трой. «Описание протокола DCC» . irchelp.org . Проверено 10 ноября 2010 г. Первое замечание, которое я должен сделать, заключается в том, что протокол DCC никогда не был предназначен для переносимости на другие клиенты, кроме IRCII. Таким образом, я не несу ответственности за то, что это будет сложно реализовать для других клиентов.
^ «Помощь mIRC» . www.mirc.com . Проверено 24 июля 2023 г.
^ «Информация об эксплойте SecurityFocus» .
^ «CVE-CVE-2006-1068» . cve.mitre.org .
^ «CVE-CVE-2006-1067» . cve.mitre.org .

Внешние ссылки

Описание протокола DCC (примечание: большинство IRC-клиентов и сетей реализовали расширения протокола DCC. Обычно используемый сегодня DCC значительно развился по сравнению с тем, что описано в этом документе.)
Переговоры и подключение DCC. Архивировано 15 декабря 2005 г. на Wayback Machine.
Описание протокола Turbo DCC
Описание протокола DCC Whiteboard

[1] «Открытый исходный код и свободное программное обеспечение» . Трой.ролло.имя . Архивировано из оригинала 16 ноября 2018 г. Проверено 15 ноября 2018 г.

[2] «Переговоры и подключение DCC» . kvric.net .

[3] «IRCHelp.org — Протокол клиент-клиент (CTCP)» . www.irchelp.org .

[4] Пиккар, Пол; Брайан Баскин; Джордж Спиллман; Маркус Сакс (1 мая 2005 г.). «IRC-сети и безопасность». Защита приложений обмена мгновенными сообщениями и P2P на предприятии (1-е изд.). Сингресс. п. 386. ИСБН 1-59749-017-2 . Авторы программного пакета ircII изначально впервые использовали передачу файлов через IRC.

[5] См. файлы «ПРИМЕЧАНИЯ» и «source/ctcp.c», включенные в состав ircii-2.1.4e.tar.gz. ^{[ постоянная мертвая ссылка ]}

[6] См. файлы «ОБНОВЛЕНИЯ» и «source/dcc.c», включенные в состав ircii-2.1.4e.tar.gz. ^{[ постоянная мертвая ссылка ]}

[7] Трой Ролло (20 января 1993 г.). "/дкк" . Группа новостей : alt.irc . Usenet: [электронная почта защищена] . Проверено 10 ноября 2010 г.

[8] Ролло, Трой. «Описание протокола DCC» . irchelp.org . Проверено 10 ноября 2010 г. Первое замечание, которое я должен сделать, заключается в том, что протокол DCC никогда не был предназначен для переносимости на другие клиенты, кроме IRCII. Таким образом, я не несу ответственности за то, что это будет сложно реализовать для других клиентов.

[9] «Помощь mIRC» . www.mirc.com . Проверено 24 июля 2023 г.

[10] «Информация об эксплойте SecurityFocus» .

[11] «CVE-CVE-2006-1068» . cve.mitre.org .

[12] «CVE-CVE-2006-1067» . cve.mitre.org .

[ 1 ]

[ 2 ]

[ 3 ]

[ 4 ]

[ 5 ]

[ 6 ]

[ 7 ]

[ 8 ]

[ 9 ]

[ 10 ]

[ 11 ]

[ 12 ]