直接クライアント間

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ネットワークを介して、あるユーザーから別のユーザーに送信されます。
• DCCセッションを開始するもう一つの方法は、クライアントが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 ]}

一般的なDCCアプリケーション

DCCチャット

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

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

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

DCCホワイトボード

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

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

DCC送信

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

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

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

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

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

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

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

DCC SENDエクスプロイト

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

DCC送信

XMITサービスはDCC SENDの改良版であり、ファイルの再開を可能にし、ACKロングによる無駄なトラフィックを削減します。XMITは広くサポートされていません。

XMITハンドシェイクはSENDハンドシェイクとは若干異なります。送信側は受信者にファイルを提供するCTCPを送信します。DCC XMIT protocolipport[ 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と同様の制限があります。さらに、32ビットオフセットのため、2ギガバイトを超えるファイルの再開はできません。

パッシブDCC

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

DCCサーバー

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

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

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

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

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

DCCリレー

DCCリレーは、DCC転送を別のユーザーに転送するためのスクリプトです。^{[ 13 ]}ユーザーは、ダイアログでニックネームとサーバーを指定して、DCCリレースクリプトをユーザーに設定します。ニックネームとサーバーの設定が完了すると、ユーザーはXDCCボットにファイルを要求し、ファイル転送が別のユーザーに転送されます。この方法は、XDCCチャンネルが他のXDCCチャンネルからXDCCボットにファイルを送るために使用できます。

RDCC

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

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

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

DCCリバース

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

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

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

DCC RSEND

これはKVIrcクライアントにおけるDCC REVERSEの代替手段です。送信側はCTCP: を送信することでファイルを提供します。受信側はCTCPで を応答することでファイルを受け入れ、送信側は受信側に接続して通常のDCC SENDと同様に を送信します。 DCC RSEND filenamefilesizeDCC RECV filenameipportstart

リバース / ファイアウォール DCC

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

受信側は、リスニングソケットを開き、CTCPメッセージで応答することでファイルを受け取ることができます。これは、ipとportによって受信側がリスニングしているソケットが識別される点を除けば、元のリバースDCCメッセージと同じです。tokenは元のリクエストと同じで、送信者にどのリクエストが受け入れられるかを知らせます。（このメッセージは通常のDCC送信リクエストと同じ形式であるため、DCCリクエストをフィルタリングするサーバーの中には、送信者に受信側を「DCC許可」リストに追加することを要求するものもあります。） DCC SEND filenameipportfilesizetoken

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

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

>> DCC SEND filenameip 0 filesizetoken << DCC RESUME filename 0 positiontoken >> DCC ACCEPT filename 0 positiontoken << DCC SEND filenamepeer-ipportfilesizetoken

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

ファイルサーバー（FSERV）

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

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

参照

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

参考文献

1. 「オープンソースとフリーソフトウェア」 . troy.rollo.name . 2018年11月16日時点のオリジナルよりアーカイブ。2018年11月15日閲覧。
2. 「DCCネゴシエーションと接続」kvric.net。
3. 「IRCHelp.org — クライアント間プロトコル（CTCP）」www.irchelp.org。
4. ポール・ピカール、ブライアン・バスキン、ジョージ・スピルマン、マーカス・サックス（2005年5月1日）「IRCネットワークとセキュリティ」『企業向けIMおよびP2Pアプリケーションのセキュリティ確保』（第1版）Syngress、386ページ。ISBN 1-59749-017-2ircII ソフトウェア パッケージの作成者は、もともと IRC 経由のファイル転送の先駆者でした。
5. ircii-2.1.4e.tar.gzに含まれる「NOTES」および「source/ctcp.c」ファイルを参照してください
6. ircii-2.1.4e.tar.gzに含まれる「UPDATES」および「source/dcc.c」ファイルを参照してください
7. Troy Rollo (1993年1月20日). "/dcc" .ニュースグループ:  alt.irc . Usenet: [e-mail] . 2010年11月10日閲覧。 
8. Rollo, Troy. 「DCCプロトコルの説明」 . irchelp.org . 2010年11月10日閲覧。まず最初に申し上げたいのは、DCCプロトコルはIRCII以外のクライアントへの移植性を考慮して設計されたものではないということです。したがって、他のクライアントへの実装が困難であることについて、私は一切の責任を負いません。
9. 「mIRCヘルプ」 . www.mirc.com . 2023年7月24日閲覧。
10. 「SecurityFocus エクスプロイト情報」。
11. 「CVE - CVE-2006-1068」 . cve.mitre.org .
12. 「CVE - CVE-2006-1067」 . cve.mitre.org .
13. https://web.archive.org/web/20090804013445/http://www.hawkee.com/snippet/4739/

外部リンク

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