ネットワーキンググループ C. Kalt Request for Comments: 2810 2000年4月 1459のアップデート カテゴリ: インフォメーション インターネットリレーチャット:構造 この文章について この文章は、インターネットコミュニティのための情報を提供します。インターネ ットの基準を定義するものではありません。この文章の配布に制限はありません。 コピーライト Copyright (C) The Internet Society (2000). All Rights Reserved. 概要 IRC (Internet Relay チャット) プロトコルはテキストベースの会議に使われま す。もともとはBBSでユーザたちが内輪のチャットをするために1989年から開発され てきました。 1993年5月に初めて公式にRFC 1459 [IRC]で文書化されたときには、このプロトコ ルはまだ発展途上にありました。このドキュメントは、現在のIRCプロトコルの構造 およびおのおののコンポーネントの役割を記述する、1459のアップデートドキュメン トです。ここで述べられるさまざまなコンポーネント間で利用されるプロトコルの詳 細については、別のドキュメントで述べられます。 目次 * 1 導入 * 2 コンポーネント o 2.1 サーバ o 2.2 クライアント + 2.2.1 ユーザクライアント + 2.2.2 サービスクライアント * 3 構造 * 4 IRCプロトコルサービス o 4.1 クライアントロケーター o 4.2 メッセージリレー o 4.3 チャンネルの主催と管理 * 5 IRCのコンセプト o 5.1 1対1コミュニケーション o 5.2 1対多 + 5.2.1 対チャンネル + 5.2.2 対ホスト/サーバマスク + 5.2.3 対リスト o 5.3 1対すべて + 5.3.1 クライアント対クライアント + 5.3.2 クライアント対サーバ + 5.3.3 サーバ対サーバ * 6 現在の問題点 o 6.1 スケーラビリティ o 6.2 信頼性 o 6.3 ネットワークの密集 o 6.4 プライバシー * 7 セキュリティについての配慮 * 8 現在のサポートおよび入手先 * 9 謝辞 * 10 リファレンス * 11 筆者の連絡先 * 12 コピーライトの完全記述 1. 導入 IRC(Internet Relay チャット)プロトコルはテキストベースの会議向けに何年も開 発されてきました。このドキュメントにはその現在の構造について記述してありま す。 IRCプロトコルはクライアント-サーバモデルのうえに成り立っており、またたくさ んの分散したマシン上でうまく動くようにできています。通常のセットアップの場 合、接続されるべきクライアント(または他のサーバ)のために(サーバが)中心点をつ くり、メッセージの配送/多重化、その他必要な機能を実行するという一つのプロセ スが行われます。 すべてのサーバがグローバルな状況の情報のコピーをもたなくてはならないという この分散モデルは、ネットワークが広がれる範囲を制限する重大なハンデであるた め、いまだにこのプロトコル最悪の問題点です。もしネットワークがそれなりのペー スで成長しつづけると、もっとパワフルなマシンをハードウエアメーカーがつくって くれないと困る、ということになります。 2. コンポーネント ここからはIRCプロトコルの基本的なコンポーネントを定義します。 2.1 サーバ 「サーバ」は、このプロトコルのうち他のすべてのコンポーネントを取りまとめら れるただ一つのコンポーネントとして、IRCのバックボーンを形成します。サーバは クライアントがほかの[IRC-クライアント]と接続して通信できるための接点や、ほか のサーバが[IRC-サーバ]と接続するための接点を提供します。またIRCプロトコルで 定義されている基本的なサービスを提供する役割もあります。 2.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 [ 図. 1. 小さなサンプルIRCネットワーク ] IRCプロトコルには、二つのクライアントが直接にやりとりする手段はありませ ん。クライアント間のすべてのコミュニケーションは、１つ以上のサーバによってリ レーされます。 4. IRCプロトコルサービス このセクションでは、IRCプロトコルが提供するサービスについて記述します。こ れらのサービスの組み合わせがリアルタイム会議を実現します。 4.1 クライアントロケーター メッセージを交換するためには、二つのクライアントは相手の位置を特定できなく てはなりません。 サーバに接続するとき、クライアントはラベルを使って登録します。ほかのサーバ やクライアントは、このラベルによってこのクライアントの位置がわかります。サー バは使われているラベルの記録を取っておかなくてはなりません。 4.2 メッセージリレー IRCプロトコルには、二つのクライアントが直接にやりとりする手段はありませ ん。クライアント間のすべてのコミュニケーションは、１つ以上のサーバによってリ レーされます。 4.3 チャンネルの主催と管理 チャンネルとは、そのチャンネルにきたすべてのメッセージを受け取る、1人かそ れ以上のユーザのグループです。チャンネルは名前と現在のメンバーで他と特徴づけ られ、またメンバー(か、メンバーの一部)が操作できるプロパティを持っています。 チャンネルはメッセージがいくつかのクライアントに送られる手段を提供します。 サーバは必要におうじてメッセージをマルチプレクシングすることによってチャン ネルをホストします。 サーバはまた、チャンネルのメンバーを記憶しておくというチャンネルの管理もし ます。サーバの役割については、"Internet Relay Chat: Channel Management" [IRC-CHAN]で定義されています。 5. IRCのコンセプト このセクションでは、IRCプロトコルの機構の後ろにある実質的なコンセプトと、 違うクラスのメッセージがどのように配送されるかということを述べます。 5.1 1対1コミュニケーション 1対1のコミュニケーションは大抵、クライアントによって実行されます。なぜなら ほとんどのサーバ対サーバのトラフィックは、サーバ同士の通信のためではないから です。クライアントが他のクライアントと通信できるようにするためには、すべての サーバがどんなクライアントにも届けるように、スパニングツリー構造に沿って確実 に一つの方向にメッセージを送れることが「必要不可欠」です。だからメッセージが 配送される経路はスパニングツリーの中の二つのポイント間の一番短い経路なので す。 次の例はすべて上の図1を参照してください。 例1: クライアント1とクライアント2の間のメッセージは、クライアント2にストレ ートにメッセージを送るサーバAのみで見ることができます。 例2: クライアント1とクライアント3の間のメッセージは、サーバAとサーバBとク ライアント3で見られます。ほかのクライアントやサーバはすべてこのメッセージを 見られません。 例3: クライアント2とクライアント4の間のメッセージは、サーバA、サーバB、サ ーバC、サーバD、クライアント4でのみ見られます。 5.2 1対多 IRCの主な目的は、簡単で効果的な「会議(1対多の会話)」を開ける手段を提供する ことです。IRCにはこの目的を達成するいくつかの方法があります。各々はそれ固有 の目的を達成するために動きます。 5.2.1 対チャンネル IRCにおいては、チャンネルはマルチキャストグループと同等の役割を持っていま す。チャンネルの存在は動的で、チャンネル内で行われる実質的な会話は、与えられ たチャンネルにいるユーザをサポートするサーバにのみ送られ「なくてはなりませ ん」。またメッセージはただ一回だけすべてのローカルリンクに送られます。各々の サーバがすべての受け取り手に届くようにオリジナルメッセージを広げなくてはなら ないからです。 次の例はすべて図2を参照。 例4: 1クライアントだけがいるチャンネル。このチャンネルへのメッセージはサー バに行って、他へは行きません。 例5: 2クライアントがいるチャンネル。すべてのメッセージはあたかもチャンネル 外にいる二つのクライアント間のプライベートメッセージであるかのように経路をと おります。 例6: クライアント1、クライアント2、クライアント3がいるチャンネル。 このチ ャンネルへのすべてのメッセージは、すべてのクライアントに送られます。もしメッ セージが一つのクライアントへのプライベートメッセージであればそれらがとおるサ ーバのみに送られます。もしクライアント1がメッセージを送ると、それはクライア ント2に帰っていって、サーバB経由でクライアント3に届きます。 5.2.2 対ホスト/サーバマスク 大人数ユーザにメッセージを送るメカニズムを提供するため、ホスト/サーバマス クメッセージが使えます。これらのメッセージは、マスクに合致する情報をもってい るホストやサーバのユーザに送られます。メッセージはチャンネルのときと同じよう なかんじで、ユーザがいる場所にだけ送られることになります。 5.2.3 対リスト 1対多の会話で一番スマートでないやり方は、クライアントがターゲット(クライア ント、チャンネル、マスク)の「リスト」に通信する方法です。いかにこれを成し遂 げるかというのはほとんど自明です。クライアントがメッセージを届けるべきところ のリストをつくり、サーバがこれを分割して、メッセージを各々の目的地にとにかく ただ送る、という方法です。 この方法ではチャンネルを使うほどの効果は望めません。目的地リストが壊される 「かもしれない」し、複製がちゃんと経路にそって送られたかどうかのちゃんとした チェックなしで、たれながしで送られてしまう「かもしれない」からです。 5.3 1対すべて 「1対すべて」タイプのメッセージは、すべてのクライアントやサーバ、もしくは 両方に送られるブロードキャストメッセージといったほうがいいかもしれません。ユ ーザとサーバによる大きなネットワークでは、すべての目的地に届こうとして送られ て、一つのメッセージが莫大なトラフィックを生んでしまう場合があります。 メッセージのとあるクラスでは、各々のサーバが保持している状態情報がサーバ間 で一致しているようにするため、すべてのサーバにブロードキャストするしかありま せん。 5.3.1 クライアント対クライアント 一つのメッセージからほかのすべてのクライアントに送られるメッセージとなるメ ッセージのクラスはありません。 5.3.2 クライアント対サーバ 状態情報(チャンネルのメンバーや、チャンネルのモード、ユーザステータスなど のような)の変更に関するほとんどのコマンドは、デフォルトですべてのサーバに送 られ「なくてはなりません」。またこの配送はクライアントによって変更「されませ ん」。 5.3.3 サーバ対サーバ サーバ間のほとんどのメッセージが「ほかの」すべてのサーバに送られるのです が、これはユーザ、チャンネルやサーバに影響を与えるメッセージのためだけに必要 なものです。これらはIRCの中にある基本的なアイテムなので、サーバから出るほと んどすべてのメッセージは接続されているすべてのほかのサーバにブロードキャスト されます。 6. 現在の問題点 このプロトコルに関する既知の問題点がいくつもありますが、このセクションでは 単にこのプロトコルの構造に関係する問題点を列挙します。 6.1 スケーラビリティ このプロトコルが大きな舞台で使われた場合、うまくスケールしないのは広く知ら れるところです。この問題は主に、すべてのサーバが、すべてのほかのサーバ、クラ イアント、チャンネル、そして変更があったらすぐにアップデートされるべき情報を 知っていなくてはならない、ということからきます。 6.2 信頼性 IRCサーバに許される唯一のネットワークの形はスパニングツリーであるため、二 つのサーバ間のリンクは、明白で非常に深刻な麻痺を起こすポイントです。このこと については"Internet Relay Chat: Server Protocol" [IRC-SERVER]で詳しく述べら れています。 6.3 ネットワークの輻輳 スケーラビリティや信頼性の問題、それからスパニングツリー構造に関係するもう 一つの問題点は、このIRCのためのプロトコルと構造はネットワークの輻輳に対して 非常に脆いということです。 この問題点は特有のもので、次世代では解決されるであろう問題です。もしネット ワークの輻輳や高いトラフィックが二つのサーバ間の接続の失敗を引き起こすと、こ の失敗がより多くのネットワークトラフィックを生むだけでなく、二つのサーバの接 続のリトライ(ほかの場所でということもあります)がさらにトラフィックを増やすの です。 これらの問題点のインパクトを最小限にするため、サーバは接続のリトライを自動 的にあまりに早くしないことが強く「推奨されます」。状況をますます悪化させない ためです。 6.4 プライバシー うまくスケールしないほかに、サーバがほかの接続してるもののすべての情報を知 らなくてはならないという事実から、プライバシーの問題もまた考慮されるべき点で す。これはとくにチャンネルに当てはまります。なぜならチャンネルに関係ある情報 は、ユーザがオンラインであるかどうかより非常に強く暴露的であるからです。 7. セキュリティについての配慮 セクション6.4 (プライバシー)で述べたことに関係あるプライバシーはさておき、 セキュリティはこのドキュメントには関係ないと思われます。 8. 現在のサポートおよび入手先 IRC関係の議論のメーリングリスト: 一般議論: ircd-users@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 translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. 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 PARTICOLAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. 13. 日本語訳にあたって 関わった人と会社は下記のとおりです。 * 齋藤華子 (翻訳) * ワタナヴェイタル (HTML化) * 株式会社タフ (編集) 翻訳の正確さには可能なかぎりの努力をはらいましたが、不正確な部分や「よくない 訳」もまだまだあると思います。より正確な情報を求める方は原文も参照してくださ い。もし、誤訳や誤植を発見したり、もっといい翻訳があると思われた方は(株)タフ までご連絡ください。今後も継続的にメンテナンスしていく予定です。 [最終更新: 2000年8月16日]