【２ちゃんねるビューア】　巡回機能の巻。Part3

おはようございます。
今日は夜勤さん、テスト鯖拡大するのでしょうか？

>>640
一応その件は板違い、というか・・・・

>>637
参加しますた。

２ちゃんねるビューアの技術的な負荷軽減策を話しています。

【２ちゃんねるビューア】　巡回機能の巻。Part3
http://pc.2ch.net/test/read.cgi/software/1016905060/l50


bbs.cgiまわりの件はこちらです

★ bbs.cgi軽量化開発コンペ ★
http://qb.2ch.net/test/read.cgi/jikken/1017071166/l50


圧縮の件はこちらで

圧縮要望スレッド
http://kaba.2ch.net/test/read.cgi/accuse/1016705143/l50


運営関係の話はこちらです。

「monazillaツールと課金及び転送量・鯖負荷問題を考えるスレ」
http://kaba.2ch.net/test/read.cgi/accuse/1016974669/l50


こんなスレッドもあります。

monazilla Part 3
http://pc.2ch.net/test/read.cgi/tech/1012544484/l50
dat->html化自動処理プログラムをつくるスレ
http://pc.2ch.net/test/read.cgi/tech/1012310594/l50
read.cgi改良スレッド 3
http://pc.2ch.net/test/read.cgi/tech/1002820903/l50

>>649
予定なし〜
ちょっと、お出かけしようかと、

>>653
了解です〜。
では私はbbs.cgi開発の方に注目いたします〜
おきをつけて

各２ちゃんねるツールの仕様比較はこちら。

乱立する2ch用ブラウザの比較 Part3
http://pc.2ch.net/test/read.cgi/software/1015928913/l50

現状は・・・
>>154-163
あたりです。

現状、テストの成果としては、
>>582
>>589

というところです。

>>650　>>641ｗ

夜勤★がいるのはここか？

めちゃくちゃすんなや！
半角二次元で稼働中のスレをいっぱい落としちまいやがって。
板最古スレもこれで落ちた。保守sageしてたのに。。
規定どおりの仕事しろよ！　泣くに泣けんのだぞこっちはYO!

異論（議論の余地）有り
Ａ．monazillaはデフォルトでは巡回等に規制をかける。
Ｂ．ログインした場合のみ巡回等の規制なし。
Ｃ．ツールにお知らせ機能（仕様変更等の）を追加。
Ｄ．ツール側で巡回、更新チェック以外の機能を●もちと●無しで差別する。
Ｅ．２ｃｈ側で●もちと●無しで差別する。

Ａ．については各ツールの最新版では鯖負荷を抑える機能を実装済みが多い（kage等）
　　また、効果があった模様。
Ｂ．については有料ユーザの優遇策は実施されていないツールが多い。
Ｃ．は今回のことのようにツールをはじくような改造があった場合に各ツールにお知らせ
　　機能があれば便利→そんなに頻繁ではないので、各ツールスレをみてもらえばＯＫかも？
Ｄ．ツール側での差別化はそうなってﾎｽｨが、それは各ツールの作者さんに任せる。
Ｅ．についてはアイデアは出ている（スレ立て規制無し（緩和？一日５スレまでとか）

Ａ．の目安は（今のところ、これを基準に各作者さんに実装してもらう？）
　巡回：datをとってくる：スレ取得後にスレ数×２０秒のインターバル
　更新チェック：ゾヌ方式（datから）：スレ数×４秒のインターバル
　更新チェック：abone方式（subject.xtから）：板数×５秒のインターバル（.gzは行わない？）
スレごとのウェイトはダイヤルアップユーザの為に避けて、巡回、更新チェックはまとめてあ
とで行う

結局問題の本質は鯖負荷等の費用と収入の問題。
α：鯖負荷等の軽減策＋β：収入増加策を考える必要有り。

>>659
なのですが、これ今まだたたき台を作ってるという感じ、のようなのですが、
作者さん達の現時点での見解とかご提案とかアドバイスとか、そんな感じの
お話をいただければ、と思いますです。

私自身の個人的な感想や見解はじゃまになるそうですので・・・
お願いできましたらお願いいたします＞ツール作者各位さま

昨日の二次板の一件で殆ど眠れず、嫌な夢を見、発熱しました。
これは立派な対人攻撃だと思いますが。

>>夜勤

本質的なところで、Ａの目安に挙げられている インターバルの時間について。

これらの数値は、当然対象サーバごとに持つ数字だよね。
pc.2ch.netとcomic.2ch.netと両方にアクセスする場合
それぞれへのアクセス時間について4秒なり20秒なりの
インターバルを持て、ということだよね？

数値そのものについての議論はとりあえず置いとくとして。

>>659
「monazillaツールと課金及び転送量・鯖負荷問題を考えるスレ」
http://kaba.2ch.net/test/read.cgi/accuse/1016974669/542-543

↑全文はこちらにあります。

で、これは向うで言うべきことかもしれないが 一応こっちでも言っておくと

●持ち、●なし の差別化 は 「サーバ側で行う」 のが筋だと考える。
ツール側でどうにでもできることなら、少なくとも私ならクラックします。
（例えばインターバルとかね）

サーバサイドの技術話になるからこっちでいいか。

たぶん　仕組みがわかっていないと思う >>664

>>665
いや、一応ひととおり読んだり試したりしてるから多分わかってると思う。
（つもりかもしれないけど）
だからなおのこと気になるんだよね。それで規制できんのかなって。

>>656
いくらなんでも>>589の発言はド素人だと思うんですが、
夜勤さんってUNIXの分かる技術者ではないんですか?

別に揶揄してるとかじゃなくてね。表現悪くてごめん。
要するにド素人であることが悪いということではなくて...

>>667
どうして　そう思うの?
あなたの実験結果の感想とかは?

>>662
まだ、その辺の話はしてません。

>>664
ログインした時のみ差別化されると、通常は巡回を鯖側ではじくと、
で、ログインしてる場合はスルーさせると、、、そういう意味です。
で、ツール側にはそれが可能な仕様を追加してもらうと、、、

１．デフォルトで制限をかけたツールのみ鯖側で受け入れる
２．その中でログインした場合のみ巡回制限をなくすと

クラックする人数が問題なのよね。
例えば、６０万人中６００人くらいだったら無視できる数字じゃないかとか・・・。

規制の数値を矢鱈とハードにするな（別途受け口がある場合は別。逆にハード
にして、その次善の受け口に誘導することは十分考えうる）ってのは、
クラックまでする強烈な不満をもつ人間が増えすぎて
例えば１０万人以上がクラックしますた、とかになると不味いからで
逆にはみ出す奴を1％以下に押さえられる程度の規制なら
規制としては十分成功かと。

要は、多数を占めるフツーの人が標的ですからね。
積極的にクラックするような人の存在は、ある意味一定の確率での必然で、
仮にそいつが無視できないほどヘビーな奴だとしても、
フツーの人の規制が成功しているのならば、規制の一般論を考え直すよりも
単に個別に狙い撃ちの規制を別途考えるのが賢明かと。

だから、フツーの人を生かさず殺さずに治める規制の数値は
どこなのかがむしろ問題ではないかな。
こりゃまさしく政治だねｗ

A Boneの委員長です。
A.についてですが、現在はまだ叩き台との断りがあるので
細部について問うのは早計なのかもしれませんが、一応
疑問点を書いておきますね。

[各方式のインターバルの取り方について]
確かホットゾヌが選択式になってたように記憶してますが、
このインターバルは後で纏めて取る方式でも良いのだろうか？
dat取り巡回で20秒のインターバルとのことですが、
10スレッド分を一気に取ってしまい、次の巡回を200秒後にしか
出来ない仕様というのも、レギュレーション違反とならないのか？
この方法でもOKならば、通常の使用目的ではそれ程不便でも
ないように思いますが、20秒毎に1スレッドを取得する以外は
ダメだと、心情的にはツライですねぇ。
要は1分で巡回を終えてオフライン読みにして、オフライン中に
インターバルを払いたいんですよね、出来れば。
ただ、「一気に取るのがマズイんだ」という意見もあったと思うので
不可かな？(^-^;
これは開発的にではなく、使い勝手的な問題ね。

[更新チェックと巡回を併用の場合]
このdat取り巡回20秒は、従来のかちゅ〜しゃのように、更新されて
ようと、されてなかろうと関係なしにdat取りをトライする場合を想定
しているのかな？
更新チェックと巡回を併用するのであれば、無用の不可をかけていない
という理屈もあるので、その場合もう少し緩和されるのだろうか？

以上2点が現時点の疑問で、私の個人的な要望としては、
インターバルの後払いOK、更新チェックと巡回の併用の場合
更新チェックのインターバルのみ払えばOKという感じです。
「これが正しい」という主張ではなく、「こうだったら嬉しいなぁ」
という意味で取って下さいませ。
長文すません。

そういえば倉庫のスレを並べ替えて鯖負荷を減らすように努力する
(要するに同じ鯖に連続でアクセスしないように配置する)
って言ってたかちゅユーザがいたけどツール側で再配置すればいいかな。
ダイアルアップユーザの人権が守られてインターバルがまとめでいいみたいだから
頑張ろうって気にもなるし。

>>672
あーそれおれだ。

>>668
> どうして　そう思うの?
CPU1つ(?、まあ2つでも変わんないね))のPCサーバーの
LAが100から50になって負荷が下がったと思うUNIXの
分かる技術者は一人もいませんから、理由は特に述べません。
解説すると長くなるし。

> あなたの実験結果の感想とかは?
データが少なすぎです。
vmstat iostat netstatと
httpのレスポンスタイムくらい見ないとなんとも。

