RFC2810 Internet Relay Chat: Architectureを読んでみた。

# はじめに
どうも。こんにちは。
[42tokyo](https://42tokyo.jp/)といったところで、IRCサーバの再実装を行なっています。
前回は、[RFC1459 Internet Relay Chat Protocolを読んでみた。（１）](https://qiita.com/gu-chi/items/d14c99f716da6133bce8)を書きました。

今回は、[RFC2810 Internet Relay Chat: Architecture](https://datatracker.ietf.org/doc/html/rfc2810)を読んでいきます。
RFC2810は、RFC1459の更新版といった立ち位置となっているので、RFC1459との違いを意識しながら読んでいきたいと思います。

間違い等があれば、ご指摘ください。

# Abstract
* この文書は、1993年5月に作成されたRFC 1459の更新版
* 現在のIRCプロトコルのアーキテクチャとその異なるコンポーネントの役割を説明する
* コンポーネント間で使用されるプロトコルは、他の文書で説明する

# 1. Introduction
* この文書では、現在（2000年ごろ）のアーキテクチャについて説明する
* IRCプロトコルは、クライアント-サーバーモデルに基づいている（このモデルは、ネットワークの大きさが制限される可能性を持つ）
* 典型的な構成は、１つのサーバが様々な機能を実行する中心を形成し、クライアントがそのサーバに接続する形である

# 2. Components
* この章で解説されるものは、IRCプロトコルの基本的なコンポートネントとなる

## 2.1 Servers
* サーバは、IRCプロトコルの中心的な役割を果たす
* サーバは、他のすべてのコンポーネントを結びつけることができる
* これは、コンポーネントの中で、唯一サーバだけが持つ役割となる
* サーバは、[クライアント](https://datatracker.ietf.org/doc/html/rfc2812)や、他の[サーバ](https://datatracker.ietf.org/doc/html/rfc2813)が接続するポイントを提供する
* サーバーは、IRCプロトコルで定義された基本的なサービスを提供する責任もある

## 2.2 Clients
* クライアントとは、サーバに接続するものを指す。ただし、サーバではない
* クライアントは2種類あり、異なる目的を持つ
 
### 2.2.1 User Clients
* User Clientsとは、IRCを介して対話的に通信するために使用される、テキストベースのインタフェースを提供するプログラムを指す
* こうしたクライアントは、「users」と呼ばれることもある

### 2.2.2 Service Clients
* 「Service」とは、ユーザに対して（IRC自体とは必ずしも関連しない）ある種のサービスを提供するために使用される自動プログラムを指す（例えば、IRCネットワークに接続しているユーザの出自に関する統計を収集するサービスがある）
* Service Clientsは、usersとは異なり、手動で使用することや会話を行うためのプログラムではない
* Service Clientsは、プロトコルのチャット機能へのアクセスが制限されている
* Service Clientsは、サーバが保持するプライベートなデータへアクセスできる

# 3. Architecture
* IRCネットワークは、互いに接続された複数のサーバーによって構成される
* IRCネットワークを構成する最小部分は、単一のサーバとなる
* IRCサーバーに許される唯一のネットワーク構成はスパニングツリー
* 各サーバはネットワークの残りの部分を見るための中心的なノード（Root Bridge）として機能する
* IRCプロトコルは、2つのクライアントが直接通信する手段を提供しない
* クライアント間の通信は、すべてサーバが中継します

# 4. IRC Protocol Services
* この章では、IRCプロトコルが提供するサービスについて説明する
* これらのサービスを組み合わせることで、リアルタイムの会議が可能となる

## 4.1 Client Locator
* メッセージのやり取りには、クライアントが互いの位置を特定できる必要がある
* クライアントは、サーバに接続すると、ラベルを登録する（このラベルは、クライアントを一意に識別する）
* クライアントは、このラベルを用いて、通信相手となるクライアントの位置を特定する
* サーバーは、使用されているすべてのラベルを追跡できる必要がある

## 4.2 Message Relaying
* IRCプロトコルは、2つのクライアントが直接通信する手段を提供しない
* クライアント間の通信はすべてサーバによって中継されます

## 4.3 Channel Hosting And Management
* チャンネルは、1人以上のユーザが所属する名前付きグループのこと
* チャンネルは、そのチャネル宛てのメッセージをすべて受信する
* チャンネルは、チャンネル名と所属メンバーによって特徴付けられる
* チャンネルは、権限を持ったメンバーが設定できるプロパティを持つ
* チャンネルは、複数のクライアントにメッセージを送信する
* サーバは、チャンネルを管理し、必要なメッセージの多重化を提供する
* サーバは、チャンネルメンバーの追跡を通じてチャンネルの管理をする
* サーバのチャンネルに対する詳細な役割は、[RFC2811 Internet Relay Chat: Channel Management](https://datatracker.ietf.org/doc/html/rfc2811)で定義されている

# 5. IRC Concepts
* この章では、IRCプロトコルを支える概念と、さまざまなクラスがあるメッセージの配信方法について説明する

## 5.1 One-To-One Communication
RFC1459と同じなので省略
参考：[RFC1459 Internet Relay Chat Protocolを読んでみた。（１）](https://qiita.com/gu-chi/items/d14c99f716da6133bce8#31-one-to-one-communication)

## 5.2 One-To-Many
RFC1459と同じなので省略
参考：[RFC1459 Internet Relay Chat Protocolを読んでみた。（１）](https://qiita.com/gu-chi/items/d14c99f716da6133bce8#32-one-to-many)

### 5.2.1 To A Channel
* IRCにおけるチャンネルは、マルチキャストグループと同等の役割を持つ
* チャンネルは、動的な存在である
* チャンネル内で送受信されるメッセージは、チャンネルに所属するユーザが接続するサーバのみに送信されなければならない[MUST]
* 各サーバは、メッセージを全ての受信者に届ける責任があるため、ローカルリンクには一度だけ送信されるべき[SHALL]
（ローカルリンクとは、隣り合うサーバ間の接続を指す）

### 5.2.2 To A Host/Server Mask
RFC1459とほぼ同じなので省略
参考：[RFC1459 Internet Relay Chat Protocolを読んでみた。（１）](https://qiita.com/gu-chi/items/d14c99f716da6133bce8#323-to-a-hostserver-mask)

以下、違い
RFC2810より
> To provide with some mechanism to send messages to a large body of related users, host and server mask messages are available.

RFC1459より
> To provide IRC operators with some mechanism to send messages to a large body of related users, host and server mask messages are provided.
* これより、IRCオペレータだけでなく、一般ユーザも、ホスト・サーバマスクメッセージが利用できる？

### 5.2.3 To A List
RFC1459とほぼ同じなので省略
参考：[RFC1459 Internet Relay Chat Protocolを読んでみた。（１）](https://qiita.com/gu-chi/items/d14c99f716da6133bce8#321-to-a-list)

以下、違い
RFC2810より
> The least efficient style of one-to-many conversation is through clients talking to a 'list' of targets (client, channel, mask).

RFC1459より
> The least efficient style of one-to-many conversation is through clients talking to a 'list' of users.

* メッセージの送信先としてリストにできる対象が、RFC1459では「users」、RFC2810では「client, channel, mask」となっている

## 5.3 One-To-All
RFC1459とほぼ同じなので省略
参考：[RFC1459 Internet Relay Chat Protocolを読んでみた。（１）](https://qiita.com/gu-chi/items/d14c99f716da6133bce8#33-one-to-all)

### 5.3.1 Client-to-Client
RFC1459と同じなので省略
参考：[RFC1459 Internet Relay Chat Protocolを読んでみた。（１）](https://qiita.com/gu-chi/items/d14c99f716da6133bce8#331-client-to-client)

### 5.3.2 Client-to-Server
RFC1459とほぼ同じなので省略
参考：[RFC1459 Internet Relay Chat Protocolを読んでみた。（１）](https://qiita.com/gu-chi/items/d14c99f716da6133bce8#332-clients-to-server)

違い
RFC2810より
> Most of the commands which result in a change of state information (such as channel membership, channel mode, user status, etc.) MUST be sent to all servers by default, and this distribution SHALL NOT be changed by the client.

RFC1459より
> Most of the commands which result in a change of state information (such as channel membership, channel mode, user status, etc) must be sent to all servers by default, and this distribution may not be changed by the client.

* クライアントによる配布方法の変更が、RFC1459では「may not」だったが、RFC2810では「SHALL NOT」になった

### 5.3.3 Server-to-Server
RFC1459とほぼ同じなので省略
参考：[RFC1459 Internet Relay Chat Protocolを読んでみた。（１）](https://qiita.com/gu-chi/items/d14c99f716da6133bce8#333-server-to-server)

# 6. Current Problems
* このプロトコルには多くの問題点がある
* この章では、プロトコルのアーキテクチャに関する問題点のみを取り上げる

## 6.1 Scalability
* すべてのサーバーがグローバルな状態情報を把握する必要があること
* その情報が変更されるとリアルタイムで他のサーバーに通知される必要があること
* これらの要因から、IRCネットワークを拡張すると、情報の更新や通知にかかる負荷が増加し、パフォーマンスが低下する可能性を含んでいる

## 6.2 Reliability
* IRCサーバーのネットワーク構成はスパニングツリーであるため、2つのサーバ間の各リンクで障害が発生する可能性を持つ
* この問題の詳細は、[RFC2812 Internet Relay Chat: Server Protocol](https://datatracker.ietf.org/doc/html/rfc2813)を参照のこと

## 6.3 Network Congestion
* IRCのプロトコルとアーキテクチャは、ネットワークの輻輳に対して極めて脆弱
* ２つのサーバ間のリンクで障害が起きると、更に大量のトラフィックが発生し、ネットワークに負荷が掛かる
* こうした状況を踏まえて、サーバ間のリンクで問題が起きた時は、自動で再接続を試みないようにすることを強く推奨する **[RECOMMENDED]**

## 6.4  Privacy
* 各サーバが、他のサーバの情報を持つので、プライバシーの問題が生じるかもしれない
* 特に、チャンネルに関連した情報は、ユーザに関連した多くの情報を持つので扱いには注意すること

# 12. Full Copyright Statement
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 PARTICULAR PURPOSE.

# さいごに
事前知識がないと理解が難しい文章あると感じました。
例えば、3. Architectureの１文
> The only network configuration allowed for IRC servers is that of a spanning tree where each server acts as a central node for the rest of the network it sees.

deepLの翻訳
> IRCサーバーに許される唯一のネットワーク構成は、スパニングツリーで、各サーバーがネットワークの残りの部分を見るための中心ノードとして機能するものである。

この翻訳を理解するのに「スパニングツリーとは？」から始まり「中心ノードとは？」、「スパニングツリーにおける中心ノードとは？」といった疑問を解消する必要がありました。

次回は、RFC2812Internet Relay Chat: Client Protocolを読んでいきたいと思います。
特に、クライアントから接続開始の要求があった場合、サーバ側で行われる処理について読んでいきたいと思います。

ありがとうございました。

# 参考
https://datatracker.ietf.org/doc/html/rfc2810

https://ja.wikipedia.org/wiki/%E3%82%A2%E3%83%BC%E3%82%AD%E3%83%86%E3%82%AF%E3%83%81%E3%83%A3

※ この記事で「アーキテクチャ」とは、ある構造の全体を指す言葉として使用

https://ja.wikipedia.org/wiki/%E3%82%B3%E3%83%B3%E3%83%9D%E3%83%BC%E3%83%8D%E3%83%B3%E3%83%88

https://ja.wikipedia.org/wiki/%E3%82%B9%E3%82%B1%E3%83%BC%E3%83%A9%E3%83%93%E3%83%AA%E3%83%86%E3%82%A3