直接クライアントからクライアントへ

Direct Client-to-Client ( DCC ) (元々はDirect Client Connection ^{[1] [2] [3]} ) はIRC関連のサブプロトコルで、ピアがIRC サーバーを介してハンドシェイクすることで、ファイル交換や非中継チャットを行えるようにするものです。確立されると、一般的な DCC セッションは IRC サーバーから独立して実行されます。元々はircIIで使用するために設計されたものですが、現在では多くのIRC クライアントでサポートされています。Napster プロトコル サーバー上の一部のピアツーピア クライアントにも、TekNap、SunshineUN、Lopster など、DCC 送受信機能があります。DCC プロトコルのバリエーションである SDCC (Secure Direct Client-to-Client) は、DCC SCHAT とも呼ばれ、暗号化された接続をサポートしています。DCCの使用に関する RFC 仕様は存在しません。

DCC 接続は 2 つの異なる方法で開始できます。

• 最も一般的な方法は、CTCP を使用してDCC セッションを開始することです。CTCP は、IRC ネットワークを介して 1 人のユーザーから別のユーザーに送信されます。
• DCC セッションを開始するもう 1 つの方法は、クライアントが DCC サーバーに直接接続することです。この方法を使用すると、トラフィックは IRC ネットワークを通過しません (DCC 接続を開始するために、関係者が IRC ネットワークに接続する必要はありません)。

ircIIはCTCPとDCCプロトコルを実装した最初のIRCクライアントでした。^[4] CTCPプロトコルは1990年にMichael SandrofによってircIIバージョン2.1で実装されました。^[5] DCCプロトコルは1991年にTroy Rolloによってバージョン2.1.2で実装されましたが、^[6]他のIRCクライアントへの移植は意図されていませんでした。^{[7] [8]}

CHATサービスでは、ユーザーはDCC接続を介して互いにチャットすることができます。^[9]トラフィックはIRCネットワークを経由せず、ユーザー間で直接送信されます。通常のメッセージ送信と比較すると、これによりIRCネットワークの負荷が軽減され、フラッド制御がないため一度に大量のテキストを送信でき、メッセージがIRCサーバーに公開されないため通信がより安全になります（ただし、メッセージはプレーンテキストのままです）。

DCC CHAT は通常、CTCPハンドシェイクを使用して開始されます。接続を確立したいユーザーは、次の CTCP をターゲットに送信します。ここで、ipとport は送信者の IP アドレスとポート番号で、整数で表されます。protocolは標準の DCC CHAT の場合chatです。受信側は、指定されたポートと IP アドレスに接続できます。 DCC CHAT protocol ip port

接続が確立されると、DCC CHAT に使用されるプロトコルは非常に単純になります。ユーザーはCRLFで終了するメッセージを交換します。ASCII 001 (control-A、以下では[^A]で表されます) と単語ACTIONで始まり、別の ASCII 001で終了するメッセージは、絵文字として解釈されます。 [^A]ACTION waves goodbye[^A]

これは DCC CHAT の拡張機能であり、テキスト行だけでなく簡単な描画コマンドも送信できます。DCC ホワイトボードは DCC CHAT に似たハンドシェイクで開始されますが、プロトコルchat はwboard : に置き換えられます。 DCC CHAT wboard ip port

接続が確立されると、2 つのクライアントはCRLFで終了するメッセージを交換します。ASCII 001で始まる (およびオプションで終了する) メッセージは、特別なコマンドとして解釈されます。コマンドACTION は絵文字を表し、その他のコマンドはユーザーのホワイトボードの表面に線を描画したり、2 つのクライアントが一連の機能をネゴシエートできるようにします。

SEND サービスを使用すると、ユーザーは互いにファイルを送信できます。ハンドシェイクの元の仕様では、受信側がファイルの合計サイズを知ることも、転送を再開することもできませんでした。そのため、クライアントはハンドシェイクに独自の拡張機能を導入するようになり、その多くが広くサポートされるようになりました。

