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

Эта статья поднимает множество проблем. Пожалуйста помоги Улучши это или обсудите эти вопросы на страница обсуждения. (Узнайте, как и когда удалить эти сообщения-шаблоны) Эта статья может содержать чрезмерное количество сложных деталей, которые могут заинтересовать только определенную аудиторию. Пожалуйста, помогите спиннинг или же переезд любая соответствующая информация и удаление лишних деталей, которые могут противоречить Политика включения Википедии. (Август 2012 г.) (Узнайте, как и когда удалить этот шаблон сообщения) Эта статья нужны дополнительные цитаты для проверка. Пожалуйста помоги улучшить эту статью к добавление цитат в надежные источники. Материал, не полученный от источника, может быть оспорен и удален. Найдите источники: «Прямой клиент-клиент»  – Новости  · газеты  · книги  · ученый  · JSTOR (Август 2012 г.) (Узнайте, как и когда удалить этот шаблон сообщения) Эта статья использует Разметка HTML. Пожалуйста помощь изменив разметку HTML на Разметка вики где необходимо. Для получения помощи в поиске или замене проблемных тегов см. инструкции. (Февраль 2019 г.) (Узнайте, как и когда удалить этот шаблон сообщения)

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

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 ЧАТ

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

DCC CHAT обычно запускается с помощью CTCP рукопожатие. Пользователь, желающий установить соединение, отправляет целевой объект CTCP:

DCC CHAT <протокол> <порт>

и принадлежат отправителю и выражаются целыми числами. <протокол> - это "чат" для стандартного DCC CHAT. Затем принимающая сторона может подключиться к заданному порту и адресу.

Как только соединение установлено, протокол, используемый для DCC CHAT, очень прост: пользователи обмениваются CRLF -завершенные сообщения. Сообщения, начинающиеся с ASCII 001 (control-A, представленный ниже как ^ А) и слово «ДЕЙСТВИЕ» и заканчиваются другим кодом ASCII 001, интерпретируются как эмоции:

^ АACTION машет рукой на прощание^ А

Доска DCC

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

DCC CHAT wboard <порт>

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

DCC ОТПРАВИТЬ

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

Первоначальное рукопожатие состояло из отправки отправителем следующего CTCP получателю:

DCC SEND <имя файла> <порт>

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

DCC SEND <имя файла> <порт> <размер файла>

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

DCC RESUME <имя файла> <порт> <положение>

Если отправляющий клиент поддерживает DCC RESUME, он ответит:

DCC ACCEPT <имя файла> <порт> <положение>

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

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

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

DCC SEND эксплойт

Эксплойт DCC send может относиться к двум ошибкам, вариант переполнение буфера ошибка в mIRC запускается именами файлов длиннее 14 символов^[9] и ошибка проверки ввода в некоторых маршрутизаторах производства Netgear, D-Link и Linksys, вызванный использованием порта 0.^[10][11] Эксплойт роутера, в частности, может сработать, когда фраза 'DCC ОТПРАВИТЬ', за которым следует не менее 6 символов без пробелов или символов новой строки, появляется в любом месте TCP поток на порт 6667, а не только при фактическом запросе DCC SEND.

DCC XMIT

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

Рукопожатие XMIT несколько отличается от рукопожатия SEND. Отправитель отправляет CTCP предлагая файл получателю:

DCC XMIT <протокол> <порт> [<имя> [<размер> []]]

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

ERRMSG DCC CHAT <протокол> недоступен

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

ERRMSG DCC CHAT <протокол> отклонен

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

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

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

Пассивный DCC

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

DCC Сервер

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

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

Для ЧАТа инициатор отправляет:

1000 <ник инициатора>

Затем цель отвечает:

1000 <целевой ник>

а все остальное происходит по стандартному протоколу DCC CHAT.

Для SEND инициатор отправляет:

1200 <ник инициатора> <размер файла> <имя файла>

Цель отвечает:

1210 <целевой ник> <возобновить позицию>

где <позиция возобновления> - это смещение в файле, с которого следует начать. Отсюда передача происходит как обычная передача DCC.

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

RDCC

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

Инициатор запрашивает порт, который прослушивает цель, отправляя запрос CTCP:

RDCC <функция> <комментарий>

где - это 'c' для чата, 's' для отправки и 'f' для файлового сервера.

Затем цель может ответить CTCP:

RDCC 0 <порт>

где и имеют то же значение, что и для обычных DCC SEND и CHAT. После этого инициатор подключается к IP-адресу и порту, и следует рукопожатие DCC Server.

DCC REVERSE

В отличие от сервера DCC, где квитирование осуществляется через прямое IP-соединение, DCC REVERSE имеет обычное квитирование CTCP, подобное тому, которое используется DCC SEND. Это широко не применяется. Отправитель предлагает файл получателю, отправив сообщение CTCP:

DCC REVERSE <имя файла> <размер файла> <ключ>

<ключ> - это строка длиной от 1 до 50 символов ASCII символов в диапазоне от 33 до 126 и действует как идентификатор для передачи.

Если получатель принимает, он отправляет ответ CTCP:

DCC REVERSE <ключ> <начало> <порт>

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

DCC REJECT REVERSE <ключ>

DCC RSEND

Это клиент KVIrc, альтернативный DCC REVERSE. Отправитель предлагает файл, отправив CTCP:

DCC RSEND <имя файла> <размер файла>

Затем получатель может принять ответ CTCP, ответив:

DCC RECV <имя файла> <порт> <начало>

и отправитель подключается к получателю и отправляет как при обычном DCC SEND.

Обратный / межсетевой экран DCC

Этот пассивный механизм DCC поддерживается как минимум mIRC, Визуальный IRC, XChat, KVIrc, DMDirc, Klient, Konversation, и PhibianIRC. Отправитель предлагает файл, отправив сообщение CTCP:

DCC SEND <имя файла> 0 <размер файла> <токен>

- это айпи адрес отправителя в сетевом порядке байтов, выраженном как одно целое число (как в стандартном DCC). Число 0 отправляется вместо действительного порта, сигнализируя о том, что это обратный запрос DCC. <токен> - уникальное целое число; если TSEND используется (клиентом, который его поддерживает), к токену добавляется буква «T», чтобы получатель знал, что ему не нужно отправлять подтверждения.

Получатель может принять файл, открыв прослушивающий сокет и ответив сообщением CTCP:

DCC SEND <имя файла> <порт> <размер файла> <токен>

Это идентично исходному сообщению Reverse DCC, за исключением того, что и идентифицируют сокет, который прослушивает получатель. - это то же самое, что и в исходном запросе, позволяя отправителю узнать, какой запрос принимается. (Поскольку это сообщение имеет тот же формат, что и обычный запрос отправки DCC, некоторые серверы, которые фильтруют запросы DCC, могут потребовать от отправителя добавить получателя в свой список «DCC allow».)

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

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

>> DCC SEND <имя файла> 0 <размер файла> <токен>

<< DCC RESUME <filename> 0 <position> <token>

>> DCC ACCEPT <имя файла> 0 <позиция> <токен>

<< 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)

Рекомендации

внешняя ссылка

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