網際網路延遲交談：體繫結構（RFC-2812 :Internet Relay Chat: Architecture）

網際網路延遲交談：體繫結構
（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延遲交談：體系與結構