Клиент-клиентский протокол

Протокол клиент-клиент ( CTCP ) - это особый тип связи между клиентами Internet Relay Chat (IRC).

CTCP - это общий протокол, реализованный большинством основных клиентов IRC, используемых сегодня. ^{[ необходима цитата ]} CTCP расширяет исходный протокол IRC, позволяя пользователям запрашивать других клиентов или каналы, это заставляет всех клиентов в канале отвечать CTCP для получения конкретной информации. Кроме того, CTCP можно использовать для кодирования сообщений, которые необработанный протокол IRC не разрешил бы отправлять по ссылке, таких как сообщения, содержащие символы новой строки или значение байта 0 (NULL). CTCP не устанавливает прямого соединения между клиентами; однако он обычно используется для согласования соединений DCC .

CTCP позволяет пользователям запрашивать удаленный клиент о версии клиента, который они используют (через CTCP VERSION), или времени (через CTCP TIME), среди прочего. Он также используется для реализации команды / me (через CTCP ACTION).

История [ править ]

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

Структура [ править ]

Сообщение CTCP реализовано как PRIVMSGили, NOTICEгде первый и последний символы сообщения имеют значение ASCII 0x01. Кроме того, символы, которые не разрешены в протоколе IRC, экранируются. Поскольку NOTICEпо стандарту a не должен генерировать ответ, сообщения CTCP отправляются как, PRIVMSGа ответ реализуется с помощью a NOTICEвместо PRIVMSG.

Запрос CTCP инициируется на большинстве клиентов следующим образом:

CTCP <цель> <команда> <аргументы>

Где <target> - это целевой псевдоним или канал, <command> - это команда CTCP (например VERSION), а <arguments> - дополнительная информация, которая должна быть отправлена ​​на <target> .

Общие команды CTCP [ править ]

Команды и ответы CTCP зависят от клиента; Таким образом, в зависимости от клиента IRC, некоторые из следующих команд CTCP могут не вызывать ответа или будут иметь другой формат, чем показано здесь.

ВЕРСИЯ [ править ]

CTCP VERSIONЗапрос возвращает имя и версию клиента IRC цель использует, а в некоторых случаях технические данные , такие как операционная система , тактовая частота , CPU Производитель и архитектуры процессора / набора команд .

Образец ответа на CTCP VERSIONзапрос к цели , которая использует HexChat клиент ( вилка из XChat) является:

ВЕРСИЯ HexChat 2.9.1 [x86] / Windows 8 [1,46 ГГц]

ВРЕМЯ [ править ]

CTCP TIMEЗапрос возвращает местное время целевого компьютера. В зависимости от клиента IRC ответ может состоять из даты , времени (в 12-часовом или 24-часовом формате ), года (например, 2012), а иногда и часового пояса (например, EST ).

Пример ответа на CTCP TIMEзапрос к цели, использующей клиент ChatZilla :

ВРЕМЯ Пт, 23 ноября 2012 г., 19:26:42 EST

ПИНГ [ редактировать ]

CTCP PINGЗапрос будет определять скорость пинга , что непосредственно существует между двумя клиентами (т.е. дисконтированием сервера). Команда CTCP PINGработает, отправляя (часто) целочисленный аргумент ( метку времени ) целевому клиенту, затем целевой клиент отвечает, предоставляя точно такой же числовой параметр. Разница между первоначальной временной меткой и текущим временем рассчитываются с результатом , что отображается для пользователя , который инициировал CTCP PING . Чаще всего используется временная метка, в которой используются миллисекунды, поскольку у большинства пользователей с широкополосным подключением к Интернету пинг составляет менее 1 секунды.

Пример CTCP PINGзапроса на таргетинг на <ник> от клиента XChat :

CTCP PING 23152511

Аналогичным образом, образец вывода, созданный на основе разницы (см. Выше):

Ping-ответ от <ник>: 0,53 сек.

DCC CHAT [ править ]

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

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

DCC CHAT <protocol> <ip> <port>

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

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

^AACTION waves goodbye^A

Доска DCC [ править ]

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

DCC CHAT wboard <ip> <port>

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

DCC ОТПРАВИТЬ [ редактировать ]

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

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

DCC SEND <filename> <ip> <port>

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

DCC SEND <filename> <ip> <port> <file size>

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

DCC RESUME <filename> <port> <position>

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

DCC ACCEPT <filename> <port> <position>

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

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

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

DCC SEND эксплойт [ править ]

Эксплойт DCC send может относиться к двум ошибкам: вариантной ошибке переполнения буфера в mIRC, вызванной именами файлов длиной более 14 символов ^[4], и ошибкой проверки ввода в некоторых маршрутизаторах производства Netgear , D-Link и Linksys , вызванной использованием порт 0 . ^{[5] [6]} Эксплойт маршрутизатора, в частности, может сработать, когда фраза « DCC SEND », за которой следует не менее 6 символов без пробелов или новых строк, появляется в любом месте TCP- потока на порту 6667, а не только тогда, когда фактический DCC SEND запрос был сделан.

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

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

ERRMSG DCC CHAT <protocol> declined

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

В случае «чистого» протокола сервер 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 <initiator nick>

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

1000 <target nick>

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

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

1200 <initiator nick> <filesize> <filename>

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

1210 <target nick> <resume position>

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

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

RDCC [ править ]

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

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

RDCC <function> <comment>

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

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

RDCC 0 <ip> <port>

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

DCC REVERSE [ править ]

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

DCC REVERSE <filename> <filesize> <key>

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

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

DCC REVERSE <key> <start> <ip> <port>

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

DCC REJECT REVERSE <key>

DCC RSEND [ править ]

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

DCC RSEND <filename> <filesize>

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

DCC RECV <filename> <ip> <port> <start>

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

Обратный / Брандмауэр DCC [ править ]

Этот пассивный механизм DCC поддерживается как минимум mIRC , Visual IRC , XChat , 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> и <port> идентифицируют сокет, который прослушивает получатель. <token> - то же самое, что и в исходном запросе, позволяя отправителю знать, какой запрос принимается. (Поскольку это сообщение имеет тот же формат, что и обычный запрос отправки DCC, некоторые серверы, которые фильтруют запросы DCC, могут потребовать от отправителя добавить получателя в свой список «DCC allow».)

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

Когда используется расширение 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 .

См. Также [ править ]

• Интернет-чат (IRC)
• IRC-клиент
• Сравнение клиентов Internet Relay Chat
• DCC (прямой клиент-клиент)

Ссылки [ править ]

Внешние ссылки [ править ]

• Детали CTCP