組織：中國互動出版網（http://www.china-pub.com/）
RFC文檔中文翻譯計劃（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：ouyang@china-pub.com
譯者：謝煒（x1982212   x1982212@263.net）
譯文發布時間：2001-7-26
版權：本中文翻譯文檔版權歸中國互動出版網所有。可以用于非商業用途自由轉載，但必須
保留本文檔的翻譯及版權信息。




Network Working Group                                           C. Kalt
Request for Comments: 2810                                   April 2000
Updates: 1459
Category: Informational



因特網延遲交談：體系結構
（Internet Relay Chat: Architecture）

該備忘錄的狀態
該備忘錄為互聯網團體提供信息。它并不制定任何互聯網標準，可以被無限制的發布。
Copyright(c)The Internet Society (2000).All Rights Reserved.

摘要:
IRC(因特網延遲交談)協議用于文本交談，1989年它首次被實現并用于BBS用戶間的交談
1993年五月RFC 1459(IRC)將它以文獻形式正式確立下來，以后它就不斷發展 
這篇文獻描述了目前IRC協議的結構以及它各個組成部分的在整個協議中的角色
其它文獻詳描述了這里定義的各種組成之間的協議

目錄
1.介紹	2
2．組件	2
2.1服務器	3
2.2客戶機	3
2.2.1用戶客戶機	3
2.2.2服務客戶機	3
3.結構	3
4.IRC協議服務	3
4.1客戶機定位	4
4.2消息延遲	4
4.3頻道收集和管理	4
5.IRC 概念	4
5.1一對一交流	4
5.2和多個	4
5.2.1和一個頻道	5
5.2.2向 一個主機/服務器掩網	5
5.2.3向一系列目標	5
5.3向所有	5
5.3.1客戶機向客戶機	5
5.3.2客戶機向服務器	6
5.3.3服務器向服務器	6
6當前的問題	6
6.1可用范圍	6
6.2可靠性	6
6.3網絡擁塞	6
6.4保密問題	6
7．保密	7
8．目前的支持和獲取渠道	7
9. 感謝	7
10.參考文獻	7
11.作者地址	7
12．完整版權說明	8
致謝	8
 
1.介紹
IRC(Internet延遲交談)協議用于文本交談被設計出來已經有許多年了，這篇文檔描述了
它目前的體系結構。
IRC協議是基于客戶服務器模型的，可以很好地分布式地在許多機器上運行。一個典型
的設置涉及一個進程(服務器)，它作為中心點接受客戶(或其它服務器)的連接，并且實現
要求的消息傳送/多元技術和其它的功能。
這種分布模型，由于它要求每個服務器都擁有全局狀態信息，限制了一個網絡所能達到
的最大規模，因此是此協議最令人不能容忍的問題。現存的網絡能夠以難以置信的速度
持續增長，我們必須感謝硬件制造商們給了我們比以往更加強大的系統。
2．組件
接下來的幾節定義了IRC協議的基本組件
2.1服務器
服務器是IRC的主干，因為它是協議中唯一能夠將所有其它組件連接在一起的組件：它
為客戶機提供連接的節點以使它們之間進行交談[IRC-CLIENT],并且提供供其它服務器
連接的節點[IRC-SERVER]。服務器也負責提供IRC協議定義的基本服務。
2.2客戶機
任何不是服務器并且連到一個服務器的機器都可以稱作客戶機。有兩種客戶機，它們用
于不同的目的。
2.2.1用戶客戶機
用戶客戶機一般是提供基于文本界面的程序，程序用來通過IRC進行交流。這種特
殊類型的客戶機常被稱作“用戶機”。
 2.2.2服務客戶機
       不像用戶機，服務客戶機沒有設計為手工作用，也不用于交談。它們對協議交談功
能的使用受到更加的限制，卻可以隨意地使用來自服務器的更加秘密的數據.
服務機是典型的用來向用戶機提供各種服務(不必和IRC自身相關)的自動機器。一
個例子是一個收集和IRC網絡相連的用戶機的來源的統計數據的服務。
3.結構
一組相互連接的服務器就定義了一個IRC網絡，一臺服務器構成最簡單的IRC網絡。
對IRC服務器來說，唯一允許的網絡結構是一個生成樹，每個服務器都作為對它可見的
網絡的中心結點。
                   1--\
                           A        D---4
                       2--/ \      /
                             B----C
                            /      \
                           3        E