で、別に夜勤さんを非難してるわけじゃなくてね。
もし分かんないんだったらやり方考えたほうが...
と思ってるだけ。

>>647
100 とか 50 とかを　load ave の数値と思っているのは貴方だけという罠。

夜勤★、マジでいい加減にしろよ！
虹板の大事に育ててきたスレッドが全部逝っちまったじゃねーか！

UZEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE
EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE
EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE
EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE
EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE
EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE
EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE
EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE
EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE!!

>>676
人の敷地内で店開いて、所有者に怒られたらあんたは文句言うんですか？
逝ってよしですな。自分の敷地で店開いてください（自分の鯖で板立ててって
ことね）

>>677
(ﾟДﾟ)ﾊｧ?
バカの方ですか？

>675の誤爆さん、じゃあ何の数値ですか?

あんましスレ汚したくないから、これで終わり。

>>678
自分で鯖立てて、自分で管理しろ。消されなくて済むぞ。出来ないなら
おとなしくしてろ。

>>677
じゃあ、あなたはレストランで鞄を置き引きされても
何も文句言わないんですね。

バカは逝ってよし。

>>680
氏ね

>>680
何言ってんの？

>>680
（　´_ゝ`）ﾌｰﾝ

680必死だな（藁

>677はバカだが、>676の抗議はクレームを出す先が違うので>652を見てくだちい。

>>679
10 5 0.1 じゃわかりにくいか、

1,000 500 10
10,000 5,000 100

でもいいんじゃない　きっと　

>>680
頭悪いんならこういう議論に参加するなよ

あ〜あ、終わりたいんだけどな
>>681
次元が違う。
レストランで鞄を置き引き→鞄は自分の所有物
２ｃｈへの書き込み→書き込んだ時点で２ｃｈの所有
DQN春房はカエレ

>>672
インターバルはまとめて、というのは、いつ入ったんでしょね？
驚きました。いみねー。

もうどうでもいいや。そもそもスレと全然関係ないし。勝手に盛り上がってクレ。

>>689
必死だね

クレームを出しても失ったものは戻らないという罠。
過去を顧みず明日を夢見て生きれ。

>>689
著作権って知ってるか？
俺の書き込みは俺の物らしいぞ。
関係無い話っぽいけど。

>>689
春厨はアナタ！

>>689
逝ってよしですな・・・

なんか話にならない・・・
レベルが低すぎて・・・

>>693
禿道。

イタい６８９がいるスレ

>>676-682 ここでやってくれ。開発の邪魔はしちゃいかん。

圧縮要望スレッド
http://kaba.2ch.net/test/read.cgi/accuse/1016705143/l50

>>681　その鞄は、実は自分の鞄（所有物）ではないという罠。

>>670
そんな考え方を私も持ってます。

>>671
>[各方式のインターバルの取り方について]
>確かホットゾヌが選択式になってたように記憶してますが、
>このインターバルは後で纏めて取る方式でも良いのだろうか？

いいと思います。ダイヤルアップユーザのオフライン読みのためにも。

>要は1分で巡回を終えてオフライン読みにして、オフライン中に
>インターバルを払いたいんですよね、出来れば。
>ただ、「一気に取るのがマズイんだ」という意見もあったと思うので
>不可かな？(^-^;
>これは開発的にではなく、使い勝手的な問題ね。

マスで考えれば、実はそんなに1スレごとでもまとめてでも
あんまり変わらない気がします。
ゾヌのように選択式になれば一番良いかと。。。
それは各作者さんが考える問題か。。。。

>[更新チェックと巡回を併用の場合]
>このdat取り巡回20秒は、従来のかちゅ〜しゃのように、更新されて
>ようと、されてなかろうと関係なしにdat取りをトライする場合を想定
>しているのかな？
>更新チェックと巡回を併用するのであれば、無用の不可をかけていない
>という理屈もあるので、その場合もう少し緩和されるのだろうか？

１．従来かちゅ：とにかくdat取得
２．本来の巡回：更新チェック後、更新のあったスレのdat取得
３．更新チェック：更新チェックのみ（ゾヌ方式、abone方式）

１．は言うまでもなく規制の対象とすべきですね。というか禁止かな？（●もち含む）
２．はそれでも負荷は大きいので規制は必要かと←これを想定してます。
３．は前に書いたとおりです。

ツール作者さま。
「monazillaツールと課金及び転送量・鯖負荷問題を考えるスレ」
http://kaba.2ch.net/test/read.cgi/accuse/1016974669/542-543

なのですが、これ今まだたたき台を作ってるという感じなのですが、
作者さん達の現時点での見解とかご提案とかアドバイスとか、そんな感じの
お話をいただければ、と思いますです。

現在いただいているコメントです。。

委員長さん→>>671
西安さん　→>>672

>>687
俺は load average だと思ってる。
>687は「100 が 50 になっても、負荷が高いことには変わりない」
ってことが言いたいんだよね?

>>702
違うって、「先はなが〜〜〜いのう」ということを言いたいんだって。

>>690
ダイヤルアップユーザ対策のためです。
で、マスで考えれば個々が１dat取得ごとにインターバル入れなくても
トータルでは分散化するのではないかと。。。

この辺の話は、批判要望の方がいいと思うので、そちらで、、、
委員長さん、批判要望の方にも来てくださいね。

>>703
ヽ(｀д´)ﾉﾅｴｻｹﾞ!

>>700
本当にそれでいいんですかね＞インターバル。
いっぺんに、ががーっと来るのを回避したくてこんなお話ししているんですよ？
んじゃ、セッションもいっぺんに何本でも張ってよし、ですか？
あとでインターバル取れば。

いま考えましょうよ、っていっているのは、「理屈上こうなればいいんでしょ？」
なんてお話じゃなくて
「お財布に限度があるサーバの上に載っかってるサービスなんだから、
　知恵と工夫で乗り切りましょうよ」
ってお話なんじゃないかとおもてました。
その観点で、理想的な方式を「ツール作者さん達にお願い」するための
たたき台を作ってるんですよね？
私の認識だと、そんな感じなんですけど、どうなんでしょね？

ああ鬱陶しい。関係ない話でスレを流すなボケ。
叩いてる奴も689も同じだ。
掲示板への書き込みに著作権を主張するのも間違い。

投稿確認
・投稿された内容はコピー、保存、引用、転載等される場合があります。
・投稿に関して発生する責任は全て投稿者に帰します。

これ読んだことある？>>693

>703 夜勤さん、>702だって「先はなが〜〜〜いのう」ということを言いたいんですよ。

百歩が五十歩になったと。

これだけ　みんなの労力、時間を費やして
100 が 50 になった、50 も減った、半分になった訳だけど、
目標はまだまだ先で、到底たどり着かないんじゃないかなぁ　ふぅー
と言いたいのよ。同じ労力をかけても次は 50 -> 25 な訳で
その次は 25 -> 12.5 -> 6.25 -> 3.125 となるのが常でしょ?
1 が目的だとしたら　ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ

>>704
ダイアルアップユーザにインターバル入れるのはおかしくないですか？
ダイアルアップのユーザは、すぽんと取って回線切って欲しいわけですよ。
(ソフト上でインターバル入れられたらそれはまずいんじゃないかと)
んで、その代わり、●買って下さいよ、って話じゃないんでしょうか？

＞この辺の話は、批判要望の方がいいと思うので、そちらで、、、
＞委員長さん、批判要望の方にも来てくださいね。

え？

>>709
ヽ(｀д´)ﾉﾅｴｻｹﾞ!

>>710

ちょっと、話こんがらがっているので（ｉｎ　ｍｙ　ｈｅａｄ）
あっちのスレにまとめて書いておきます。

>>704
まとめ取り方式ならすぱっと取った後にどれだけ課せられようがまず関係ない。
だから全然おかしくない。
つーか、●前提の話しかしないね、マジに。
すでに管理者サイド？

>713 まとめ取りというのは特殊な動作なんだから課金前提でいいんでないの。

>>713
いや、私は「まとめてとる」推進派なのですが。。。

夜勤 ★殿
半角二次元のスレでアップしようとしたスレを落とさないでくれますか？
昨日と日中まで有ったものが突然無くなるなんて止めてください。
確認をしてから落として欲しいですね。
半角二次元の処女喪失の画像スレだったかな、確か。
おかげで再度スレあげる事になるじゃないですか。
今度からきおつけてくださいね。お願いしますね。

>>715
自己レス、
「まとめてとってあとでドカンとインターバル」推進派でした。

インターバルの議論は批判要望板のすれの方で議論したいのですが、。。。

>>715
違った。
>>713 の >>704 は >>710 の間違え。

私が想像していた感じを書きます。

１　更新チェック
スレッドに新しい書き込みなんかがでているかどうかのチェックはsubject.txtで行う
各datの確認ごとにdatに対してセッション張らない分サーバに優しい

２　巡回チェック
●ユーザで、ダイアルアップ環境のユーザのために提供するようにしたい
お気に入り登録されたスレッドのdatを一括して獲得して、回線断する
それ以外の巡回チェックは、サーバの負荷とかを考えて、サーバに優しい方式を
考案してやっていきたい・・・インターバルとか・・・

３　subject.txtやdatの場所を変える
クラッキングツールとか、自作ツール系で手軽なアクセスが出来ないように、
掲示板としては本来隠れたデータであるべき(ブラウザから見える必要のない)
これらのデータは、極力ユーザから見えない場所にしまうようにする。
で、ツール作者さんには、たとえば、Monazillaに参加されている方に
情報としてお伝えしたり、アクセス方法をお知らせしたり・・・とか。

４　read.cgiベースのrawモードの使用中止
去年８月の段階で、回線帯域使用量の圧縮のために取り組まれたrawモードなどは、
今後、サーバ負荷軽減のために、別の方式に切り替えていく。
転送量とサーバ負荷とのトレードオフの綱引きが続きそう・・・

５　bbs.cgiなど、cgiやサーバの見直し
bbs.cgiやread.cgiの負荷を削れるだけ削りたいな・・・と。

なんか認識間違ってますでしょか？

>>682
>>683
>>684
>>685
>>692
>>694
>>695
>>696
>>697
気持ち悪い

>>658
アニオタはキモイ

>>720
誰、君？

>>713
巡回機能を許すんだったら、●購入した人って感じにしようよ、
って話の流れだと思ってましたが・・・・
いやべつに私なんの権限もないですよ。管理もなにも。
そんなことより、●無しの人にもダイアルアップ機能ありでいくって
感じになってきてるんですか？＞西安さん
それだったら認識改めますです。おっす。

>>722
確かに私の目にも、巡回機能を許すんだったら、
●購入した人って感じにしようよ、
って話の流れには見えてました
だからこそ寝る間も惜しんで UCK を更新してるし、反対活動もしてるわけですが。
なんか、目的毎に分割したつもりが逆に混同を招いてるような気がしますね。
悩ましいことです。

短時間の負荷がきついってのは、ユーザー総体からのコールが厳しいという
話だから、各ユーザーにまとめてインターバル（といっても個別にウェイトかける
ことを直ちに否定する話にもならないと思うけど）でも、ユーザー総体では分散
つーことになりえないかねぇ？

そりゃ、各ユーザーレベルで分散すれば総体でも分散になるであろうことは
容易に想像できるけど。

質問。どっちがサーバに優しいのかな。

巡回もしくは更新チェックをする際、一つのサーバに複数のリクエストを出すとき、
・Keep-Alive の時間を超えるインターバルを取って、一回ごとに接続・切断を繰り返す。
・Keep-Alive の時間を越えない範囲でインターバルを取る。

>>725
とっとと切断。
他の人のこと考えましょう。

>>723
巡回機能＝一括してどかどかdatとりまくる
更新チェック＝理想的には個別にdatに触らずsubject.txtなどでスレッドの状況を確認する

ということであれば、「巡回機能」は●買ってもらおうよ、という風にいってくれればいいな、
受益者負担って感じだよな、って話だったと思います。
更新チェックと巡回は、上の認識が前提条件で、このスレッドは進行していたはずです。

「monazillaツールと課金及び転送量・鯖負荷問題を考えるスレ」
http://kaba.2ch.net/test/read.cgi/accuse/1016974669/528-529

昨日までは↑のスレは↑みたいな感じの議論のような気がしましたがｗ

>719 (3)についてはhttpを使う以上無意味でないですか。tcpdumpでｲﾊﾟｰﾂ

つーか、ダイアルアップユーザは制限からテレホじゃない時間帯は余り出没しないのよね。
故に時間帯によっては常時接続な人しかいないわけだから、
ダイアルアップを無視した方向に話が進み易いと思うのよね。
その点について少しでも気に掛けてくれるとうれしいです。

同床異夢のようで。

お知らせ の類はサーバをわけたら？

>>729
たとえば３についてですが、Monazillaに参加している方の申告で、ツール単位に
Basic認証発行して・・・・という感じで、一つの方法は考えられると思うんですけど、
tcpdumpとかリバースしてリソース拾ったりする分については、
それは仕方ないのではないかということなんですよね。
もちろん、厳密にいえば通信法の適用範囲でもありますし・・・・

これは暴論で妄想なんですけど、
４／１はエイプリールフールでもありますんで、丸一日、すべてのdatとsubject.txt
隠しちゃって、全員Web使ってみて、負荷がどう推移するかとか、データ取りできませんかね？

ユーザとしての私個人は「冗談蛇ねえ・不便でしょうがない！」て思いますけど、
この問題ながめさせてもらってるところから見ると、負荷の実体というか、
手がかりがこういう実験で見えないかなぁ？
って気もします。

あんまし意味のないデータですかねぇ。

ツール作者さま。
「monazillaツールと課金及び転送量・鯖負荷問題を考えるスレ」
http://kaba.2ch.net/test/read.cgi/accuse/1016974669/542-543

なのですが、これ今まだたたき台を作ってるという感じなのですが、
作者さん達の現時点での見解とかご提案とかアドバイスとか、そんな感じの
お話をいただければ、と思いますです。

現在いただいているコメントです。。

委員長さん→>>671
西安さん　→>>672

>>734
4/1 だけってわかってるならその日は寝ておしまいだが(苦笑)
問題はどうなってんだｺﾞﾙｧという書き込みの群れで逆に通常より負荷が高くなったり(笑)

常時接続ユーザーがダイアルアップ用巡回を使えないようにできるわけ？

ダイアルアップユーザ専用のログゲットソフトを別に作れば
（ログの形式は各ビューワの形式にあわせられるようにする）
ダイアルアップユーザはそれを使って一日に数回まとめて
ダウンロードすることが可能になるな。
で、既存のビューワは全て「巡回」機能は廃止する。
(更新チェックのみ残す）

>>738
いや、確かにそれで良いんだが、それは誰が書くんだい？

>>739
それによって困る人

>>740
・・・・・。

>>741
いい機会だと思うんだよね。
この機に、作者チームが集まって
ログ取得とか更新チェックとかそのたもろもろの
ライブラリを作っておく ってのも。
2ch.dllってわけじゃないけど。

>>737
問題は「頻繁な巡回」なので、ダイヤルアップ、常時接続関係なく
「頻繁な巡回」を規制する方向で考えてます。
常時接続でも巡回後は一定時間のインターバルをおかないと、再度巡回できない。
っといった感じです。

お話は批判要望板のスレのほうがいいかも。政治的な問題なので。。。

>>743
いやなんでさっきからこっちの話あっちに誘導するの？いいけど(笑)

>733 datはともかく、subject.txtを隠すのって意味あるんですか?
subback.htmlから等価なものが作れるのに。

>>744
あれだけの混乱っぷりを見せた俺としては一つの方がありがたかったりも(笑)

>>745
全く無意味ですよ。
まあ、攻撃ツールが１日ほど使えなくなるくらいじゃないすか？

>>744
いや、こっちはもっと専門的な技術を議論して頂いて、政治的な、
野次が飛び交うようなのはあっちのほうが、ここに迷惑をかけないかと。
賛成・反対が出そうな政治的議論はあっちの方が良いかと。
こっちは技術のbetterとmore　betterの議論をしていただければと。。。

>>745
subbackは、いくらでも名前変えちゃえるそうです。夜勤さん曰く。
既出です。

>>747
ああ、攻撃ツール利用者の切り分けとかに使えそうですね。
subback要求があったらそれは攻撃ツールだ、という感じで・・・

つまり、今みんな一生懸命実装している更新チェックも
当然やりにくく（場合によっては全く出来なく）なるわけだ。

ま、そうしたら攻撃方法かえるだけだよな。
攻撃側だって、なにも上から順番に落書きしたいわけじゃないしさ。

>>749
でも subback へリンクを張ってるところはそう簡単に変えられないよね？
もし、そこが変えれるとしてもどんどん上にさかのぼって変えられないところがどこか出るはず。
そうすると最終的にはなんとかされちゃうかも。
もちろんその前に向こうがやる気をなくす可能性もあるけど。

攻撃側の人間としての仮想人格を作って話してもいい？
その方がうまく話ができそう。

>>752
置換一発で終了のような気がしませんか？

>>753
ああ、どぞどぞ。
ただ私管理側の知識ないので、おながいします。

もっかい質問
そのダイアルアップユーザ専用のログゲットソフトとやらを
常時接続ユーザーが頻繁に使い倒すのを阻止できるの？

>>756
無理。絶対使う。バンバン使う。

>>754
その気になれば 2ch.net のルートからオートパイロットで追えるような。
もちろんインテリジェントに書くのはすっげー難しいけど、あんまり頻繁に変動するとブラウザユーザにも被害が出るからどっこいどっこい。
もちろん、そういう手法では守り手側のほうが有利だけど、必要部分を人間に置き換えることも可能だし。
完全に動的生成にするとツール側はほぼ敗北必死だけどサーバ負荷が増す罠。
そしてアタッカーは何事もなかったように別の手法に切り替え(苦笑)

一言で表現すると　いたちごっこ

批判要望の方に提案文書のドラフトかいてみたです。
ご一読お願いします。

>>756
それは作者さんがどんな感じで実装するか次第だと思うんですよ。
あと、自力でハックできるようなひとって、この際考慮するのは
コーディング時というか、そういうときまでおいといて、っていうと
あれでしょうか？

>>756
巡回がエラーで止まるとかいったことを考慮しなければ、
ダイアルアップから切断までを含めてツール化すれば常時接続側は難しいかも。
でも、俺もそこら辺はそんなに知識があるわけではない。

今思ったんだけど、ダイアルアップユーザだけを確実に認識する
方法があるね。ちょっと時間（とお金）がかかるけど。

>>760
まあ、もちろん最悪論的な見方なので実際にどうかは別です。
ただ、そこまでするアタッカーが本当に出てしまった場合は不便になっただけという罠って話です。
だから、実際にはなんともいえまへん。

>>762
それだと、ダイヤルアップユーザの優遇策になるのでは、、、
常時接続もダイヤルアップも同様にするほうが良いのでないかと、、、
それにいまのところの意見では、常時接続を冷遇する必要はないのではないかと。

ぎじゅつでない常時接続vsダイヤルアップ的な政治的な話になりそうでしたら、
あっちのすれに移動してくださいです。

>>764
一見優遇に見えるのかもしれないけど、実情として更新チェックだけされてれば常接は困らない気も。
まあDAT落ちが激しい板とかもあるかあ・・・。

ダイアルアップユーザはまずほとんどグローバルIPってところ。
プロバイダに割り当てられた範囲内のIPアドレスを配っているから
その範囲を調査すればネットワークアドレスで切り分け可能かな。
当然串は弾く。これは現状の規制とほぼ同じ扱いでいける。

問題は調査にかかる時間とお金。あまり現実的じゃないね。
このへんは政治的な話だけど。

前提条件として

１）ダイアルアップで従量制だったりすると、課金辛い
２）一瞬でも早く回線断したい
３）あちこちうろうろするより、さっと取ってぷちっと切ってオフラインで読みたい

てのがあって、ダイアルアップ用巡回、って発想があると思うんですよ。
常駐しないというか、お祭り参加しないというか、リロードしないというか、なんというか。

>>Basic認証発行して
Basic認証ってパスワード垂れ流すものっていうことは知っていますか？

それに、navi2chや2ch-mode他、原理的にソースを隠すことが不可能な
ツールがあることを認識してください。

だからダイアルアップだとしても、テレホーダイとかだったら
扱い違うと思うんですよね。もう当然の話なんですけどね。
そのへん、巡回の実装でたぶん、考えないといけないと思うんですよ。
ひろゆ子のいうとおり、クラックパッチ一発で何とかなっちゃうにしてもしなくても。

>>768
はい、しってます。
でも、ぎそうするとつうしんほういはんにはなります。

>>733 datはともかく、subject.txtを隠すのって意味あるんですか?
>subback.htmlから等価なものが作れるのに。

全く意味ないと思います。それより、混雑サーバの混雑時間帯はDATへの
直アクセスを一切遮断し、●持ちの人だけread.cgi経由でDAT取得可能、
とかやった方がいいのでは。

>>771
subbackがいまの位置に今の通りに今後もあるとは限らないです。

>>760
どっちかといえばクラックしなくっても
使い方を工夫すればチェックを誤魔化せるんじゃないかという気が
するんですよ
簡単なら口コミですぐ広まっちゃうでしょ
規制関係は性悪説で考えないとバカ見そう

>巡回機能＝一括してどかどかdatとりまくる
>更新チェック＝理想的には個別にdatに触らずsubject.txtなどでスレッドの状況を確認する

If-Modified-Sinceで更新が無かった場合はDATには触りません。statかけるだけ。
subject.txt の大きさの問題、アクセスがsubject.txtに集中することのI/O負担、
なども考慮する必要があります。

subject.txtを転送させて空振りする(304)リクエストを減らすことと、
subject.txtを転送させずに空振りするリクエストを許容することは
注意しないとその負荷(CPU/Disk/Network)はすぐ逆転します。

>>772
つまり、更新チェック機能も否定するということになるね・・・いや〜ん

規制するのはあれか、巡回機能を悪用するヤツを閉め出すため？
それとも、鯖の負荷を低く抑えるため？
てっきり後者だと思いこんでいたのだけど、
どうも両方を目的にしているっぽい。

どちらか一方に絞らないと無理。

２ちゃんねるの転送量が増大し、運営費を圧迫している(昨年８月の問題以降)
これに対応するべく、read.cgiでのgzip圧縮やMonazilla（２ちゃん閲覧ツール作者さんの集まり）
が開発するツールなどで、様々に工夫をしていた
そうこうするうち、転送量の圧縮は出来ているが、今度はサーバの負荷が増大して、
運営に支障があるレベルになってしまった（今回の問題）

対策のため、現在choco、love、vip、gameなどで、これまで許可してきたツールでの閲覧や書き込みの
方式を変更した。変更は以下の通り。

●dat、subject.txtの取得=>Monazillaツール（但しkageは0.99.1以降）でのみ取得できる。
●bbs.cgi=>kage 0.99.1未満をはじく。
●read.cgi=>Monazillaツールをはじく。

>>772
板のトップページをパースすればすぐ分かります。フォーマットが変わっても
解析なんて簡単です。他の部分を作る方が大変。

この変更によって影響がでる可能性のあるツールは、以下の通り
現在も影響があるツール：

●MapleSyrup Ver.0.05g (read.cgiを使っているためレス取得不可)
●ぎこはにゃ〜ん　0.22.04 (read.cgiを使っているためレス取得不可)
●Hikky 02/01/22 版 (read.cgiを使っているため新着レス差分取得不可)
●Gickoブラウザ改良版 スレリスト取得不可(read.cgi使用)

影響があったが、バージョンアップにて対応可能なもの：

●A Bone Ver.1.23 (V1.23bで対応)
●かちゅ〜しゃ+kage (Ver.0.99.1.2で対応済)
●ホットゾヌVer.1.0 β2.1.4以下でスレリストを取得できない (β2.1.5で対応済)
●えまのん (3/24版で暫定対応、ただし差分DAT転送に対応していないので要注意)
●マカー用。エレメンツ (Ver0.992β で暫定対応)
●jane 低速回線・ダイアルアップ設定でレス取得不可 (高速回線設定に変更すればok)
●navi2ch (read.cgiを使わない設定にすればok)

なお、この負荷低減実験は、今後順次、ほかのサーバに拡大していく予定。

※上記以外のツールの情報をお持ちの方は、
　【２ちゃんねるビューア】　巡回機能の巻。Part3
　http://pc.2ch.net/test/read.cgi/software/1016905060/l50
までお知らせ下さい。

>>779
ぎこはにゃーんもHikkyも既に対応版出てるよ

>>778
全体の問題と、そういうスキルがある人一人一人にまで意識してサイトを構成するか、
というのは、コスト意識のバランスなんだと思うんです。
今ここでやっていることの、目的はなんなのか？
っていうことに尽きると思います

>>780
次スレのテンプレートに使いたいので、教えていただけるとありがたいです・・・・

>>782
monazilla.org みなよ

>>783
お前が調べて書けよ、って感じっすか？

素朴な疑問
なぜにそこまで従量制にやさしいってなことを重視しますか？
別に従量制で余計な金がかかっても知ったこっちゃないじゃないですか。
言葉は物凄く悪いですけど。
それでも2chを利用したければその人の勝手じゃないですか。
便利に使いたければそれ相応の金を出すってのがすじってもんじゃないですか。
それが2chにであれ、プロバイダにであれ。
やっぱ巡回なんて金出さなきゃ使えないようにするのがいいじゃないですか。

しろゆきも言ってるように。

>>781
言いたいことは、subject.txt を隠したところでその意味は限りなく薄いということ。
それよりは、もっと現実的かつシンプルな提案として >>771 を書いたのです。

>>785
俺が従量制でできるだけ金を払いたくないから。
そしてそういう人が他にもいるから。
そういう話は対象を置き換えていくときりがない。

>>786
＞言いたいことは、subject.txt を隠したところでその意味は限りなく薄いということ。

私そうは（限りなく意味が薄い）思わないんですけど。

それに、subject.txt隠したいというのは、転送量とか負荷の問題以外のところからも
あがってきているようですよ。要望として。

>>784
影響があったが、バージョンアップにて対応可能なもの： (追加
●Hikky (02/03/26AMup版で対応済)
●ぎこはにゃ〜ん (0.23.03 で対応済)

あと、Mac用ツールはどうなってんだろう、
・iTteyoshi
・マクモエ
・Ahyazilla
・Fuuun
・CocoMonar

ていうか、サイト設計として、datやsubject.txtやSETTING.TXTっていうものは、
一般ユーザが容易に接触できるところにおいてあるべきものかという話も、
どこかにあってしかるべきじゃないでしょうか？

これは、純粋に私の私感なんですけどね。

想定する近未来：
・「串制限中」などと同じように「ツール制限中」などの言葉が普通に使われるようになる。
・●持ちの人は、串制限が緩和されるように、ツール制限も緩和される。
・「2ちゃんねるを便利に見たい場合はコレ！」「混雑時間帯でもスイスイ巡回。面倒な操作は不要」

>>789
ありがとうございますです

>>790
腹が腹痛、私の私感(ぼそっ

>>791
ｶﾞｸｶﾞｸ(((((((( ；ﾟДﾟ)))))))ﾌﾞﾙﾌﾞﾙ

>>791さんは、転送量の問題と、サーバの負荷の問題は、
どうやって解決するべきだと思ってらっしゃいますか？

>>776
鯖の負荷を低く抑えるためには、やたらめったら巡回する人たちを
どうにかするのが近道なんじゃないの？

まあいいや、みんなあんまり興味ないみたいだから
この話はやめる　お邪魔さま

この変更によって影響がでる可能性のあるツールは、以下の通り
現在も影響があるツール：

●MapleSyrup Ver.0.05g (read.cgiを使っているためレス取得不可)
●Gickoブラウザ改良版 スレリスト取得不可(read.cgi使用)

影響があったが、バージョンアップにて対応可能なツール：

●A Bone Ver.1.23 (V1.23bで対応)
●かちゅ〜しゃ+kage (Ver.0.99.1.2で対応済)
●ホットゾヌVer.1.0 β2.1.4以下でスレリストを取得できない (β2.1.5で対応済)
●えまのん (3/24版で暫定対応、ただし差分DAT転送に対応していないので要注意)
●マカー用。エレメンツ (Ver0.992β で暫定対応)
●jane 低速回線・ダイアルアップ設定でレス取得不可 (高速回線設定に変更すればok)
●navi2ch (read.cgiを使わない設定にすればok)
●Hikky (02/03/26AMup版で対応済)
●ぎこはにゃ〜ん (0.23.03 で対応済)

なお、この負荷低減実験は、今後順次、ほかのサーバに拡大していく予定。

※上記以外のツールの情報をお持ちの方は、
　【２ちゃんねるビューア】　巡回機能の巻。Part3
　http://pc.2ch.net/test/read.cgi/software/1016905060/l50
までお知らせ下さい。

日本国全てで常時接続が実現してないのが現況のようなので。

規制して数を減らす、という政治的な話ばっかりだな。
httpd.conf触らしてもらえるようにするとか、そっちの話のほうが
てっとりばやくて効果絶大なんだけど、それは
政治的な話なのかい？それとも技術的な話なのかい？

>>795
巡回・更新チェックといった見方ではなく、ツールによるDATへのアクセスを
一旦すべて遮断した上で、●持ちの優遇策を取る。

●持ちの人の絶対数は将来に渡っても○の人より少ないわけだから、
read.cgiでsidを判定した上でのDAT転送といった、重めの処理も許容できると考える。

ここでのポイントは、すべて鯖側でアクセス可否が判断されるということ。
UAを偽装しようが、クライアントのソースを書き換えようが、有償ID/PASSを
盗まない限りはどうしようも無い。

また、一律全サーバ・全時間帯で同じ仕様にするわけではなく、時間帯ごと・鯖ごとに
制限をかけわけることで、ある程度リソース(この場合DAT)をフリーで解放する。

つまり、実況版は別に見ないから無料ユーザのままでいいや、みたいな逃げ道を
確保しておくことで「運営側からの強い圧力」といった印象を抑える心理的効果も期待する。
(この場合の対象はツールユーザ・ツール作者・クラッカー)

>>791
串無しでIEを使ってる人（想定している通常ユーザ）
は何の変化もないでしょうね。

>>799
がいしゅつです

>>799
　>>308　>>314

>>803
Thx!

Dreamさんにsubjext.txtを隠すことの利点を解説して欲しい人の数→(1001)

>>805　夜勤さんに聞くのが筋と思われ。
　もっとも答えない気がする。

>>803
そうでしたか。
今議論されてるレベルなら、どうころんでも規制をすり抜けられます。
結局性善説の上での話ですから。
性悪説で話を進めるならサーバ側での対処が必要なのに・・・

これじゃなにゆってもだめぽ

>>807のラインでいくと、性悪というより最早敵対視してると思われ。

逆にいえば、今の話がまとまってほしいとも思う。
だって規制が無いようなもんだからね。

>>793
気分転換に煽っていい?
「彼の私感」という言葉も存在するので、「私の私感」というのはおかしくない。
http://dictionary.goo.ne.jp/cgi-bin/dict_search.cgi?MT=%8E%84%8A%B4&sw=2

>>805
こまったなぁ。
ある程度、このスレと、批判要望の方の発言読めば、夜勤さんとトオルさんとひろゆ子さんが
隠したがっているという意向が伺えると思う。
だから盲目的に「隠そうよ」っていうわけじゃないけど、
一つは、イリーガルなツールに、ある程度責任を負わせられるって事。
二つ目は、Monazillaつーる(便宜的にたとえているだけですけど)みたいな、
２ちゃんの負荷とかの事を考えて下さる作者さんのグループに、
認証手順とかを提供することで、ほかのツールとの差を発生させることが出来て、
その差の部分で、そうじゃないツールと、サーバ的に区別する手段が
得られるような方策が将来的に取れるか、ということ。

ここまで書いて思ったんだけど、どうして、subject.txtが隠れてしまうことに
拘泥するのでしょうか？拘泥する必要がないと思うのですけれど。
Webでも、ツールでも、通常使用の範囲では今まで通り提供されるのに。

>800
dat遮断したらread.cgiへのアクセスが集中して全鯖即死です。

>>810
また一つ賢くなったよ。
ありがとう。

>>812
そうなるのかなぁ。
read.cgiへの呼び出しは、localhostからのもの以外弾いてみたらどうでしょう？

別に「フツーのユーザー」（←大事）が困らないんだったら隠しちゃえ、隠しちゃえｗ

>>811
現状では私もある種非Monazillaツール扱いなのよね(^^;
(すでに monzilla.org で紹介されてはいるが)
開発始めるにあたって隠れてたらやる気なくしただろうねえ。
まあ、そこらへんは感情論であって、正規の手段で取得できるなら問題はないかな。

>811
subject.txt隠したら負荷が増大するだけで軽減にはならない。
subject.txtを隠す云々は荒らし対策なだけで、今回の件とは関係無い。

>>812
現在呼び出しの５０％以上を占めるというツールユーザが全員
負荷の軽いdat読みをやめてIEなどのブラウザでread.cgiを呼ぶことになるわけだからなぁ。

>>816
そうなんだよね、結局、monazillaツールって何？ってなっちゃう
んだよね。
別に2chがライセンスしてるわけじゃないし、著作権持っている
わけじゃないんだよ。
そういうのに乗っかって規制する事が出来るのかと言うと、不
可能とは言わないけど、かなり難しいんだよね。

>>818
ぎゃー

>>812
だから全鯖にはせずに一部の鯖・一部の時間帯だけにする。
read.cgi HTMLパースするツールが現れたら作者に警告する。

>>817
その積算根拠があるとうれしいんですよ。

>>821
作者がソースを垂れ流して改造版が出回ったら？

＞811
とりあえず、gikozillaプロジェクトの発足と
その現状については関知している？
＃今はgikozillaもたいがい氏んでるけどな。

>>819
いえね、そういう意味では、いわゆる２ちゃんねる側の人たち、
夜勤さんとかひろゆきとか、トオルさんもかも知れないけど、
気を使っていると思いますけどね。
ただ、サーバが破綻している現状があって、この現状をおかしい、
って思わない人がいるんならしょうがないでしょうけど、
おかしい、とおもって、協力しよう、って思う人がいたら、
単純に私は可能だと思いますけどね。
●機能の実装だって、そういう経緯でされたんじゃないんですか？

>>824
不勉強ですいませんです。

>>816
ちょっと、その辺は私の感知できる部分ではないし、
私自身Monazilla不参加なので、まずいっすかねぇ？参加しないと・・・
どうなんでしょ？

>>819
現時点でのmonazillaツールの定義は「有償IDの認証機能を備えている2chブラウザ」
だと思われ

そして有償IDはクライアントの特定や制限に利用できる有効な手段と思う

subject.txtのアクセスに、なんらかのパスワードが必要なようにしておけば、
それを正規に得ていないツール/会社からのアクセスを「不正アクセス」と
して、罪に問うことができますね。
管理者がパスワードを「みだりに知らせてはならない」としておけば、あとは
実際にその機密性が保たれているかどうかは問題ではない。

日本の法律が、米国に所在する2chのサーバに適用されればですけど。

一番簡単なのは、2chが自分の責任でツールを提供する事なんだけど
（monazillaのツール作者にお任せでなく）
でも、現状ではそこまで出来ない。
結局、ツールで規制する事には限界がある（溜息

単純明快に
「subject.txtもdatも基本認証の中に隠しちゃえ」
みたいなことが言えるのは、私がニュートラルな場所にいるからだと思ってるんですけどね。
夜勤さんは、このスレッドのどこかで、
「私からそういうことを言えた義理はないです」みたいな事いってましたし。
「管理者以外の人間が批判されたりしませんか？」って気を使ってましたし。

>>829
だからsubback.html(またはそれに相当するもの)を使うだけだってのに..

>>829
運用会社が日本にあるのだから、専管裁判所は札幌地裁になるんじゃないっすか？

>>832
この話回ってますね、四週目くらいです

>>832
subback.htmlにアクセスしてきたIPを弾く機能って、実装難しいですかねぇ？

IPによりアク禁をかけるのは、それじたいは難しくないが、
そのIPリストを誰が管理するのかということと、
レイヤー8以降の問題が山積みではある。

>>836
2ちゃんねるの場合 political layer の所が難しいよな。
Big-Server はサーバの表面程度しかいじれない。
ひろゆきはやる気もスキルもない。

>>835
subback.htmlにどういうアクセスをしてきたものを弾くんでしょう？
通常使用でも見ることがあると思いますが

gikozilla騒動について知らない、歴史を軽視するような
香具師は、monazilla part2の、、、あ、offaw落ちか、、、
http://www.google.com/search?q=cache:EU7vRQnwjxQC:pc.2ch.net/test/read.cgi/tech/1005282763/+&hl=ja
140〜を参照セヨ

>>838
その辺は今話し手も仕方ないと思いますし、実装するとしたらなおさらいわないと思います。
私実装する人間ではありませんし、どんな権限もないです。

ツール作者さま。
「monazillaツールと課金及び転送量・鯖負荷問題を考えるスレ」
http://kaba.2ch.net/test/read.cgi/accuse/1016974669/542-543

なのですが、これ今まだたたき台を作ってるという感じなのですが、
作者さん達の現時点での見解とかご提案とかアドバイスとか、そんな感じの
お話をいただければ、と思いますです。

現在いただいているコメントです。。

委員長さん→http://pc.2ch.net/test/read.cgi/software/1016905060/671
西安さん　→http://pc.2ch.net/test/read.cgi/software/1016905060/672

過去ログを縦読みしたけど、
昨日からなーんも進展がないような気がするんだけど・・・^^;

>>842
現状の2ちゃんねるの問題が、それだけ深刻だと言う事

>831
転送量や負荷を抑えるために
subback.htmlより小さいsubject.txtを読んだりread.cgiより負荷の小さいdat直読みしたりするツール
の使用が推奨されてるわけで、
subject.txtやdatを隠して誰が得するのか説明しろｺﾞﾙｧ(ﾟдﾟ)

ゲイツか？

subject.txtを使った荒らしが減る。

TCPの3-Way-Handshakeは重い、という話をきいた
ことがあったので、あちしのツールではKeep-Aliveによる
Persistance-Connectionがなるべく途切れないように
しているわけだですけども、intervalがあるなら、当然
Connectionは毎回切れるわけで、そういうものなのか、と。

intervalを間に挟んだり、複数の鯖を交互に使用したりして
軽減される負荷というのは、Keep-AliveしてHandshakeを
削減するのよりも大きいのかな？という疑問はありますです。

>>844
一定の枠を用意して、みたいないいカタすると官僚のようだけど、
ようするに、サーバ維持策を打ち出して、賛同して参加してくらさる
ツール作者さんには、subject.txtやdatを公開するって形だと、どうなんでしょね？

＃ずっと私は、それを提案してきているんですけど
＃誤解されていますか？

公式発表的には、subject.txtは隠されているのですが。
つか、あなた、ブラウザから取得できますか。

>>847
それなら隠すといわずに取得に制限を加えると言った方がいいのでわ

>>846
インターバルを挟む、という思想は、ツールによる断続的で集中的な
リクエストを防ぐ、という視点に大きく立脚しちゃっているものだと思います。
作者さんの視点で、どういう方法が、サーバの負荷と転送量という問題に対して
効果的である、という、啓蒙というか、教育というか(私みたいなのに対して)
をしていただけると、とてもうれしいです。

>>846
>>725-726 ではとっとと切断、って言って終わってるけど、
もうちょっと考えるべき事だと思う。

「じゃあ Keep alive せずに Rapid fire しろっていうことか?」
と誤解する人が出るのが怖い。

>>849
ああなるほど。

＃ここまでに、このスレッドでも前スレでもしつこくさんざん書いてたから了解済みだ
＃という思いこみでした。
＃すみませんでした

>>851
是非お願いします。
SYN ACKの認証が正直きつい、というのがそもそも、dat直取りで巡回を
されたくない、という話の始点だったと思うんです。
私自身は、その程度の認識しかなく、
「だったらどうやるのが効果的なのか？」
については、是非お聞かせいただきたいと思っております。

もちろん、dat直取りのもう一つの要因としては
転送量に影響する、というところもありますけど、これは、
要求されるのはHEAD情報だけで、datを直に取ってるわけではない、
というお話だと思いましたが・・・・
その場合でも、SYN←→ACKのハンドシェイク的に、サーバ負荷につながっていないのか？
とか、いろいろ、お聞きしたいことがありますです。

あと夜勤さんに、
http://www.yakin.cc/pv200201.html
には、HEAD要求は含まれていますか？というのを確認させていただきたいと思います。
PVという言い方の印象では、GETのみ、で、ページ単位のカウントのような気がします。
(イメージファイルとかそういう者を除いている、という意味で)
お願いします。

>>843
なるほど

場合わけをきちんとしようや。
・更新があるばあい
　・Head(stat) [+ Get(read)]
　・ims-Get(stat&read)
・ない場合。
　・Head(stat)
　・ims-Get(stat)
で、どっちにしろ、更新があれば中身をみたくなるわけで、
むしろIf-Modified-SinceをつけたGetの方が軽いのでは？
というのがすくなくとも8ヶ月前の結論だったわけですが。

>>854
あの〜普通に巡回といわれるものはすべてIf-Modified-Since付きのGETですよ。
巡回時に自動でHEAD→GETとわざわざ無駄なことやってるものは即刻修正すべし、です。

>>857
ああ、はい。
巡回じゃなくて、更新チェックですよね。はい・・・

＞ようするに、サーバ維持策を打ち出して、賛同して参加してくらさる
＞ツール作者さんには、subject.txtやdatを公開するって形だと、
＞どうなんでしょね？

ところで、これは現在のsubject.txtの状態と具体的に
どのあたりが異なるのでしょうか？

>>859
いまはhtaccessやcgi内部で判別してアクセス受け付けてるようですが、
たとえば、基本認証使ってリクエスト受ける、というイメージです。
イメージ的には。

>>859
ぎこはにゃ〜ん作者登場。

>>860
ナニを認証するのさ？●？

>>860
それが何の解決になるの？鯖負担が増えるだけでは？
荒らしツールはどれかのツールに簡単になりすましができるけど。

>862
ツール（と作者）、じゃないかな。
セキュリティ的にはヨワヨワでないも同然だけど、
そこを不正アクセス禁止法で補助するような感じがする。

>>863　荒らし対策の話をするスレなのか？

>>865
違うはずなんだけど、まとめ役がそっちに話を持っていくんだもの。

>>860
イメージとか、イメージ的では正直意味がとれないよ。
具体的な説明求む。

>>867
すいません。イメージなイメージ的にエクスキューズな単語ですけど、
＞たとえば、基本認証使ってリクエスト受ける
これそのものずばりではないかと愚考します。

>>866　責任転嫁すな。

ん、だから普通にsubject.txtをGETしても
HTTP/1.1 401 Authorization Required
が帰ってきて、ちゃんとパス送らないと
受信できねって事だろ。
で、このパスを勝手に解析すると不正アクセス防止法に触れる可能性があると。

>>865
荒らしが過負荷の要因になっていない、または、別の手段で対応が出来る、
ということであれば、そういう仕組みは一切要らないかと思います。
たとえば、特定の業者がdatクロールして利益を得ようとしているわけです。
たとえば、全くランダムなdatから書き込みを抽出して、それを、
subject.txtで特定のスレッド拾って、bbs.cgiにPOSTしたりしているわけです。
そういう行為を、負荷低減策として検討する必要がないのであれば、
datもsubjectも、現行のままでよろしいのではないかと思います。

>>870
法律なんか気にするな！

>>871
それが問題なんだからそっちを対処しようよ。

手に入れたデータまたはその統計を商業利用しようとしている
ところから金を取れるように何か利用規定を設ければいい。

具体的には抜き打ちでIP統計とって、異常に多いところの
IPがどっかの会社だったら 「金払え」 って言えばいいよ。

抜け道はあるかもしれないけど、それはそれで
バレた日にはその会社は２ちゃんねらに潰される

抜け道はあるかも → 抜け道はたくさんあるけど
だった。

少なくともちょっとは金取れるようになるよ。
そしてその金で回線増強なりなんなりできる、と。

>>873
でもですね、やっぱしあれなんですよ。
荒らしが発生していない日でも、厳然としてサーバはぱんぱん
帯域かつかつ。なんだそうです。

>>868
いや、基本認証使ってリクエスト受けると、基本認証する分だけ
負荷が増すと思うんで、その辺どう考えてるのか知りたいなと。

現状だとUAをモナジラと詐称するだけで、
荒らしツールだろうとなんだろうとsubject.txtは受信できちゃうわけで、
しかもそれは法にはふれない。犯罪じゃない。
（UAを偽る＝鯖を騙す＝詐欺罪って話もなきにしもあらずって感じらしいが）

そこを認証にすれば、不正アクセス防止法違反という立派な犯罪にできる。
だから荒らしツールを抑制できる。
悪質なら訴えれば逮捕される。
って事だな。

まぁ、俺ならそんな事されたらsubback.htmlで同じ事するけどね。
それもなくなったとしてindex.htmlから生成すればいいし、
それもだめだったら
http://pc.2ch.net/test/read.cgi/software/1016905060←ここのキーを
現在時刻からさかのぼって存在をチェックしてランダムに荒らすようにだってできる。
ブラウザで見れてカキコできる時点で、なんでもできるわな、そりゃ。

つか、むしろそういう規制された方が燃えるね。
なんとしても荒らしてやろう！ってな。

>>875
この話は批判要望に書くべき内容だった。すまんこ。

荒らしが原因の日もあるだろうけど問題なのは
慢性的にクロールしてる企業がいるで重い
ってとこかと

かちゅーしゃのアクセスが多い、ってのはそういう企業が作ったツールが
とりあえず有名なかちゅーしゃのUAを偽ってる、ってパターンが多かったりしてね

でもそれは、オープンソースの死だよね。
dat、subject.txtのgetにpassが必要で、
それをツールに埋め込んでしまう時点で。

なにか起死回生の良いアイデアありませんでしょうか？

>>880 >>768 で一度指摘されたが、返答なし
オープンソースの場合、隠しているとはどう考えても言えないから
法に頼るのも難しいと思われるが

>>880
パス埋め込んでもかんけねーよ。
認証なんてなんの暗号化もされてないんだから、
ローカルでプロクシ立てて通信内容のぞき見れば、
すぐにパスなんて分かるっつーの。
仮にプロクシ立てられなくてもTCP/IP通信内容をのぞき見るツールだってあるんだし。

というか自分がなにを発信しているか、受信しているかはすぐわかる。

>>882-883
なんか代替案がありましょうか？

BASIC認証はたとえなので、Digest認証くらいは
使うものだと当然思っていましたが、、、
別にこれがSSLのClient Certificationでもそんなに
話は変わらないと思うのですが。

誰かの書いた内容について、批判したり、だめな面を指摘するのは
すごく簡単だと思うんですよね

でも、ここ重役会議やっているわけじゃないんですよ。
どうしようかね？って話してるつもりなんです。

私の提案に不具合や不足があったらとっとと引っ込めます。
良い案を考えていただけるととてもうれしいんです。
(否定すんなよ、ていうんじゃないですよ、もちろん(笑))

だから平凡なパスを埋め込むというのは愚行。
送信内容の一部を暗号化して・・・ってのなら効果はあるけどね。
一部にPGPを使うとか。（遅そー）

そもそも、大体subject.txtをいかに強いセキュリティをもって隠したところで、
subback.htmlだってなんだってあるんだから無駄って話でしょ。

>>886
ええ、仕様を決めているんではなくて、要求分析というか
まだそこまでいっていないブレインストーミング的な話ではないかと思います。
そう宣言しているレスが、残っているはずです。

>>889
なんでそこではなしがとまっちゃうかな？
ずっと同じ方ですか？
じゃ、どうすればいいの？

公開鍵が公開されてなければ（ツール内に隠蔽されてれば）いけるかも。

しかしこの方法はソース丸見えなのには(j2ch-cashだっけ？)使えないな

>>891
どうしようもないって事かと

>>894
いや、あなたがそういう感想なのはわかりましたので、
だったらもうあなたの意見わかったのでもういいです。おつかれさまでした。

どうせやられるんだからsubbackよりsubjectの方がまだましだ。
異様にアクセス多いIPだけ完全アクセス禁止にしろ。

>>894
今回の問題については、100% 完全無欠のシステムを作るのは無理。
だけど、できることはあるはず。UserAgent 詐称だって、
それをやる人がどれだけ存在するかどうかの問題。

規制したことで、トータル的に負荷が減るならやる価値はある。
そのためにも統計とデータが必要。
これからの2ちゃんねるは、様々な実験が必要なんだよ。

【２ちゃんねるビューア】　巡回機能の巻。Part4
http://pc.2ch.net/test/read.cgi/software/1017161683/l50

ちょっと早いですけれど、次のスレを用意しておきました。

>>896
そうだね。それが一番現実的かつ簡単。

そのIPアドレスがどっかのプロバイダでないにもかかわらず
アホみたいにアクセスが頻繁だったら禁止ってのはいいかも。

>>875
荒らし対策しても意味無いってこと？

ツール側と鯖側でsubject.txtを強度な暗号化して通信したとしても、
結局自分のPCから発信してるわけで、
串とかで通信内容のぞき見られたら、
荒らしツール、dat総ざらいツールでもそのまま使えちゃうんじゃないの？
まったく同じリクエストを送信するだけじゃないの？

>901
は、SSLについてもっと勉強してください。

>>900
先日のkaba鯖アタックのときは、対策が非常に効果的だったよ。
対策してないときは、ロードアベレージ 150 は軽く越えてたはず。

>>898

>>1のテンプレが古い。

>>901
でも、その行為は、これまでのグレーではなく、
レッドになるわけですよね？法的には。

「そういう使い方をされたくないために意図された」
ものを乗り越えるんですから。

>>904
ああ！すいません。

>>904
http://pc.2ch.net/test/read.cgi/software/1017161683/10

このあたりでお許し下さい。

>>903
そうなんですか？
対策効いて沈静化したのか、攻撃終わって沈静化したのか
わかりませんでした。

どなたか批判要望板の容量を教えてください。
１０００行く前に１０２４ｋの制限でdat落ちする可能性がおおいので
長文レスが多いもので、、、って漏れか（ｗ

>>909
このすれも300kも全然いってないから大丈夫

>>910
こっちあげでいって、９５０くらいまで使いますですか？
わたし、いったんお休みいたします。
早めにスレ立てましてすんません。

GickoBrowser修正改良版
Information

(2002/03/26)　暫定的にかちゅのUAを借りてsubject.txt取得するようにしました

>>912
なんでかちゅ・・・・。
しかもそれって実質 kage の UA よね・・・。

◆hAnYaNVA さんじゃないけど、インターバルの件でどうしても納得いかない。

「インターバルを設ける理由」から
「巡回を不便にして巡回自体(回数/スレ数)を減らす」目的を除き
純粋に「複数のリクエストを送る必要がある」場合。

Keep-Aliveしたまま接続断を待つ/サーバーを待たせるのは論外とし、
同じサーバーに対してのconnectionは
一つに限定する(タブブラウザなどは複数？)場合、

本当に、
　connect-request-response-close
　-interval-
　connect-request-response-close
　-interval-
　connect-request-response-close
　-interval-
が、
　connect-
　　request-response-request-response-request-response
　-close
よりサーバーに優しいか、結論は出ているのかな？

詳しい条件等は全然知らないので、2chには当てはまらないかもしれないけど
Apache自体はKeep-Aliveの実装によって50%近く負荷が下がったらしい。
game鯖等が軽くなったのは、インターバルを設けた効果ではなく、
単にread.cgiのrawモードを不可にした効果に思えるのだけれど。

リクエストの集中が問題というかもしれないが、
仮にKeep-Aliveにしも、サーバーが処理するリクエストは、
各接続に対して同時に１つだけなのだから
接続要求の度にacceptすることを考えれば
Keep-Aliveしたままの方がトータルの負荷は少ないと思う。
そもそも、同時接続数が256では足りないような状態のサーバーに対して
単独のクライアントからのリクエストが連続しない程度で
負荷分散になるとはとても思えない。

それでも、Keep-Aliveにしたら次のリクエストを待つ間の
idleなconnectionが負荷を高める原因だと言うのならば、
リクエストをパイプラインして送ればいい。
　connect-
　　request+request+request - response+response+response
　-close
これならidleなconnectionも発生しないし、無駄なconnect/closeもない。
HEAD等の軽いリクエストを数十件まとめて送り
レスポンスにかかる時間を比較しすれば
サーバーが短時間で処理を完了して解放されるのがわかる。

どこか間違ってる？あるいは何か見落としてる？

話が追いきれてないけど、書いとく。
# 今は話がループしてるっぽいし。

●で認証を行うか、ツールで認証を行うかと聞かれれば、
私は●を進めますが。何故かというと
1.ツール認証はhttp内で行うには抜け道が多いから
2.●で認証は無料ユーザにも発行することができ、
　ココの負荷を把握することができるから。
の二点が理由なんですが。

●の発行で無料用の話って出てないよね？

【２ちゃんねるビューア】　巡回機能の巻。Part3
http://pc.2ch.net/test/read.cgi/software/1016905060/l50
でいま、２ちゃんの負荷低減とかを話してます。

ところで、２ちゃんねるはいま、htaccessを使ってRewriteCondをつかい、
各ツールなどにdatなどを供給している訳なのですが、
「httpd.conf」に一本化し、htaccessを一切使わないようにすれば、サーバの負荷低減がはかれる、
というお話をなさった方が居られました。
お聞きしたいのは、この方法をに変えると、どのくらい負荷が低減するのか？
といった、見積もり的な試算は可能なのか？ということと、
具体的に、これを裏付けるベンチマーク結果などは、存在するのか？
という２点です。
もし、おわかりの方、この問題に詳しい方が居られましたら、上記スレッドで
お話をいただければと思います。
よろしくお願いします。

マルチポストしてきました。うざくてすんません。

スレが立てられない。
だれか2ちゃん専用ブラウザ「かちゅ〜しゃ」Part588を立ててくれ。
http://pc.2ch.net/test/read.cgi/win/1017034701/904

>>917
>>314
できもしないこと話してどうするんですか?

>>919
はい。
劇的に効果があるんだったら、再度提案してみたいし、もし、
劇的に効果があるなんて言えない内容だったら、もう忘却してしまったらいいかと思っただけです。

>>917を夜勤に無理強いする。

負荷軽減を要望するが、変化を望まない夜勤がボトルネック。

>>920
今すぐ忘却してしまっていいと思います。

Dream ★さんスレ立てありがとうございます。
でもソフトウェア板…

やっちゃったようですなぁ・・・

シロートの思いつきですが、datにgzipでアクセスする代わりに、
あらかじめbbs.cgiが圧縮データを生成して、それを普通にgetしたら
サーバ負荷と転送量の二律背反は緩和されません？
アクセス頻度は書き込み<<読み込みなハズだし、
bbs.cgiも一カキコだけ圧縮してアペンドすれば負荷は小さそうだし。

httpd.confって、それ自体にスクリプト噛ませて、動的に認識させることが出来ましたよね？
特に、Perlディレクティヴかなんかを使えたと思うし、とにかく、夜勤さんに
負担や負荷かけない方法がとりえるんであれば、お願いしてみてもいいかと思いました。
夜勤さんが「出来ない」といっている事情と、こちらがデータそろえて、方法も添えて、
これでいかがでしょう？っていう提案をして、それを天秤に掛けて判断していただくしかないでしょう。

「その方法だと負荷が軽くなる」

という一言だけで、人を動かそうなんてしちゃだめです。
やっぱり、根拠と方法、目論見見積もりがなければ、人の心なんて動きません。

>>923
あーおれってばかだ。ごめんなさい。いますぐいきます。

>>925
gzip圧縮したものに何か追加するには
全部解凍→追加→再圧縮しなくてはならないのです。

>>928
両方生成するとか．．．

>927
つーか本来はソフトウェア板にあって然るべきスレッドだったり。。。

>928
ええ。ですから一レスごとにgzipしたものをアペンドできないかなと。
クライアントも１レスずつ解凍する実装が必要だし、圧縮率はgzip本来の
レベルからは程遠い悲しい物になるかもしれませんけどね。

そうでなく書き込みごとにdatから丸ごと生成するとしても、bbs.cgiが実際に動作する
回数がread.cgiやdatがアクセスされる回数よりも少ないならメリットがあると思います。

ついにソフト板にもかちゅユーザー進出か。
WIN板とまたがって幾つスレ立てれば気が済むんだ。

>929
あ、補足どうもです。
サーバ自体の(html生成の)動作のためにも
今まで通りのdatの生成はしたほうがいいと思います。

>>931
read.cgiが表示するために必ず解凍しなくてはならないとなると
負荷の面で相当厳しいと思われます。

夜勤氏にはあきらめて頑張ってもらう。

これが今夜の結論だな。

>>926
夜勤たんが「できない」って言ってるのは、割に合わないからだろ。
結局金だよ。この問題は。

だいたい全部読んだが、
とりあえず dream 氏はもう少し勉強してくださいという事でしょうか。
http と tcp について。

それと、技術的な方法でツール作者さん達にも手伝ってもらいたい
ならせめて2ch管理側は負荷についての具体的な数値
くらいまとめて出すべきだね。

>>937
つうか、誤爆すんなよ、ってのをまずいうべきなんじゃないの？(笑)

>>926
httpd.confはいじれないって、かなり前から夜勤さんが言ってなかった？

>>939
>>920
ってことなんじゃないの？

>937
他人に「もう少し勉強して下さい」て言っておいて、いいっぱなし？
具体的な数値出せ、っていって、なんの数値が具体的に欲しいのかはいわない？
それはいくらなんでも、かたておち？

>>940
なるほど・・・。
でもさぁ、結局は、夜勤さんの>>314発言を
完全に無視していると捕らえられてもおかしくない意見だよね。

>>942
>>926
素直に読めば理解できないか？話の流れが。

>ええ。ですから一レスごとにgzipしたものをアペンドできないかなと。
そんなことをしたら、圧縮の効果がほとんどなくなりますよ。
実験してみればすぐにでもわかることでしょうに。

>とりあえず dream 氏はもう少し勉強してくださいという事でしょうか。
>http と tcp について。

前も書かれてたと思うけど、彼は事実のとりまとめに徹して、自分の意見を
言う時は名無しになるべきだと思う。正直引き気味

>>943
>>926の話は理解してますってば。
私が言いたいのは、2chの負荷軽減に付いて議論しているこのスレ中で、
夜勤さんは>>314の発言をされているということです。
負荷軽減の効果うんぬんの事を話している場で、httpd.confをいじることを
したくないという意思表示をしていると思われますが？

>>946
>>926を見る限り、Dreamが夜勤さんにやってくれっていっているんじゃなくて、
httpd.confをいじればパフォーマンス良くなるからやれっていうんだったら
それなりの手順用意できるの？っていう話に見えるのは俺だけ？

>>947
ええ、そうなんですが、
最終的に夜勤さんにやってもらうしかない方法であり、かつ、
夜勤さん本人が拒絶している方法(httpd.confいじり)について、
検討していることには変わりないと思いますが？

夜勤さんの意思を尊重するのであれば・・・ね。

>941
申し訳ないですが、言いっぱなしです。
dailup user が云々とか本質的でないこと長々と言ってたり、
自分でツール作ればいくらでも回避できそうな案ばかりだったり、
もうこれはせめて >945 の通り名無しで発言くらいにとどめないと、
読んでるだけでおなかいっぱいですよ。
というわけで >945 氏の意見に ++;

>>645
いや不揮発の馬鹿高いメモリじゃなくて、サーバー飛んだらログ全滅でも
いいからってこと。どうせ飛ぶこと覚悟の負荷隔離鯖だし。

そのそも2chは過去ログ残さなくてもいいような気もする。
現状でも住人が自主的に過去ログサイト立ち上げてる例がいくつかあるし、
2ch側が残さなければより一般的になると思う。
ただ.dat落ち寸前のを拾うためのアクセスが殺到する可能性を考えて
950-1000だけは一定期間読めるようにする等は要るかも。
…過去ログ有料検索とか言ってる現状では期待薄か。

>>944
その通りだけど考え方としては面白いかも、20レスごとくらいにして。
（最大19レスの未圧縮がくっついた圧縮ファイル…ちょっと読み方が
複雑になりそうだが）
どうせブラウザでは読まないし、専用ツール前提ならlzoみたいな軽い圧縮
アルゴリズムも使える。

>>950
それはあなただけの意見です。

<独り言>tcpわかってhttpわかって、ＣでツールかけてPerlかけて、この巨大な
案件すっきりまとめて人望もあって理にかなったことを常に冷静に言える奴って
こんなばかげた話なんかに参加しないよな。</独り言>

念のため、貼っておきます。

【２ちゃんねるビューア】　巡回機能の巻。Part4
http://pc.2ch.net/test/read.cgi/software/1017161683/l50

>>952
ここに書き込んだあなたは・・・。そして私は・・・。
お互い精進しましょ。

HTTP でデータ GET して多少解析して表示するなんてのは
ネットワークプログラミングしたことのある人なら１日も要りません.
技術の話なのに性善説でインターバルなんてのは臍で茶がわきます.
便利に使えるツールにするのは別の話.

>>944
んーそういうことなのか．．．
てっきり、bbs.cgiでdatを生成するときについでに圧縮かけたものも作ってしまえってこと
かと思ってた。

>>955
それJOKESIZE★の方じゃないのか？

>>950
誰が設備投資費をまかなうんでしょ？

>>955
「monazillaツールと課金及び転送量・鯖負荷問題を考えるスレ」
http://kaba.2ch.net/test/read.cgi/accuse/1016974669/l50
こっちで思う存分やってくれ。

>956
両睨みでいいと思います。
一括圧縮ファイルの同時生成なら現在の転送量で負荷削減。
差分圧縮ファイルへの追加なら転送量が増えるけどさらに負荷が下がる。

現実的なのはおそらく前者でしょうね。

>>945が良いことを言った。
正直、司会者としての根性は見上げたものがあるので、その役目に徹してほしい。

>>961
おお、やっぱ皆も思ってたのか。
あの意見のしかたはマジで勘弁して欲しいと思ったり。
頑張って反対してる人もいるけどさぁ…。
そもそもここは議論の場なんだから。

>>961-962
(ﾟдﾟ)ｳﾏｰ

んじゃ、個人的な見解は一切言わないつー事でいきます。
もういいたいことはいったし。
どーせ仕切やなんて、うざがられてナンボですし。ただでさえ。

仕切ってなくてもうざい奴だろうけどな

>>963
いや、そうじゃなく、まとめる場合にそのハンドルにしてほしいんです。
Dream ★ で絞りこめば流れが読めるようにしたいんです。

過去ログを読んでませんが、、、
インターバルをツールに実装すると、patchが出まわるので、
正直者がバカを見ると、、、ソース公開してるツールもありますしね。
んで、サーバで実装するとサーバ負荷が増えるので、
そもそも意味がない。
ということで、IDがあったら巡回できて、
なければ出来ないというのが落としどころになるかと。

>>966
【２ちゃんねるビューア】　巡回機能の巻。Part4
http://pc.2ch.net/test/read.cgi/software/1017161683/

>>966
夜勤氏を説得しる。
サーバがわの対処で今の数倍のキャパ増大見込めるんだから
それやればいいだけだろーが

早晩破綻しそうだがなｗ

>>968
んだんだ。
ありえねーけど（ｗ

>>958
8月危機の際に既に各鯖１Ｇづつ積んでて大半がディスクキャッシュ
っての読んだ気がする。それをRAMディスクにすれば要らないかと。
ログ消滅の危険性は別の議論として。

>>971
あげんなや。

そういう話は、ソース付けなきゃただのガセ
それから、メモリは欠乏中。vip鯖は512MBでもう足りない。
よく考えてから言ってけれ。相手にされなくなるよ。

>>972
>>529-536 を見る限り、スワップ使ってないんだから、欠乏とはいえないんじゃない?
メモリは欠乏というか、あればあるだけキャッシュもしくはバッファとして
有効活用される。WindowsNT と違って、Unix はメモリをかなり効率よく使ってくれる。

さらにメモリを積めばパフォーマンス良くなるのは認めるけど、
それよりも CPU の負荷を何とかする方が先。

>vip鯖は512MBでもう足りない。
それはあれじゃないかな。apacheとかperlとかの
プロセスが乱立しているからでしょ？

じゃあ、プロセス低減策をとって(read/bbs.cgiが直接Listenして、
selectによる多重化をするとか)その上で、キャッシュデーモンで
オンメモリ処理への道を開くのが王道。

>>974
クズみたいなセキュリティの穴
自前主義は万能とか思ってない？

>>974
apacheより出来が悪いものが完成するに１００ペソ

【２ちゃんねるビューア】　巡回機能の巻。Part4
http://pc.2ch.net/test/read.cgi/software/1017161683/

【２ちゃんねるビューア】　巡回機能の巻。Part4
http://pc.2ch.net/test/read.cgi/software/1017161683/1-10

>>978
埋　め　立　て　屋　死　ん　で　く　だ　さ　い
http://pc.2ch.net/test/read.cgi/software/1016172411/

埋め立てるなと警告しても止めない悪質な奴だからな。

>>979-980
おまえたちもなー

埋め立て屋ってなに？

>>982
地上屋より（略

香取先生見てる？

コイツは埋め立て屋ですか （ｗ
http://kaba.2ch.net/test/read.cgi/sakud/1001476296/984-1000

万能とまでは思っていないが、汎用よりも、
専用のほうがパフォーマンスを稼ぎ易いのは事実。
別にapacheよりも高機能にする必要はない。

>>979-986
埋め立てご苦労！

>>986
いうはやすし。
行うはきよし。

[壁]_・)

>>989
http://www.yomiuri.co.jp/minijiten/23991218.htm

>>990
ワラタ

あ、漏れ仕切り過ぎてたかも…
そうだね　ちょっと反省してる　言いたいこともまだあるけど
これ以上居座ると荒れるだろうから去ることにするよ　みんな
がんばってね　

かちんと来て俺も脊髄反射してたかもね
ゆるしてね
いい夢見ろよ　　　　　
！

かゆければ、かけ。

http://pc.2ch.net/test/read.cgi/software/1017161683/

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。