Entering Passive Mode

カテゴリ 'C++, C' の記事
< 1 2 3 4 5 6 >

UNIX ファイルシステムのリンク機能

UNIX 系のファイルシステムには、
ハードリンクとシンボリックリンクがある。

これらは、ファイルに別名をつける機能である。
同じデータを参照する別名のファイルを作成するので、
ファイルのコピーと異なり、余計な容量を占有しない。

ハードリンクは、ファイルに複数の名前を持たせる機能である。

あるファイルに対してハードリンクを作成することで、
1 つのファイル内容に対して、複数のファイル名が対応する。

導通

いよいよこの日がやってきた。
デバッグで正常に動作することを確認できたので、
サービスの皮を被せてリリースビルドを行う。
開発機にサービスとしてインストールしてテスト、OK!

いよいよ本番稼動機に仕込む。

サービスをインストールした後、UPnP を利用するため、
Windows コンポーネントの追加と削除を開き、
ネットワークサービスの
「インターネットゲートウェイデバイスの検出とクライアントの制御」「UPnP ユーザインタフェース」をインストール。
SSDP Discovery Service サービスを有効にしておく。
ADSL モデムの静的 NAPT でポートを外部に公開。

短くテスト

今日もあまり時間がない……

取り合えずコントロール接続の内容を
デバッグウィンドウに吐き出すように設定
便利な API があるもんだ。

    OutputDebugString(command);

そして昨日と同じように接続テスト。
……あれ? 何も流れない?

軽くテスト

本職の方が無茶苦茶忙しかったため、
今日はほとんど時間がない。

そんな中、昼休みを利用してテストをしてきました。
AirStation は自宅にないので。

幸い会社のルータも UPnPNT に対応していたので、
ログを吐き出すコードを追加し、
ビルドしてデスクトップ機でデバッグ実行。

デスクトップ機のプロキシポートを
ルータに静的 NAPT 登録して外部に公開し、
AIREDGE カードを利用して外部から接続してみる。

データ通信部の実装

方針も決まったことだし、実装に行こう。

まずはサクっとデータ待機スレッドを実装する。
これは前に作ったコントロール待機スレッドと変わらない。

Socket を作成して Bind, Listen、

    auto_ptr<Socket> listener(new Socket(AF_INET, SOCK_STREAM));
    listener->Bind(localAddr);
    listener->Listen(2);

スレッドとオブジェクト指向

スレッドとオブジェクト指向の間で悩ましいことがある。
実装上の壁ではないので、大きな悩みではないけれど、
今回は趣味の範囲だし、とことん偏執してみよう。

現在、スレッドはクラスとして実装している。
Thread クラスを継承してスレッドを実装する仕組みだ。
派生クラスは new に引数を渡して作成して実行される。
delete で削除すると、スレッドも強制的に終了される。
Shutdown メソッドで終了の同期を取ることもできる。

今回の場合、listener(L) ソケットを持つスレッドは、
クライアントからの接続を受信すると、
接続を受理して新しいセッション用のソケットを作成し、
新しい session(S) 用のスレッドを作成して実行する。

追加仕様

データ接続をどのように実装するか。

コントロール接続とデータ接続を同時に扱う必要があるので、
素直にスレッド化したほうがよさそうだ。

PASV に対してサーバがポートを開くので、
プロキシも新しいポートを開いて待機する。
クライアントからの接続を処理するために、
データ接続用の待機スレッドを作成しておく。

UPnPNT で登録するのはプロキシのアドレスであり、
クライアントに返信するのはプロキシの外部アドレス。
また、待機スレッドを終了させるときに、
プロキシの外部アドレスを登録解除すると効率が良い。

対策を練る

LinkStation のような FTP 実装に対応するには、
データ接続もプロキシが媒介する必要がある。
さて、もう一度 PASV 対応を考えてみよう。

大文字はグローバル、小文字はプライベート IP/Port
R: リモートホスト(クライアント)
P: プロキシコントロール IP/Port
S: サーバコントロール IP/Port
X: プロキシデータ IP/Port
Y: サーバデータ IP/Port
静: 静的 NAPT ルール
動: 動的 NAPT ルール

面倒くさい…

調査のつづきをしたが、
前回の推測でほぼ間違いないようだ。

これを回避するためには、
データ接続も、プロキシが媒介する必要がある。

逆に言うと、データセッションを監視できるので、
UPnPNT の登録解除もできるかもしれない。

正月なのに…

FTP プロキシの接続のテストをしているうちに、
意外な事実が判明した。

色々なサーバでテストしようと思い、
BUFFALO の LinkStation の FTP 機能を有効にして、
プロキシのテストをしてみた。すると繋がらない。

色々調べてみると、どうやらサーバから見て、
コントロール接続の相手先 IP アドレスと、
データ接続の相手先 IP アドレスが異なる場合、
サーバがデータ接続を拒否するらしい。

< 1 2 3 4 5 6 >
このページのトップへ戻る
© 2008 Project Loafer/Project Fireball and all blog writers. Powered by Nucleus CMS