服務器：A,B,C,D,E         客戶機：1,2,3,4
                    [圖一 小型IRC網絡示例]
4.IRC協議服務
  這個部分描述了IRC協議提供的服務。這些服務的組合可以實現實時會議。
  4.1客戶機定位
  為了相互交換消息，兩個客戶機必須能夠相互定位對方。
     一連上服務器，客戶機就注冊一個標志，此標志此后被其它服務器和客戶機用來定位該客
戶機。服務器負責跟蹤所有使用的標志。
  4.2消息延遲
   IRC協議無法提供兩臺客戶機的直接連接，所有客戶機間的交流都被服務器延遲
4.3頻道收集和管理
一個頻道是一個由一個或更多的客戶機組成的命名組，這個組中的所有成員都接收發送給
這個頻道的消息。一個頻道由它的名字和目前的成員來標志，它也有一系列能被它的成員
使用的屬性。
頻道提供了向多個客戶機發送信息的方法。服務器收集頻道，提供必須的消息多路技術。服
務器也負責通過跟蹤頻道成員來管理頻道。服務器的確切角色在"Internet Relay Chat: 
Channel Management" [IRC-CHAN]中定義。
5.IRC 概念
  這個部分專門描述IRC協議組織背后的真實概念，以及不同種類的消息如何被傳送。
  5.1一對一交流
     一對一基礎上的交流經常由客戶機實現，因為大部分的阻塞是經由服務器進行的交談。
      為了提供一各客戶機相互交談的方法，要求所有服務器能夠沿著生成樹到達任何客戶
機以單向發送消息。因此消息發送路徑是生成樹上任意兩點之間的最短路徑。
   下面的例子都涉及上面的圖一。
     例一：1和2之間的消息只同時被服務器A看到，A直接將消息發送給2。
     例二：1和3之間的消息同時被服務器A，B和客戶機3看到。沒有其它客戶機或服
務器允許看到此消息。
          例三：2和4之間的消息只被服務器A，B，C，D和客戶機4看到。
  5.2和多個
     IRC的方根目的是提供簡單有效的會議論壇。IRC提供了許多方法來實現，每個方法
都為各自的目的服務。
5.2.1和一個頻道
      在IRC里，頻道和多播組角色等同，它們都動態生存而且實際上的談話必須發送到
正支持給定頻道上客戶機的服務器。還有，消息將向每個本地鏈接只發送一次，因
為每個服務器都負責散發原始消息以保證它能到達所有收件人。
下面的例子都涉及圖二
例四：任何包括客戶機一在內的頻道。任何發送給該頻道的消息到達服務器并且不會
到達其它任何地方。  
例五：二個客戶機在一個頻道里。所有消息經過的路徑使它們看起來像頻道、之外的
兩個客戶機之間的秘密消息。
例六：客戶機1,2,3在一個頻道里。所有發送給該的消息都發送給所有客戶機和那些發
送給單個客戶機的秘密消息所必須經過的服務器。如果客戶機1發送一條消息，它返回
到客戶機2然后經由服務器B到達客戶機3。
5.2.2向 一個主機/服務器掩網
為了提供一種向大量相關客戶機發送消息的機制，必須能夠向主機/服務器掩網發送消
息。這些消息發送給掩碼信息相符的那些主機和服務器。消息只被發送到客戶機所在
的特定區域，和頻道的方式差不多。
 5.2.3向一系列目標
 效率最差的一對多談話方式是客戶機向一系列目標談話(客戶機，頻道，掩網)。
這種方式的實現是不言自明的：客戶機給出消息目的地的列表，服務器將它分解并向
每個目的地發送一份消息拷貝。
這種方式沒有頻道方式有效率，因為列表可能被破壞而且不能保證沿著每條路徑向下
發送每條消息的拷貝。
5.3向所有
   一對所有式的消息最好是用廣播消息來描述，這種消息是發送給所有客戶機或服務
