このアーカイブは同期化されません。 mixi の日記が更新されても、このアーカイブには反映されません。
データ接続をどのように実装するか。
コントロール接続とデータ接続を同時に扱う必要があるので、
素直にスレッド化したほうがよさそうだ。
PASV に対してサーバがポートを開くので、
プロキシも新しいポートを開いて待機する。
クライアントからの接続を処理するために、
データ接続用の待機スレッドを作成しておく。
UPnPNT で登録するのはプロキシのアドレスであり、
クライアントに返信するのはプロキシの外部アドレス。
また、待機スレッドを終了させるときに、
プロキシの外部アドレスを登録解除すると効率が良い。
クライアントがデータポートに接続してきたら、
プロキシからサーバのデータポートに接続代行し
後はクライアントやサーバのデータをそれぞれに転送する。
これは、データ転送用スレッドを作成して実行する。
クライアントかサーバのどちらかが切断した場合、
双方のソケットを閉じてデータ転送用スレッドを終了する。
ややこしいのはスレッドの相互関係だ。
以下のような親子関係にするのがいいか。
A. FTP サービススレッド（クラス）
B. コントロール待機スレッド（クラス）
C. コントロール管理スレッド（クラス）
D. コントロール通信スレッド（クラス）
E. データ待機スレッド（クラス）
F. データ通信スレッド（クラス）
・親スレッドが終了する場合、子スレッドも終了する。
・A は、1 個の B と 1 個の C を所有する。
・C は、0 個以上の D を所有する。
・D は、0 個か 1 個の E を所有する。
・E は、0 個か 1 個の F を所有する。
1 つのセッション中に複数のデータ通信は起こらないから。
F を E の子として持たせてもいいだろう。
A は FTP サービス自体。サービスとしての実装。
B は Listen ソケット。接続があれば、C に D の生成を要求。
C は セッションの開始と終了を監視し、インスタンスを管理。
D も Listen ソケット。接続があれば、E を生成。
既に E が存在すれば接続を許可しない
E は 1 番単純な実装。2 つのソケット間のデータを仲介する。