Shinya TAKEBAYASHI
takeb****@oss*****
2008年 8月 28日 (木) 14:14:18 JST
中居 様 竹林です. お疲れ様です. > この部分ですが、error.htmlが別サーバに設定している場合は > 挙動が異なりませんか? > URLですとurlごとにサーバ振り先が異なりますよね? 現在の実装でも,Keepalive 無効の場合は URL ごとに振り分け先を分ける事が できますが,Keepalive が有効な場合は,URL ごとに振り分け先は変えられません. 実機で今の実装を確認してみました. ○ 条件 UM-L7 バージョン: 2.0.0-1 試験用ファイル : 192.168.0.104 には index.html のみ 192.168.0.202 には error.html のみ l7directord.cf : virtual=192.168.0.251:8080 real=192.168.0.104:80 masq module=url --pattern-match 'index.html' ・・・・ virtual=192.168.0.251:8080 real=192.168.0.202:80 masq module=url --pattern-match 'error.html' ・・・・ Apache の設定 : Keepalive On Firefox の設定 : Keepalive 有効 ○ 試験パターン(矢印以下は,期待する動作) 1. index.html を取得 → 正常に取得できる 2. index.html を取得 → error.html を取得 → error.html 取得時に HTTP 404 発生 Keepalive 無効時は,error.html も取得可能 3. error.html を取得 → 正常に取得できる 4. error.html を取得 → index.html を取得 → index.html 取得時に HTTP 404 発生 Keepalive 無効時は,index.html も取得可能 5. index.html を取得 → 202 を落とす → error.html を取得 → error.html 取得時に HTTP 404 発生 Keepalive 無効時は,error.html 取得時に Connection 切断 6. error.html を取得 → 104 を落とす → index.html を取得 → error.html 取得時に HTTP 404 発生 Keepalive 無効時は,index.html 取得時に Connection 切断 ※ それぞれの試験の前に,Firefox は再起動します ○ 結果 1. 期待通り 2. 期待通り(HTTP 404 発生) 3. 期待通り 4. 期待通り(HTTP 404 発生) 5. 期待通り(HTTP 404 発生) 6. 期待通り(HTTP 404 発生) サービス決定後は,コネクションが維持されている限りリアルサーバは固定されるので URL パーシスタンスは機能しません. > あと、現状まだ実装されていませんがurlaも対応できないと思われますが。 確かにそうですね. 考えないといけません. ----------------------------------------------------------- Shinya TAKEBAYASHI E-mail: takeb****@oss***** GPG ID: 395EFCE8 GPG FP: 58B2 B5D0 A692 1BD8 328B E31E E027 AC35 395E FCE8 ----------------------------------------------------------- 中居憲久 <nakai****@yes*****> wrote in message <48B62****@yes***** > *** Subject: Re: [Ultramonkey-l7-develop 192] Re: QoSコードの修正および追加 - 2 *** Date: 2008/08/28 13:30:37 > 中居@幕張です。 > お疲れ様です。 > > #なぜか自社メールに流れてきていなかったので。 > > > ○ URL モジュールの場合 > > index.html に適合するルールが無い場合は,接続拒否. > > 動作は現在の実装と変わらない. > > この部分ですが、error.htmlが別サーバに設定している場合は > 挙動が異なりませんか? > URLですとurlごとにサーバ振り先が異なりますよね? > cookie-insertはコネクションごとに変わると思うので問題はないと思います。 > あと、現状まだ実装されていませんがurlaも対応できないと思われますが。 > (これは中身を全部走査しますので、先頭だけを渡すのは難しいと思います) > よって、urlaモジュールに当てはまる場合は全部渡す… > と、なると今度はQoSに制限が出るような気がします。 > > > 先頭から L7VS_CONN_READ_BUFSIZE 分だけ読み込んだバッファを, > > サービス判定のフローに丸投げすることで回避できそうです. > > プロトコルモジュールに新しくサービス判定用のインタフェイスを作ったりして, > > 各プロトコルに応じた判定処理をすれば問題ないと思います. > > > サービス判定用IFが一番スマートのような気がしますね。 > ただ、現状のMonkeyのつくりではprotocolmodule側がサービスを確定するという > つくりが足を引っ張っているような気がしないでもないです。 > > 長期的にはこの部分をもう少し考慮する必要があるかもしれません。 > > > >