器或兩者兼備。在一個包含客戶機和服務器的大型網絡上，一條消息就能引起大量
堵塞，因為它會努力被發送到所有想達到的目的地。
   對某些種類的消息來說，沒有其它選擇只有向所有服務器廣播，這樣才能保持各個
服務器保存的狀態信息之間的一致性。
   5.3.1客戶機向客戶機
        沒有哪種消息能夠導致來自單一客戶機的消息發送給所有其它客戶機。
  5.3.2客戶機向服務器
       大部分引起狀態信息(比如頻道成員人數，頻道狀態，客戶機狀態等等)改變的命令
必須缺省地向所有服務器發送，而且這種分發不應被客戶機改變。
  5.3.3服務器向服務器
  盡管大多數服務器之間的消息都向所有其它服務器分發，但只有當消息影響客戶機，
頻道或服務器時才有必要。因為在IRC里有一些基本的條目，因此幾乎所有的來自
服務器的消息都向其它相連的服務器廣播。
6當前的問題
  這個協議有一些公認的問題，這個部分僅僅講述那些和協議體系有關的問題。
6.1可用范圍
當大范圍應用時，此協議用得不太好，這一點已經得到廣泛認同。主要原因是所有服務器
都必須知道其它服務器，客戶機和頻道并且關于它們的信息必須及時更新。
6.2可靠性
因為IRC服務器唯一允許的網絡結構是生成樹，因此兩個服務器之間的連接是明顯的而
且很容易斷連。這個問題在“Internet延遲交談：服務器協議”[IRC-SERVER]中有更加詳
細的描述。
6.3網絡擁塞
   生成樹結構引起的問題除了可用范圍和可靠性兩個問題之外，還有就是使IRC極容易導
致網絡擁塞。這個問題是區域性的，直到下一代才能解決：如果擁塞和高流量導致兩個
服務器之間的連接失敗，不僅這種失敗導致網絡擁塞，而且它們之間的重連也將導致更
加嚴重的網絡擁塞。
   為了使這個問題的影響減到最小，服務器最好不要自動地太快地嘗試重新連接，以避免
使情況惡化。
6.4保密問題
   除了不能很好地適用大范圍，以及服務器必須知道其它實體的所有信息外，優先級問題
也是引人注目的問題。特別是對頻道，

7．保密
   除了6.4節提到的保密問題外,安全和這個文檔不相關。
8．目前的支持和獲取渠道
   IRC相關討論郵件列表：
       一般討論：irce-user@irc.org
       協議開發：ircd-dev@irc.org
       實現軟件：ftp://ftp.irc.org/irc/server
                 ftp://ftp.funet.fi/pub/unix/irc
                 ftp://coombs.anu.edu.au/pub/irc
       新聞組:    alt.irc
9. 感謝
   這篇文檔部分拷貝自第一次正式發布的IRC協議RFC 1459[IRC]，它也受益于許多評論
和討論。特別是以下人對這篇文檔作出了重要貢獻：
   Matthew Green, Michael Neumayer, Volker Paulsen, Kurt Roeckx, Vesa
   Ruokonen, Magnus Tjernstrom, Stefan Zehl.
10.參考文獻
   [KEYWORDS]  Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.      
   [IRC]        Oikarinen, J. and D. Reed, "Internet Relay Chat
                Protocol", RFC 1459, May 1993.
   [IRC-CLIENT] Kalt, C., "Internet Relay Chat: Client Protocol", RFC
                2812, April 2000.
   [IRC-SERVER] Kalt, C., "Internet Relay Chat: Server Protocol", RFC
                2813, April 2000.
   [IRC-CHAN]   Kalt, C., "Internet Relay Chat: Channel Management", RFC
                2811, April 2000.
11.作者地址
   Christophe Kalt
   99 Teaneck Rd, Apt #117
   Ridgefield Park, NJ 07660
   USA
   EMail: kalt@stealth.net
12．完整版權說明
    Copyright (C) The Internet Society (2000).  All Rights Reserved.
This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

致謝

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




RFC2811——Internet Relay Chat: Channel Management
                                                               Internet延遲交談：體系與結構


1
RFC文檔中文翻譯計劃