From hibari.michirou ＠ nttcom.co.jp Tue Aug 9 21:07:45 2011 From: hibari.michirou ＠ nttcom.co.jp (=?ISO-2022-JP?B?GyRCMUA/fSEhTylPLxsoQg==?=) Date: Tue, 09 Aug 2011 21:07:45 +0900 Subject: [Ultramonkey-l7-develop 716] Re: =?iso-2022-jp?b?dWx0cmFtb25rZXktbDcgVjMgGyRCJE4/NzUsJWIbKEI=?= =?iso-2022-jp?b?GyRCJTglZSE8JWszK0gvJEskRCQkJEYbKEI=?= In-Reply-To: <20110808.120035.2113337934188172344.tateishi.katsuyuki@oss.ntt.co.jp> References: <20110804.174425.568956462776812355.tateishi.katsuyuki@oss.ntt.co.jp> <4E3BA793.1080609@nttcom.co.jp> <20110808.120035.2113337934188172344.tateishi.katsuyuki@oss.ntt.co.jp> Message-ID: <4E412311.5010903@nttcom.co.jp> 雲雀です。 >>>> 2. 複数の VirtualService のキーワードにマッチした場合、どの >>>> Virtual Service にいくのか。(設定ファイルに書かれた上のほ >>>> うだけに振り分けられる、とか) >>> >>> V2だと一番最初にヒットしたやつ(一番上にかかれたやつ)のルールに従う >>> だったかな。とりあえず、それでいいとおもう。 > > l7directord.cf に書いた順番がよさそうですね。 > > あと URL モジュールを使った Virtual Service しか存在せず、か > つどの Virtula Service にもマッチしなかった場合はどうします > か？ > v2ですと、どのVirtula Service にもマッチしなかった場合はリアルサーバには つながれずに、そのまま切断されます。 そのまま切断がいやな場合は、URLの条件で"*"といった形で、 何でもマッチするVirtual Serviceを最後に追加しておくことで、 どれにもマッチしなかったリクエストを処理することが出来るので、 v2の仕様のままでよいと考えます。 >>>> あと、これはURLモジュールというよりも本体側の仕様なのですが、 >>>> モジュールを単体でビルドできるようにしておくと、独自のモジュー >>>> ルを作りたい人が嬉しいのではないかと思います。 >>>> 具体的にはモジュールのビルドに必要なヘッダファイル、ライブラ >>>> リをシステムにインストールするように変更することを意図してい >>>> ます。 >>>> >>>> 現状ではヘッダファイルや(スケジューラ/プロトコルモジュール以 >>>> 外の)ライブラリはインストールされないので、モジュールのビルド >>>> には展開したソースコード(とビルドしたライブラリ)が必要です。 >>> >>> まあ、libuml7proto.soのライブラリとヘッダをセットにした、 >>> devパッケージはあるといいかもですねぇ。 >> >> これは必要ですね． >> v2 だとプロトコルモジュール／スケジューラモジュールを >> ビルドするのに必要なヘッダファイルを切り出すくらいなら >> すぐにできそうですが，v3 だとどうなんでしょう． > > これは共有ライブラリ化&& ヘッダといっしょにインストールとい > う方向でよさそうですね。 v3でプロトコルモジュール／スケジューラモジュールをビルドするのに必要な ファイルを抽出してみました。（もしかしたら漏れがあるかもですが・・・） 添付ファイルをご覧下さい。 プロトコルモジュールはprotocol_module_base.hを、スケジューラモジュールは schedule_module_base.hをインクルードするのですが、これらのbase.hのなかで logger.hがインクルードされており、/include配下のloggerに関係するヘッダ ファイルが色々と必要になってます。 (2011/08/08 12:00), TATEISHI Katsuyuki wrote: > 立石です。 > > Shinya TAKEBAYASHI-san wrote: > >>>> 1. キーワードはリクエストのどこを捜査するのか(リクエスト行 >>>> (PATH, パラメータ) or ヘッダ全体 or (POSTなどの)ボディを含 >>>> む)。 >>>> >>>> マニュアルを見る限りではv2ではヘッダの「リクエスト行」と >>>> 「Host フィールド」それぞれに専用のオプションが用意されて >>>> います。 >>>> >>>> いただいた図においても、www.YYY.com という文字列で振り分け >>>> るのであれば、Hostフィールドを見なければなりませんし、図に >>>> はありませんが、たとえば >>>> 「http://www.YYY.com/path/to/contents.html」というリクエス >>>> トの /path 部分で振り分けたいのであればリクエスト行を見な >>>> ければなりません。 >>> >>> ボディ見るのは、厳しいかもね〜。 >>> HTML解析しないといけないし。 > > ボディを見るとして、の話ですが、HTML解析は不要だと思います。 > >>> V2みたいにリクエストとホストで分けるほうがいいかな。利用者も >>> これまでと同じ設定方法のほうがわかりやすいだろうし。 >> >> リクエストと HOST を見るのが良いと思います． >> ボディを見ないといけない場合って・・・なんでしょう． > > 私も強く必要だと思っているわけではありませんが、以下のような > 場合が考えられないでしょうか: > > 1. あるフォームでGETにパラメータを渡すページがあり、そのパラ > メータを URL モジュールでマッチさせて振り分けていた > 2. そのフォームで大きなデータを送ることになり(ファイルアップ > ロード等)、GET から POST に変更する必要が生じた > 3. しかし URL モジュールはリクエストボディを見て振り分けでき > ない。困った。 > >> >> >>>> 2. 複数の VirtualService のキーワードにマッチした場合、どの >>>> Virtual Service にいくのか。(設定ファイルに書かれた上のほ >>>> うだけに振り分けられる、とか) >>> >>> V2だと一番最初にヒットしたやつ(一番上にかかれたやつ)のルールに従う >>> だったかな。とりあえず、それでいいとおもう。 > > l7directord.cf に書いた順番がよさそうですね。 > > あと URL モジュールを使った Virtual Service しか存在せず、か > つどの Virtula Service にもマッチしなかった場合はどうします > か？ > >>>> 3. 継続的HTTPコネクション(HTTP KeepAlive)における連続したリク >>>> エストをどう扱うか。 >>>> >>>> v2 は HTTP リクエスト単位を意識していないので、HTTP >>>> KeepAliveが有効な環境では、一度 URL モジュールでリアルサー >>>> バが決定してしまうと、同一の TCP セッション内のリクエスト >>>> はすべて同一のサーバに振られていたように記憶しています。こ >>>> れは望ましい動作ではないと思いますので、v3 ではリクエスト >>>> ごとに正しい宛先に振るようにすべきだと思います。 >>> >>> この3番の状況が、うまくイメージできなかったｗ >>> KeepAliveが有効だとソケットをcloseしないから、その間おなじ >>> サーバに振られるってことかな？ > > そうです。 > >>> >>> リアルサーバのApacheがKeepAlive有効だと・・・そか、UltraMonkeyと >>> リアルサーバの間の接続がクローズされずにつなぎっぱになるのか。 >>> その場合、UltraMonkeyとクライアントの間は、1リクエスト終わると >>> すぐクローズするのかな？それともKeepAlive的にクローズしないのかな？ >> >> 猿とリアルサーバの間も繋ぎっぱなしです． >> 一番最初のリアルサーバ未定のときを除いて，どちらかのコネクションが >> TCP レイヤで切断されない限りは，片方だけ生き残っていることは >> 無いと認識しています． > > 竹林さんと同じ認識です。 > > UltraMonkey-L7 はリアルサーバあるいはクライアントからのクロー > ズをそのまま他方に伝えるだけで、コネクションプーリングしたり > はできないはず。 > >> >> >>> URLモジュールに関係なく、その辺の仕様の整理が必要かも。 >> >> そうですね． > > クライアント:リアルサーバの接続が1:nになるような状況では、い > くつか考えないといけないことがありそうです。 > > ・あるリアルサーバからのコネクションクローズ時に、別のリアル > サーバとのコネクションが生きている場合がある > > ・通常ではなさそうなレスポンスをサーバが返すことになる。 > > たとえば、サーバはレスポンスヘッダの Keep-Alive フィールド > にあと何回リクエストを受け付けられるかを入れて返してきます > が(max=100 など)、これがリクエストのたびに変わる可能性があ > ります。これがプロトコル仕様上問題があるかどうかはわかりま > せん＝対応しなくていいかも > > とか。 > > もちろん、UltraMonkey-L7 が > ・クライアント-UML7間におけるHTTPサーバとしての動作 > ・UML7-リアルサーバ間におけるHTTPクライアントとしての動作 > についてそれぞれ正しいHTTPを喋るというのが、あるべき姿だと思 > います。 > > >> >> >>>> あと、これはURLモジュールというよりも本体側の仕様なのですが、 >>>> モジュールを単体でビルドできるようにしておくと、独自のモジュー >>>> ルを作りたい人が嬉しいのではないかと思います。 >>> >>> さらに、Firefoxの拡張機能のように、動的にロード・アンロードできると >>> 嬉しいと思いま〜す('∇')ノ >>> >>> ・・・まあ、難しいと思いますけどｗ >>> # 単に動的ロードとアンロードは、dlopen系の関数で出来ますが >>> # (C++/Boostだとどうやるのかは知んないｗ)、「安全に」「通信中 >>> # データに影響を与えないように」動的ロード・アンロードできる >>> # 仕組みを実装するのが大変。 >> >> 既存のコネクションを救済する必要はないと思います． >> あっても困ることはないのですが，設変はメンテナンスウィンドウで >> 実施するもの ＝ サービスを閉塞した状態で実施するものと >> 割り切ってしまってもいいと思います． > > 竹林さんと同じ意見です。 > > サーバプログラムという用途を考えると、コスト効果は低いかなと > 思います。ないと困る or あると大変便利な機能かといわれるとそ > うでもない気がしますし。 > >> >> >>>> 具体的にはモジュールのビルドに必要なヘッダファイル、ライブラ >>>> リをシステムにインストールするように変更することを意図してい >>>> ます。 >>>> >>>> 現状ではヘッダファイルや(スケジューラ/プロトコルモジュール以 >>>> 外の)ライブラリはインストールされないので、モジュールのビルド >>>> には展開したソースコード(とビルドしたライブラリ)が必要です。 >>> >>> まあ、libuml7proto.soのライブラリとヘッダをセットにした、 >>> devパッケージはあるといいかもですねぇ。 >> >> これは必要ですね． >> v2 だとプロトコルモジュール／スケジューラモジュールを >> ビルドするのに必要なヘッダファイルを切り出すくらいなら >> すぐにできそうですが，v3 だとどうなんでしょう． > > これは共有ライブラリ化&& ヘッダといっしょにインストールとい > う方向でよさそうですね。 > > -- > TATEISHI Katsuyuki > > _______________________________________________ > Ultramonkey-l7-develop mailing list > Ultramonkey-l7-develop ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/ultramonkey-l7-develop > > -- ============================================== ＮＴＴコムウェア株式会社 品質生産性技術本部　技術SE部　基盤ソフトSE・OSS部門 雲雀　路朗（ひばり　みちろう） E-Mail:hibari.michirou ＠ nttcom.co.jp TEL:043-211-2452 ============================================== -------------- next part -------------- テキスト形式以外の添付ファイルを保管しました... ファイル名: モジュールをビルドするのに必要なファイル.odp 型: application/vnd.oasis.opendocument.presentation サイズ: 17043 バイト 説明: 無し URL: http://lists.sourceforge.jp/mailman/archives/ultramonkey-l7-develop/attachments/20110809/98b740ec/attachment-0001.odp