元のハンドシェイクは、送信者が次の CTCP を受信者に送信するというものでした。 DCC SEND filename ip port

DCC CHAT と同様に、ipとport は、送信マシンが着信接続を待機する IP アドレスとポートです。一部のクライアントは、スペースを含むファイル名を二重引用符で囲みます。最後の引数としてファイル サイズを追加するのが一般的です: 。 DCC SEND filename ip port filesize

この時点で、元の仕様では、受信側は指定されたアドレスとポートに接続してデータを待つか、要求を無視するかのいずれかでしたが、DCC RESUME 拡張をサポートするクライアントの場合、3 番目の選択肢として、CTCP 応答を送信してファイルの一部をスキップするように送信側に要求します。 DCC RESUME filename port position

送信クライアントが DCC RESUME をサポートしている場合は、 で応答し、受信側は指定されたアドレスとポートに接続して、既存のファイルに追加するデータをリッスンできます。 DCC ACCEPT filename port position

データはブロック単位でクライアントに送信され、クライアントは各ブロックに対して、受信したバイトの合計数を32 ビット ネットワーク バイト オーダー整数の形式で送信して確認応答する必要があります。これにより接続速度が低下し、TCPのため冗長になります。先行送信拡張機能は確認応答を待たずに済むため、この問題はいくらか軽減されますが、送信側が確認応答を期待している場合、受信側は受信するブロックごとに確認応答を送信する必要があるため、完全に解決されるわけではありません。

別の拡張機能である TDCC (ターボ DCC) では、確認応答が削除されますが、ハンドシェイクが若干変更される必要があり、広くサポートされていません。TDCC の古いバージョンでは、ハンドシェイクの単語 SEND が TSEND に置き換えられました。後のバージョンでは、単語 SEND が使用され、ハンドシェイクの後にTが追加され、このバージョンの TSEND は他のクライアントと互換性があります (変更されたハンドシェイクを解析できる限り)。

「DCC 送信エクスプロイト」は、2 つのバグを指します。1つは、ファイル名が 14 文字を超えると発生するmIRCのバリアントバッファ オーバーフローエラーです^[10]。もう 1 つは、ポート0の使用によって発生する、Netgear、D-Link、Linksys製の一部のルーターの入力検証エラーです^{[11] [12]。}特に、ルーター エクスプロイトは、実際の DCC SEND 要求が行われたときだけでなく、ポート 6667 のTCPストリームのどこかに「 DCC SEND 」という語句の後にスペースや改行のない 6 文字以上が続くと発生する可能性があります。2000 年代には、複数のエクスプロイトを 1 つの文字列DCC SEND startkeylogger 0 0 0に組み合わせることが可能でした。これをパブリック チャネルに投稿すると、複数のユーザーが切断される可能性があります (IRC クライアントのクラッシュ、ルーターのクラッシュ、またはウイルス対策ソフトウェアの過度に厳格なデフォルト設定のトリガーによって)。^[要出典]

XMIT サービスは、ファイルの再開を可能にし、ACK ロングからの無駄なトラフィックを削減する DCC SEND の修正バージョンです。XMIT は広くサポートされていません。

XMIT ハンドシェイクは SEND ハンドシェイクとは若干異なります。送信者は受信者にファイルを提供するCTCPを送信します。DCC XMIT protocol ip port[ name[ size[ MIME-type]]]

ここで、角括弧はオプション部分を囲みます。protocolは転送に使用するプロトコルです。現在定義されているのはclearのみです。標準の DCC SEND とは異なり、 ip はIPv4 の場合は標準のドット表記、IPv6 の場合は 16 進数または混合表記の追加形式にすることができます。前のパラメータを空のままにして、後のパラメータを指定するには、前のパラメータを-として指定します。受信側が使用されているプロトコルを実装していない場合は、次の形式の CTCP 応答が返されます。 ERRMSG DCC CHAT protocol unavailable

