■スレッドリストへ戻る■ 全部 1- 101- 201- 301- 401- 501- 601- 701- 801- 901- 最新50
read.cgi改良スレッド ２
- 756 ：デフォルトの名無しさん ：01/09/28 20:31
- datの書き込み時にどういう処理をしているのかわからないけど
もし open("hoge.dat", O_WRONLY|O_TRUNC) or fopen("hoge.dat", "w")
に相当するようなやり方でオープンして書き込んでたりすると
その書き込み中にread.cgiでBigBufferを参照すると
ファイルの終端より後ろの領域を参照 -> SIGBUS or SIGSEGV
ということもあり得るんだな...... 例のmmap時のlock問題
- 757 ：デフォルトの名無しさん ：01/09/28 21:18
- bbs.cgiに関してはそんな.dat消失の危険があることは
やらんでしょう。普通はO_APPENDを使うと思われ
流出スクリプトもそうなってるし。
ただ削除系のスクリプトはぁゃιぃかも。
- 758 ：デフォルトの名無しさん ：01/09/29 01:31
- 非常に簡単なテストプログラムを作ってみたのだが・・・
255個の空白と改行を１行とし、
1)まず新規にファイルを16*4行分作成し、閉じる
2)次にファイルサイズ+10バイトをPROT_READ,MAP_SHAREDでmmapする
3)マップされた領域をスキャンし、行数と最初に'\0'が現れる位置を表示する
4)次に同じファイル名で(マップしたまま)16*1行分作成し、閉じる
5)3)を繰り返す
この結果は３の時と５の時で異なり、
どちらも実際のファイルの行数(64と16)を報告し、
最初に'\0'が見つかったのは、ファイルサイズの次の位置だった。
どちらも実際のファイルサイズを超え、ページ境界をまたいでいるが、
coreは吐かなかった。
(ページ境界をまたがない時でも、
'\0'が最初に現れた位置はファイルが終わった位置だった)
もしこれ(ファイルサイズ以上の領域には'\0'が入り、
マップされている間にサイズが小さくなっても'\0'が入る)が常に当てはまるなら、
map_sizeをほんの少し多めに取り、
BigBufferをスキャンしている最中に'\0'が現れた場合のみ、
オーバーしているかをチェックすればよいことになる。
とりあえず、これが成立するを仮定して、
dat_readとressplitter_splitを修正した。
- 759 ：デフォルトの名無しさん ：01/09/29 03:32
- ファイルを書きかえるプログラムとの協調ができない限り
どうやろうが危険は残る。
ターゲットOSがいつまでも同じとは限らない。
未定義部分の振る舞いなんか利用したら、後で必ず痛い目にあう。
削除ツールとかを変更できるまでは、mmapの使用はあきらめた方がいいんじゃない。
- 760 ：デフォルトの名無しさん ：01/09/29 04:08
- 振るまいが違ったらその時直せばいいじゃん。
納品して終りじゃないんだから。
それと「mmapの使用」と「MAP_SHAREDの使用」は等価ではないよ。
- 761 ：デフォルトの名無しさん ：01/09/29 08:35
- cvs鯖落ちてる?
- 762 ： ◆YaKIN/eo ＠夜勤 ★ ：01/09/29 14:37
- umm
choco にまだ、 core できてませんでした、
観察継続中。。。
- 763 ：デフォルトの名無しさん ：01/09/29 15:54
- read.cgi の不具合報告です。
http://piza2.2ch.net/test/read.cgi/tech/1000035521/627
http://piza2.2ch.net/test/read.cgi/tech/1000035521/627/
どちらも同じ書きこみが表示されますが
下のURLだと
「■掲示板に戻る■ 全部 1- 101- 201-・・・・」
とか
「>>123」
などのリンク先がおかしいです。
（それともこのような指定方は想定外？）
- 764 ：デフォルトの名無しさん ：01/09/29 15:56
- がいしゅつです。>>747-749
で、
・エラーにする
・R2CH_HTML_BASE_DEFINEを出す
どちらにしましょうか。
- 765 ：デフォルトの名無しさん ：01/09/29 16:55
- >>764
BASE出すほうに一票
- 766 ：デフォルトの名無しさん ：01/09/29 19:15
- >>732-733にあるようなdatの部分取得と、
subject.txtの上位50件取得等に対応するために、
raw=0.0時のみ、
st,to,lsを参照して要求された部分のみを返すようにすることを考え、
RAWOUT_PARTIALとして試験的に加えてみた。
(nofirstは無視したので、ls=nn時にはレス１は送信されない)
ls=nnに対応するために、送信するレス番の範囲を教える必要があり、
是非次回は続きを差分取得して欲しいから、
dat全体の中でどの部分にあたるかの、位置と範囲も返したい。
となると、部分取得時は返信ヘッダがかなり窮屈になってしまう。
実行した場合のヘッダ("/512K"以後の区切りはTAB)。
/tech/?raw=0.0&to=50 #subject.txtの範囲指定にpathは使えない
+PARTIAL 2441/512KRange:0-2440/22735Res:1-50/478
/tech/998845501/?raw=0.0 #今までと同じ
+OK 297551/512K
/tech/998845501/50-99?raw=0.0
+PARTIAL 11767/512KRange:12226-23992/297551Res:50-99/883
/tech/998845501/l50?raw=0.0
+PARTIAL 27967/512KRange:269584-297550/297551Res:834-883/883
/tech/998845501/l20000?raw=0.0 #強引に全部送信
+PARTIAL 297551/512KRange:0-297550/297551Res:1-883/883
(本物のログとサイズが違うのは、手動でいじったからなので気にしない)
返信するステータス等を勝手に決めるのも心苦しいので、
返信コードやフォーマットなども含め、意見求む。
- 767 ：デフォルトの名無しさん ：01/09/29 19:17
- cvs使えないので、ここに書いて意見を聞く
int dat_out_raw(void)
{
const char *begin = BigLine[0];
const char *end = BigLine[lineMax];
char statusline[512];
char *vp = statusline;
#ifdefRAWOUT_PARTIAL
int first = 0, last = 0;
if (raw_lastnum == 0 && raw_lastsize == 0
&& (nn_st || nn_to || nn_ls > 1)) {
/* nn_xxはnofirstの関係等で変化しているかもしれないので再算出 */
int st = atoi(zz_st), to = atoi(zz_to), ls = atoi(zz_ls);
first = 1, last = lineMax;
if (ls == 1)/* for Ver5.22 bug */
ls = 0;
if (ls)
st = lineMax - ls + 1;
if (0 < st && st <= lineMax)
first = st;
if (0 < to && to <= lineMax)
last = to;
if (first > last)
last = first;
begin = BigLine[first-1];
end = BigLine[last];
vp += sprintf(vp, "+PARTIAL");
} else
#endif
/* ・・・ */
if (・・・) {
・・・
} else {
・・・
}
vp += sprintf(vp, " %d/%dK", end - begin, MAX_FILESIZE / 1024);
#ifdefRAWOUT_PARTIAL
if (first && last) {
vp += sprintf(vp, "\t""Range:%u-%u/%u",
begin - BigLine[0], end - BigLine[0] - 1, BigLine[lineMax] - BigLine[0]);
vp += sprintf(vp, "\t""Res:%u-%u/%u", first, last, lineMax);
}
#endif
- 768 ：デフォルトの名無しさん ：01/09/29 19:17
- 続き
#ifdefAUTO_KAKO
{
static char *messages[] = {
"",
"\t""Status:Stopped",
"\t""Location:temp/",
"\t""Location:kako/",
/* 正確な位置を知らせる必要はないはず */
};
int where = zz_dat_where;
if (where || isthreadstopped())
where++;
vp += sprintf(vp, "%s", messages[where]);
}
#endif
pPrintf(pStdout, "%s\n", statusline);
・・・
}
- 769 ：デフォルトの名無しさん ：01/09/29 19:45
- subject.txtのraw=0.0時の出力内容は、意味的には1が最新だし、
途中からの受信はそれまでの取得済み内容の続きにできないので
st, toは無視して、lsで先頭からの個数を指定するほうが
より良いような気もする。
- 770 ：デフォルトの名無しさん ：01/09/30 00:23
- かちゅ～しゃのgzip対応化DLLを作っている者です。
現在のrawモードの仕様だと最終レス番号を指定しなくては
ならないので、これをログから取得しているのですが、
ディスク上のログがすぐには更新されないとか、
ログ保存をオフにしたりレス取得上限を設定したり
されると対応できないとか、いろいろ大変です。
http://piza2.2ch.net/test/read.cgi/tech/1000035521/?raw=.12345
のように、レス番号指定を省略しても(指定位置が
ちょうど行頭なら)差分だけを返すようにできないでしょうか?
- 771 ： ◆YaKIN/eo ＠夜勤 ★ ：01/09/30 02:57
- 以下のサーバに mod_gzip が導入それました。
mentai , saki/corn , cheese/cocoa , teri/ton , kaba , bbspink2
www/salami , salad , yasai , natto , ebi/curry
そこで yasai に read.cgi を /*#define GZIP*/ のようにコメントアウトして
コンパイルしたものを上げました。
本当はどうすればいいのかな? 教えてください、おねがいします。
- 772 ：デフォルトの名無しさん ：01/09/30 04:21
- 今、永らく読んでなかったかちゅスレ(18-19)を読んでます。
伸びが急激なので、まだ19の途中ですが。
proxyではなく、DLL対応とは結構驚きました。
で、できるだけ(他の人の同意があれば)対応する方向にしたいのですが、
現行のかちゅ～しゃをサーバー側から見ると、２つ程欠点があります。
１つ目は、If-Modified-Sinceを付加していないこと
２つ目は、常に１バイト以上の送信をリクエストすること
です。
どちらも本質は同じで、更新がなくてもファイルI/Oの負荷が発生するため、
必要以上にサーバーに負担をかけることになっています。
多分、かちゅ～しゃのidxに保存されているのは
サーバー側のLastModifiedではなく、ローカル側のGET日時だと思うので
難しいとは思いますが、可能ならば、If-Modified-Sinceをお願いしたいです。
実際の対応ですが、
まだwsockspyのソースもろくに読んでいないので
外れたことをいってるかもしれませんが、
その形式だと、最終の'\n'部をGETしないため、
リクエストのRangeが範囲を超える場合が頻発すると思います。
その場合、
・Rangeの範囲がファイルサイズジャストの次からだった場合
→304 NotModifiedを返す
としたいと思いますが、よいでしょうか？
また、
・Rangeの範囲が大きく超えた場合、及び、指定位置が行頭ではなかった場合
はどうしましょう？
かちゅ～しゃでは、
あぼーん等でRangeが範囲を超えていて全体が返された場合でも
(ローカルあぽーん等の結果が無効となるため)
それを利用してログを再構築する事はせず、
常に「ログが詰まった」を表示しているように思います。
ですので、この場合はエラーが起きたことだけを知らせ、
全体は返さないようにしたいと考えていますが、
それでよいでしょうか？
- 773 ：デフォルトの名無しさん ：01/09/30 04:21
- あと、「過去ログが取得できない」問題は、
read.cgi側でAUTO_KAKOをONにすれば即対応可能です。
夜勤さんにお願いするしかないですが。
こうなった場合、最初のGETで取得できなければ、
../kako/や../dat2/をGETするのは完全に無駄なので
DLL側で(302を返すよう)対処してもらえればと思います。
(-ERRの戻りが、「../kako/...で発見」の場合は非対応)
もう１つ、他のツールの作者さんも読んでいると思うので。
この形式での対応は、
Accept-Encoding: gzip
かつ、
User-Agent: Katjusha
の場合だけにしたいと思います。
これは、同様のリクエストは(レス番号さえわかれば)
RAWOUT_PARTIALで対応可能で、
そこで返されるRangeを見ればあぼーん等の検出も可能であり、
ツールの(ソースに触れる)作者から見れば
あまり必要のない機能だと思うからです。
かちゅ～しゃユーザーののgzip移行を促すためにも
あえて厳しくしたいと思います。
- 774 ：デフォルトの名無しさん ：01/09/30 04:25
- あ、以上は>>770でした。
mod_gzip導入については、
特に何もしなくてもいいと思います。
(全鯖導入されたら、index.htm/index.htmlチェックが不要になるので消しますか)
GZIPは、ZLIBが定義されていると再defineされちゃいますし。
- 775 ：デフォルトの名無しさん ：01/09/30 08:07
- cvs復活してるね
- 776 ：デフォルトの名無しさん ：01/09/30 08:50
- http://www.gedoh.org/aki/2ch/current/bbs/
がInternal Server Errorになるよー
- 777 ：770 ◆DLL/lGHE ：01/09/30 09:10
- >>772-773
「Range:」ヘッダは削除して、?raw=nn.xxxxに変換しています。
>・Rangeの範囲がファイルサイズジャストの次からだった場合
>→304 NotModifiedを返す
>としたいと思いますが、よいでしょうか？
よって「+OK 12345/512K」みたいな1行だけが返ってくる
はずなのでとくに考慮は不要です。
内部的に、ファイルサイズジャストでも実際にファイルを読み込
んで処理しているとしたら、その内部処理だけを修正してインター
フェースは変えない(上記のヘッダ行を生成する)ようにしたほうが
いいのではないでしょうか。
>・Rangeの範囲が大きく超えた場合、及び、指定位置が行頭ではなかった場合
>はどうしましょう？
おっしゃる通り、エラーの通知のみでいいと思います。
>あと、「過去ログが取得できない」問題は、
>read.cgi側でAUTO_KAKOをONにすれば即対応可能です。
過去ログに関しては.datをmod_gzipの圧縮対象に指定するという
手もありますね(過去ログの差分取得はあまり行わないでしょう
から)。
>DLL側で(302を返すよう)対処してもらえればと思います。
今でも、「過去ログ倉庫で発見」以外のエラーのときは
無駄なリクエストが飛ばないように対処済みです。
ちなみに、BIG-serverではNot Foundだったとき404を返す
代わりに news.kakiko.com/mentai/ へ飛ばす(302を返す)
ようになっているので、302ではだめです。
- 778 ：770 ◆DLL/lGHE ：01/09/30 09:13
- Last-Modifiedについては、ファイルサイズジャストのとき
中身を読まないように修正すれば結局stat一回だけなので
対応不要だと思っているのですがどうでしょうか?
- 779 ：デフォルトの名無しさん ：01/09/30 09:19
- AUTO_KAKO関係、AUTO_LOGTYPE関係とその周辺を少し変えた。
rawmode時はget_title()等を呼ばないようにした。
subject.txt取得時と!busytime時はMAP_PRIVATEにした。
RAWOUT_PARTIALで、subject.txt取得時のみ、
lsがあってtoがなかったら、lsをto扱いするようにした。
Katjusha_DLL_REPLYを作った。
read.cにデバッグコードが残ってたらごめん。
>>778
LastModifiedの判定の他にサイズ判定をいれたので、要らなくなったです。
- 780 ：デフォルトの名無しさん ：01/09/30 09:26
- ＞「Range:」ヘッダは削除して、?raw=nn.xxxxに変換しています。
あ、そういう意味です。
＞よって「+OK 12345/512K」みたいな1行だけが返ってくる
＞はずなのでとくに考慮は不要です。
これは、read.cgi側の都合です。
+OKを返すときは、通常、HTTPヘッダを全て出力した後、
さらにdatを読みこんで(行数を数える等もして)からなので、
サイズだけでNotModifiedが返せた方が楽だからです。
サイズだけで判定して+OKを返しても大差ないといえばその通りなのですが。
＞ちなみに、BIG-serverではNot Foundだったとき404を返す
＞代わりに news.kakiko.com/mentai/ へ飛ばす(302を返す)
＞ようになっているので、302ではだめです。
「302を返す」は、そのつもり(404の代わり)で書きました。
かちゅ～しゃは302に反応すると思われるので、
見つからない時にはDLLで細工してかちゅ～しゃに302を返すという意味です。
っていうか、cvs修正した直後に>>777(おめでとう)を読んだので、
サイズジャストは+OKではなく、NotModifiedのままです。
直しましょうか？
- 781 ：デフォルトの名無しさん ：01/09/30 09:30
- ruby撲滅スレ
http://piza2.2ch.net/test/read.cgi?bbs=tech&key=1001125342
ruby撲滅スレ
http://piza2.2ch.net/test/read.cgi?bbs=tech&key=1001125342
ruby撲滅スレ
http://piza2.2ch.net/test/read.cgi?bbs=tech&key=1001125342
ruby撲滅スレ
http://piza2.2ch.net/test/read.cgi?bbs=tech&key=1001125342
ruby撲滅スレ
http://piza2.2ch.net/test/read.cgi?bbs=tech&key=1001125342
ruby撲滅スレ
http://piza2.2ch.net/test/read.cgi?bbs=tech&key=1001125342
ruby撲滅スレ
http://piza2.2ch.net/test/read.cgi?bbs=tech&key=1001125342
ruby撲滅スレ
http://piza2.2ch.net/test/read.cgi?bbs=tech&key=1001125342
ruby撲滅スレ
http://piza2.2ch.net/test/read.cgi?bbs=tech&key=1001125342
ruby撲滅スレ
http://piza2.2ch.net/test/read.cgi?bbs=tech&key=1001125342
ruby撲滅スレ
http://piza2.2ch.net/test/read.cgi?bbs=tech&key=1001125342
ruby撲滅スレ
http://piza2.2ch.net/test/read.cgi?bbs=tech&key=1001125342
ruby撲滅スレ
http://piza2.2ch.net/test/read.cgi?bbs=tech&key=1001125342
ruby撲滅スレ
http://piza2.2ch.net/test/read.cgi?bbs=tech&key=1001125342
ruby撲滅スレ
http://piza2.2ch.net/test/read.cgi?bbs=tech&key=1001125342
ruby撲滅スレ
http://piza2.2ch.net/test/read.cgi?bbs=tech&key=1001125342
ruby撲滅スレ
http://piza2.2ch.net/test/read.cgi?bbs=tech&key=1001125342
ruby撲滅スレ
http://piza2.2ch.net/test/read.cgi?bbs=tech&key=1001125342
ruby撲滅スレ
http://piza2.2ch.net/test/read.cgi?bbs=tech&key=1001125342
- 782 ：デフォルトの名無しさん ：01/09/30 09:33
- >+OKを返すときは、通常、HTTPヘッダを全て出力した後、
>さらにdatを読みこんで(行数を数える等もして)からなので、
>サイズだけでNotModifiedが返せた方が楽だからです。
なるほど。「+OK」を返してもらえると私(とかほかのツール
作者)が楽なので結局どちらが楽できるかの問題ですね。
>サイズジャストは+OKではなく、NotModifiedのままです。
>直しましょうか？
面倒でなければお願いします(^^;。
- 783 ： ◆DLL/lGHE ：01/09/30 09:36
- 782も私です。
よく考えたらレス数を求めるには中身を読まなくてはならないから
ほかのツールは関係ないですね。
- 784 ：デフォルトの名無しさん ：01/09/30 09:54
- 仕様書き忘れてました。
今(304を返す仕様)のところ、
・ファイルサイズと一致
304 Not Modified
Content-Type: text/plain
(ヘッダのみ)
・あぼーんされたっぽい(要求Rangeが大きすぎ)
-ERR どこかであぼーんがあったみたいです。
(非圧縮・この時はLast-ModifiedやContent-Encodingを出力しない)
・あぼーんされたっぽい(要求Rangeが大きすぎ)
-ERR どこかであぼーんがあったみたいです。
(ヘッダにLast-ModifiedとContent-Encodingが含まれる)
・続きあり
+OK 27967/512K
・・・
wsockspyのソースを見て問題なさそうだったので、
サイズだけをみてあぼーんが判断できる場合は
非圧縮で返すようにしています。
あと、304を返す代わりに
+OK 0/512K
にする方向にしますね。
- 785 ： ◆DLL/lGHE ：01/09/30 09:57
- >・あぼーんされたっぽい(要求Rangeが大きすぎ)
2つありますけど下のは
・あぼーんされたっぽい(行頭ではない)
ですね。
- 786 ：784 ：01/09/30 10:02
- >>785
ごめんなさい。その通りです。
ところで、他のツールの場合は
必ずIf-Modified-Sinceをつけてくると思いこんでいたので、
「raw=x.xでファイルサイズジャストの場合」というのは
あまり想定していなかったんですが、
もしかしたら、
raw=x.xのリクエスト全てに対して、
「ファイルサイズジャストなら+OKの行のみを返す」
ことを考えた方がいいかもしれませんね。
その方向で考えます。
- 787 ：デフォルトの名無しさん ：01/09/30 10:12
- 仕様が固まったらread2ch.hとconfig.txtの更新もよろしくー
- 788 ：デフォルトの名無しさん ：01/09/30 10:14
- >>787
ChangeLogもね(o^-')b
- 789 ：784 ：01/09/30 10:35
- >>786の変更を加えた。
うーん、でもよく考えたら、If-Modified-Sinceには
「実況禁止」効果を見こんでいた部分があるので、
できれば何か対策が欲しいところでもある。
>>787-788
これからやりまーす。
- 790 ：デフォルトの名無しさん ：01/09/30 10:45
- >>786
OKのみの行を返すときでもLast-Modifiedはあったほうがいいような。
サイズは一致していても変更があったかもしれないし(まれだろうけど)
- 791 ：784 ：01/09/30 11:29
- read2ch.h,config.txt,ChangeLogを更新しました。
Last-Modifiedはどうしましょ？
サイズを見てOKのみを返す場合は、
既にIf-Modified-Sinceのチェックをくぐってしまった時なので、
そういうUAにLastModifiedを返す必要があるかとか、考えたんですが。
まあ、出す分には全然かまわない気もします。
ただ、「偶然の一致」を減らすなら、レス数も数えた方がいいでしょうし。
あと、この場合にはContent-Lengthも返さないので
それも問題ありかもしれません。
- 792 ：784 ：01/09/30 11:46
- サイズを見て+OKのみを返す場合に、条件として
「If-Modified-Sinceがなかった場合」を加えてみた。
- 793 ：デフォルトの名無しさん ：01/09/30 14:00
- おお、mod_gzipはいったんだ。ご苦労様>>夜勤さん
Trying 64.71.134.194...
Connected to piza2.2ch.net.
Escape character is '^]'.
HEAD /tech/index.html HTTP/1.1
HOST: piza2.2ch.net
Accept-encoding: gzip, inflate
HTTP/1.1 200 OK
Date: Sun, 30 Sep 2001 04:55:31 GMT
Server: Apache/1.3.6 (Unix) PHP/4.0.3pl1 mod_gzip/1.3.19.1a mod_ssl/2.3.6 OpenSS
L/0.9.3a
Content-Type: text/html
って 771みると piza2には前から入ってた?
- 794 ：デフォルトの名無しさん ：01/09/30 15:12
- 対応したread.cgiが導入されるまでの間、
かちゅーしゃでの巡回は
今まで以上に無駄な負担を鯖に強いることになるわけか。
巡回が重くなったって言われるのもわかる気がする。
mod_gzipで重くなったってのもあるだろうけど。
- 795 ：デフォルトの名無しさん ：01/09/30 16:41
- Katjusha_DLL_REPLY時には、
getLineMaxで全体を走査する必要がない事に気付いたので、変えた。
そうすると、この形式は、他の?raw=x.xのリクエストに比較して、
(mmapが有効に使える点も含め)負荷的に有意ということになる。
ならば、UserAgentチェックも外して、
他のツールにも積極的に利用してもらうことも考えた方がいいかな？
UserAgentチェックは、かちゅ～しゃ利用者の(変更しての)
非rawモードでのread.cgi呼出を減らせるかも、と考えたからなんだけど。
- 796 ：デフォルトの名無しさん ：01/09/30 18:39
- >>747-749,>>763-765
PATH形式での呼出時、解析された以降の文字列に'/'が含まれるとき、
BASE_DEFINEを出力するようにした。
- 797 ：デフォルトの名無しさん ：01/10/01 04:17
- >>795
UAチェック外すほうに一票。
- 798 ：デフォルトの名無しさん ：01/10/01 10:29
- rawモードでファイルサイズジャストの時にも
Last-ModifiedとContent-Lengthを出すようにした。
raw=.nnn形式のUAチェックを外した。
というのをやったんだが、cvs鯖落ちてるっぽい。
- 799 ：デフォルトの名無しさん ：01/10/01 10:43
- 今はcvs動いてるみたい
- 800 ：デフォルトの名無しさん ：01/10/01 12:15
- >>799
ありがと。
>>798をcommitした。
- 801 ：名無しさんの声 ：01/10/01 16:14
- ｉモード時の要望です。
批判要望板のスクリプト関連要望統合スレッドにも
書き込んだのですが
ｉモードでスレ巡回するときは
決まったスレを見ることが多いので
1-10よりも最新-5レス前 とか5レス前-10レス前とか
今見てるとこから数レス前とかの方が便利です。
現在ｉモードから見る際
ログが流れると1-10を開いてブックマークしてから
編集して見たいレス番号に書き換えて移動って
手順で見ているので何かと不便で博打性も強いです。
手間がかかるかも知れませんが検討をお願いしたいと思います。
- 802 ：デフォルトの名無しさん ：01/10/01 19:53
- >>801
最新10レスというのがなかったか?
- 803 ：デフォルトの名無しさん ：01/10/01 19:54
- 「大きすぎます」対策として、ファイルサイズが
MAX_FILESIZE - 4255バイトを超えたら
フォームを消すようにできませんか?
- 804 ：デフォルトの名無しさん ：01/10/01 19:58
- CGI自身にgzip圧縮の機能がなくても、その先のmod_gzip
が圧縮してくれるかもしれないので、BadAccess中での
gzip_flagの判定とかNN4_LM_WORKAROUNDの処理とか
Katjusha_DLL_REPLYの判定とかはしたいのですが、
これらをGZIPのconditionから外に出せませんか?
- 805 ：デフォルトの名無しさん ：01/10/01 21:49
- >>804
mod_gzipに圧縮をまかせたら、NN4_LM_WORKAROUNDは役にたたないよ。
- 806 ：デフォルトの名無しさん ：01/10/02 00:20
- bbs.cgiがパス対応になったので、USE_PATHとALWAYS_PATHは
オン固定にしましょう。
- 807 ：デフォルトの名無しさん ：01/10/02 00:44
- >>805
mod_gzipが勝手に付けちゃうの?
そうだとしても後2つのこともあるし。
- 808 ：デフォルトの名無しさん ：01/10/02 05:37
- むー、なんか俺には意味が完全には把握できない話が続いている気がする。
>>801の件は、>>802の言うように
「最新10」「前10」「次10」があった気がするのだが。
もう一回確かめて、なければ作る。
上部に欲しいということかな？
もしかしたら、呼出形式によっては表示されないかもしれないので、
・どういう形式のリンクだと不足があるのか(実例を出してもらえるとうれしい)
・その時に、現状のほかにどんなリンク先が欲しいか
を書いてもらえると助かる。
>>803の件は4255というのが「１レスの最大バイト数」なのかもしれないが、
これは>>nnのリンクや改行の数によって左右されないのかな？
よくわからないので、
#define WRITESTOP_FILESIZE 5 として、
MAX_FILESIZE - WRITESTOP_FILESIZE*1024 を超えたら、
スレッドストップ扱いにしてみた。
>>806
USE_PATHとALWAYS_PATHはON固定で良さそうなので、そうした。
RAWOUTも外せない機能ではあるが、
こちらは、「RAWモード専用CGI」の可能性があるので、残しておく。
- 809 ：デフォルトの名無しさん ：01/10/02 05:38
- >>804の意図が一番わからないのだが、
>CGI自身にgzip圧縮の機能がなくても、その先のmod_gzip
>が圧縮してくれるかもしれないので、
これは、mod_gzipがcgi出力も圧縮するという意味だろうけど、
>BadAccess中でのgzip_flagの判定とか
>NN4_LM_WORKAROUNDの処理とか
>Katjusha_DLL_REPLYの判定とかはしたいのですが、
>これらをGZIPのconditionから外に出せませんか?
「これら」というのが何を指しているのかが不明なので、よく理解できない。
「Accept-Encodingを見てgzip_flagを設定すること」を言っているのか、
「rawmode時等に圧縮非対応のリクエストは受け付けない」を言っているのか、
「NN4リクエスト時にContent-Lengthを出力しない」を言っているのか、
「rawmode以外はKatjushaのリクエストを受け付けない」を言っているのか。
出力の圧縮を完全にmod_gzipに任せることになった場合、
#define GZIP/ZLIBを外す事になり、
そのことにより、いくつかのリクエストがBadAccessで弾けなくなり、
特にrawmode関係のリクエストが受け付けられてしまうのがまずいということかな？
それなら、その通りだとも思うけど。
ただ、出力の圧縮を全てmod_gzipに任せる可能性はあるかな？
というか、既に、
http://piza2.2ch.net/test/check.cgiの出力なんかは圧縮されて返ってくるから、
どちらかというと、
・CHECK_MOD_GZIPで、mod_gzipが導入されていれば、圧縮しないで出力する
・BadAccessで、圧縮を受け付けないrawモードのリクエストは弾く
ぐらいでもいいかもしれない。
負荷的にも、mod_gzipに任せた方がいいかもしれないし。
ただ、NN4時にもContent-Lengthを付けてしまう(おそらく)のが欠点か。
- 810 ：801 ：01/10/02 05:50
- >802>808
確認しました。付いておりました。
多謝です。お騒がせして申し訳ありません。
- 811 ：デフォルトの名無しさん ：01/10/02 06:45
- >>809
mod_gzipが入ってるならGZIP/ZLIBとも外したほうが
オブジェクトサイズの節約になるのでは。
とくにZLIBはスタティックリンクされてますし。
で、現状ではGZIP/ZLIBを外してしまうと、たとえば
rawモードの取得をgzip対応クライアント以外に認め
ない機能も消えてしまうと言いたかったわけです。
- 812 ：デフォルトの名無しさん ：01/10/02 07:10
- 了解。
ZLIB/GZIPはOFFにする方向で、
なおかつrawモード時のAccept-Encodingチェックは行うにする、と。
かちゅチェックは、rawモードに含まれるのでそのままでもよさそう。
NN問題はとりあえずあきらめて、
圧縮をmod_gzipに任せ、cgiサイズ(と負荷)が小さくなるようにする。
この方向でよい？
- 813 ：デフォルトの名無しさん ：01/10/02 07:12
- read.cgiが生成するURLは常にパス仕様になりましたから、
create_link()の旧形式を生成してる部分はバッサリ削除
できます。
- 814 ：811 ：01/10/02 07:15
- >>812
かちゅチェックは
main()の
#ifdefined(GZIP) && defined(RAWOUT) && defined(Katjusha_DLL_REPLY)
を
#ifdefined(RAWOUT) && defined(Katjusha_DLL_REPLY)
にしてくださいと言いたかったのでした。
あとはよいと思われ
- 815 ：デフォルトの名無しさん ：01/10/02 08:17
- >>813
#ifndef ALWAYS_PATHに相当する部分なので消してもよいかと思ったが、
一応#ifdef CREATE_OLD_LINKで囲むだけにした。
>>814
read2ch.hは変えなかったが、
GZIP/ZLIBがなくてもAccept-Encodingをチェックするようにした。
- 816 ：デフォルトの名無しさん ：01/10/02 12:57
- たまたまrawモードをブラウザで叩いてみたんですけど、
>>[レス番号] にアンカー入ってるんですけど…こういう仕様ですか？
- 817 ：デフォルトの名無しさん ：01/10/02 13:05
- >>816
bbs.cgiが.datに書き込んでるので仕様です。
read.cgiは仕方ないので指す先を捨ててURLを再生成してます。
- 818 ：デフォルトの名無しさん ：01/10/02 13:16
- >>817
解かりました。有難う御座います。
- 819 ：林檎おいしいよ。 ：01/10/02 16:30
- がいしゅつだったらｽﾏｿ｡｡
ニュー速板で、"最新50"の時、下の「掲示板に戻る」をクリックしたら、
http://news.2ch.net/news/index.htmに行っちゃって、
ブックマーク変更してねっていわれちゃったんですけど。。
私はとっくに変更済みなんですけど、
夜勤さんに念のためここで報告するようにいわれたので。。よろしくです。
- 820 ：デフォルトの名無しさん ：01/10/02 19:43
- どうやらmod_gzipがまだ入っていない板でもindex.htmが
廃止されたみたいなので判定のロジックはばっさり
捨て去ったほうがよさそう
- 821 ： ◆YaKIN/eo ＠夜勤 ★ ：01/10/02 21:00
- お世話になってま～す。
負荷がばかにならないくらいあがっています。
なにやら かちゅーしゃとかが新しくなったとか。。。(詳しく知りません)
で提案なんですが、ご検討していただけないでしょうか?
-------------------------------------------------------------
大きな流れとしては、各ツールの要求に答えていくことなんだけど、、、
うーん 転送量の次は負荷が、
dat を細切れにして、さらに圧縮をかけて転送量を削る方向に
向かっているから、これをやめるのが吉か?
ルールが必要か?
1.dat 読みのときは、一気に全部読む。
2.read.cgi はあらかじめ作ってある xxxxxxxxxxxx.dat.gz を返す。
まずは、プログラム板で聞いてこよう。
- 822 ： ◆DLL/lGHE ：01/10/02 21:04
- 差分はdat経由で読むようにしましょうか?
とりあえず現在開発中のバージョン入れてKatjusha_DLL_REPLY
が使えるようになると負荷が多少は減ると思います。
- 823 ：デフォルトの名無しさん ：01/10/02 21:06
- 夜勤さん、かちゅ"～"しゃです。。。
それとかちゅ用のwsock32.dll作ってる人に聞くと仕様わかるっすよ。
- 824 ：823 ：01/10/02 21:07
- ∑(￣□￣；)!! のんびりし過ぎた！！
- 825 ：デフォルトの名無しさん ：01/10/02 21:21
- プロセス起動数の増加による負荷を下げるなら、
rawモードをさらに拡張して複数dat同時転送とかできませんかね。
- 826 ：デフォルトの名無しさん ：01/10/02 21:26
- read.cgiをApacheモジュールにしちゃえば軽くなるんだろうけど
mod_gzipの導入でもいろいろ交渉したりしなきゃならなかったみたいだから
大変なのかな......CGIプロセス起動しない分軽くなるのは確実だけど
- 827 ：デフォルトの名無しさん ：01/10/02 21:27
- みんな速くなってますます巡回しまくっちゃったりして…
- 828 ：デフォルトの名無しさん ：01/10/02 21:28
- read.cgiが自分でgzipを使うかを動的に選択できるのなら、
raw差分転送である程度以下のサイズのものは圧縮しないようにするとか。
- 829 ：デフォルトの名無しさん ：01/10/02 21:32
- それはmod_gzipがすでにやってたりして…
そういう意味でもmod_gzip任せにしたほうがいいのかも。
- 830 ：デフォルトの名無しさん ：01/10/02 21:33
- >>827
一応一度巡回すると5分間巡回できない制限ありますので、
レス取得の速さは特に大きな問題ではないです。
- 831 ：デフォルトの名無しさん ：01/10/02 21:37
- ん？ 今のread.cgiで使ってるのはgzipじゃなくてzlibでわ？
mod_gzipにやらせるのと負荷的にはあまり変わらないと思うけど......
それにmod_gzipにやらせた場合NN4_LM_WORKAROUNDに相当する処理が
可能かどうかも問題だけど
- 832 ：デフォルトの名無しさん ：01/10/02 21:37
- 巡回がとんでもなく無用な負荷をかけてるってことでしょ。
- 833 ：デフォルトの名無しさん ：01/10/02 21:39
- 同じようなことするバイナリはCGI側に持たせなければ
CGIは軽くなるよ。多少は。
- 834 ：831 ：01/10/02 21:40
- 勘違い 無視してちょ 氏ぬわ
- 835 ：デフォルトの名無しさん ：01/10/02 21:44
- そういえば、UNIX板でやってた頃、これを勧めてた人がいたね。
http://www.fastcgi.com
- 836 ：デフォルトの名無しさん ：01/10/02 21:46
- >>835
cgiのロードタイムは短縮できるだろうけど
fastcgiにするならグローバル変数バシバシなのは一旦見直さないとまずい?
あと、ロードタイムがどれだけ負担になってるのかってのも分からないと…(^^;
- 837 ：デフォルトの名無しさん ：01/10/02 21:51
- とりあえず、
http://www.gedoh.org/aki/2ch/current/bbs/read.tgz
が更新されないので、変更されたファイルを
ftp://readcgi.dyndns.org/incoming/ver5/read.5.24.1.tgz
に置いてみた。
- 838 ：デフォルトの名無しさん ：01/10/02 22:01
- 夜勤さん召喚しますか?
- 839 ：デフォルトの名無しさん ：01/10/02 22:05
- うん、一度これをいれて様子をみてもらったらいいと思う。
(あまり変わらないかもしれないけど)
mod_gzipが導入されている鯖はZLIB/GZIPの#defineを外してもらって。
- 840 ： ◆YaKIN/eo ＠夜勤 ★ ：01/10/02 22:09
- 過去ログ(もうほ更新されない dat)の読み込みが
とてつもなく沢山リクエストが来ているようです。
kako/xxx/xxxxxxxx.dat は、あらかじめ xxxxxxxx.dat.gz にしておいて
read.cgi が呼ばれたとき、そのまま返すとかにしたいなぁ
- 841 ：デフォルトの名無しさん ：01/10/02 22:11
- >>840
.dat.gzを用意しておいてmod_gzipでdatを処理対象に加える
だけで解決します。
- 842 ： ◆YaKIN/eo ＠夜勤 ★ ：01/10/02 22:14
- 今、 salad//anime/kako で実験しています。
.htaccess に dat も gz 読めよって書けばいいのかな?
(こっそり、書式教えてくだせ～)
- 843 ：デフォルトの名無しさん ：01/10/02 22:16
- mod_gzip_item_include file \.dat$
です。
- 844 ： ◆YaKIN/eo ＠夜勤 ★ ：01/10/02 22:21
- う～ん、よく考えたら、 xxx.dat.gz だけ置きたいんだなぁ。
anime/kako/xxx/xxxxxxxxxx.dat.gz だけってことです。
dat の本体は、見えないところで管理ということなんです。
ということは、kako を見る場合はツールが直接 .dat.gz を
取り込めばいいのかな?
anime/kako/xxx/xxxxxxxxxx.html
anime/kako/xxx/xxxxxxxxxx.html.gz
anime/kako/xxx/xxxxxxxxxx.dat.gz
の三つを可視にすると、
- 845 ：デフォルトの名無しさん ：01/10/02 22:22
- サフィックスに関わりなくテキストを圧縮するということなら
mod_gzip_item_include mime "text/.*"
でいいと思うけど......しかしNN4_LM_WORKAROUNDを
.htaccessでどうやって実現できるのかが難儀......
- 846 ：デフォルトの名無しさん ：01/10/02 22:24
- >>844
確かに非圧縮版のdatを置いておく意味はあまりありませんね。
- 847 ：デフォルトの名無しさん ：01/10/02 22:25
- >>845
mod_gzipのデフォルト設定でtext/.*は圧縮対象に含まれてる
はずなんですけど.datはなぜか指定してやらないと圧縮対象
にならないみたいなんです。
- 848 ：デフォルトの名無しさん ：01/10/02 22:25
- hoge.datのリクエストにhoge.dat.gzを返すということなら
mod_gzip_can_negotiate Yes
かな？
- 849 ：デフォルトの名無しさん ：01/10/02 22:29
- >>848
index.html.gzで負荷が減ったそうなのでそれはすでに
オンになってるはず。
- 850 ： ◆YaKIN/eo ＠夜勤 ★ ：01/10/02 22:29
- ツールさんたちは、直接 .dat.gz を読むということで、いかがでしょうか?
というか、そうしたいです。
kako の中の話です。
anime/kako/xxx/xxxxxxxxxx.html
anime/kako/xxx/xxxxxxxxxx.html.gz
anime/kako/xxx/xxxxxxxxxx.dat.gz
の三つを可視にするという仕様です。
ほとんどの場合 kako 下のファイルは、できあがったら
そのままで変更はかからないので、あまり細工は必要ないと思います。
- 851 ：デフォルトの名無しさん ：01/10/02 22:31
- 異議ありません。
- 852 ：デフォルトの名無しさん ：01/10/02 22:31
- >>847 ん？ オレのとこで実験すると mod_gzip_item_include を何も指定しないと
*.txtも圧縮しないで返ってくるし 逆に mime "text/.*" を指定すると
*.datでも圧縮されて返ってくるけど？
- 853 ：デフォルトの名無しさん ：01/10/02 22:32
- mod_gzipに任せちゃった方がCPU負荷は減るはず。
lawモードはほとんど何もする必要がない(.datを更新分だけ
出力してくれればいい)のだから、別cgiにすることでオーバー
ヘッドを減らせないだろうか。
- 854 ：デフォルトの名無しさん ：01/10/02 22:33
- >>850
それで良いと思います。2chあってのツールですし、
作者さん達にも納得してもらえると思いますです。
- 855 ： ◆YaKIN/eo ＠夜勤 ★ ：01/10/02 22:35
- あっ 今日の話は、過去ログ(dat落ちして、html化されたスレッド)の話ですので、
ライブなスレッドとか、html化待ちしているやつは、また別の話ですよ。
325KB
新着レスの表示
スレッドリストへ戻る 全部 前100 次100 最新50
0ch BBS 2004-10-30