RFC1459 - Internet Relay Chat Protocol - RFC 1459
Network
Working Group
J. Oikarinen
Request for Comments: 1459
D. Reed
May 1993
Internet Relay Chat Protocol
Статус документа
Данный документ описывает Експериментальный Протокол для Интернет
обьединения. Обсуждения и предложения для улучшения приветствуются.
Пожалуйста, изучите текущую редакцию "Официальные Стандарты протокола
IAB". Распространение документа не ограничено.
Резюме
IRC-протокол был разработан 4 года назад (в 1989 году, относительно
года издания этого документа. -- прим. пер.) для того, чтобы
пользователи BBS могли общаться между собой. Сейчас этот протокол
поддерживается web-серверами и клиентами, и на этом он завершает свое
развитие. Последние 2 года среднее количество пользовательских
соединений к IRC-сети возросло в 10 раз.
IRC-протокол работает с текстом, и поэтому даже самый простой клиент,
оснащенный сокет-программой, может соединиться с сервером.
Содержание
1. ВСТУПЛЕНИЕ ................................................. 4
1.1 Серверы ................................................ 4
1.2 Клиенты ................................................ 5
1.2.1 Операторы .......................................... 5
1.3 Каналы .................................................. 5
1.3.1 Операторы Каналов .................................... 6
2. СПЕЦИФИКАЦИЯ IRC ............................................ 7
2.1 Ознакомление ............................................ 7
2.2 Коды символов ........................................... 7
2.3 Сообщения ............................................... 7
2.3.1 Формат сообщения в 'псевдо' BNF ................... 8
2.4 Нумерация ответов ....................................... 10
3. КОНЦЕПЦИЯ IRC ............................................... 10
3.1 Соединение один-на-один ................................. 10
3.2 Один-со-всеми ........................................... 11
3.2.1 Со списком ......................................... 11
3.2.2 С группой (каналом) ................................ 11
3.2.3 С маской хоста/сервера ............................. 12
3.3 Один-всем ............................................... 12
3.3.1 Клиент-Клиенту ..................................... 12
3.3.2 Клиент-Серверу ..................................... 12
3.3.3 Сервер-Серверу ..................................... 12
4. ДЕТАЛЬНОЕ РАССМОТРЕНИЕ СООБЩЕНИЙ ............................ 13
4.1 Регистрация Соединения .................................. 13
4.1.1 Password ........................................... 14
4.1.2 Nickname ........................................... 14
4.1.3 User ............................................... 15
4.1.4 Server ............................................. 16
4.1.5 Oper ............................................... 17
4.1.6 Quit ............................................... 17
4.1.7 Server Quit ........................................ 18
4.2 Операторы Каналов ....................................... 19
4.2.1 Join-сообщение ..................................... 19
4.2.2 Part-сообщение ..................................... 20
4.2.3 Mode-команда ....................................... 21
4.2.3.1 Режимы канала ................................. 21
4.2.3.2 Режимы пользователя ........................... 22
4.2.4 Topic-сообщение .................................... 23
4.2.5 Names-сообщение .................................... 24
4.2.6 List-сообщение ..................................... 24
4.2.7 Invite-сообщение ................................... 25
4.2.8 Kick-сообщение ..................................... 25
4.3 Серверные запросы и комманды ............................ 26
4.3.1 Version-сообщение .................................. 26
4.3.2 Stats-сообщение .................................... 27
4.3.3 Links-сообщения .................................... 28
4.3.4 Time-сообщение ..................................... 29
4.3.5 Connect-сообщение .................................. 29
4.3.6 Trace-сообщение .................................... 30
4.3.7 Admin-команда ...................................... 31
4.3.8 Info-команда ....................................... 31
4.4 Сообщения отправки ...................................... 32
4.4.1 Private-сообщения .................................. 32
4.4.2 Notice-сообщения ................................... 33
4.5 Пользовательские запросы ................................ 33
4.5.1 Who-запрос ......................................... 33
4.5.2 Whois-запрос ....................................... 34
4.5.3 Whowas-сообщение ................................... 35
4.6 Всевозможные сообщения .................................. 35
4.6.1 Kill-сообщение ..................................... 36
4.6.2 Ping-сообщение...................................... 37
4.6.3 Pong-сообщение ..................................... 37
4.6.4 Error-сообщение .................................... 38
5. ОПЦИОНАЛЬНЫЕ СООБЩЕНИЯ ...................................... 38
5.1 Away-сообщение .......................................... 38
5.2 Rehash-команда ......................................... 39
5.3 Restart-команда ......................................... 39
5.4 Summon-сообщение......................................... 40
5.5 Users-сообщение ......................................... 40
5.6 Operwall-команда ........................................ 41
5.7 Userhost-сообщение....................................... 42
5.8 Ison-сообщение .......................................... 42
6. ОТВЕТЫ ...................................................... 43
6.1 Error-ответы ............................................ 43
6.2 Отклики команд .......................................... 48
6.3 Зарезервированные числа ................................. 56
7. ИДЕНТИФИКАЦИЯ КЛИЕНТА И СЕРВЕРА ............................. 56
8. ПОДРОБНОЕ РАССМОТРЕНИЕ ТЕКУЩИХ СРЕДСТВ СВЯЗИ ................ 56
8.1 Сетевой протокол TCP .................................... 57
8.1.1 Поддержка Unix-сокетов ............................. 57
8.2 Проверка команд ......................................... 57
8.3 Передача сообщений ...................................... 57
8.4 Соединение 'Liveness' ................................... 58
8.5 Установка соединения сервер-клиент ...................... 58
8.6 Установка соединения сервер-сервер ...................... 58
8.6.1 Обмен информацией о состоянии соединения ........... 59
8.7 Разрыв соединения сервер-клиент ......................... 59
8.8 Разрыв соединения сервер-сервер ......................... 59
8.9 Слежение за измененияит никнейма ........................ 60
8.10 Flood-контроль клиентов ................................ 60
8.11 Non-blocking lookups ................................... 61
8.11.1 Hostname (DNS) lookups ............................ 61
8.11.2 Username (Ident) lookups .......................... 61
8.12 Конфигурационный файл .................................. 61
8.12.1 Допуск клиентов к соединению ...................... 62
8.12.2 Операторы ......................................... 62
8.12.3 Допуск серверов к соединению ...................... 62
8.12.4 Административная часть ............................ 63
8.13 Формирование сообществ ................................. 63
9. ТЕКУЩИЕ ПРОБЛЕМЫ ............................................ 63
9.1 Расширение .............................................. 63
9.2 Знаки ................................................... 63
9.2.1 Никнеймы ........................................... 63
9.2.2 Каналы ............................................. 64
9.2.3 Серверы ............................................ 64
9.3 Алгоритмы ............................................... 64
10. ПОДДЕРЖКА И ДОСТУП ......................................... 64
11. РАССМОТРЕНИЕ БЕЗОПАСНОСТИ .................................. 65
12. АДРЕСА АВТОРОВ ............................................. 65
1. ВСТУПЛЕНИЕ
IRC ("Internet Relay Chat" можно перевести как "Общение передающееся
посредством Интернета". Если не забыли, что первоначально этот протокол
связывал пользователей BBS -- прим. пер.) протокол был разработан
несколько лет назад для общения посредством текста (чат). Этот документ
описывает текущее (на 1993 год -- прим. пер.) состояние IRC-протокола.
IRC-протокол разработан для систем, использующих сетевой протокол
TCP/IP, хотя это не требование, чтобы этот пережиток работал только в
этой сфере.
IRC представляет собой систему телеконференций, которые (через
использование модели клиент-сервер) хорошо подходят для работы на
многих машинах в распространяемой зоне. Типичная настройка представляет
собой процесс (сервер), предоставляющий доступ для клиентов (или других
серверов), и выполняющий доставку/мультиплексирование сообщений и
других функций.
1.1 Серверы
Сервер формирует бэкбон IRC, предоставляющий точки присоединения
клиентов для общения и присоединения других серверов для формирования
IRC-сети. Серверы, доступные в сети формируют IRC-сеть, образуя сетевое
дерево (см. рис. 1), в котором каждый сервер является самостоятельным, но
тем не менее взаимодействующим с остальными серверами. (Подобная форма
сети предполагает наибольшую сохранность сети, даже при падении одного
или нескольких серверов. -- прим. пер.).
[ Сервер 15 ] [ Сервер 13 ] [ Сервер 14]
/ \ /
/ \ /
[ Сервер 11 ] ------ [ Сервер 1 ] [ Сервер 12]
/ \ /
/ \ /
[ Сервер 2 ] [ Сервер 3 ]
/ \ \
/ \ \
[ Сервер 4 ] [ Сервер 5 ] [ Сервер 6 ]
/ | \ /
/ | \ /
/ | \____ /
/ | \ /
[ Сервер 7 ] [ Сервер 8 ] [ Сервер 9 ] [ Сервер 10 ]
:
[ etc. ]
:
|
[ Рис. 1. Схематичное изображение IRC-сети ]
1.2 Клиенты
Клиент это любое присоединение к серверу, и который не является
сервером. Каждый клиент отличается от других клиентов наличием
уникального (не похожего ни на чей другой. -- прим. пер.) никнейма,
имеющего длину не больше девяти (9) символов. Посмотрите правила
протокольной грамматики для того, чтобы знать что можно и что нельзя
использовать в никнейме. В дополнение к никнейму, все серверы должны
иметь следующую информацию о всех клиентах: настоящее имя хоста, с
которого запустился клиент, имя пользователя клиента на этом хосте и
сервер, к которому присоединился клиент.
1.2.1 Операторы
Для поддержания порядка в IRC-сети, существует специальный класс
клиентов (операторы. В данный момент их называют "иркопы" -- прим.
пер.). Хотя, возможности операторов можно рассматривать как 'опасные',
они не подчиняются приказам. Операторы выполняют основные сетевые
задачи, такие как отсоединение и пересоединение серверов для улучшения
состояния сети или исправления каких-либо сетевых ошибок. Смотрите разделы
4.1.7 (SQUIT) и 4.3.5 (CONNECT).
В дополнение к возможностям операторов можно добавить, что в их силах
так же закрыть соединение между клиентов и сервером. Правда, подобное
бывает только при диструктивных и раздражающих действиях клиента.
Подробней об этом действии сказано в разделе 4.6.1 (KILL).
1.3 Каналы
Канал это обозначение группы из одного или большего числа клиентов,
которые получают сообщения, адресованные в этот канал. Канал создается
при соединении первого клиента с ним и канал исчезает, когда его
покидает последний клиент. Пока канал отсутствует, любой клиент может
завладеть каналом, назвав свой таким же именем.
Имена каналов - строка (начинающаяся с символа '&' или '#') длинной до
200 символов. В стороне от требований, что первый символ должен быть
или '&' или '#'; органичение на то, что название канала не может
содержать пробелов (' '), Ctrl-G (^G или ASCII 7), или запятых (','
которая используется для создания списка каналов).
Протоколом предоставляется два типа каналов, Один распространяемый
канал, который известен всем серверам, подсоединенным к сети.
Эти каналы помечены первым символом; доступны только тем клиентам, на
сервере которых он существует. Такие каналы отличаются начальным
символом '&'. этих двух типов, доступны различные режимы каналов
для изменения индивидуальных характеристик канала.
Смотрите раздел 4.2.3 (MODE-команда) для более подробной информации.
Для создания нового канала или входа в существующий, пользователь
должен запросить JOIN канала. Если канал отсутствовал, то канал
создается и вошедший пользователь станоавится оператором канала. Если
канал уже существует, но так или иначе он не отвечает на попытки войти,
значит в настройках канала установлен какой-либо из нижеприведенных
режимов. Возможно, этот канал только-для-приглашенных (invite-only),
(режим +i), и вы сможете на его войти только будучи приглашенным.
Пользователь может находится не нескольких каналах одновременно, но
рекомендуется ограничиться десятью (10) каналами, ибо это полне
достаточно для новичков и набирания опыта. Для более подробной
информации обо всем этом смотрите раздел 8.13.
Если в IRC-сети происходит разрыв, вызванный разъединением двух
серверов, канал так же разрывается на несколько частей, в которых
остаются пользователи, сидящие на своих серверах. Когда серверы
соединяются вновь, они восстанавливают части канала и его режимы. Если
канал доступен по разные стороны, вхождения и режимы канала
интерпретируются в своих манерах.
1.3.1 Операторы каналов
Оператор канала (так же называемые "чоп" [сокращение и
транскрибирование словосочетания "чаннел оператор", но их принято
называть просто "оп". -- прим. пер.]) на данном канале рассматривается
как владелец канала. В добавление к этому статусу, оператор канала
выполняет функции стража порядка на канале. Как владелец канала,
оператор не осуждается за действия на своей территории, хотя если его
действия несут антисоциальные или какие другие оскорбительные действия,
то будет благоразумней обратиться к IRC-оператору за поддержкой, или
даже смещения с поста оператора канала.
Список команд, которые могут использоваться только оператором канала:
KICK - Выброс клиента с канала
MODE - Изменение режима канала
INVITE - Приглашение клиента на канал с режимом +i (invite-only)
TOPIC - Изменение топика канала в режиме канала - +t
Оператор канала идентифицируется символом '@', следующим за его
никнеймом, всякий раз, как он ассоциируется с каналом (например, ответы
на команды NAMES, WHO и WHOIS).
2. СПЕЦИФИКАЦИЯ IRC
2.1 Ознакомление
Протокол, как описывалось выше, используется для соединений между
серверами и, серверами и клиентами. Ограничение стоит больше на
клиентские соединения (которые рассматриваются как не стоящие доверия)
чем на серверные.
2.2 Коды символов
Используются обычные символы. Протокол базируется на установке кодов,
которые составляют восемь (8) бит, составляя октет. Каждое сообщение
может содержать любое количество октетов: к тому же, некоторые
восьмизначные величины использутся для контрольных кодов, которые
распознаются как неограниченые сообщения.
Не обращая внимания на 8-битный протокол, неограниченность и
переменные этого протокола наиболее используемые терминалом USASCII
и телнет-соединением.
Так как IRC имеет скандинавские корни, символы {}| рассматриваются как
эквивалент символов []\, но в малом регистре. Это приводит к критическим
результатам, когда определяется уникальность двух никнеймов.
2.3 Сообщения
Серверы и клиенты создают сообщения на которые можно ответить, а можно
и нет. Если сообщение содержит правильные команды, как описано в
предыдущем разделе, клиенту следует ответить как полагается, но это не
означает, что всегда можно дождаться ответа; связь клиент-сервер и
сервер-сервер очень рассинхронизированы по своей природе.
Каждое IRC-сообщение может содержать до трех главных частей: префикс
(опционально), команду и параметры команды (которых может быть до 15).
Префикс, команда и все параметры разделены одним (или более) символом
пробела (' ', 0x20).
Префикс обозначается одним символом, стоящим вначале (':', 0x3b),
который должен быть первым символом в сообщении. Между префиксом и
двоеточием не должно быть никаких пробелов. Префикс используется
серверами для обозначения источника появления сообщения.
Если префикс сообщения утерян, то за источник сообщения берут
соединение, с которого было получено сообщение. Клиентам не следует
использоваться префиксами при отсылке сообщения; если они начнут
использовать префиксы, то приниматься будут только правильные и только
с зарегистрированных никнеймов. Если исходные идентификаторы префиксов
не будет найдены в серверных базах данных, или если они зарегистрированы
с различных линков, то сервер будет игнорировать сообщение.
Команда должна содержать правильную IRC-команду или трехзначное число,
представленное в ASCII-тексте.
IRC-сообщения всегда выглядят как строки символов, заканчивающихся
парой символов CR-LF (Carriage Return - Line Feed. Возврат Каретки -
Перевод Строки) и длиной строки, не превышающей 512 символов (в эти
512 входят и CR-LF). Так что, максимальная длина строки для команд и
параметров - 510 символов. Перенос строки невозможен. Для более подробной
информации смотрите раздел 7.
2.3.1 Формат сообщения в 'псевдо' BNF
Протокол сообщений должен быть извлечен из смежных потоков октетов
Текущим решением стало определение двух символов, CR и LS, как
разделители сообщений. Игнорирование пустых сообщений, которые
используют последовательности CR-LF между сообщениями без каких-либо
проблем.
Распакованное сообщение проверяется внутри компонентов <prefix>,
<command> и список параметров подравнивается с помощью <middle> или
<trailing> компонентами
BNF представляет собой нечто подобное:
::= [':' ]
::= | [ '!' ] [ '@' ]
::= { } |
::= ' ' { ' ' }
::= [ ':' | ]
::= <Любая *не пустая* последовательность октетов, не
включающая в себя пробел, или NUL, или CR, или LF;
первой не может быть ':'>
::= <Любая, возможно *пустая*, последовательность октетов, не
включающих в себя NUL или CR, или LF>
::= CR LF
|
ЗАМЕЧАНИЯ:
1) <SPACE> содержит только символ(ы) пробела (0x20). Табуляция и
другие контрольные символы рассматриваются как НЕ-ПУСТЫЕ-ПРОБЕЛЫ
(NON-WHITE-SPACE).
2) После извлечения списка параметров, все параметры равняются
с помощью <middle> или <trailing>. <trailing> просто
синтаксическая штуковина, включающая SPACE внутри параметра.
3) Факт, что CR и LF нельзя добавить в строки параметров, просто
артефакт оформления сообщения. Его можно изменить позже.
4) NUL не является специальным символом в оформлении сообщения и
в основе служит окончанием внутри параметра, но это является
причиной усложнения в нормальной C-строке. Так же, NUL не
позволителен внутри сообщений.
5) Последний параметр может быть пустой строкой.
6) Использование расширенного префикса (['!' <user> ] ['@' <host> ])
может быть в связи сервера с сервером и предполагается
только для сообщений между сервером и клиентом, предоставляя
клиентам больше полезной информации о пользователях без
использования дополнительных запросов.
Многопротокольные сообщения указывают на дополнительную семантику и
синтаксис для параметров извлечения строк, указанием их позицией в
списке. Например, многие команды серверов будут предполагать, что первый
параметр после команды - список заданий, которые описаны таким образом:
::= [ "," ]
::= | '@' | |
::= ('#' | '&')
::=
::= смотри RFC 952 [DNS:4] для информации о именах хостов
::= { | | }
::= ('#' | '$')
::= <любой 8-битный код, включающий в себя SPACE, BELL,
NUL, CR, LF и запятую (',')>
Другие параметры синтаксиса:
::= { }
::= 'a' ... 'z' | 'A' ... 'Z'
::= '0' ... '9'
::= '-' | '[' | ']' | '\' | '`' | '^' | '{' | '}'
::= <любой 8-битный код, включающий SPACE, (0x20),
NUL (0x0), CR(0xd), и LF (0xa)>
|
2.4 Нумерация ответов
Многие сообщения, отправленные к серверу, создают отсортированные
ответы. Многие полученные ответы являются пронумерованными, что
используется как для отлова ошибок, так и нормальных ответов.
Пронумерованный ответ может быть послан как одно сообщение, содержащее
префикс отправителя, трехзначный номер и цель ответа. Нумерация ответов
не допускает сообщения от клиента-отправителя; любые такие сообщения,
полученные сервером, удаляются. Во всех других случаях, нумерованный
ответ просто обычное сообщение, которое содержит переменную. Переменная
имеет вид трехзначного номера, что неизменно лучше, чем строка символов.
Список различных ответов находится в разделе 6.
3. КОНЦЕПЦИЯ IRC
Этот раздел призван описать нынешнюю концепцию организации протокола
IRC и представление о различных классах сообщений.
1--\
A D---4
2--/ \ /
B----C
/ \
3 E
Серверы: A, B, C, D, E Клиенты: 1, 2, 3, 4
|
[ Рис. 2. Пример небольшой IRC-сети ]
3.1 Соединение один-на-один
Соединение один-на-один обычно осуществляется клиентами, но с тех пор
как траффик между серверами стал не так важен, данный вид соединения
упразднили. Предоставление возможности безопасного общения для клиентов,
предполагает собой, что все серверы должны предоставить возможность
прохождение сообщения по всей длине дерева до любого клиента. Сообщение
должно найти наиболее короткий путь между двумя точками в серверном
дереве.
Следующие примеры относятся к рис. 2.
Пример 1:
Сообщение между клиентами 1 и 2 должно пройти только через сервер A,
который отправит его прямо к клиенту 2.
Пример 2:
Сообщение между клиентами 1 и 3 должно пройти через серверы A и B.
Остальным клиентам и серверам увидеть сообщение не суждено.
Пример 3:
Сообщение между клиентами 2 и 4 пройдет по серверам A, B, С и D.
3.2 Один-со-всеми
Основная цель IRC - предоставить форум, который позволит легко и
эффективно устраивать конференции (одному с многими собеседниками).
И IRC как нельзя лучше справляется с этой обязанностью.
3.2.1 Со списком
Самый большое неудобство в общении один-со-всеми - разговор с помощью
клиентов со "списком" пользователей. Как это происходит: клиенты
предоставляют список получателей, которым адресовано сообщение и сервер
копирует сообщение всем указанным получателям. Это не так эффективно,
как использование группы, при нарушении списка получателей и отправке
сообщений без проверки может породить дубликаты сообщений.
3.2.2 С группой (каналом)
В IRC-канале имеется фунцкия, эквивалентная многосоставной группе; их
жизнь динамична (люди входят и покидают каналы) и текущая беседа
выходит на канал и отсылается серверам, которые поддерживают
пользователей на данном канале. Если на сервере несколько
пользователей, сидящих на одном канале, текст сообщения отсылается
только серверу, который в свою очередь отсылает каждому клиенту на
канале. Это действие повторяется для каждого соединения клиент-сервер,
пока исходное сообщение не дойдет до каждого пользователя на канале.
Следующие примеры относятся к рис. 2.
Пример 4:
Любой канал с одним клиентом(клиент 1). Сообщения в канал уходят на
сервер и потом кому-нибудь еще.
Пример 5:
На канале клиент 1 и клиент 2. Все сообщения проходят путь, как если
бы они были приватными сообщениями между двумя клиентами вне канала.
Пример 6:
На канале клиенты 1, 2 и 3. Все сообщения канала отправляются всем
клиентам и только их сервера, которые обязаны пропустить сообщение,
как если бы оно было приватное и для одного клиента. Если клиент 1
отправил сообщение, оно повернет обратно на клиента 2 и только тогда
через сервер B к клиенту 3.
3.2.3 С маской хоста/сервера
Предоставляя IRC-операторам возможность отправки сообщений большому
числу общающихся пользователей, используются маски отправки сообщений
по хосту или серверу. Эти сообщения отправляются пользователям,
чья информация о хоста или сервера попала под маску. Сообщения
отсылаются только туда, где расположены пользователи, в виду похожести
каналов.
3.3 Один-всем
Тип сообщения один-всем лучше описать как обьявление,
отправляемое всем клиентам или серверам, или тем и другим вместе. В
больших сетях одно сообщение может повлечь большое количество траффика
для того, чтобы попасть ко всем желающим.
Для многих сообщений, которые не имеют выбора, но извещение ими всех
серверов эта форма посылки информации каждым сервером - разумная
последовательность между серверами.
3.3.1 Клиент-Клиенту
Класса подобных сообщений нет, который позволяет отсылать сообщение
от пользователя, к каждому другому клиенту.
3.3.2 Клиент-Серверу
Многие команды, которые в результате изменения информации (такой как
членство канала, режим канала, статус пользователя, etc), могут быть
отправлены всем сервером по умолчанию, и их распространение не может
быть изменено клиентом.
3.3.3 Сервер-Серверу
Пока многие сообщения между серверами распространяются на все 'другие'
серверы, требования для любого такого сообщения - влиять на каждого
пользователя, канал или сервер. С тех пор, как эти начальные пункты
находятся в IRC, почти все сообщения, отправленные с сервера, являются
извещениями для всех остальных присоединенных серверов.
4. ДЕТАЛЬНОЕ РАССМОТРЕНИЕ СООБЩЕНИЙ
На следующих страницах описывается каждое сообщение узнаваемое
IRC-сервером и клиентом. Все команды, описанные в этом разделе должны
быть обеспечены любым сервером для этого протокола.
Когда приходит ответ ERR_NOSUCSERVER, это значит, что параметр <server>
не найден. Сервер может не отсылать других ответов после этой команды.
Сервер, к которому присоединился клиент требует к парсингу
(проверка на синтаксис. -- прим. пер.) полное сообщение, возвращая
любые найденные ошибки. Если сервер встретит смертельную ошибку в процессе
парсинга, ошика может быть возвращена обратно клиенту с остановкой
процесса проверки. Эта ошибка может быть вызвана некорректной
командой, направление которой неизвестно серверу (сервер, никнейм или
название канала подходят под эту категорию), не достаточно параметров
или неправильные привилегии.
Если представлен полная список параметров, тогда каждый из них должен
быть проверен на правильность и с присущим ответом вернуться клиенту.
В этом случае сообщения, которые использовалист списками параметров,
использующие запятую как разделитель пунктов, должны получить ответы
для каждого такого пункта.
В примерах ниже, многие сообщения, кажется, используют полный формат:
:Name COMMAND список параметров
Как .. примеров, сообщение от "Name" отправлена транзитом между
серверами, где оно вставит имя оригинального отправителя сообщения
и удаленные серверы смогут отправить ответ по правильному пути.
4.1 Регистрация Соединения
Команды, описываемые здесь, используется для регистрации соединения с
IRC-серверов, как для пользователя или сервер, как лучше и как
правильней рассоединяться.
Команда "PASS" не требуется для регистрации каждого клиентского или
серверного соединения, но она должна предшествовать сообщения сервера
или быть после комбинации NICK/USER. Она очень рекомендуется, чтобы у
всех серверных соединений был пароль, который дает некоторый уровень
защиты в текущих соединениях. Рекомендуемые условия для регистрации
клиента ниже:
1. Pass-сообщение
2. Nick-сообщение
3. User-сообщение
4.1.1 Password-сообщение
Команда: PASS
Параметры: <password>
Команда PASS используется для установки 'парольного соединения'. Пароль
может и должен быть установлен перед любой попыткой регистрации
установленного соединения. В текущий момент, это требования к клиентам
отправлять команду PASS перед отправкой комбинации NICK/USER и серверы
*должны* отправить команду PASS перед любой SERVER-командой. Пароль
должен быть снабжен одним содержимым в C/N-строках (для серверов) или
I-строках (для клиентов). Это возможно для отправки большого количества
PASS-команд перед регистрированием, но только одно последнее
используется для проверки и может не изменить уже зарегистрированое.
Числовые ответы:
ERR_NEEDMOREPARAMS ERR_ALREADYREGISTRED
Пример:
PASS secretpasswordhere
4.1.2 Nick-сообщение
Команда: NICK
Параметры: <nickname> [ <hopcount> ]
NICK используется для установки пользовательского никнейма или
изменения предыдущего. Параметр <hopcount> используется только
серверами, показывая как далеко никнейм от своего "домашнего" сервера.
При локальном соединении счетчик (hopcount) будет равен 0. Если этот
параметр запросится клиентом, параметр будет игнорирован.
Если NICK-сообщение придет от сервера, который уже знает об
идентификации никнейма другим клиентов, никнейм ...
Результатом этого ..., все примеры этого никнейма сотрутся из серверной
базы данных и командой KILL удалит этот никнейм из базы данных остальных
серверов. Если сообщение NICK станет причиной изменения никнейма, то
оргинальный (старый) никнейм удалится.
Если сервер получит идентичный NICK от клиента, который подсоединился
напрямую, он может вывести ERR_NICKCOLLISION локальному клиенту,
отменить команду NICK и не генерировать любых киллов.
Числовые ответы:
ERR_NONICKNAMEGIVEN ERR_ERRONEUSNICKNAME
ERR_NICKNAMEINUSE ERR_NICKCOLLISION
Пример:
NICK Wiz
; Вступление нового никнейма "Wiz".
:WiZ NICK Kilroy ; WiZ изменяет свой никнейм на Kilroy.
4.1.3 User-сообщение
Команда: USER
Параметры: <username> <hostname> <servername> <realname>
Сообщение USER используется вначале соединения для указания имени
пользователя, названия хоста, названия сервера и реального имени нового
пользователя. Так же оно используется в соединении между серверами для
указания нового пользователя, попавшего на IRC, с того только после USER
или NICK, полученными от клиента, пользователь будет зарегистрирован.
Между серверами USER должен быть использован как префикс для
клиентского NICKнейма. Замечено, что имя хоста и имя сервера обычно
игнорируются IRC-сервером, когда приходит команда USER от клиента,
присоединенного напрямую (по причине безопасности), но они
использовались в соединении сервер-сервер. По этому NICK должен всегда
посылаться удаленному серверу, когда новый юзер появляется в сети,
перед посылкой USER.
Должно быть обьявлено, что параметр realname должен быть последним,
потому что он может содержать пробелы и перед ним должен быть префикс
(':'), делающим распознавание более лучшим.
С тех пор для клиентов стало обычным делом - сочинять свое имя
исключительно с помощью USER, рекомендуется использовать "Сервер
Идентификации" ("Identity Server")
Числовые ответы:
ERR_NEEDMOREPARAMS ERR_ALREADYREGISTRED
Примеры:
USER guest tolmoon tolsun :Ronnie Reagan
; Пользователь зарегистрировал себя
под именем "guest" и
его реальное имя
"Ronnie Reagan".
:testnick USER guest tolmoon tolsun :Ronnie Reagan
; Сообщение между
серверами с
никнеймом, установленным командой USER
4.1.4 Server-сообщение
Команда: SERVER
Параметры: <servername> <hopcount> <info>
Эта команда используется для того, чтобы сервер мог понять, что на
другом конце соединения тоже сервер. Так же используется для передачи
данных сервера через всю сеть. Когда новый сервер присоединяется к
сети, информация об этом расходится по всей сети. <hopcount>
используется для передачи всем серверам информации о том, на каком
расстоянии находятся друг от друга серверы. С полным списком серверов
возможно создать карту серверного дерева, но маски хостов предотвратят
подобное дело.
Сообщение SERVER может быть подтверждено только (a) соединеним, которое
еще будет зарегистрировано и зарегистрировано как сервер, или (b)
соединение другого сервера, в этом случае сообщение SERVER является,
как бы, приветствием нового сервера.
Многие ошибки, случающиеся при получении команды SERVER, являются
результатом разрыва соединения хостом-получателем (мишень SERVER).
Ответы ошибок обычно посылаются, используя команду "ERROR", что
несравненно лучше, чем числовые. Подобные ответы несут больше полезной
информации.
Если SERVER-сообщение проверено и пытается пробится к серверу, который
уже знает запрашиваемый сервер, соединение, с которого идет это
сообщение, может быть закрыто (следую корректным процедурам).
Числовые ответы:
ERR_ALREADYREGISTRED
Пример:
SERVER test.oulu.fi 1 :[tolsun.oulu.fi] Experimental server
; Новый сервер test.oulu.fi
представляет
себя и пытается
зарегистрироваться.
В [] имя хоста для хоста,
запущенного
test.oulu.fi.
:tolsun.oulu.fi SERVER csd.bu.edu 5 :BU Central Server
; Сервер tolsun.oulu.fi является
вашим
аплинком для csd.bu.edu,
который
находится в 5 скачках от вас.
4.1.5 Oper
Команда: OPER
Параметры: <user> <password>
Сообщение OPER используется нормальным пользователем для взятия
операторских привилегий. Комбинация <user> и <password> используется
для идентификации пользователя, запрашивающего права IRC-оператора.
Если клиент послал команду OPER с корректным паролем для текущего
пользователя, сервер информамирует сеть о новом операторе, используя
"MODE +o" для никнейма клиента.
Сообщение OPER только для клиент-сеовер.
Числовые ответы:
ERR_NEEDMOREPARAMS RPL_YOUREOPER
ERR_NOOPERHOST
ERR_PASSWDMISMATCH
Пример:
OPER foo bar ; Попытка зарегистрироваться как
оператору, используя
имя пользователя
"foo" и пароль "bar".
4.1.6 Quit-сообщение
Команда: QUIT
Параметры: [<Quit message>]
Сессия клиента заканчивается с QUIT-сообщением. Сервер должен закрыть
соединение с клиентом, когда увидит посланное сообщение.
При нетсплите (разрыве соединения между двумя серверами), сообщение
QUIT содержит в себе имена двух серверов, разделенные пробелами.
Первое имя это сервер, который соединяется, второе имя сервера, который
отсоединился.
Если, по какой-либо причине, соединение клиента закрылось без введения
клиентом команды QUIT (например, обрыв связи), сервер потребует запаса
в quit-сообщениях с некоторой сортировкой сообщения, в поисках причины
разрыва.
Числовые ответы:
None.
Пример:
QUIT :Gone to have lunch ; Обычный формат сообщения.
4.1.7 Server Quit-сообщение
Команда: SQUIT
Параметры: <server> <comment>
Сообщение SQUIT требуется для указания мертвых или вышедших серверов.
Если сервер желает оборвать соединение с другим сервером, он должен
послать сообщение SQUIT другому серверу, используя имя другого сервера
в качестве параметра server.
Эта команда так же доступна IRC-операторам для помощи в сохранеии сети
соединений IRC-серверов в порядке. IRC-операторы могут так же послать
SQUIT для удаленных серверных соединений. В этом случае, SQUID будет
парситься каждым сервером, находящимся между IRC-оператором и удаленным
сервером.
Параметр <comment> обеспечивается всеми операторами, которые запускают
SQUIT для удаленных серверов (которые не присоединены к серверу,
который хотят выключить), так что все операторы знают причины этого
действия.
Один из серверов, которые находятся на другой стороне соединения, будет
закрыт по требованию, высланным сообщением SQUID (ко всем другим
соединениям) дл остальных серверво, которые рассматриваются как линки.
Подобным образом, SQUIT может быть послана другим серверам, находящимся
в сети ради клиентов. В дополнение к этому, все члены канала, который
разбило сплитом, может послать SQUIT-сообщение.
Если соединение сервера закрыто преждевременно (т.е сервер на другом
конце соединения разорвал линк), сервер, который засек этот разрыв
соединения, информирует всю сеть о том, что соединение закрыто и
показывает поле <comment>, обьясняя причину рассоединения.
Числовые ответы:
ERR_NOPRIVILEGES ERR_NOSUCHSERVER
Пример:
SQUIT tolsun.oulu.fi :Bad Link ? ; серверный линк tolson.oulu.fi has
будет закрыт,
потому что "Bad Link".
:Trillian SQUIT cm22.eng.umd.edu :Server out of control
; сообщение от
Trillian, отсоединило
cm22.eng.umd.edu
от сети,
потому что
"Server out of control".
4.2 Операторы каналов
Этот раздел посвящен управлению каналами, их настройками (режимы
каналов), и их содержимым (обычно - клиенты). Для обеспечения этого,
число коренных обстоятельств неизбежен, когда клиенты на разных концах
сети начнут посылать команды, которые приведут в конечном счете к
конфликту. Так же требует, что серверы хранят историю никнейма,
обеспечивая ввод параметра <nick>, сервер проверяет его историю, в
случае, если он был изменен.
4.2.1 Join-сообщение
Команда: JOIN
Параметры: <channel>{,<channel>} [<key>{,<key>}]
Команда JOIN используется клиентом для входа на канал. Так или иначе,
клиенту позволительно войти на канал, проверенным только сервером, к
которому подсоединен; все остальные серверы автоматически добавляют
пользователя на канал, когда получают уведомление от других серверов.
Условия выполнения все того, ниже:
1. Пользователь может быть приглашен, если канал invite-only;
2. Никнейм/имя пользователя/имя хоста не должны быть
забанеными;
3. Если установлен пароль, но должен быть верным.
Это обсуждается в разделе MODE-команды более подробно (см. 4.2.3).
Когда пользователи заходят на канал, они получат уведомление о всех
командах их сервера. Оно вмещает в себе MODE, KICK, PART, QUIT и,
конечно же, PRIVMSG/NOTICE. Команда JOIN требуется для сообщения всем
серверам, чтобы каждый сервер знал, где искать пользователей, которые
находятся на канале. Это позволяет оптимальную передачу сообщений
PRIVMSG/NOTICE в канал.
Если JOIN прошла хорошо, пользователь получает топик канала
(используя RPL_TOPIC) и список пользователей, которые находятся на канале
(используя RPL_NAMREPLY).
Числовые ответы:
ERR_NEEDMOREPARAMS ERR_BANNEDFROMCHAN
ERR_INVITEONLYCHAN ERR_BADCHANNELKEY
ERR_CHANNELISFULL ERR_BADCHANMASK
ERR_NOSUCHCHANNEL ERR_TOOMANYCHANNELS
RPL_TOPIC
Примеры:
JOIN #foobar ; вход на канал #foobar.
JOIN &foo fubar
; вход на канал &foo, используя ключ "fubar".
JOIN #foo,&bar fubar ; вход на канал #foo, используя ключ "fubar"
и на канал &bar
без использования ключа.
JOIN #foo,#bar fubar,foobar ; вход на канал #foo, используя ключ "fubar".
и на канал #bar,
используя ключ "foobar".
JOIN #foo,#bar ; вход на каналы #foo и #bar.
:WiZ JOIN #Twilight_zone ; JOIN-сообщение от WiZ
4.2.2 Part-сообщение
Команда: PART
Параметры: <channel>{,<channel>}
Сообщение PART удаляет клиента, пославшего эту команду из списка
активных пользователей для всех каналов, указанных в параметре.
Числовые ответы:
ERR_NEEDMOREPARAMS ERR_NOSUCHCHANNEL
ERR_NOTONCHANNEL
Примеры:
PART #twilight_zone ; покинуть канал "#twilight_zone"
PART #oz-ops,&group5 ; покинуть каналы "&group5" и
"#oz-ops".
4.2.3 Mode-сообщение
Команда: MODE
Команда MODE интересна своей двоякостью в IRC. Она позволяет изменять
режим как имен пользователей, так и каналов. Рациональность этого
выбора в том, что один день никнеймы будут устаревшими. Так же дела
обстоят и с настройкой канала.
Когда проверяются MODE-сообщения, это рекомендуется делать, ибо
вводимое сообщение будет проверено первым, и тогда изменения, которые
проверены и верны, вступят в силу.
4.2.3.1 Режимы канала
Параметры: <channel> {[+|-]|o|p|s|i|t|n|b|v} [<limit>] [<user>]
[<ban mask>]
Команда MODE предоставляет операторам канала изменять характеристики
'своего' канала. Так же есть требование, что изменять режимы канала
могут только те операторы канала, которые создали канал.
Список доступных режимов канала:
o - брать/давать привилегии операторов канала
p - флаг приватности канала;
s - флаг секретности канала;
i - флаг канала invite-only;
t - при установке этого флага, менять топик могут только
операторы;
n - запрещает сообщения на канал от посторонних клиентов;
m - модерируемый канал;
l - установка ограничения на количество пользователей;
b - установка маски бана;
v - брать/давать возможность голоса при модерируемом режиме;
k - установка на канал ключа (пароля).
Когда используются установки 'o' и 'b', ограничение на полный из трех
When using the 'o' and 'b' options, a restriction on a total of three
per mode command has been imposed. That is, any combination of 'o'
and
4.2.3.2 Параметры пользователя
Параметры: <nickname> {[+|-]|i|w|s|o}
Режимы пользователя обычны такими изменениями, которые воздействуют на
то, каким видят клиента или какие 'экста'-сообщения посылает клиент.
Пользовательская команда MODE может относитется или к отправителю
сообщения или к тому, чей никнейм указали в качестве параметра.
Доступные режимы:
i - делает пользователя невидимым;
s - marks a user for receipt of server notices;
w - user receives wallops;
o - флаг оператора.
Дополнительне режимы будут доступны позже.
Если пользователь пытается сделать себя оператором, используя "+o"
флаг, его попытка будет проигнорирована. Это не разрешено, в отличие от
чьего-либо `деопа' себя самого (используя "-o").
Числовые ответы:
ERR_NEEDMOREPARAMS RPL_CHANNELMODEIS
ERR_CHANOPRIVSNEEDED ERR_NOSUCHNICK
ERR_NOTONCHANNEL ERR_KEYSET
RPL_BANLIST
RPL_ENDOFBANLIST
ERR_UNKNOWNMODE ERR_NOSUCHCHANNEL
ERR_USERSDONTMATCH RPL_UMODEIS
ERR_UMODEUNKNOWNFLAG
Примеры:
Использования режимов канала:
MODE #Finnish +im ; Делает канал #Finnish модерируемым и
'invite-only'.
MODE #Finnish +o Kilroy ; Дает привилегии оператора Kilroy
на канале #Finnish.
MODE #Finnish +v Wiz ; Дает WiZ право голоса на канале #Finnish.
MODE #Fins -s ; Убирает флаг 'secret' с канала #Fins.
MODE #42 +k oulu ; Устанавливает на канал пароль "oulu".
MODE #eu-opers +l 10 ; Устанавливает максимальное количество
пользователей на канале (10).
MODE &oulu +b ; Вывод списка масок бана для канала.
MODE &oulu +b *!*@* ; Предотвращает вход на канал для любого
пользователя.
MODE &oulu +b *!*@*.edu ; Предотвращает вход любого пользователя
подходящего под маску хоста
*.edu.
Использование пользовательских режимов:
:MODE WiZ -w ; turns reception of WALLOPS messages
off for WiZ.
:Angel MODE Angel +i ; Сообщение от Angel далает его невидимым.
MODE WiZ -o ; WiZ 'деопится' (убирает статус
оператора). Прямой доступ к
этой команде
("MODE WiZ +o") не может быть
доступен
пользователям, с тех пор как
введена
команда OPER.
4.2.4 Topic-сообщение
Команда: TOPIC
Параметры: <channel> [<topic>]
Используется для изменения или просмотра топика канала. Топик канала
<channel> останется прежним, если не будет дан новый топик <topic>.
Если параметр <topic> подставлен, - топик канала изменится, если режим
канала позволяет это сделать.
Числовые ответы:
ERR_NEEDMOREPARAMS ERR_NOTONCHANNEL
RPL_NOTOPIC RPL_TOPIC
ERR_CHANOPRIVSNEEDED
Примеры:
:Wiz TOPIC #test :New topic ;Пользователь Wiz устанавливает топик.
TOPIC #test :another topic ;Установка на #test топика "another
topic".
TOPIC #test ;Проверка топика на #test.
4.2.5 Names-сообщение
Команда: NAMES
Параметры: [<channel>{,<channel>}]
Используя команду NAMES, пользователь может получитт список всех
никнеймов, которые он видит на любом канале, на которых они находятся.
Имена каналов, которые они могут видеть это те, которые не приватные
(+p) или секретные (+s), или те, на которых сидит пользователь.
Параметр <channel> указывает, с какого канала(ов) собрать информацию.
Эта команда не возвращает кода ошибки из-за неправильных названий
каналов.
Если параметр <channel> не задан, выводится список всех каналов и имен
тех, кто на них находится. И к концу списка - список пользователей,
которые видимые, но не находятся ни на одной канале, или не на одном
видимом канале, которые начинаюся как 'channel' "*".
Числовые ответы:
RPL_NAMREPLY
RPL_ENDOFNAMES
Примеры:
NAMES #twilight_zone,#42 ; Список видимых пользователей на канале
#twilight_zone и #42,
если каналы
видимы вам.
NAMES
; Список всех видимых каналов
и
пользователей.
4.2.6 List-сообщение
Команда: LIST
Параметры: [<channel>{,<channel>} [<server>]]
LIST используется для вывода списка канало и их топиков. Если
используется параметр <channel>, то выводится только статус этого
канала. Приватные каналы указаны (без их топиков) как каналы "Prv", без
указания количества клиентов, сидящих на этом канале. Само собой -
секретные каналы не приводятся в списке,
если, конечно, клиент не является членом подобного канала.
Числовые ответы:
ERR_NOSUCHSERVER RPL_LISTSTART
RPL_LIST
RPL_LISTEND
Примеры:
LIST
; Список всех каналов.
LIST #twilight_zone,#42 ; Список каналов #twilight_zone и #42
4.2.7 Invite-сообщение
Команда: INVITE
Параметры: <nickname> <channel>
Сообщение INVITE используется для приглашения пользователей на канал.
Параметр <nickname> - указание пользователя, которого требуется
пригласить на канал, который указывается следующим параметром <channel>.
Не обязательно, чтобы канал, на который приглашается указанный
пользователь, был отсутствующим или не правильным каналом. Приглашая
пользователя на канал, который является invite-only (MODE +i), клиент,
посылающий приглашение, должет быть указан как оператор канала на
данном канале.
Числовые ответы:
ERR_NEEDMOREPARAMS ERR_NOSUCHNICK
ERR_NOTONCHANNEL ERR_USERONCHANNEL
ERR_CHANOPRIVSNEEDED
RPL_INVITING RPL_AWAY
Примеры:
:Angel INVITE Wiz #Dust ; Пользователь Angel пригласил WiZ на
канал #Dust
INVITE Wiz #Twilight_Zone ; Команда приглашения WiZ на канал
#Twilight_zone
4.2.8 Kick-команда
Команда: KICK
Параметры: <channel> <user> [<comment>]
Команда KICK может быть использована для ускоренного удаления
пользователя с канала. Как бы выпинывает его с канала (быстрый PART).
Только оператора канала может "кикнуть" другого пользователя с канала.
Каждый сервер, который получил сообщение KICK, проверяет ее на
достоверность (напрмер, что отправитель являтся оператором канала),
перед удалением жертвы с канала.
Числовые ответы:
ERR_NEEDMOREPARAMS ERR_NOSUCHCHANNEL
ERR_BADCHANMASK ERR_CHANOPRIVSNEEDED
ERR_NOTONCHANNEL
Примеры
KICK &Melbourne Matthew ; Кик Matthew с канала &Melbourne
KICK #Finnish John :Speaking English
; Кик John с #Finnish, используя
"Speaking English", как причину
(комментарий).
:WiZ KICK #Finnish John ; KICK-сообщение WiZ удаляет John
с канала #Finnish
ПРИМЕЧАНИЕ:
Возможно расширение команды KICK следующими параметрами:
<channel>{,<channel>} <user>{,<user>} [<comment>]
4.3 Серверные запросы и команды
Группа команд запроса сервера была разработана для возврата информации о
любом сервере, который находится в сети. Все присоединенные сервера
должны отвечать на эти запросы и отвечать корректно. Любой неверный
ответ должен быть рассмотрен как знак того, что сервер неисправен и его
следует отсоединить/отключить до прояснения ситуации.
В этих запросах, в качестве параметра <server> можно указать как
никнейм или сервер, так и маску имен. Для каждого параметра будет
создан один запрос и установлены ответы.
4.3.1 Version-сообщение
Команда: VERSION
Параметры: [<server>]
Используется для запроса версии программы сервера. Параметр <server>
используется для указания сервера, к которому клиент не подсоединен.
Числовые ответы:
ERR_NOSUCHSERVER RPL_VERSION
Примеры:
:Wiz VERSION *.se ; Сообщение от Wiz для проверки версии
сервера, попадающего
под маску "*.se"
VERSION tolsun.oulu.fi ; Проверка версии сервера "tolsun.oulu.fi".
4.3.2 Stats-сообщение
Команда: STATS
Параметры: [<query> [<server>]]
STATS предназначен для запроса статистики указанного сервера. Если
параметр <server> опущен, то возвращается обратно только окончание
stats-ответа.
Запрос может быть дан любым письмом, которое проверяется только
сервером-получателем (если указан параметр <server>) и в противном
случае - на промежуточных серверах, игнорируя и неизменяя.
Следующие запросы содержаться в текущем IRC, обеспечивая и предоставляя
большую часть информации о нужном сервере. Хотя, они могут не
поддерживаться в некоторых версиях, все серверы будут обеспечивать
корректный ответ на запрос STATS, который содержится в текущих
используемых форматах ответа.
На данный момент поддерживаются следующие запросы:
c - возврат списка серверов, к которым может присоединится
сервер;
h - возврат списка серверов, которые доступны как хабы или
свободные;
i - возврат списка хостов, сервер которых доспускает соединение
клиента;
k - возврат списка забаненых имен пользователей/хостов для
указанного сервера;
l - возврат списка серверных соединений, проказывающих
длину каждого соединения и траффик в байтах и сообщениях
для каждого направления;
m - возврат списка команд, поддерживаемых сервером и
используемый подсчет
для каждого, если не равен нулю;
o - возврат списка хостов, с которых нормальные клиенты могут
достать операторов;
y - показ Y (Class) строк из конфигурационного файла сервера;
u - возврат строки, показывающей как давно был поднят сервер.
Числовые Ответы:
ERR_NOSUCHSERVER
RPL_STATSCLINE RPL_STATSNLINE
RPL_STATSILINE RPL_STATSKLINE
RPL_STATSQLINE RPL_STATSLLINE
RPL_STATSLINKINFO RPL_STATSUPTIME
RPL_STATSCOMMANDS RPL_STATSOLINE
RPL_STATSHLINE RPL_ENDOFSTATS
Примеры:
STATS m ; проверка используемой команды для
сервера, с которым вы соединены
:Wiz STATS c eff.org ; запрос WiZ для C/N строки
информации с сервера eff.org
4.3.3 Links-сообщение
Команда: LINKS
Параметры: [[<remote server>] <server mask>]
С LINKS пользователь может создать список всех серверов, которые
знают сервер ответом на запрос. Возвращенный список серверов должен
попадать под маску, или если маска не задана - вернуть полный список.
Если <remote server> задан в дополнительно в <server mask>, команда
LINKS отправится на первый сервер, найденный по этому значению, имени
(если несколько), и этот сервер будет опрашиваться.
Числовые ответы:
ERR_NOSUCHSERVER
RPL_LINKS
RPL_ENDOFLINKS
Примеры:
LINKS *.au ; список всех серверов, попадающих
под маску *.au;
:WiZ LINKS *.bu.edu *.edu ; LINKS-сообщение от WiZ первому серверу
из попадающих под маску *.edu
для выдачи
списка серверов с маской
*.bu.edu.
4.3.4 Time-сообщение
Команда: TIME
Параметры: [<server>]
Используется для запроса локального времени указанного сервера. Если
параметр <server> опущен, будет выдан ответ с сервера ващего соединения.
Числовые ответы:
ERR_NOSUCHSERVER RPL_TIME
Примеры:
TIME tolsun.oulu.fi ; проверка времени на сервере
"tolson.oulu.fi"
Angel TIME *.au ; пользователь Angel запрашивает время
на серверах,
попадающих под маску "*.au"
4.3.5 Connect-сообщение
Команда: CONNECT
Параметры: <target server> [<port> [<remote server>]]
Команда используется для попытки создания сервером нового соединения с
другим сервером. CONNECT-сообщением могут пользоваться только
IRC-операторы. Если удаленный сервер указан в строке параметров, он
присоединяется к <target server> на <port>.
Числовые ответы:
ERR_NOSUCHSERVER ERR_NOPRIVILEGES
ERR_NEEDMOREPARAMS
Примеры:
CONNECT tolsun.oulu.fi ; Попытка присоединиться к серверу
tolsun.oulu.fi
:WiZ CONNECT eff.org 6667 csd.bu.edu
; CONNECT вызывает WiZ для соединения
eff.org и csd.bu.edu на порт
6667.
4.3.6 Trace-сообщение
Команда: TRACE
Параметры: [<server>]
TRACE используется для поиска маршрута до указанного сервера. Каждый
сервер, через которого проходит это сообщение, должен информировать
отправителя о прозрачности линка и формировать цепочку ответов от
использования "traceroute". После отправления ответа, он должен послать
TRACE-сообщение следующему серверу и так до указанного сервера. Если
параметр <server> опущен, то отправителю придет ответ, который будет
содержать всех серверы, которые соединены с его сервером.
Если указанный в <server> является текущим сервером, тогда придет
ответ, содержащий все серверы и пользователей, которые присоединены к
нему, хотя просмотр пользователей разрешается делать только операторам.
Если в <server> указать никнейм, придет ответ для этого никнейма.
Числовые ответы:
ERR_NOSUCHSERVER
Если TRACE отправлено к другому серверу, все промежуточные серверы
должны вернуть ответ RPL_TRACELINK для сообщения о прохождении сквозь
них TRACE-сообщения.
RPL_TRACELINK
TRACE-ответ может быть составлен из любых следующих числовых ответов.
RPL_TRACECONNECTING RPL_TRACEHANDSHAKE
RPL_TRACEUNKNOWN RPL_TRACEOPERATOR
RPL_TRACEUSER RPL_TRACESERVER
RPL_TRACESERVICE RPL_TRACENEWTYPE
RPL_TRACECLASS
Примеры:
TRACE *.oulu.fi ; TRACE серверу из маски *.oulu.fi
:WiZ TRACE AngelDust ; TRACE используется WiZ для никнейма AngelDust
4.3.7 Admin-команда
Команда: ADMIN
Параметры: [<server>]
Сообщение ADMIN используется для поиска администратора указанного
сервера, или текущего сервера, если параметр <server> не указан. Каждый
сервер должен иметь возможность отправить ADMIN-сообщения другим
серверам.
Числовые ответы:
ERR_NOSUCHSERVER
RPL_ADMINME
RPL_ADMINLOC1
RPL_ADMINLOC2 RPL_ADMINEMAIL
Примеры:
ADMIN tolsun.oulu.fi ; запрос ADMIN-ответа с tolsun.oulu.fi
:WiZ ADMIN *.edu ; ADMIN-запрос от WiZ для первого
сервера, найденного по
маске *.edu.
4.3.8 Info-команда
Команда: INFO
Параметры: [<server>]
Команда запрашивает информацию, которой описывается сервер: версия,
когда скомпилирован, patchlevel, когда запущен, и другую информацию,
которая может заинтерисовать запрашивающего.
Числовые ответы:
ERR_NOSUCHSERVER
RPL_INFO
RPL_ENDOFINFO
Примеры:
INFO csd.bu.edu ; запрос INFO с csd.bu.edu
:Avalon INFO *.fi ; INFO запрошен Avalon для первого
сервера, найденного по
маске *.fi.
INFO Angel
; запрос INFO от сервера, к которому
подсоединен Angel.
4.4 Сообщения отправки
Основное предназначение IRC-протокола - предоставление основы для связи
и общения между клиентами. PRIVMSG и NOTICE являются текстовыми
сообщениями от одного клиента к другим.
4.4.1 Private-сообщения
Команда: PRIVMSG
Параметры: <receiver>{,<receiver>} <text to be sent>
PRIVMSG используется для частной переписки между пользователями.
<receiver> - никнейм получателя сообщения. Так же там можно указать
список имен или каналов, разделенных запятыми.
Параметр <receiver> так же может быть маской хоста (#mask) или маски
сервера ($mask). В обоих случаях сервер будет отсылать PRIVMSG только
тем, кто попадает под серверную или хост-маску. Маска должна содержать
в себе как минимум 1 (одну) ".". Это требование вынуждаеит пользователей
отсылать сообщения к "#*" или "$*", которые уже потом рассылаются всем
пользователям; по опыту, этим злоупотребляет большое количество
пользователей. В масках используются такие символы как '*' и '?'. Это
расширение команды PRIVMSG доступно только IRC-операторам.
Числовые ответы:
ERR_NORECIPIENT ERR_NOTEXTTOSEND
ERR_CANNOTSENDTOCHAN ERR_NOTOPLEVEL
ERR_WILDTOPLEVEL ERR_TOOMANYTARGETS
ERR_NOSUCHNICK
RPL_AWAY
Примеры:
:Angel PRIVMSG Wiz :Hello are you receiving this message ?
; Сообщение от Angel к Wiz;
PRIVMSG Angel :yes I'm receiving it !receiving it !'u>(768u+1n) .br ;
Сообщение к Angel;
PRIVMSG jto@tolsun.oulu.fi :Hello !
; Сообщение от клиента на
сервер.
tolsun.oulu.fi с именем "jto";
PRIVMSG $*.fi :Server tolsun.oulu.fi rebooting.
; Сообщение ко всем, кто находится на
серверах, попадающих под маску
*.fi;
PRIVMSG #*.edu :NSFNet is undergoing work, expect interruptions
; Сообщение для всех
пользователей,
сидящих на хосте, попадающим
под маску *.edu.
4.4.2 Notice-сообщения
Команда: NOTICE
Параметры: <nickname> <text>
Сообщение NOTICE используеьтся подобно PRIVMSG. Отличия между ними в
том, что на NOTICE-сообщение ждать автоматического ответа бесполезно.
Это правило распространяется и на серверы, - они не должны отсылать
обратно сообщения-NOTICE клиентам, содержащие ошибки. Обьект этого
правила заключается в петле между клиентом, автоматически посылающим
что-либо в ответ на что-либо полученное. Обычно, это используется
автоматами (клиентами с AI или другой интерактивной программой,
управляющей их действиями).
См. PRIVMSG для более подробной информации о запросах и ответах.
4.5 Пользовательские запросы
Пользовательские запросы являют собой группу команд, которая главным
образом касается поиска подробностей на особенном пользователе или
группы пользователей. Когда используются маски с разнымит командами,
если они подставляются, они должны возвращать информацию только тех
пользователей, которые 'видны' вам. Видимость пользователя определяется
как комбинация режима пользователя и установки каналов.
4.5.1 Who-запрос
Команда: WHO
Параметры: [<name> [<o>]]
Сообщение WHO используется клиентом для создания запроса, который
возвращает список информации, которая 'подставляется' параметром <name>
указанным клиентом. В отсутствии параметра <name>, все видимые
(пользователи, которых не видно (пользовательский режим +i) и те, кто
находятся на других каналах, нежели запрашивающий клиент) попадают в
список. Результат может быть достигнут использованием вместо <name> "0"
или других масок, которые будут подставлять все возможные окончания.
<name> обратиться к WHO, подставленному против пользовательского
хоста, сервера, реального имени или никнейма, если канал <name> не найден.
Если параметр "o" прошел только операторам, обеспечивается возврат
только маски имени.
Числовые ответы:
ERR_NOSUCHSERVER
RPL_WHOREPLY
RPL_ENDOFWHO
Примеры:
WHO *.fi
; Список пользователей, кто стоит
напротив "*.fi";
WHO jto* o
; Список пользователей, кто находится
напротив подходящей
маски "jto*", если
они являются операторами.
4.5.2 Whois-запрос
Команда: WHOIS
Параметры: [<server>] <nickmask>[,<nickmask>[,...]]
Это сообщение используется для запроса информации об отдельном
пользователе. Сервер будет отвечать на это сообщением различными
числовыми сообщениями, указывая разность положений каждого пользователя,
который попал под маску (если вы указали ее). Если в <nickmask> не
указана никакая информация о том, какой никнейм опросить, вы получите
информацию о всех доступных никнеймах. Запятая разделяет список
никнеймов.
Предыдущая версия отправляла запрос на указанный сервер. Это полезно,
если хотите знать как долго опрашиваемый пользователь будет
бездействовать , как только локальный сервер (т.е, пользователь
напрямую соединен с сервером) узнает эту информацию.
Числовые ответы:
ERR_NOSUCHSERVER ERR_NONICKNAMEGIVEN
RPL_WHOISUSER
RPL_WHOISCHANNELS
RPL_WHOISCHANNELS RPL_WHOISSERVER
RPL_AWAY
RPL_WHOISOPERATOR
RPL_WHOISIDLE ERR_NOSUCHNICK
RPL_ENDOFWHOIS
Примеры:
WHOIS wiz
; возврат пользователю информацию
о никнейме WiZ;
WHOIS eff.org trillian ; опрос сервера eff.org о информации
пользователя trillian.
4.5.3 Whowas-сообщение
Команда: WHOWAS
Параметры: <nickname> [<count> [<server>]]
WHOWAS запрашивает информацию о никнейме, который долгое время
отсутствует. Это может понадобиться при изменении никнейма или если
пользователь покинул IRC. В ответе на этот запрос, сервер ищет историю
никнейма, просматривая все никнеймы, которые хоть как-то похожи на
нужный (без использования масок). Наибольший размер найденного
отсылается обратно. Если было многоразовый ввод, ответы будут равны
числу указанного в <count> (или все из них, если параметр будет не
задан).
Числовый ответы:
ERR_NONICKNAMEGIVEN ERR_WASNOSUCHNICK
RPL_WHOWASUSER RPL_WHOISSERVER
RPL_ENDOFWHOWAS
Примеры:
WHOWAS Wiz
; возврат всей информации в истории о
никнейме "WiZ";
WHOWAS Mermaid 9 ; возврат 9 наиболее запрашиваемых
вводов в
никнейм-истории для "Mermaid";
WHOWAS Trillian 1 *.edu ; возврат наиболее запрашиваемой
истории для "Trillian"
с первого
сервера, попавшего под
маску "*.edu".
4.6 Всевозможные сообщения
Сообщения этого раздела не попали в другие категории, но они так же
доступны и требуемые протоколом.
4.6.1 Kill-сообщение
Команда: KILL
Параметры: <nickname> <comment>
Сообщение KILL используется соединением клиент-сервер для закрытия
сервером текущего соедиения. KILL используется серверами, когда они
замечают двойной вход в список разрешенных никнеймов и удаляют второго
зашедшего. Так же, команда доступна IRC-операторам.
Клиенты, у которых настройки позволяют автоматически пересоединяться,
делают эту команду бесполезной. Этому так же может служить ухудшение
связи и использоваться в остановке большого количества ошибок, любой
пользователь может выбрать получение KILL-сообщений, созданных для
других, сохраняя 'глаз' на наличествующей проблеме.
В месте, где к никнеймам существует требование уникальности, сообщения
KILL отправляется всем замеченым 'дупликатам' (что пытаются
зарегистрировать двух пользователей с некоторым никнеймом) в надежде,
что один из них исчезнет и останется только один.
Коментарий указывается для сообщения причины KILL. Для KILL'ов,
созданных сервером, обычно причина указывается как конфликт между двумя
никнеймами. Для пользователей это является достаточной адекватной
причиной для удовлетворения тех, кто видел это. Предотвращая обманные
KILL'ы, коментарий так же показывает 'kill-path', который обновляется
каждым сервером, тем самым показывая "источник" KILL-сообщения.
Числовые ответы:
ERR_NOPRIVILEGES ERR_NEEDMOREPARAMS
ERR_NOSUCHNICK
ERR_CANTKILLSERVER
KILL David (csd.bu.edu <- tolsun.oulu.fi)
; Никнейм застрял между
csd.bu.edu
и tolson.oulu.fi
ЗАМЕЧАНИЕ:
Рекомендуется разрешить "убивать" других пользователей только
IRC-операторам. В идеальном мире не каждому оператору понадобиться
делать подобное.
4.6.2 Ping-сообщение
Команда: PING
Параметры: <server1> [<server2>]
PING испольщуется для тестирования наличия активности клиента на другом
конце соединения. Это сообщение посылается с регулярными интервалами,
если не замечено другой активности, исходящей от соединения. Если
соединение не отвечает на PING - соединение закрыто.
Любой клиент, который получил PING-сообщение, должен ответить на
<server1> (сервер, который посылает сообщение PING) так быстро, как это
только возможно, с PONG-сообщением, указывая на то, что он еще здесь и
живой. Серверы могут не отвечать на команды PING, но полагаясь на
PING'и с другого конца соединения, устанавливают живо ли соединение.
Если указан параметр <server2>, PING'сообщение перенаправляется туда.
Числовые ответы:
ERR_NOORIGIN
ERR_NOSUCHSERVER
Примеры:
PING tolsun.oulu.fi ; сервер послал PING-сообщение другому
серверу для проверки
живости соединения.
PING WiZ
; PING-сообщение послано никнейму WiZ
4.6.3 Pong-сообщение
Команда: PONG
Параметры: <daemon> [<daemon2>]
PONG является ответной реакцией на PING. Если дан параметр <daemon2>,
это сообщение должно быть перенаправленна данному демону. Параметр
<daemon> является именем демона, который отвечает на PING-сообщение и
генерирует это сообщение.
Числовые ответы:
ERR_NOORIGIN
ERR_NOSUCHSERVER
Примеры:
PONG csd.bu.edu tolsun.oulu.fi ; PONG-сообщение от csd.bu.edu к
tolsun.oulu.fi
4.6.4 Error-сообщение
Команда: ERROR
Параметры: <error message>
Команда ERROR предназначена для использования серверами, когда они
сообщают о серьезных или смертельных ошибках IRC-операторам. Сообщение
так же может быть отправлена с одного сервера на другой, но это не
сможет быть подтверждено с любых нормальных неизвестных клиентов.
ERROR используется для сообщения ошибок, которые случаются только при
соединениях класса сервер-к-серверу. Сообщение отсылается на сервер с
другого конца соединения (который оправляет его всем IRC-операторам,
подсоединенным к нему) и всем операторам текущего соединения. Оно не
может быть отослано каким-либо другим серверам, если оно не получено с
сервера.
Когда сервер отсылает полученное ERROR-сообщение к своим операторам,
сообщение следует поместить в сообщение NOTICE, сообщающее, что клиент
не может отвечать на ошибку.
Числовые ответы:
None.
Примеры:
ERROR :Server *.fi already exists; ERROR-сообщение с другого сервера,
являющегося причиной
ошибки.
NOTICE WiZ :ERROR from csd.bu.edu -- Server *.fi already exists
; Несколько
ERROR-сообщений, но
посланнных от
пользователя WiZ на
другой сервер.
5. ОПЦИОНАЛЬНЫЕ СООБЩЕНИЯ
Этот раздел описывает опциональные сообщения. Они не требуются в рабочем
сервере, но так или иначе они тоже часть протокола. В отсутствии опции,
может создаваться ERROR-сообщение или просто неизвестная командная
ошибка. Если сообщение адресовано другому серверу, тогда она должна
быть пропущена (потребуется элементарный парсинг). Назначенные
числители для того, описаны ниже.
5.1 Away-сообщение
Команда: AWAY
Параметры: [message]
С сообщением AWAY, клиенты могут устанавливать автоматическую строку
ответа на любые PRIVMSG-команды, направленные им (не на канал).
Автоматический ответ посылается сервером к клиенту, пославшего команду
PRIVMSG. Только отвечающий сервер может быть только один, к которому
подсоединен клиент.
AWAY используется вместе с одним параметром (установка сообщения AWAY)
или без параметров (снятие сообщения AWAY).
Числовые ответы:
RPL_UNAWAY
RPL_NOWAWAY
Примеры:
AWAY :Gone to lunch. Back in 5 ; установка away-сообщения "Gone to lunch.
Back in 5".
:WiZ AWAY
; снятие пользователем WiZ сообщения
AWAY.
5.2 Rehash-сообщение
Команда: REHASH
Параметры: None
REHASH используется IRC-оператором для перечитывания конфигурационных
файлов сервера.
Числовые ответы:
RPL_REHASHING ERR_NOPRIVILEGES
Примеры:
REHASH
; сообщение от клиента со статусом
IRC-оператора запускает
процесс перечитывания
конфигурационных файлов сервера.
5.3 Restart-сообщение
Команда: RESTART
Параметры: None
RESTART также испольщуется только IRC-оператором для перезагрузки
сервера. Это сообщение опциональное, хотя оно может быть рассмотрено
как рискованное - позволяя пользователям присоединяться к серверу в
качестве IRC-оператора и запустить эту команду, причиняя разрушения
сервису.
Команда RESTART должна всегда быть полностью выполняема сервером,
к которому присоединен посылающий команду клиент и не принимать от
других серверов.
Числовые ответы:
ERR_NOPRIVILEGES
Примеры:
RESTART ; не требует параметров.
5.4 Summon-сообщение
Команда: SUMMON
Параметры: <user> [<server>]
Команда может быть использована для вызова пользователей, сидящих на
том же хосте, что и IRC-сервер, в IRC. Это сообщение посылается только
если требуемый сервер (a) имеет включенный SUMMON, (b) пользователь
находится в сети и (c) сервер может написать в пользовательский tty
(или подобное).
Если параметр <server> не задан, то попытки вызвать <user> с сервера
будут на сервере, на котором подсоединен клиент, вызывающий <user>.
Если SUMMON отключена на сервере, должен возвратиться числовой ответ
ERR_SUMMONDISABLED и оригинал сообщения.
Числовые ответы:
ERR_NORECIPIENT ERR_FILEERROR
ERR_NOLOGIN
ERR_NOSUCHSERVER
RPL_SUMMONING
Примеры:
SUMMON jto
; вызов пользователя jto на хост сервера
SUMMON jto tolsun.oulu.fi ; вызов пользователя jto на схост
сервера, который
обьявлен параметром -
"tolsun.oulu.fi"
5.5 Users-сообщение
Команда: USERS
Параметры: [<server>]
USERS выводит список пользователей находящихся на сервера в формате,
подобном who(1), rusers(1) и finger(1). Многие могут отключить эту
команду на своем сервере по причине безопасности. Если отключено, то
выйдет числовой ответ, указавая на это.
Числовые ответы:
ERR_NOSUCHSERVER ERR_FILEERROR
RPL_USERSSTART RPL_USERS
RPL_NOUSERS
RPL_ENDOFUSERS
ERR_USERSDISABLED
Ответ отключенной команды:
ERR_USERSDISABLED
Примеры:
USERS eff.org ; запрос списка пользователей с сервера
eff.org
:John USERS tolsun.oulu.fi ; запрос от John списка пользователей
с сервера tolsun.oulu.fi
5.6 Operwall-команда
Команда: WALLOPS
Параметры: Текст, отсылаемый всем IRC-операторам, находящихся в сети.
Отправка сообщения всем IRC-оператороам, которые находятся в данный
момент в сети. После выполнения WALLOPS как команды пользователя,
это будет расцениваться как частое и обычно неверное, ибо отправлено
сообщение большому количеству людей (подобно WALL). Прямо рекомендуемо,
что текущая принадлежность WALLOP будет использована каак пример
доступности и узнаваема только серверами, как отправителями WALLOPS.
Числовые ответы:
ERR_NEEDMOREPARAMS
Примеры:
:csd.bu.edu WALLOPS :Connect '*.uiuc.edu 6667' from Joshua; WALLOPS
сообщение от
csd.bu.edu, обьявляющая,
что CONNECT-сообщение
получено и
активизировано Joshua.
5.7 Userhost-сообщение
Команда: USERHOST
Параметры: <nickname>{<space><nickname>}
Команда USERHOST требует список больше 5-ти никнеймов, разделеных
пробелом и возвращает информацию о каждом никнейме, который был найден.
Числовые ответы:
RPL_USERHOST
ERR_NEEDMOREPARAMS
Примеры:
USERHOST Wiz Michael Marty p ;USERHOST запрос информации о никнеймах
"Wiz", "Michael",
"Marty" и "p"
5.8 Ison-сообщение
Команда: ISON
Параметры: <nickname>{<space><nickname>}
ISON предоставляет быстрый и экономичный вариант отдачи отклика о
каком-либо из двух никнеймов, находящихся в IRC. ISON использует тольуо
один (1) параметр: список никнеймов, разделенных пробелами. Для каждого
никнейма, представленного в списке, сервер добавляет в свою ответную
строку. Но эта строка может вернуться и пустой, и просто копией
параметра строки, или какой-другой подстановкой никнеймов. Есть только
одно ограничение - длина списка никнеймов не должна превышать 512
символов, иначе сервер обрежет параметр под этот предел.
ISON поддерживается сервером только для клиентов, присоединенных к нему
и игнорирует запросы других.
Числовые ответы:
RPL_ISON ERR_NEEDMOREPARAMS
Примеры:
ISON phone trillian WiZ jarlek Avalon Angel Monstah
; Пример ISON запроса
7 никнеймов.
6. ОТВЕТЫ
Следующий список числовых ответов, которые создаются как ответная
реакция на вводимые команды. Каждый
Each numeric is given with its number, name and reply string.
6.1 Error-ответы
401 ERR_NOSUCHNICK
"<nickname> :No such nick/channel"
- Используется для сообщения, что опущен параметр,
отвечающий за никнейм.
402 ERR_NOSUCHSERVER
"<server name> :No such server"
- Используется для сообщения, что сервер, указанный в
строке параметров, не найден.
403 ERR_NOSUCHCHANNEL
"<channel name> :No such channel"
- Используется для сообщения, что название канала не
верно.
404 ERR_CANNOTSENDTOCHAN
"<channel name> :Cannot send to channel"
- Отсылается пользователю, который либо (a) не на канале,
с режимом +n, либо (b) не является чанопом (или режима
+v) на канале, который имеет режим +m, и пытается
отослать PRIVMSG-сообщение на этот канал.
405 ERR_TOOMANYCHANNELS
"<channel name> :You have joined too many \
channels"
- Отсылается пользователю, когда он уже находится на
максимально разрешенном количестве каналов и пытается
зайти на еще один канал.
406 ERR_WASNOSUCHNICK
"<nickname> :There was no such nickname"
- Возвращается командой WHOWAS, показывая тем самым
отсутствие истории информации об указанном никнейме.
407 ERR_TOOMANYTARGETS
"<target> :Duplicate recipients. No message \
delivered"
- Возвращается клиенту, который пытается отослать
PRIVMSG/NOTICE, используя формат отправки user@host и
для user@host, который имеет особые случаи.
409 ERR_NOORIGIN
":No origin specified"
- PING или PONG сообщения теряют параметр источника,
который требуется, хотя эти команды должны работать без
правильных префиксов.
411 ERR_NORECIPIENT
":No recipient given (<command>)"
412 ERR_NOTEXTTOSEND
":No text to send"
413 ERR_NOTOPLEVEL
"<mask> :No toplevel domain specified"
414 ERR_WILDTOPLEVEL
"<mask> :Wildcard in toplevel domain"
- 412 - 414 возвращаются командой PRIVMSG, показывая, что
сообщение не смогло пройти по некоторым причинам.
ERR_NOTOPLEVEL и ERR_WILDTOPLEVEL ошибки, что
возвращаются, когда неправильно используют
"PRIVMSG $<server>" или "PRIVMSG #<host>".
421 ERR_UNKNOWNCOMMAND
"<command> :Unknown command"
- Возвращается зарегистрированному клиенту, при попытке
отослать неизвестную серверу команду.
422 ERR_NOMOTD
":MOTD File is missing"
- Серверный файл MOTD не может быть открыт сервером.
423 ERR_NOADMININFO
"<server> :No administrative info available"
- Возвращается сервером при ответе на ADMIN-сообщение,
когда оно является ошибкой в найденной информации.
424 ERR_FILEERROR
":File error doing <file op> on <file>"
- Генерация ERROR-сообщения, используя для отчета
поврежденного файла.
431 ERR_NONICKNAMEGIVEN
":No nickname given"
- Возвращается, когда в параметре отсутствует никнейм.
432 ERR_ERRONEUSNICKNAME
"<nick> :Erroneus nickname"
- Возвращается после получения NICK-сообщения, которое
содержит символы, которые запрещены. Смотрите раздел
х.х.х для более подробной информации.
433 ERR_NICKNAMEINUSE
"<nick> :Nickname is already in use"
- Возвращается при смене никнейма на другой, уже
используемый.
436 ERR_NICKCOLLISION
"<nick> :Nickname collision KILL"
- Возвращается сервером к клиенту, когда сервер видит
конфликт никнейма (зарегистрированный никнейм уже есть).
441 ERR_USERNOTINCHANNEL
"<nick> <channel> :They aren't on that channel"
- Возвращается сервером, указывая на то, что данный
пользователь отсутствует на канале, заданном в
параметре.
442 ERR_NOTONCHANNEL
"<channel> :You're not on that channel"
- Возвращается сервером, как только клиент пытается
выполнить команду канала, на котором отсутствует.
443 ERR_USERONCHANNEL
"<user> <channel> :is already on channel"
- Возвращается, когда клиент пытается пригласить
пользователя на канал, на котором пользователь
уже присутствует.
444 ERR_NOLOGIN
"<user> :User not logged in"
- Возвращается вызывающим после команды SUMMON для
пользователя, который в данное время недоступен в сети.
445 ERR_SUMMONDISABLED
":SUMMON has been disabled"
- Возвращается как ответ на команду SUMMON. Может быть
возвращено любым сервером.
446 ERR_USERSDISABLED
":USERS has been disabled"
- Возвращается как ответ на команду USERS. Может быть
возвращено любым сервером.
451 ERR_NOTREGISTERED
":You have not registered"
- Возвращается сервером для напоминания, что клиент должен
быть зарегистрирован, перед тем, как сервер даст
дополнительные возможности.
461 ERR_NEEDMOREPARAMS
"<command> :Not enough parameters"
- Возвращается сервером, числительными командами для
указания пользователю, что тот не указал всех параметров.
462 ERR_ALREADYREGISTRED
":You may not reregister"
- Возвращается сервером любому линку, который пытается
изменить часть подробностей регистрации (подобные паролю
или пользовательской информацией из второго
USER-сообщения).
463 ERR_NOPERMFORHOST
":Your host isn't among the privileged"
- Возвращается клиенту, который пытается
зарегистрироваться с сервером, который не настроен на
поддержку соединений с хостом, который пытается
присоединиться.
464 ERR_PASSWDMISMATCH
":Password incorrect"
- Возвращается при неправильно введеном или неуказанным
паролем.
465 ERR_YOUREBANNEDCREEP
":You are banned from this server"
- Возвращается после попытки соединения и регистрации с
сервером, который настроен на отказ регистрации с вами.
467 ERR_KEYSET
"<channel> :Channel key already set"
471 ERR_CHANNELISFULL
"<channel> :Cannot join channel (+l)"
472 ERR_UNKNOWNMODE
"<char> :is unknown mode char to me"
473 ERR_INVITEONLYCHAN
"<channel> :Cannot join channel (+i)"
474 ERR_BANNEDFROMCHAN
"<channel> :Cannot join channel (+b)"
475 ERR_BADCHANNELKEY
"<channel> :Cannot join channel (+k)"
481 ERR_NOPRIVILEGES
":Permission Denied- You're not an IRC operator"
- Любая команда, требующая привилегий IRC-оператора,
должна вернуть подобную ошибку, показывая на
безуспешность действий рядового пользователя.
482 ERR_CHANOPRIVSNEEDED
"<channel> :You're not channel operator"
- Любая команда, требущая привилегий "чанопа" (подобно
MODE-сообщениям), должна вернуть подобную ошибку,
показывая на безуспешность действий рядового пользователя.
483 ERR_CANTKILLSERVER
":You cant kill a server!"
- Любые попытки использования KILL-команды на сервере
будут отклонены и эта ошибка вернется клиенту.
491 ERR_NOOPERHOST
":No O-lines for your host"
- Если сервер не настроен на поддержку клиентского хоста
для сообщения OPER, клиенту будет возвращена эта ошибка.
501 ERR_UMODEUNKNOWNFLAG
":Unknown MODE flag"
- Возвращается сервером, если MODE-сообщение не было
распознано.
502 ERR_USERSDONTMATCH
":Cant change mode for other users"
- Ошибка отсылается любому пользоватею, пытающемуся
посмотреть или изменить режим какого-либо другого
пользователя.
6.2 Отклики команд
300 RPL_NONE
Dummy reply number. Not used.
302 RPL_USERHOST
":[<reply>{<space><reply>}]"
- Формат ответа, используемый командой USERHOST для списка
ответов к запрашиваемому списку. Строка ответа
представляет собой следующее:
<reply> ::= <nick>['*'] '='
<'+'|'-'><hostname>
'*' обозначает, что клиент зарегистрирован как
IRC-оператор. Символы '-' или '+' обозначает, что клиент
установил режим AWAY или не доступен.
303 RPL_ISON
":[<nick> {<space><nick>}]"
- Формат ответа, используемый командой ISON для списка
ответов к запрашиваемому списку.
301 RPL_AWAY
"<nick> :<away message>"
305 RPL_UNAWAY
":You are no longer marked as being away"
306 RPL_NOWAWAY
":You have been marked as being away"
- Эти ответы используются с командой AWAY (если доступно).
RPL_AWAY отсылается любому клиенту, пославшему PRIVMSG
клиенту, который находит в состоянии AWAY. RPL_AWAY
отсылается только сервером, к котому присоединен клиент.
Ответы RPL_UNAWAY и RPL_NOWAWAY отправляются, когда
клиент удаляет или устанавливает режим AWAY.
311 RPL_WHOISUSER
"<nick> <user> <host> * :<real
name>"
312 RPL_WHOISSERVER
"<nick> <server> :<server info>"
313 RPL_WHOISOPERATOR
"<nick> :is an IRC operator"
317 RPL_WHOISIDLE
"<nick> <integer> :seconds idle"
318 RPL_ENDOFWHOIS
"<nick> :End of /WHOIS list"
319 RPL_WHOISCHANNELS
"<nick> :{[@|+]<channel><space>}"
- Ответы 311 - 313, 317 - 319 генерируются в ответ на
WHOIS-сообщение. Отвечающий сервер должен
формулировать каждый ответ числовым (если найден
запрашиваемый никнейм) или возвращать ERROR-ответ. '*' В
RPL_WHOISUSER не является маской, но буквенным символом.
Для каждого ответа установка, только RPL_WHOISCHANNELS
может казаться больше, тогда только (для длинных списков
имен каналов). '@' и '+' символы, указывающие какой
клиент является оператором канала или кому разрашается
говорить на модерируемом канале. RPL_ENDOFWHOIS
используется для пометки окончания WHOIS-сообщения.
314 RPL_WHOWASUSER
"<nick> <user> <host> * :<real
name>"
369 RPL_ENDOFWHOWAS
"<nick> :End of WHOWAS"
- Когда отвечают на WHOWAS-сообщения, сервер должен
использовать ответы RPL_WHOWASUSER, RPL_WHOISSERVER или
ERR_WASNISUCHNICK для каждого никнейма в указаном
списке. К концу всех пакетов ответов, может быть
RPL_ENDOFWHOWAS (только если будет один ответ или будет
являться ошибкой).
321 RPL_LISTSTART
"Channel :Users Name"
322 RPL_LIST
"<channel> <# visible> :<topic>"
323 RPL_LISTEND
":End of /LIST"
- Ответы RPL_LISTSTART, RPL_LIST, RPL_LISTEND помечают
начало текущих ответос с данными и конец серверных
ответов на команду LIST. Если недоступен ни один канал,
отправятся только начало и конец ответа.
324 RPL_CHANNELMODEIS
"<channel> <mode> <mode params>"
331 RPL_NOTOPIC
"<channel> :No topic is set"
332 RPL_TOPIC
"<channel> :<topic>"
- Когда отправляется TOPIC-сообщение, обозначающее топик
канала, отправиться должен один из двуъ ответов. Если
топик установлен, отсылается RPL_TOPIC. Иначе -
RPL_NOTOPIC.
341 RPL_INVITING
"<channel> <nick>"
- Возвращается сервером, обозначая что попытка
INVITE-сообщения была успешно выполнена по отношению к
приглашенному клиенту.
342 RPL_SUMMONING
"<user> :Summoning user to IRC"
- Возвращается сервером, отвечающего на SUMMON-сообщение
и обозначающего, что вызывается пользователь.
351 RPL_VERSION
"<version>.<debuglevel> <server>
:<comments>"
- Ответ сервером, показывающий версию в подробностях.
<version> - версия программного обеспечения,
(включая все патчи) и <debuglevel> использующийся для
обозначения того, что сервер запущен "дебаг-режиме".
Поле "comments" может содержать любые комментарии о
версии и других подробностях.
352 RPL_WHOREPLY
"<channel> <user> <host> <server>
<nick> \
<H|G>[*][@|+] :<hopcount> <real name>"
315 RPL_ENDOFWHO
"<name> :End of /WHO list"
- RPL_WHOREPLY и RPL_ENDOFWHO пара, используемая для
ответа WHO-сообщения. RPL_WHOREPLY отсылается только
если предназначена подстановкой к WHO-запросу. Если
список параметров обеспечен WHO-сообщением, RPL_ENDOFWHO
должен отослаться после обработки каждого пункта
списка, начинающегося на <name>.
353 RPL_NAMREPLY
"<channel> :[[@|+]<nick> [[@|+]<nick>
[...]]]"
366 RPL_ENDOFNAMES
"<channel> :End of /NAMES list"
- Для ответа на NAMES-сообщения, пара ответов, содержащих
RPL_NAMEREPLY и RPL_ENDOFNAMES отправляются сервером
обратно к клиенту. Если запрашиваемый канал не найден,
возвращается RPL_ENDOFNAMES. Исключая то, когда
NAMES-сообщение отправлено без параметров, и все каналы
видимые с содержимым - возвращается серия
RPL_NAMEREPLY-сообщений с RPL_ENDOFNAMES, как пометкой
окончания.
364 RPL_LINKS
"<mask> <server> :<hopcount> <server
info>"
365 RPL_ENDOFLINKS
"<mask> :End of /LINKS list"
- В ответе на LINKS-сообщение, сервер должен отослать
ответы обратно, используя RPL_LINKS и пометкой конца
списка - RPL_INDOFREPLY.
367 RPL_BANLIST
"<channel> <banid>"
368 RPL_ENDOFBANLIST
"<channel> :End of channel ban list"
- Когда создается список активных 'банов' для данного канал,
сервер требует отправки списка обратно, используя
сообщения RPL_BANLIST и RPL_ENDOFBANLIST. Разделитель
RPL_BANLIST отсылается для каждого активного забаненного.
После того, как все забаненные попали в список (или если
отсутствуют), должен отослаться RPL_ENDOFBANLIST.
371 RPL_INFO
":<string>"
374 RPL_ENDOFINFO
":End of /INFO list"
- Сервер, отвечая на INFO-сообщение требует отправления
всех этих 'info' в серии RPL_INFO-сообщений с
RPL_ENDOFINFO ответом, указывающем окончание ответов.
375 RPL_MOTDSTART
":- <server> Message of the day - "
372 RPL_MOTD
":- <text>"
376 RPL_ENDOFMOTD
":End of /MOTD command"
- При ответе на MOTD-сообщение и MOTD-файл найден, файл
отбражается строка к строке с каждой строкой, не длше80
символов, используя RPL_MOTD-формат ответов. Их следует
разместить между RPL_MOTDSTART (перед RPL_MOTD) и
RPL_ENDOFMOTD (после).
381 RPL_YOUREOPER
":You are now an IRC operator"
- RPL_YOUREOPER отправляется клиенту, который благополучно
выполнил OPER-сообщение и получил статус IRC-оператора.
382 RPL_REHASHING
"<config file> :Rehashing"
- Если использовалась функция REHASH и оператор послал
REHASH-сообщение, RPL_REHASHING отправилась обратно
оператору.
391 RPL_TIME "<server> :<string showing server's local time>"
- При ответе на TIME-сообщение, сервер должен отправить
ответ, используя RPL_TIME-формат. Строка, показывающая
время, должна содержать только правильный день и время.
Это не является допольнительным требованием к строке
времени.
392 RPL_USERSSTART
":UserID Terminal Host"
393 RPL_USERS
":%-8s %-9s %-8s"
394 RPL_ENDOFUSERS
":End of users"
395 RPL_NOUSERS
":Nobody logged in"
- Если USERS-сообщение обработано сервером, использовались
ответы RPL_USERSTART, RPL_USERS, RPL_ENDOFUSERS и
RPL_NOUSERS. RPL_USERSSTART должен отправится первым,
следуя за одним из RPL_USERS или одним RPL_NOUSER.
Следом идет RPL_ENDOFUSERS.
200 RPL_TRACELINK
"Link <version & debug level>
<destination> \
<next server>"
201 RPL_TRACECONNECTING
"Try. <class> <server>"
202 RPL_TRACEHANDSHAKE
"H.S. <class> <server>"
203 RPL_TRACEUNKNOWN
"???? <class> [<client IP address in dot
form>]"
204 RPL_TRACEOPERATOR
"Oper <class> <nick>"
205 RPL_TRACEUSER
"User <class> <nick>"
206 RPL_TRACESERVER
"Serv <class> <int>S <int>C
<server> \
<nick!user|*!*>@<host|server>"
208 RPL_TRACENEWTYPE
"<newtype> 0 <client name>"
261 RPL_TRACELOG
"File <logfile> <debug level>"
- Все RPL_TRACE* возвращаются сервером в ответ на
TRACE-сообщение. Как много будет возвратов на
TRACE-сообщение зависит от того, посланы они
IRC-оператором или нет. Ответы RPL_TRACEUNKNOW,
RPL_TRACECONNECTING И RPL_TRACEHANDSHAKE используются
для соединений, которые не имеют полного разрешения и
неизвестны, попытки соединения, оканчивающиеся на
'server handshake'. RPL_TRACELINK посылается любым
сервером, который пропустил TRACE-сообщение и отправил
ее к следующему серверу. Список команд RPL_TRACELINK
отправится в ответ на TRACE-команду через всю IRC-сеть,
создавая карту серверных соединений. RPL_TRACENEWTYPE
будет использован для другого соединения, которое не
стыкуется с остальными категориями, но было отображено.
211 RPL_STATSLINKINFO
"<linkname> <sendq> <sent messages> \
<sent bytes> <received messages> \
<received bytes> <time open>"
212 RPL_STATSCOMMANDS
"<command> <count>"
213 RPL_STATSCLINE
"C <host> * <name> <port> <class>"
214 RPL_STATSNLINE
"N <host> * <name> <port> <class>"
215 RPL_STATSILINE
"I <host> * <host> <port> <class>"
216 RPL_STATSKLINE
"K <host> * <username> <port>
<class>"
218 RPL_STATSYLINE
"Y <class> <ping frequency> <connect \
frequency> <max sendq>"
219 RPL_ENDOFSTATS
"<stats letter> :End of /STATS report"
241 RPL_STATSLLINE
"L <hostmask> * <servername> <maxdepth>"
242 RPL_STATSUPTIME
":Server Up %d days %d:%02d:%02d"
243 RPL_STATSOLINE
"O <hostmask> * <name>"
244 RPL_STATSHLINE
"H <hostmask> * <servername>"
221 RPL_UMODEIS
"<user mode string>"
- Для ответа запроса о режиме владельца клиенту,
RPL_UMODEIS отправляектся обратно.
251 RPL_LUSERCLIENT
":There are <integer> users and <integer> \
invisible on <integer> servers"
252 RPL_LUSEROP
"<integer> :operator(s) online"
253 RPL_LUSERUNKNOWN
"<integer> :unknown connection(s)"
254 RPL_LUSERCHANNELS
"<integer> :channels formed"
255 RPL_LUSERME
":I have <integer> clients and <integer> \
servers"
- При обработке LUSERS-сообщения, сервер
отправляет настроки ответов от RPL_LUSERCLIENT,
RPL_LUSEROP, RPL_USERUNKNOWN, RPL_LUSERCHANNELS
и RPL_LUSERME. При ответе, сервер должен
отослать обратно RPL_LUSERCLIENT и RPL_LUSERME.
Другие ответы отсылаются только если найдено их
не нулевое значение.
256 RPL_ADMINME
"<server> :Administrative info"
257 RPL_ADMINLOC1
":<admin info>"
258 RPL_ADMINLOC2
":<admin info>"
259 RPL_ADMINEMAIL
":<admin info>"
- При ответе на ADMIN-сообщение, сервер ожидает
использование ответов RPL_ADMINME через
RPL_ADMINEMAIL и предоставляет текст сообщения с
каждым. Для RPL_ADMINLOC1 описывапется город,
шатат и страна сервера, следуемый подробностями
университета и факультета (RPL_ADMINLOC2) и
оканчивается административной связью для сервера
(здесь потребуется e-mail адрес) в RPL_ADMINEMAIL.
6.3 Зарезервированные числа
Эти числа не описани, хотя они попадают в одну из следующих категорий:
1. не долго в использовании;
2. зарезервированы для последющего использования;
3. используются в данный момент, но часть "прибамбасов" не
генерируются текущим IRC-сервером.
209 RPL_TRACECLASS 217 RPL_STATSQLINE
231 RPL_SERVICEINFO 232 RPL_ENDOFSERVICES
233 RPL_SERVICE
234 RPL_SERVLIST
235 RPL_SERVLISTEND
316 RPL_WHOISCHANOP 361 RPL_KILLDONE
362 RPL_CLOSING
363 RPL_CLOSEEND
373 RPL_INFOSTART 384 RPL_MYPORTIS
466 ERR_YOUWILLBEBANNED 476 ERR_BADCHANMASK
492 ERR_NOSERVICEHOST
7. ИДЕНТИФИКАЦИЯ КЛИЕНТА И СЕРВЕРА
Клиенты и серверы используют одни и те же уровни идентификации. Для
обоих это IP-номер имени хоста (и обратная проверка этого) это
выполняется для всех соединений к серверу. Так же соединения
проверяются парольно (если возможно установить пароль для этого
соединения и он установлен). Их проверяют на всех возможных
соединениях, хотя проверка пароля испольщуется только с серверами.
В дополнение проверка отклика имени пользователя для созданных
соединений. Поиск пользовательского имени на другом конце соединения,
обычно включаются соединения, идентификация сервера подобна IDENT, или
описана в RFC 1413.
Есть мнение, что без паролей не так то легко достоверно определить, кто
находится на другом конце сетевого соединения, использовать пароли очень
рекомендуется в интер-сервер соединениях в дополнеение к другим
возможностям идентификации сервера.
8. ПОДРОБНОЕ РАССМОТРЕНИЕ ТЕКУЩИХ СРЕДСТВ СВЯЗИ
Текущей версией IRC-сервера, для рассмотрения этого протокола, является
версия 2.8. Более ранние версии могут быть совместимы некоторыми или
всеми командами, описанные в этом документе с NOTICE-сообщениями
расположены многие числовые ответы. К несчастью, требуется обратная
совместимость, предоставленные части этого документа различаются с
выложенным. Отличия в:
* определение, что любые LF или CR везде в сообщении помечают
окончание этого сообщения (в отличие от требуемых CR-LF);
Остаток этого раздела наиболее важен тем, кто желает держать сервер, но
некоторые части так же напрямую связаны с клиентом.
8.1 Сетевой протокол TCP - почему его здесь лучше использовать
IRC обеспечивается на высоте TCP, и TCP предоставляет надежный сетевой
протокол, который наиболее хорошо вписывается в масштабы общения.
Использование многослойность IP является альтернативой, но он не пока
не получил широкого растространения и поддержки.
8.1.1 Поддержка Unix-сокетов
Unix-domain-сокетам доступны операции прослушивания/соединения, в
текущем исполнении может быть настроена на прослушивание и
подтверждение как клиентских, так и серверных соединений на
Unix-domain-сокете. Их узнают как сокеты, где имя хоста начинается с '/'.
Когда предоставление любой информации о соединениях на
Unix-domain-сокете, сервер требует вытеснения текущего имени хоста в
пути, если текущее имя сокета будет этого просить.
8.2 Проверка команд
В предоставление полезной 'non-buffered' сети IO для клиентов и
серверов, каждое соединение из которых является частным 'input buffer',
в котором результируются большинство полученного, читается и
проверяется. Размер буфера 512 байт, используется как одно полное
сообщение, хотя обычно оно бывает с разными командам. Приватный буфер
проверяется после каждой операции чтения на правильность сообщений.
Когда распределение с многослойными сообщениями от одного клиента в
буфере, следует быть в качестве одного случившегося, клиент может быть
'удален'.
8.3 Передача сообщения
Это простой поиск сети, насыщенной линками или хостами, к которым вы
отправляете данные. Хотя Unix обычно это делает через TCP-окно и
внутренними буферами, часто сервер имеет большое количество данных,
готовых к отправке (особенно при формировании нового сервер-сервер
линка) и небольших буферов в ядре не хватает для исходящей очереди.
Для облегчения этой проблемы, "send queue" использует как FIFO-очередь
для пересылки данных. Обычно, "send queue" может возрастать до 200 кб
в большой IRC-сети с медленным сетевым соединением при соединении
нового сервера.
Когда они начинают соединяться, сервер первым читает и проверяет все
входящие данные, откладывая все исходящие данные. Когда все доступные
вводы обработаны, посылаются отложенные данные. Это понижение числа
write() системных звонков и помогает TCP создавать большие пакеты.
8.4 Соединение 'Liveness'
Для выявления прекращения соединения или отклика, сервер должен
пинговать каждое из соединений.
Если соединение не отвечает некоторое время, это соединение
закрывается, используя предназначенные для этого процедуры. Так же
соединение может оборваться, если отправлено сверх обозначенного
максимума, ибо это наилучщий выход при медленном соединении.
8.5 Установка соединения сервер-клиент
При соединении с IRC-сервером, клиенту посылается MOTD (если
присутствует), а так же текущее число серверов/клиентов (подобно
команде LUSER). Так же сервер требует сообщения к клиенту, которое
содержит имя и версию, как и любые другие сообщения-вступления.
После разделения с этим, сервер должен отправить наружу новый никнейм
пользователя и другой информации, как снабжение себя (команда USER) и
как открываюший сервер (из DNS/серверы идентификации). Сервер должен
послать эту информацию с NICK первым следующим USER.
8.6 Установка соединения сервер-сервер
Процесс установки соединения сервер-к-серверу чреват опасностью с тех
пор, как много возможных областей, где возникают проблемы - наименьшие
из которых - конфликтные ситуации.
После соединения сервера, следуя PASS/SERVER, которыми
При соединении, сервера обмениваются парами PASS/SERVER, с помощью
которых устанавливаются парольные линки. С помощью этих же команд и их
ответов, сервера обмениваются информацией о соединении, которая описана
ниже.
При инициализировании серверных запросов пары PASS/SERVER, так же
проверярся, что сервер должным образом отвечает на идентификацию перед
подтверждением соединения (проверяется для того, чтобы убедиться в том,
что это действительно сервер).
8.6.1 Обмен информацией о состоянии соединения
Информацию необходимо будет разделить между серверами. Преимущества
следущие:
* все знают другие сервера;
* все знают пользовательскую информацию;
* все знают информацию каналов.
Информация которой располагают сервера, пересылается SERVER-сообщениями,
пользовательская информация с сообщениями NICK/USER/MODE/JOIN и с
каналов (MODE-сообщения).
ЗАМЕЧАНИЕ: топики канала *НЕ* обмениваются здесь. потому что команда
TOPIC перезапишет всю остальную информацию о топиках, это хорошо при
двухстороннем соединении и обмене топиками.
Прохождением информации о серверах первой, любые конфликты с серверами,
которые уже существуют, занимая место перед никнеймом, могут
происходить только всвязи со специфичностью никнейма, находящегося на
втором сервере. IRC-сеть только будучи к существующему, как
нециклический график; это может быть возможно, что сеть уже
переподсоединилась в другом месте, где происходит конфликт, показывая
сети необходимость в разрыве.
8.7 Разрыв соединения сервер-клиент
Когда клиет закрывает соединение, создается QUIT-сообщение от имени
клиента сервером, к которому присоединен клиент. Не используется и не
создается никакое другое сообщение.
8.8 Разрыв соединения сервер-сервер
При закрытии соединения сервер-сервер, и тот и другой удаленно создают
SQUIT или 'натуральные' причины закрытия соединения с IRC-сетью,
которые должны быть известны всем серверам. Для этого сервер отсылает
список SQUIT'ов (по одному на каждый сервер, имеющий соединение с ним)
и список QUIT'ов (снова, по одному для каждого клиента, соединенных
с ним).
8.9 Слежение за изменениями никнейма
Все IRC-сервера требуют хранение истории последних изменений никнейма.
Это требование предоставляет серверу шанс предоставить нетронутую
информацию по изменениями никнейма при возникновении конфликтов с
командами управления им. Команды, которые должны фиксировать изменения
никнейма.
* KILL (прибитие никнейма)
* MODE (+/- o,v)
* KICK (кик никнейма)
Остальные команды не проверяют изменения никнейма.
В упомянутых случаях, сервер требует, во-первых, проверку на наличие
никнейма, тогда проверяется его история, смотря кому этот никнейме
принадлежит в данный момент. Это уменьшает шансы возникновения
конфликтов, но они могут встретиться на сервере, упомянутые по ошибке
клиентом. При выполнении изменения дается некий отрезок времени,
которые дает возможность игнорировать более старые.
Для умеренной истории, серверу следует хранить предыдущие никнеймы для
каждого известного ему клиента, если они все решатся их изменить. Этот
обьем ограничен другими факторами (такие как обьем памяти и тому
подобное).
8.10 Flood-контроль клиентов
В больших сетях соединенных между собой IRC-серверов, действительно
легко для любого клиента, присоединенного к сети, обеспечивать
непрерывный потоксообщений, как результат не только сетевого флуда,
но так же и ухудшение работы сервисов. Лучше чем требовать от каждой
`жертву' защиты самих себя, флуд-защита была встроена в сервер и
добавлена к сервисам, доступных всем клиентам. Текущий алгоритм таков:
* проверка клиентского `таймера сообщений', если он отстает от
текущего времени - подкорректировать;
* чтение любых данных, поступающих с клиента;
* пока таймер опережает текущее время меньше, чем на десять
секунд, - проверять любые сообщения с клиента и штрафовать
клиента по две секунды за каждое сообщение;
который, в сущности, разрешает клиенту посылать одно сообщение
каждые две секунды без каких-либо последствий.
8.11 Non-blocking lookups
В окружении реального времени, необходимо чтобы сервер мог делать как
можно меньшие остановки для того, чтобы все клиенты обслуживались в
равной мере. Очевидно, этот асинхронный IO работает во всех сетевых
операциях чтения\записи. Для нормальных серверных соединений, это было
не трудно, но здесь другая поддержка операций, что может статть
причиной блокирования сервера (подобно чтениям диска). Это возможно,
подобно активации, следующей быть выполненной с коротким перерывом.
8.11.1 Hostname (DNS) lookups
Использование стандартных resolver-библиотек от Berkeley и другие,
имеющие предназначение больших задержек в некоторых случаях, где ответы
имеют перерывы. Во избежение этого, разделяют уставноленные
DNS-шаблоны, которые настраивают для асинхронных операций ввода\вывода
(IO) и тогда вызывается внутренняя IO-петля главного сервера.
8.11.2 Username (Ident) lookups
Хотя эти многочисленные ident-библиотеки существуют для использования и
включения в другие программы, они являются причинами проблем, с тех пор
как они работают в синхронном режиме и выводят результат в обычных
задержках. Вновь разрешение записано установкой шаблонов, которые будет
обьединяться с неподвижностью сервера и работать, используя асинхронный
ввод\вывод.
8.12 Конфигурационный файл
Предоставляя гибкость настройки и запуска сервера, рекомендуется
исползовать конфигурационный файл, который содержит инструкции к
серверу на следующие темы:
* с каких хостов допускать соединения клиентов;
* с каких хостов допускать серверные соединения;
* с какими хостами соединяться (как активно, так и пассивно);
* иформация о нахождении сервера (университет, город/район,
компания и тому подобное);
* кто отвечает за сервер и е-мейл адрес, по которому можно
связаться с администратором;
* имена хостов и пароли для клиентов, которые хотят получить
доступ к командам IRC-операторов.
В указании имен хостов, следует указывать как имена доменов, так и
использовать 'точечную' запись (127.0.0.1). Это дает возможность
указания пароля, используемого/подтверждаемого все входящие и исходящие
соединения (хотя, на другие серверы используются только исходящие
соедения).
Выше есть список минимальных требований для любого сервера, который
желает создать соединение с каким-либо другим сервером. Остальные
пункты, которые могут быть использованы:
* указание, каким серверам можно присоединяться;
* глубина серверного дерева, разрешенного на доступ;
* часы, в которые могут присоединяться клиенты.
8.12.1 Допуск клиентов к соединению
Серверу следует использовать некую сортировку 'списка контроля допуска'
(или в конфигурационном файле, или еще где), который читается при
загрузке и используется для приятия решения о том, могут или нет хосты
клиентов использовать его для соединения.
'Запрет', как и 'разрешение' следует предоставлять для более гибкого
контроля доступа хоста.
8.12.2 Операторы
Предоставление привилегий оператору для уничтожения пользователя может
иметь ужасные последствия для благополучия IRC-сети. В следствии чего
возникают трения. В текущей настройке требуется два 'пароля', один из
которых отгадывается весьмо просто. Хранение IRC-операторских паролей в
конфигурационных файлах предпочительно в хорошо закодированном виде
(например, использование crypt(3) из Unix), предотвращая легкое
похищение.
8.12.3 Допуск серверов к соединению
Взаимное соединение серверов не имеет тривиального значения: плохое
соединение может быть вызвано большим столкновением на usefulness of
IRC. Таким образом, каждому серверу следует имет список серверовв, к
которым он может присоединиться и тех, кто может присоединиться к нему.
Под безцеремонностью следует понимать сервер, доступный к соединению с
произвольным хостом, как с сервером. В дополнение ко всему этому,
серверы могут присоединяться или не присоединяться, и вследствии этого
предпочительней хранить пароль и другие характеристики на линка в
конфигурационном файле.
8.12.4 Административная часть
Для предоставления верных и правильных отклиеов на ADMIN-команды (см.
раздел 4.3.7), сервер следует на обеспечить нужными подробностями в
конфигурации.
8.13 Формирование сообществ
Текущий сервер предоставляет любому зарегистрированному локальному
пользователю зайти на не более 10 различных каналов. Это не ограничение
на не-локальных пользователей, а скорей предпочтение, для формирования
неких сообществ, которые находятся на определенных каналах.
9. ТЕКУЩИЕ ПРОБЛЕМЫ
Число известных проблем с этим протоколом, все из которых надеются быть
решенными в ближайщее время, в ближайшем будущем будет переписано. В
данный момент, идет работа по разрешению этих проблем.
9.1 Расширение
В расширенном распознании этот протокол бывает не достаточно хорош.
Основная проблема происходит от требования, чтобы все сервера знали обо
всех остальных серверах, и пользователи; и что информация, относительно
их, будет обновляться по мере ее изменения. Желательно, так же, хранить
число серверов доступно для того, чтобы расстояние между двумя точками
сохранялась минимальной и дерево ветвилось как можно сильней.
9.2 Имена
В данный момент, протокол IRC имеет три типа имени: никнейм, имя
канала и имя сервера. Каждый из них имеет свой домен и не пересекается
друг с другом. Так же, для пользователей возможен выбор любого из трех
имен, не вызывая возражений. Для расширения распознавания требуется
переработка, с намерением для уникальности имен для каналов и
никнеймов, чтобы предотвратить нежелателные столкновения, так же как и
растворение доступа к циклическому дереву.
9.2.1 Никнеймы
Идея никнеймов в IRC очень удобна для пользователей в использовании при
общении с любым на другом конце канала. Но только ограничение размера
никнейма увеличивает шансы попытки испаользования одного никнейма
разными людьми. Если такое происходит, то каждый из этих людей
становится под угрозой KILL (4.6.1).
9.2.2 Каналы
Требования к текущему каналу всего лишь, чтоб все сервера знали о всех
каналах, их место расположения и настройки. Конфликты каналов
обьясняются как тем же случаем (так и людей, кто создал новый канал,
рассматривают как членов канала), подобно которому возникают конфликты
по поводу использования никнеймов.
9.2.3 Серверы
Хотя число серверов, обычно, намного меньше числа пользователей или
каналов, их требования будут известны всем.
9.3 Алгоритмы
В некотрых местах серверного кода, не возможно отклониться от N^2
алгоритмов, подобных проверке списка каналов установки клиентов.
В текущих версиях сервера отсутствуют проверки базы данных на
содержимое, каждый сервер отвечает за корректность информации соседнего
сервера. Это открытые двери к большим проблемам, если присоединенный
сервер содержит ошибки или наоборот пытается противоречить каким-либо
сетевым правилам и установкам.
В данном случае, потому что недостаток уникальных внутренних и
глобальных имен является многогранным камнем преткновения. Конфликты
возникают, главным образом, из-за проблемы захвата времени для ответных
сообщений и еффекта IRC-сети. Как раз изменением уникальных имен и
решаются проблемы с командами настроек канала.
10. ПОДДЕРЖКА И ДОСТУП
Листы подписки:
Будущее протокола: ircd-three-request@eff.org
Общие обсуждения: operlist-request@eff.org
Программное обеспечение:
cs.bu.edu:/irc
nic.funet.fi:/pub/irc
coombs.anu.edu.au:/pub/irc
Newsgroup: alt.irc
11. РАССМОТРЕНИЕ БЕЗОПАСНОСТИ
Безопасность обсуждалась в разделах 4.1, 4.1.1, 4.1.3, 5.5, и 7.
12. АДРЕСА АВТОРОВ
Jarkko Oikarinen
Tuirantie 17 as 9
90500 OULU
FINLAND
Email: jto@tolsun.oulu.fi
Darren Reed
4 Pateman Street
Watsonia, Victoria 3087
Australia
Email: avalon@coombs.anu.edu.au
|