ここで CHAT が使用されるのは、拡張 DCC CHAT によって送信されるエラー メッセージとの互換性を維持するためです。受信側が転送を拒否した場合、次の CTCP 応答が送信されます。 ERRMSG DCC CHAT protocol declined

他のエラーも同様に報告されます。受信者がファイルを受信する意思と能力がある場合、指定されたアドレスとポートに接続します。その後何が起こるかは、使用されるプロトコルによって異なります。

クリアプロトコルの場合、XMIT サーバーは接続を受信すると、ファイルの変更時刻を表す32 ビットのネットワーク バイト オーダーを送信します。次に、おそらくローカル ファイルの変更時刻に基づいて、クライアントは別のネットワーク バイト オーダーを送信します。これは、サーバーがファイルを送信するときに検索するオフセットです。ファイル全体が必要な場合はこれを 0 に設定し、クライアントが以前のダウンロードを再開する場合はローカル ファイルのサイズに設定します。 time tlong

XMIT は SEND よりも高速ですが、 CTCPネゴシエーションでファイルのサイズが指定されているか、事前に分かっている場合を除き、ファイルのサイズがどれくらいかを知ることができないという点で、SEND と同じ制限の 1 つがあります。さらに、32 ビット オフセットのため、2 ギガバイトを超えるファイルを再開することはできません。

通常の DCC 接続では、イニシエーターがサーバーとして機能し、ターゲットがクライアントになります。ファイアウォールの普及とNATによるエンドツーエンドの透過性の低下により、イニシエーターがサーバーとして機能できない場合があります。ターゲットにサーバーとして機能するように要求するさまざまな方法が考案されています。

通常の DCC SEND および CHAT へのこの拡張機能は、IRC クライアントmIRCによって導入されました。DCC サーバーは適度にサポートされていますが、すべてのクライアントで標準ではありません (「インターネット リレー チャット クライアントの比較」を参照)。

IRC サーバーを必要とせずに、IP アドレスによる DCC 接続の開始が可能になります。これは、受信側クライアントがサーバーとして動作し (名前の由来)、送信側からのハンドシェイクを (通常はポート 59 で) 待機することで実現されます。

CHAT の場合、イニシエーターは を送信します。次にターゲットは で応答し、残りは標準の DCC CHAT プロトコルに従って進行します。 1000 initiator nick1000 target nick

SEND の場合、イニシエーターは を送信します。ターゲットは で応答します。ここで、再開位置はファイル内の開始オフセットです。ここから転送は通常の DCC SEND として進行します。 1200 initiator nick filesize filename1210 target nick resume position

DCC サーバーは、mIRC スタイルのファイル サーバーと DCC GET もサポートします。

DCC サーバーは使用するポートを指定する方法を提供していないため、手動でネゴシエートする必要がありますが、一方が人間ではない可能性があるため、常に可能であるとは限りません。RDCC は DCC サーバーのハンドシェイク メカニズムであり、ポートに加えてサーバーの IP アドレスも提供しますが、ホスト マスキングのため、クライアントはこれを見つけられない可能性があります。広くサポートされているわけではありません。

イニシエーターは、CTCP クエリを送信して、ターゲットがリッスンしているポートを要求します。ここで、functionは、チャットの場合はc、送信の場合はs、ファイル サーバーの場合は f です。RDCC function comment

次にターゲットは、 で CTCP 応答します。ここで、ipとport は通常の DCC SEND および CHAT と同じ意味を持ちます。この後、イニシエーターはipとportに接続し、DCC サーバー ハンドシェイクが続きます。 RDCC 0 ip port

ハンドシェイクが直接 IP 接続を介して処理される DCC Server とは異なり、DCC REVERSE には、DCC SEND で使用されるものと同様の通常の CTCP ハンドシェイクがあります。これは広く実装されていません。送信者は、CTCP メッセージを送信して、受信者にファイルを提供します。キーは、33 ～ 126 の範囲の 1 ～ 50 文字のASCII文字列であり、転送の識別子として機能します。 DCC REVERSE filename filesize key

