此備忘錄的狀態(tài)
該備忘錄為互聯(lián)網(wǎng)團(tuán)體提供信息。它并不制定任何互聯(lián)網(wǎng)標(biāo)準(zhǔn)，可以被無限制的發(fā)布。
CopyrightNotice
Copyright(C)TheInternetSociety(2000).AllRightsReserved.
摘要
IRC(Internet延遲交談)協(xié)議最引人注目的一個特征就是答應(yīng)用戶按論壇分組，稱作通道，
提供了一種多個用戶一起交流的方法。
這篇文檔具體講述了通道、它們的特征和屬性怎樣經(jīng)由IRC服務(wù)器治理。
1．介紹
這篇文檔具體地定義了通道是如何由IRC服務(wù)器定義的，它對從事IRC服務(wù)器實現(xiàn)的人
非凡有用。
盡管這里定義的概念是IRC的一個重要部分，但它們對于客戶端的實現(xiàn)卻不是必需的。
盡管客戶端的趨勢是越來越復(fù)雜和“聰明”，能夠利用通道的內(nèi)部工作為用戶提供一個更
友好的界面，但是簡單的客戶端不需要閱讀這篇文檔就能夠?qū)崿F(xiàn)。
這里定義的許多概念都是由頭腦里的IRC體系結(jié)構(gòu)[IRC-ARCH]所限定的，并且大多數(shù)
只有在這種環(huán)境下才有意義。但是其他的許多概念能夠運用到其他的體系結(jié)構(gòu)，以便為會
議系統(tǒng)提供論壇場所。
最后，要聲明的是IRC用戶可能發(fā)現(xiàn)以下幾部分有用，非凡是第二部分(通道特征)和第四
部分(通道狀態(tài))。
2．通道特征
通道就是由一個或更多用戶組成的命名組，組里所有成員都接收寄到這個通道的消息，通
道由它的名字，屬性，目前的成員來標(biāo)志。
2.1名字空間
通道的名字(由一個‘&’，‘#’，‘+’或者‘！’開頭)可以長達(dá)五十個字符。通道的
名字對大小寫敏感。
除了第一個字符必須是‘&’，‘#’，‘+’或者‘！’（今后稱作“通道前綴”）的要
求外。對通道名字的唯一限制是它不能包含任何空格（‘’）、控制符G(^G或者ASCII7)、
逗號（‘，’被協(xié)議用作列表項的分隔符）。還有，冒號（‘：’）用作通道掩碼的分隔符。
精確的通道名字語法在“IRCServerPRotocol“[IRC-Server]中定義。
不同前綴的使用有效地為通道名字創(chuàng)造了四個名字空間。這很重要，因為此協(xié)議的局限性
和名字空間有關(guān)（一般意義上）。參閱6.1部分（標(biāo)志）以獲得關(guān)于局限性的更多細(xì)節(jié)。
2.2通道范圍
一個通道實體被IRC網(wǎng)絡(luò)上一個或更多個服務(wù)器所知曉。只有與用戶直連的服務(wù)器
知道的通道，用戶才能加入。知道一個特定通道存在的一系列服務(wù)器必須是IRC網(wǎng)絡(luò)上
一個鄰近的部分，這樣發(fā)送給該通道的消息才能被發(fā)送給所有通道成員。
以‘&’為前綴的通道對創(chuàng)建它們的的服務(wù)器來說是本地的。
其它通道被連到網(wǎng)絡(luò)上的一個或更多個服務(wù)器知曉，依靠于通道掩碼：
假如沒有通道掩碼，該通道就被所有服務(wù)器知曉。
假如有一個通道掩碼，此通道只被那些有本地用戶連到通道上的服務(wù)器所知曉，假如
掩碼和本地的以及相鄰的服務(wù)器名字相配，那么也為他的鄰近服務(wù)器知曉。因為其他服務(wù)
器完全沒有這樣一個通道的存在的任何信息，假如這個通道要為所有服務(wù)器知曉的話，這
些具有和掩碼相配的名字的服務(wù)器組成的區(qū)域必須和該通道相鄰。通道掩碼最好與服務(wù)器
主機掩碼[IRC-SERVER]配合使用。
2.3通道屬性
每個通道都有它自己的有通道狀態(tài)定義的屬性。通道模式能夠被通道成員使用。模
式影響服務(wù)器治理通道的方式。
以‘+’作為前綴的通道不支持通道模式。這意味著所有的模式都是未設(shè)定的，只設(shè)
定了‘t’通道標(biāo)志。
2.4特權(quán)通道用戶
為了使通道成員對通道保持一定的控制和一些秩序，一些通道成員被賦予特權(quán)。只
有這些成員才答應(yīng)在通道上執(zhí)行一下操作：
INVITE—邀請一個客戶到一個invite-only通道（模式+i）
KICK—將一個客戶從通道中逐出
MODE—改變通道的模式，也可以改變成員的特權(quán)
PRIVMSG—向通道發(fā)消息（模式+n,+m+v）
TOPIC—在模式為+t的通道中改變通道主題
2.4.1通道治理員
一個給定通道上的通道治理員（也被稱為“chop”或“chanop”）被認(rèn)為擁有此通道。
通道所有權(quán)由通道治理員共享。
無論什么時候和通道相關(guān)，通道治理員都由與其名字相鄰的‘@’符號來標(biāo)志（比
如說，回答NAMES,WHO,和WHOIS命令）。
由于以字符‘+’為前綴的通道不支持通道模式，因此沒有成員具有通道治理員的地位。
2.4.2通道創(chuàng)建者
創(chuàng)建一個通道的用戶稱為“通道創(chuàng)建者”，以‘！’前綴作為其標(biāo)志。一旦創(chuàng)建了通
道，此用戶也就被賦予了通道治理員的地位。
為了識別此地位，通道創(chuàng)建者被賦予鎖定通道狀態(tài)的能力，這種能力是通道治理員所沒有
的。
通過發(fā)送恰當(dāng)?shù)腗ODE命令能夠區(qū)分‘通道創(chuàng)建者’和通道治理員。參閱“IRCClient
Protocol”[IRC—CLIENT]以獲取這方面的更多信息。
3．通道生存期
和通道生存期相關(guān)的是，存在兩組典型的通道：標(biāo)準(zhǔn)通道，它的前綴不是‘&’‘#’
就是‘+’，以及安全通道，它的前綴是‘！’。
3.1標(biāo)準(zhǔn)通道
這些通道當(dāng)?shù)匾粋€用戶加入時暗中創(chuàng)建，最后一個用戶離開時停止生存。但通道生存
時，任何客戶都能夠通過通道的名字引用此通道。
創(chuàng)建通道的用戶自動變成通道治理員，當(dāng)然前綴是‘+’的通道除外，參見第四部分(通
道模式)。參閱2.4.1部分以獲取此主題的更多信息。
為了避免創(chuàng)建兩個一樣的通道（非凡是當(dāng)IRC網(wǎng)絡(luò)由于兩個服務(wù)器的斷連而脫節(jié)），通
道名字在通道治理員由于網(wǎng)絡(luò)斷連離開時應(yīng)該不答應(yīng)再被用戶使用。假如這種情況發(fā)生了，
通道名字就是暫時不能使用了。通道持續(xù)不可用時間應(yīng)該在每個IRC網(wǎng)絡(luò)的基礎(chǔ)上做出調(diào)
整。需要重點聲明的是這樣可以防止用同一個名字再創(chuàng)建一個通道，但是不能防止遠(yuǎn)端用
戶重新創(chuàng)建該通道。后者在IRC網(wǎng)絡(luò)重新連接時非凡輕易發(fā)生。很明顯，這種機制知識和
與名字以字符‘#’開頭的通道，但也可能被名字以字符‘+’開頭的通道使用。這種機制
被普遍稱作‘通道延遲’。
3.2安全通道
和其他通道不同，“安全通道”不是暗中創(chuàng)建的。希望創(chuàng)建這類通道的用戶必須向服
務(wù)器發(fā)送一個非凡的JOIN命令以申請創(chuàng)建，服務(wù)器中的通道標(biāo)識符（接著就是未知的了）
被字符‘！’替代。此類通道的創(chuàng)建受到嚴(yán)格控制。用戶只選擇部分通道名字（稱為通道
‘短名’），服務(wù)器自動將用戶提供的名字前面加上五個通道標(biāo)識符。這兩種元素結(jié)合而
成的通道名字是唯一的，使通道不會因為網(wǎng)絡(luò)斷連而被濫用。
創(chuàng)建此類通道的用戶自動成為‘通道創(chuàng)建者’。參閱2.4.2部分(通道創(chuàng)建者)以獲得關(guān)
于此主題的更多信息。
假如新通道的短名和另一個業(yè)已存在的通道的短名相同，又假如另一個具有相同短名
的通道最近存在過而且它的成員由于網(wǎng)絡(luò)斷連離開，那么服務(wù)器就禁止這樣的通道的創(chuàng)建。
這類通道在最后的成員離開并且最近沒有其他成員由于網(wǎng)絡(luò)斷連離開后停止生存。
和5.2.2部分(通道延遲)描述的機制不同的是，在這種情況下通道的名字并不變成不可用的：
這些通道在最后的成員離開后可能繼續(xù)生存。只有創(chuàng)建通道的用戶才變成“通道創(chuàng)建者”，
假如一個存在的空通道的用戶并不自動變成“通道創(chuàng)建者”也不變成“通道治理員”。
為了保證通道名字的唯一性，由服務(wù)器創(chuàng)建的通道標(biāo)識符必須遵循一定的規(guī)則。更多的細(xì)
節(jié)，參閱5.2.1部分（通道標(biāo)識符）。
4．通道模式
通道能夠獲取的各種模式如下所示：
0—賦予“通道創(chuàng)建者”地位；
o—賦予/收回“通道治理員”特權(quán)；
v—賦予/收回發(fā)言特權(quán)；
a—轉(zhuǎn)換匿名通道標(biāo)志；
i—轉(zhuǎn)換invite-only通道標(biāo)志；
m—轉(zhuǎn)換是否調(diào)節(jié)通道
n—轉(zhuǎn)換是否答應(yīng)外部客戶發(fā)送消息到通道
q—轉(zhuǎn)換安靜通道標(biāo)志；
p—轉(zhuǎn)換私人通道標(biāo)志
s—轉(zhuǎn)換秘密通道標(biāo)志
r—轉(zhuǎn)換服務(wù)器reop通道標(biāo)志
t—轉(zhuǎn)換是否只能由通道治理員設(shè)置主題
k—設(shè)置/刪除通道鑰匙（密碼）；
l—設(shè)置/刪除通道用戶限制
b—設(shè)置/刪除禁令掩碼使用戶不能進(jìn)入
e—設(shè)置/刪除異常掩碼來覆蓋禁令掩碼；
I—設(shè)置/刪除邀請掩碼來覆蓋invite-only標(biāo)志；
除非在下面非凡聲明，所有這些狀態(tài)都能被“通道治理員”通過MODE命令使用，MODE
命令在“IRCClientProtocol”[IRC-CLIENT]中定義。
4.1成員身份
此域中的模式將通道成員的昵稱作為參數(shù)并影響賦予成員的特權(quán)。
4．1．1“通道創(chuàng)建者”身份
模式‘0’只和“安全通道”結(jié)合使用而且不能被用戶使用。服務(wù)器用它來
給予創(chuàng)建通道的用戶“通道創(chuàng)建者”的身份。
4．1．2通道治理員地位
模式‘o’用來轉(zhuǎn)換通道成員的治理員身份。
4．1．3發(fā)言特權(quán)
模式‘v’用來給予通道成員發(fā)言特權(quán)和從成員處收回發(fā)言特權(quán)。具有這種特
權(quán)的用戶能夠在調(diào)節(jié)過的通道上交談。（參閱4.2.3部分(ModeratedChannelFlag)。
4.2通道標(biāo)志
此域中的模式用來定義影響通道如何治理的屬性。
4.2.1匿名標(biāo)志
通道標(biāo)志‘a(chǎn)’定義了一個匿名通道。這意味著當(dāng)一條發(fā)送到通道的消息被
服務(wù)器發(fā)送給用戶時，并且它來自用戶，那么它就要被屏蔽掉。為了屏蔽掉消息，來源被改
成“anonymous!anonymous@anonymous.”（也就是說，一個別名是“anonymous”，用戶名是
“anonymous”的用戶，來自叫做“anonymous”的主機）。因為這樣，服務(wù)器必須禁止別名
為“anonymous”的用戶。服務(wù)器不能為用戶離開這類通道而發(fā)送QUIT笑給其他通道的成員，
而是產(chǎn)生一條PART消息。
在以字符‘&’為前綴的通道上，這個標(biāo)志也許由通道治理員轉(zhuǎn)換，但是在以字符‘！’為前
綴的通道上，這個標(biāo)志只能由‘通道創(chuàng)建者’設(shè)定（但是不能夠不設(shè)定）。此標(biāo)志在其它類型
的通道上不能夠使用。
在匿名標(biāo)志已經(jīng)設(shè)定的通道上，對whois,who,和names命令的答復(fù)不能夠表明通道上其他用
戶的存在。
4.2.2InviteOnly標(biāo)志
當(dāng)通道標(biāo)志‘i’設(shè)定后，新成員只有當(dāng)他們的掩碼和邀請列表相符（參見4.3.2部
分）或者他們已經(jīng)被通道治理員邀請。這個標(biāo)志也對通道治理員限制了INVITE命令的使用
（參見“IRCClientProtocol”[IRC-CLIENT]。
4.2.3通道已調(diào)節(jié)標(biāo)志
通道標(biāo)志‘m’用來控制誰可以再通道上說話。當(dāng)它設(shè)定時，只有通道治理員，和
被賦予了發(fā)言特權(quán)的成員才可以向其他通道發(fā)送消息。
這個標(biāo)志只影響用戶。
4.2.4不答應(yīng)通道外客戶向通道發(fā)送消息
當(dāng)通道標(biāo)志‘n’設(shè)定時，只有通道成員才可以向通道發(fā)送消息。
這個標(biāo)志只影響用戶。
4.2.5安靜通道
通道標(biāo)志‘q’僅供服務(wù)器使用。設(shè)定時，它限制發(fā)送給用戶的關(guān)于通道操作的數(shù)據(jù)
類型：其他用戶加入，離開和重要的變化都不發(fā)送。從用戶的觀點來看，通道只包含一個用
戶。
這經(jīng)常用于創(chuàng)建非凡的本地通道，這種通道里服務(wù)器發(fā)送和它的操作相關(guān)的通知。它作為一
種更加有效率特富有彈性的方法可以用來取代RFC1459[IRC]里定義的用戶狀態(tài)‘s’。
4.2.6私人和秘密的通道
通道標(biāo)志‘p’用來標(biāo)志一個通道是私人的，通道標(biāo)志‘s’用來標(biāo)志一個通道是秘
密的。兩種性質(zhì)很相似，他們都向其他用戶隱藏了通道的存在。
這意味著如夠不加入就沒有辦法從服務(wù)器得到通道的名字。換句話說，對whois命令這樣的
詢問的答復(fù)必須將這些通道省略掉。
當(dāng)一個通道是‘秘密的’的時候，除了上面的限制外，對topic,list,names命令這樣的詢問，
服務(wù)器必須表現(xiàn)得象通道不存在一樣。上述規(guī)則只有一個例外：服務(wù)器會正確地答復(fù)mode
命令。最后，當(dāng)<mask>參數(shù)指定時，秘密通道沒有責(zé)任回復(fù)lusers命令（參閱“InternetRelay
Chat：ClientProtocol”[IRC—CLIENT]）。
通道標(biāo)志‘p’和‘s’不能同時設(shè)定。假如服務(wù)器的MODE消息設(shè)定‘p’標(biāo)志而且通道已
經(jīng)設(shè)定了‘s’，那么這種變化就靜靜地被忽略掉。這只有在斷連恢復(fù)期間才能發(fā)生。（在“IRC
ServerProtocol”文檔中提到）。
4.2.7服務(wù)器Reop標(biāo)志
通道標(biāo)志‘r’只有在名字以字符‘s’開頭的通道中才可用，并且也許只能由‘通道
創(chuàng)建者’來轉(zhuǎn)換。
這個標(biāo)志用來防止一個通道長期處于無通道治理員的狀態(tài)。當(dāng)這個標(biāo)志設(shè)定時，任何失去它
的所有通道治理員超過‘reop延遲’時期的通道將觸發(fā)促發(fā)服務(wù)器里的一種機制，將通道內(nèi)
的一些或所有用戶重設(shè)為治理員。這種機制在5.2.4部分中有更具體的描述（通道reop機制）。
4.2.8主題
通道標(biāo)志‘t’用來限制通道治理員topic命令的使用。
4.2.9用戶限制
一個用戶限制可以用通道標(biāo)志‘l’在通道上設(shè)置。當(dāng)達(dá)到限制人數(shù)時，服務(wù)器必須
禁止本地用戶加入通道。
限制的值可以從服務(wù)器對mode詢問的答復(fù)中獲取。
4.3通道訪問控制
狀態(tài)的最后一個域是用來控制通道的訪問的，它們將一個掩碼作為參數(shù)。
為了減小為通道設(shè)置的控制訪問狀態(tài)的整體數(shù)據(jù)庫的尺寸，服務(wù)器可能對這類狀態(tài)的設(shè)定加
上一個最大值限制。假如想加上這種限制，它必須只能影響用戶請求。這種限制對每個IRC
網(wǎng)絡(luò)來說應(yīng)該是類似的。
4.3.1通道禁令和異常
當(dāng)用戶請求加入一個通道，它的本地服務(wù)器檢查用戶的地址是否和通道的任何禁令掩
碼相符，假如相符，用戶請求就被拒絕，除非該地址也和通道的一個異常掩碼相符。
服務(wù)器不答應(yīng)通道禁止的成員在通道上發(fā)言，除非次成員是通道治理員或者由發(fā)言特權(quán)。（參
見4.1.3部分（發(fā)言特權(quán)））。
通道禁止的用戶，假如它帶有通道治理員發(fā)出的邀請，那么就答應(yīng)加入通道。
4.3.2通道邀請
對那些invite-only標(biāo)志設(shè)置了的通道，任何用戶，只要它的地址和通道的邀請掩碼
相符，就答應(yīng)加入通道，即使沒有受到邀請。
5．目前的實現(xiàn)
目前這些作為IRC協(xié)議一部分的規(guī)則的唯一實現(xiàn)是IRC服務(wù)器，版本2.10。
這部分的其他內(nèi)容涉及對那些希望實現(xiàn)服務(wù)器的人來說非凡重要的事情，但是也有些部分
對客戶機程序作者很有用。
5.1追蹤最近使用過的通道
這種機制一般叫做“通道延遲”，通常用于前綴是字符‘#’的通道（參見3.1部分
（“標(biāo)準(zhǔn)通道”）。
當(dāng)網(wǎng)絡(luò)發(fā)生斷連，服務(wù)器必須追蹤哪些通道由于斷連失去了一個‘通道治理員’。這
些通道接著就處于一種非凡的狀態(tài)，并持續(xù)一段時間。在這種非凡狀態(tài)下，通道不能停
止生存。假如所有通道成員都離開了，通道就變成不可獲取的：只要它是空的，本地客
戶就不能加入。
一旦一個通道不可獲取，當(dāng)遠(yuǎn)端用戶加入通道（最可能因為網(wǎng)絡(luò)正在恢復(fù)）或延遲
期滿（這種情況下通道停止生存，可能重新創(chuàng)建），它都會變成可獲取的。通道的死亡推
遲時間的設(shè)置需要考慮很多因素，有IRC網(wǎng)絡(luò)的規(guī)模，和網(wǎng)絡(luò)通常斷連的持續(xù)時間。對
一個給定的IRC網(wǎng)絡(luò)來說，這個時間在所有服務(wù)器上應(yīng)該都是一樣的。
5.2安全通道
這篇文檔介紹“安全通道”的概念。這些通道前綴為字符‘!’，并且盡最大努力避
免此名字空間內(nèi)的沖突。沖突并不是不可能的，但是一般不會發(fā)生。
5.2.1通道標(biāo)識符
通道標(biāo)識符是時間的一個函數(shù)。當(dāng)前時間被轉(zhuǎn)換成五個字符的字符串，以
“ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890”為基數(shù)（每個字符都有一個十
進(jìn)制的值,‘A’對應(yīng)0到‘0’對應(yīng)35）。
因此通道標(biāo)識符的周期為36^5秒（大概700天）
5.2.2通道延遲
這些通道必須服從5.1部分描述的“通道延遲”機制。但是，這種機制被稍微改
進(jìn)以運行得更好。
服務(wù)器必須追蹤由于網(wǎng)絡(luò)斷連而失去成員的通道，不管失去的用戶是不是‘通道治理員’。
但是，這些通道從不變的不可獲取，即使當(dāng)它們?yōu)榭諘r也可以加入。
5.2.3濫用窗口
因為周期如此之長，對特定通道的攻擊要很長時間才發(fā)生一次。但是，假如有
運氣和耐心的話，用戶仍然可能引起通道沖突。為了避免此類事情的發(fā)生，服務(wù)器必須
‘向長遠(yuǎn)看’，維持一個通道名字的列表，這些名字的標(biāo)識符將來要用（比如在未來的幾
天里）。這樣的列表應(yīng)該保持小的規(guī)模，不應(yīng)成為服務(wù)器要維持的負(fù)擔(dān)，這些列表用來在
比通道延遲更長的時期內(nèi)避免相同通道的再創(chuàng)建。
最后一個服務(wù)器程序可能選擇擴展這種程序，禁止短名相同的通道的創(chuàng)建（接著忽略通
道標(biāo)識符）。
5.2.4保持名字空間內(nèi)的正常
5.2.2和5.2.3部分描述的機制的結(jié)合使用戶很難令通道發(fā)生沖突。但是，存在
另外一種形式的濫用，就是創(chuàng)建許多有相同短名但是不同標(biāo)識符的通道。為了防止其發(fā)
生，假如通道的短名和目前業(yè)已存在的通道相同，服務(wù)器就必須禁止這個通道的創(chuàng)建。
5.2.5服務(wù)器Reop機制
當(dāng)一個通道開放時間長于‘reop延遲’時間，并且通道設(shè)置了‘r’標(biāo)志（參見
4.2.7(服務(wù)器reop標(biāo)志)），IRC服務(wù)器有責(zé)任隨機地將通道治理員地位賦給一些成員。
下面描述目前的實現(xiàn)中為這種機制使用的邏輯。服務(wù)器可能使用不同的邏輯，但是強烈
建議所有在一個IRC網(wǎng)絡(luò)上的服務(wù)器使用相同的邏輯，以保證一致性和公正性。基于相
同的原因，對一個給定的IRC網(wǎng)絡(luò)，“reop延遲”的值在所有主機上都應(yīng)一致。同“通
道延遲”一樣，“reop延遲”值的設(shè)置也應(yīng)該考慮很多因素，包括IRC網(wǎng)絡(luò)的規(guī)模，網(wǎng)
絡(luò)斷連通常的持續(xù)時間。
a) reop機制在“reop延遲”期滿，一段隨機時間之后被觸發(fā)。這樣可以限制此機制在
兩臺分離的服務(wù)器上同時觸發(fā)的可能性。
b) 假如通道規(guī)模很小（五個用戶或者更少），并且這個通道的“通道延遲”已經(jīng)期滿，
假如至少有一個成員對服務(wù)器來說是本地的話，那么就將所有用戶重設(shè)治理員。
c) 假如通道規(guī)模很小（五個用戶或者更少），并且這個通道的“通道延遲”已經(jīng)期
滿，“reop延遲”也已期滿。接著就將所有用戶重設(shè)治理員。
d) 對于其他情況，至多將通道上的一個成員重設(shè)治理員，以服務(wù)器的內(nèi)建方法為基礎(chǔ)。
假如你不將一個成員重設(shè)治理員，內(nèi)建方法應(yīng)該就是另一個服務(wù)器極可能將某個用
戶設(shè)為治理員。這種方法在整個網(wǎng)絡(luò)上應(yīng)該都是一樣的。一個好的啟發(fā)式方法是隨
機重設(shè)治理員。
（目前的實現(xiàn)實際上是試著選一個服務(wù)器的本地成員，這個成員要是沒有閑置太久
的，最終推遲行動，因此使其它服務(wù)器有機會尋找一個沒有太閑置的成員。這太復(fù)
雜了，因為服務(wù)器只知道本地用戶的閑置時間）
6．目前的問題
IRC通道治理方式有一些問題已經(jīng)被熟悉到了。有一些能直接歸因于這篇文檔里定義的規(guī)
則，其它的是底層的“IRCServerProtocol”的結(jié)果。盡管來源于RFC1459[IRC]，這篇文檔
試著提出了一些新鮮方法解決一些已知的問題。
6.1標(biāo)志
這篇文檔定義了IRC協(xié)議使用的眾多標(biāo)志中的一個。盡管有許多不同的名字空間（給予通
道名字前綴），但是不答應(yīng)在內(nèi)部重用他們。目前，有可能不同服務(wù)器上的用戶采用相同的可
能引起沖突的標(biāo)志，（只有一個服務(wù)器知道的通道除外，這里能夠防止沖突）。
6.1.1通道延遲
5.1部分描述的，由前綴是字符‘#’的通道使用的通道延遲機制（追蹤最近使用過的
通道）是一個防止沖突發(fā)生的簡單嘗試。經(jīng)驗表明，在通常情況下，它非常有效；但是，很
明顯它有很多局限使它不能夠解決這里討論的問題。
6.1.2安全通道
3.2部分（安全通道）描述的“安全通道”是一個較好的防止沖突發(fā)生的方法，因為
它避免用戶對他們選擇的標(biāo)志擁有完全控制。這種標(biāo)志明顯的缺點是他們對用戶不友好。但
是，客戶端要改進(jìn)這一點是相當(dāng)繁瑣的。
6.2狀態(tài)傳播延遲
因為網(wǎng)絡(luò)引起的延遲，以及每個服務(wù)器都要求檢查狀態(tài)變化的正確性（比如，用戶存在
且有合適的特權(quán)），有時一條狀態(tài)信息只影響部分網(wǎng)絡(luò)，經(jīng)常使服務(wù)器上關(guān)于通道狀態(tài)的信息
出現(xiàn)差異。
盡管這個毛病看起來輕易改正（通過讓源服務(wù)器檢查狀態(tài)變化正確性的方法），但卻有各種理
由決定不這樣做。一種擔(dān)心是服務(wù)器彼此不能信任，這樣發(fā)生錯誤的服務(wù)器就輕易檢測出來。
這樣作業(yè)防止了來自各個方向狀態(tài)信息的不同步對通道造成的巨大影響。
6.3沖突和通道狀態(tài)
“InternetRelayChat:ServerProtocol”文檔[IRC-SERVER]描述了當(dāng)兩臺服務(wù)器連接時通
道數(shù)據(jù)是如何交換的。通道沖突（不管是合理的或是不合理的）被認(rèn)為是內(nèi)部的事情，意味
著參與的通道都使通道成員優(yōu)先連接。
類似的，每個服務(wù)器發(fā)送通道狀態(tài)給其它服務(wù)器。因此，每個服務(wù)器也接收這些通道狀
態(tài)。對一個給定的通道有三種模式：標(biāo)志，掩碼，和數(shù)據(jù)。前兩種輕易處理，因為他們要么
設(shè)置要么不設(shè)置。假如這樣的一種模式在服務(wù)器上設(shè)置了，由于相連，它必須在另一個服務(wù)
器上也進(jìn)行設(shè)置。
由于主題不作為交換的一部分進(jìn)行發(fā)送，他們不成問題。但是，通道模式‘l’和‘k’
參與交換，假如在連接之前它們在雙方服務(wù)器上都設(shè)置了，就沒有一種機制來決定這兩個值
那個優(yōu)先。留給用戶去調(diào)整由此導(dǎo)致的差異。
6.4資源耗盡
4.3部分定義的以掩碼為基礎(chǔ)的模式使IRC服務(wù)器（和網(wǎng)絡(luò)）輕易草率地濫用系統(tǒng)：一
個通道治理員能夠在一個通道上盡可能多地設(shè)置不同的掩碼。這很輕易導(dǎo)致服務(wù)器浪費內(nèi)存
和網(wǎng)絡(luò)帶寬（因為信息被傳播到其它服務(wù)器上）。由于此原因，建議象4.3部分提到的那樣對
每個通道能設(shè)置的掩碼數(shù)量進(jìn)行限制。
而且，可能還有更復(fù)雜的機制用來避免為相同的通道設(shè)置多余的掩碼。
7．安全考慮
7.1訪問控制
控制對通道的訪問的最主要的方法之一就是使用掩碼，掩碼基于用戶連接的用戶名
和主機名。只有在IRC服務(wù)器有一種精確的鑒別用戶連接的方法，并且用戶不能夠輕易地逃
避這種鑒別的情況下，這種機制才有效率和安全。盡管在理論上可能實現(xiàn)如此嚴(yán)格的鑒別機
制，但是大多數(shù)IRC網(wǎng)絡(luò)（非凡是公共網(wǎng)絡(luò)）并沒有象這樣的機制，而且對一個客戶連接的
用戶名和主機名的準(zhǔn)確性只提供了很少的保證。
控制訪問的另一種方法是使用通道鑰匙，但因為這種鑰匙是以純文本形式發(fā)送的，因此中途
很輕易受到攻擊。
7.2通道秘密
因為通道沖突被視為內(nèi)部事件（參見6.3部分），所以有可能用戶超越訪問控制設(shè)置而
加入通道。這種方法很長時間都被個人用來通過非法獲取通道治理員地位來“控制”通道。
同樣的方法能用來找出通道的精確成員列表，以及接收許多發(fā)送給通道的消息。
7.3匿名
匿名通道標(biāo)志（參見4.2.1部分）能用來向這類通道上所有用戶呈遞“anonymous”，方
法是使所有發(fā)送到這個通道的消息似乎都來自一個昵稱為“anonymous”的假用戶。這是在客
戶—服務(wù)器級別上實現(xiàn)的，在服務(wù)器—服務(wù)器級別上不提供匿名。
對讀者來說應(yīng)該很明顯，匿名提供的級別是很低的而且不安全，客戶程序應(yīng)向加入此類
通道的用戶出示嚴(yán)重警告
8．目前的支持和獲取渠道
MailinglistsforIRCrelateddiscussion:
Generaldiscussion:ircd-users@irc.org
Protocoldevelopment:ircd-dev@irc.org
Softwareimplementations:
FTP://ftp.irc.org/irc/server
ftp://ftp.funet.fi/pub/unix/irc
ftp://coombs.anu.edu.au/pub/irc
Newsgroup:alt.irc
9.感謝
PartsofthisdocumentwerecopiedfromtheRFC1459[IRC]which
firstformallydocumentedtheIRCProtocol.Ithasalsobenefited
frommanyroundsofreviewandcomments.Inparticular,the
followingpeoplehavemadesignificantcontributionstothis
document:

MatthewGreen,MichaelNeumayer,VolkerPaulsen,KurtRoeckx,Vesa
Ruokonen,MagnusTjernstrom,StefanZehl.
10.參考文獻(xiàn)
[KEYWordS]Bradner,S.,"KeywordsforuseinRFCstoIndicate
RequirementLevels",BCP14,RFC2119,March1997.
[IRC]Oikarinen,J.andD.Reed,"InternetRelayChat
Protocol",RFC1459,May1993.
[IRC-ARCH]Kalt,C.,"InternetRelayChat:Architecture",RFC2810,
April2000.
[IRC-CLIENT]Kalt,C.,"InternetRelayChat:ClientProtocol",RFC
2812,April2000.
[IRC-SERVER]Kalt,C.,"InternetRelayChat:ServerProtocol",RFC
2813,April2000.
11.作者地址
ChristopheKalt
99TeaneckRd,Apt#117
RidgefieldPark,NJ07660
USA

EMail:kalt@stealth.net