From tanuma.kouhei ＠ nttcom.co.jp Tue Jun 8 13:04:11 2010 From: tanuma.kouhei ＠ nttcom.co.jp (Kohei TANUMA) Date: Tue, 08 Jun 2010 13:04:11 +0900 Subject: [Ultramonkey-l7-develop 603] Re: =?iso-2022-jp?b?c29ycnlzZXJ2ZXIgGyRCQFokakJYJCgkTklUNnEbKEI=?= =?iso-2022-jp?b?GyRCOWckSyREJCQkRhsoQg==?= In-Reply-To: References: <4BB15C79.8000009@nttcom.co.jp> <4BB18820.1090605@nttcom.co.jp> <4BB1B503.1020708@nttcom.co.jp> <4BB2A5C9.9040400@nttcom.co.jp> Message-ID: <4C0DC13B.4060509@nttcom.co.jp> 皆様 田沼です。 随分長い間放置してしまいましたが、 sorryserver の不具合についてです。 とりあえず修正したものを作成したのですが、 仕様について多少疑問があるので別バージョンも作成しました。 (1) 各種 Sorry サーバ条件により、最初のリクエストから Sorry サーバに接続後、Sorry サーバ条件から外れて Sorry サーバからリアルサーバに接続が動的に切り替わる。 (2) 各種 Sorry サーバ条件により、最初のリクエストから Sorry サーバに接続後、Sorry サーバ条件から外れても Sorry サーバへの接続は維持される。 (1) が仕様上の動作で今回うまくいっていなかった挙動です。 ただ、HTTP 通信であれば、リクエストの途中のパケットから リアルサーバに切り替わっても正常に処理されないし、そもそも Sorry サーバの提供するコンテンツとリアルサーバが提供する コンテンツは別物でしょう。 また、別のプロトコルであったとしても Sorry サーバからリアルサーバに 切り戻ってメリットを享受できるものが思いつきません。 ということで、この動的に切り替えるという機能の必要性が 感じられない、というか、接続は維持した方がいいのではないかと 考えましたので (2) の維持する版も作成しています。 皆様のご意見をお聞かせ願えればと思います。 なお、(1) については以下の未対応部分があります。 1. リアルサーバが無いため Sorry サーバに初期接続 2. 管理者がリアルサーバを追加 3. Sorry サーバからリアルサーバに接続が切り替わる （現在は切断されます。(2)では維持されます） また、強制 Sorry サーバフラグ設定についても微妙な挙動が あります。 このフラグがチェックされるのはクライアントからのパケットを 振り分ける際となっているため、例えば巨大なデータをクライアントが ダウンロードしている最中に、管理者が強制的に Sorry サーバへと 接続を変えようとしてフラグを設定したとしても、クライアントから リクエストが飛んでこない限り接続は変わりません。つまり、 ダウンロードが継続されてしまいます。 これは望ましい挙動ではないような気がします。 以上、宜しくお願い致します。 2010/03/31 10:40, Shinya TAKEBAYASHI wrote: > 竹林です． > >> 事象を確認しましたが、問題は -u 指定の値を超えた場合の >> Sorry サーバ接続で、-f による強制 Sorry サーバ接続は >> 大丈夫だと思います。 >> それで、この -u 指定の場合ですが、fast_schedule に関係なく >> Sorry サーバ接続がおかしくなるようです。 >> （sslid モジュールでも同一の事象がみられます） > > ですね． > あと，リアルサーバが無い（-w 0 ではなく，存在しない）場合も > sorry に行く機能は，きちんと動いています． > > -u を超えたときのみです． From n.nakai ＠ sdy.co.jp Tue Jun 8 16:57:42 2010 From: n.nakai ＠ sdy.co.jp (=?ISO-2022-JP?B?GyRCQ2Y1bzd7NVcbKEI=?=) Date: Tue, 08 Jun 2010 16:57:42 +0900 Subject: [Ultramonkey-l7-develop 604] Re: =?iso-2022-jp?b?c29ycnlzZXJ2ZXIgGyRCQFokakJYJCgkTklUNnEbKEI=?= =?iso-2022-jp?b?GyRCOWckSyREJCQkRhsoQg==?= In-Reply-To: <4C0DC13B.4060509@nttcom.co.jp> References: <4BB15C79.8000009@nttcom.co.jp> <4BB18820.1090605@nttcom.co.jp> <4BB1B503.1020708@nttcom.co.jp> <4BB2A5C9.9040400@nttcom.co.jp> <4C0DC13B.4060509@nttcom.co.jp> Message-ID: <4C0DF7F6.9090909@sdy.co.jp> 中居です。 お疲れ様です。 > ただ、HTTP 通信であれば、リクエストの途中のパケットから > リアルサーバに切り替わっても正常に処理されないし、そもそも > Sorry サーバの提供するコンテンツとリアルサーバが提供する > コンテンツは別物でしょう。 > また、別のプロトコルであったとしても Sorry サーバからリアルサーバに > 切り戻ってメリットを享受できるものが思いつきません。 この場合の接続とは純粋にHTTPの接続ですよね。 データ転送中(epollは複数回のeventで転送することがありますが)に sorry条件から外れたとしてもrealserverへの切り戻しは必要無いかと思います。 たとえばsorryからsorry.htmlをclientに転送中に巻き戻ったとしても データの整合性は取れませんし、そのコネクションはsorry.htmlを転送後、 切断処理となるのが理想的じゃないかと思います。 と、言うわけで中居的にも(2)がsorry制御の処理として妥当ではないかと思います。 よろしくお願いいたします。 From tanuma.kouhei ＠ nttcom.co.jp Tue Jun 8 17:44:01 2010 From: tanuma.kouhei ＠ nttcom.co.jp (Kohei TANUMA) Date: Tue, 08 Jun 2010 17:44:01 +0900 Subject: [Ultramonkey-l7-develop 605] Re: =?iso-2022-jp?b?c29ycnlzZXJ2ZXIgGyRCQFokakJYJCgkTklUNnEbKEI=?= =?iso-2022-jp?b?GyRCOWckSyREJCQkRhsoQg==?= In-Reply-To: <4C0DF7F6.9090909@sdy.co.jp> References: <4BB15C79.8000009@nttcom.co.jp> <4BB18820.1090605@nttcom.co.jp> <4BB1B503.1020708@nttcom.co.jp> <4BB2A5C9.9040400@nttcom.co.jp> <4C0DC13B.4060509@nttcom.co.jp> <4C0DF7F6.9090909@sdy.co.jp> Message-ID: <4C0E02D1.6060902@nttcom.co.jp> 中居さん 田沼です。 お疲れ様です。 > と、言うわけで中居的にも(2)がsorry制御の処理として妥当ではないかと思い ます。 そうですね。私もそう思ってました。 ただ、先程この件について話をしていたんですが、 普通ごめんなさい画面につながったら更新連打するよね、 もし Sorry サーバがキープアライブ設定有効になっていたら ずっと Sorry サーバに繋がっちゃうんじゃね？ 動的に切り替わるなら、その辺も救済されるからそっちの方が いいんじゃないの？といった意見もいただきました。 Sorry サーバを使うときは Sorry サーバのキープアライブ無効を 推奨という手もありますが、なんかそれはそれで微妙な 感じもします。 他の方もご意見いただけると幸いです。 2010/06/08 16:57, 中居憲久 wrote: > 中居です。 > お疲れ様です。 > >> ただ、HTTP 通信であれば、リクエストの途中のパケットから >> リアルサーバに切り替わっても正常に処理されないし、そもそも >> Sorry サーバの提供するコンテンツとリアルサーバが提供する >> コンテンツは別物でしょう。 >> また、別のプロトコルであったとしても Sorry サーバからリアルサーバに >> 切り戻ってメリットを享受できるものが思いつきません。 > > この場合の接続とは純粋にHTTPの接続ですよね。 > データ転送中(epollは複数回のeventで転送することがありますが)に > sorry条件から外れたとしてもrealserverへの切り戻しは必要無いかと思います。 > たとえばsorryからsorry.htmlをclientに転送中に巻き戻ったとしても > データの整合性は取れませんし、そのコネクションはsorry.htmlを転送後、 > 切断処理となるのが理想的じゃないかと思います。 > > と、言うわけで中居的にも(2)がsorry制御の処理として妥当ではないかと思います。 > > よろしくお願いいたします。 From n.nakai ＠ sdy.co.jp Tue Jun 8 18:14:19 2010 From: n.nakai ＠ sdy.co.jp (=?ISO-2022-JP?B?GyRCQ2Y1bzd7NVcbKEI=?=) Date: Tue, 08 Jun 2010 18:14:19 +0900 Subject: [Ultramonkey-l7-develop 606] Re: =?iso-2022-jp?b?c29ycnlzZXJ2ZXIgGyRCQFokakJYJCgkTklUNnEbKEI=?= =?iso-2022-jp?b?GyRCOWckSyREJCQkRhsoQg==?= In-Reply-To: <4C0E02D1.6060902@nttcom.co.jp> References: <4BB15C79.8000009@nttcom.co.jp> <4BB18820.1090605@nttcom.co.jp> <4BB1B503.1020708@nttcom.co.jp> <4BB2A5C9.9040400@nttcom.co.jp> <4C0DC13B.4060509@nttcom.co.jp> <4C0DF7F6.9090909@sdy.co.jp> <4C0E02D1.6060902@nttcom.co.jp> Message-ID: <4C0E09EB.3080404@sdy.co.jp> 田沼様 中居です。 お疲れ様です。 > 普通ごめんなさい画面につながったら更新連打するよね、 > もし Sorry サーバがキープアライブ設定有効になっていたら > ずっと Sorry サーバに繋がっちゃうんじゃね？ > 動的に切り替わるなら、その辺も救済されるからそっちの方が > いいんじゃないの？といった意見もいただきました。 > Sorry サーバを使うときは Sorry サーバのキープアライブ無効を > 推奨という手もありますが、なんかそれはそれで微妙な > 感じもします。 sorryサーバのkeep aliveがenableと言うのも微妙な気がします。 keep alive自体がTCPネゴシエーションに時間かかるから接続したままにしよう と言う発想ですから、sorryがkeep alive有効でTCPコネクションを張り続ける メリットは無いのではないでしょうか? 通常、sorryと言うのは「ごめんなさい」表示をするだけですし。 どうぞよろしくお願いします。