受信側が受け入れた場合、CTCP応答を送信します。DCC REVERSE key start ip port

ここで、start はファイル内の送信を開始する位置、ip はIPv4の場合は標準のドット表記、IPv6の場合は16 進表記の受信者の IP アドレスです。次に、送信者は受信者が指定した IP アドレスとポートに接続し、通常の DCC SEND が続きます。送信者と受信者の両方が CTCP 応答を送信してハンドシェイクをキャンセルできます。 DCC REJECT REVERSE key

これは、KVIrc クライアントの DCC REVERSE の代替手段です。送信者は CTCP: を送信してファイルを提供します。受信側は CTCP で と応答して受け入れることができ、送信者は受信側に接続して、通常の DCC SEND のように送信します。 DCC RSEND filename filesizeDCC RECV filename ip port start

このパッシブ DCC メカニズムは、少なくともmIRC、Visual IRC、HexChat、KVIrc、DMDirc、Klient、Konversation、および PhibianIRC でサポートされています。送信者は CTCP メッセージを送信してファイルを提供します。ipは、ネットワーク バイト オーダーの送信者のIPアドレスで、1 つの整数として表現されます (標準 DCC と同様)。有効なポートの代わりに数値 0 が送信され、これがリバース DCC 要求であることを示します。tokenは一意の整数です。TSEND が使用されている場合 (それをサポートするクライアントによって)、文字Tがトークンに追加され、受信側に確認応答を送信する必要がないことが通知されます。 DCC SEND filename ip 0 filesize token

受信側は、リスニング ソケットを開いて CTCP メッセージで応答することで、ファイルを受け入れることができます。これは、ipとport が受信側がリスニングしているソケットを識別することを除いて、元の Reverse DCC メッセージと同じです。tokenは元の要求と同じで、送信側にどの要求が受け入れられるかを知らせます。(このメッセージは通常の DCC 送信要求と同じ形式に従うため、DCC 要求をフィルタリングする一部のサーバーでは、送信側が受信者を「DCC 許可」リストに追加することを要求する場合があります。) DCC SEND filename ip port filesize token

次に、送信者は受信者のソケットに接続し、ファイルの内容を送信し、ファイルの送信が終了したら受信者がソケットを閉じるのを待ちます。

SEND プロトコルの RESUME 拡張が使用される場合、コマンドのシーケンスは次のようになります ( >>は開始側からの送信メッセージを示し、<< はピアからの応答を示します)。

>> DCC SEND filename ip 0 filesize token
<< DCC RESUME filename 0 position token
>> DCC ACCEPT filename 0 position token
<< DCC SEND filename peer-ip port filesize token

その後、プロトコルは通常どおり進行します (つまり、送信者が受信者のソケットに接続します)。

DCC fserveまたはファイル サーバーを使用すると、ユーザーは DCC サーバー上にあるファイルを参照、読み取り、ダウンロードできます。

通常、これは DCC CHAT セッション (ユーザーにコマンド プロンプトを表示する) またはファイルを要求するための特別なCTCPコマンドを使用して実装されます。ファイルは DCC SEND または DCC XMIT を介して送信されます。DCC ファイル サーバーの実装は多数ありますが、その 1 つが、人気のmIRCクライアントの FSERV コマンドです。

• CTCP (クライアント間プロトコル)
• XDCC (拡張DCC)

• DCC プロトコルの説明(注: ほとんどの IRC クライアントとネットワークは、DCC プロトコルの拡張機能を実装しています。現在一般的に使用されている DCC は、このドキュメントで説明されているものからかなり進化しています。)
• DCC ネゴシエーションと接続 2005-12-15 にWayback Machineでアーカイブ
• Turbo DCCプロトコルの説明
• DCCホワイトボードプロトコルの説明