■スレッドリストへ戻る■ 全部 1- 101- 201- 301- 401- 501- 601- 701- 801- 901- 最新50

read.cgi改良スレッド 2

162 :125 :01/09/11 07:34
>>161
CRC32なら、手持ちのソースがあるんですぐなんですけど〜。
算出可能にしておいて、どう使うかを後回しにしておきますか。

>>158 ちょっと手間取り中
ついでに書式ミス等の時に+OKを返してしまうのを修正している。

163 :名無し娘。 ◆vP.bOZFQ :01/09/11 07:45
>>162
32bitはちと重たいかと。。。

164 :125 :01/09/11 07:57
rawoutの修正終了。

>>163
 CRC = (CRC>>8) ^ crc32_table[(CRC&0xFF) ^ *data++];
ループ内はこんなコードなので、bit数が増えたからといって
そんなに重くはないと思いますが。
tableは最初に初期化してますが、データにしちゃえばいいし。
減らすなら8bitかな。16bitは効率悪そう。

165 :125 :01/09/11 09:10
crc32算出は、zlibにいた。(w

>>161
表示外に跳ぶ時にtarget="_blank"を付けた。
condition USE_CHUNK_LINK を追加し、
CHUNKへのリンクと従来方式を選択可能にした。
とりあえず、従来方式ってことで。

今日はここまで。

166 :134,135,137他 :01/09/11 09:36
う、一晩たったのに相手してもらってない。ちょと悲しい。
動作確認はかなり厳密にやったし、
自分でコピペをCVSのソースに反映させても動くことを確認したのに。
(WinCVSの使い方をよく知らない俺が悪いんだけど)

それと、テレホタイムに&ls=101をつけると、
>>120と同じ現象が起こることを確認。
>>120と同じ対処でもいいけど、
表示レス数が限界に達した時に、out_html()内でレス表示後に
(最終レスかを調べずに)「これ以上表示できません」と表示するのが問題なので、
レスを表示する前に判定し、オーバーしてたら注意だけ表示して戻る等、
呼出側(dat_out)とあわせて、もっとうまく解決したほうがいいかも。

167 :デフォルトの名無しさん :01/09/11 09:36
zlibのを使うのなら crc32よりadler32の方が軽いみたい

% time ./test adler32
adler32 = c23cf731
1.18u 0.00s 0:01.14 103.5%
% time ./test crc32
crc32 = 7949b790
5.34u 0.01s 0:05.31 100.7%
% cat test.c
#include <fcntl.h>
#include <stdio.h>
#include <string.h>
#include <unistd.h>
#include <sys/mman.h>
#include <sys/stat.h>
#include <zlib.h>

#define FACTOR 65536

int
main(int argc, char *const *argv)
{
 if (argc < 2) fprintf(stderr, "Usage: %s function\n", *argv);
 else if (!strcmp("adler32", argv[1]) || !strcmp("crc32", argv[1])) {
  int i, fd = open(*argv, O_RDONLY);
  void *mmptr;
  uLong val;
  struct stat st;
  uLong (*fn32)(uLong, const Bytef *, uInt) = !strcmp("crc32", argv[1])?crc32:adler32;
  if (fd < 0) return -1;
  fstat(fd, &st);
  mmptr = mmap(NULL, st.st_size, PROT_READ, MAP_SHARED, fd, 0);
  if (mmptr == MAP_FAILED) {close(fd); return -1;}
  for (i = 0; i < FACTOR; i++)
   val = fn32(fn32(0, NULL, 0), mmptr, st.st_size);
  munmap(mmptr, st.st_size);
  close(fd);
  printf("%s = %lx\n", argv[1], val);
 }
 else fprintf(stderr, "%s: Illegal function.\n", *argv);
 return 0;
}

168 :167 :01/09/11 09:41
>>166 とりあえず>>137はcrc32/adler32等によるチェックサムを実装することに
なれば そのスキームとしてETagを使うことが考えられるね

169 :166 :01/09/11 10:07
ETag話は続きそうなので、思いついた後に考えた事をいくつか。
(>>134は・・・)

まず、負荷の点で、
UAがIf-None-Matchをつけてきたら、
最初に(gzipとか呼ぶ前に)ETagを調べるためだけに
datを読み、レスを走査する必要があり、これがどうなのかな、と。
まあ、304を返せないなら、どうせ全体を返す事になるから、
それと比べればぜんぜん平気なんだけど、
変更された場合には、その後もう一回出力しなくてはいけない。

それと、LastModifiedの返し方によってはLastModifiedが変更されたのに
ETagが変更されないケースが多発するわけで、
下手するとLastModifiedとNotModifiedを両方出力してしまい、
その場合はapacheがどうするか、それを受けたUAはどう扱うか。
両方出力しないようにするには、ソースの変更が結構増えそう。

それから、ETagに反応してくれるUAってのはどのくらいなのかなと。
IEが反応してくれるから、やる価値はあるけど、
反応してくれなそうなUAなら、ETag自体を吐かない手もあるかなと。

もひとつ、基本的にCHUNK_ANCHOR時に有効と考えるんだけど、
(もちろん、それ以外でも有効だけど)
レス自体に変化がなくても、総レス数等が変わり、
「新レス」「901-」等が更新されない場合が出てくるわけで。
その場合、ある程度レスが増えたら値を変えてModified扱いしないと
あまりうまくないわけで、そのあたりをどうするか。
もちろん、1-150等の場合の時間帯制限も考えると、
URIで指定されたレスではなく、
実際に出力するレスから算出しなくてはいけないし。

それに、いろいろ見ると、CHUNK_ANCHOR自体が賛否両論な気がするし。

170 :名無し娘。 ◆vP.bOZFQ :01/09/11 10:11
>>164
何bitにせよ.datの頭から積算するんだから、確かにあまり変わらないかもですね。
でもなんか、もったいない気がしちゃって(笑
>>165
ありがとうございます。
>>166 >>168
>>135 も |  - -) さんがやってくださったようですよ(^^
>>134 方向性は賛成です。余力がなくお役に立てないですいません。

171 :名無し娘。 ◆vP.bOZFQ :01/09/11 10:18
>>169
>それに、いろいろ見ると、CHUNK_ANCHOR自体が賛否両論な気がするし。
CHUNK単位にあまりこだわらない方がいいように思います。
あくまでユーザーインタフェースとして、50なり100なりで区切ったリンクを
提供するにとどめた方がよいかと。
# その意味では、冒頭のCHUNK単位のリンクも target="_blank" で提供した方が
# よいのかもしれません。「前のxxレス」「次のxxレス」というのは、ページを
# 捲っていく感覚だけれども、CHUNK単位の参照は >>xxx のリンクを参照する
# ときの感覚に近いような気がする。

172 :125 :01/09/11 13:05
>>166
申し訳ない。
だが、あれだけの分量を検証しながらマージするのは正直言って面倒。
ここにソースを書きこむんじゃなくて、どこかにアップしてくれ。
ftp://210.170.170.118/incoming/ は...使えない?IP変わったのかな。

あと不具合修正は構わんが、機能的な変更(50- 100-の所)は、選択可能に
作って欲しい。

うーん、眠い〜。

173 :167 :01/09/11 13:21
>>169 If-None-Matchに対応してチェックサムを計算するとすれば
とりあえず dat_read() は二回目に呼ばれた時は すでにBigBufferが
代入されている状態なので その時は何もせずにそのまま帰るようにすれば
いいんでしょうかね でETagの比較をする時に dat_read() を呼んでしまう
ということでいいのでは...と思います(よく見るとdat_read()及びそこから
呼ばれるgetLineMax()では 実際にはパラメータの内st,to,lsはファイル読込
自体には影響しない模様) Last-Modifiedの比較をしてる部分にETagの
比較部分も突っ込んでしまえば 304なのにLast-Modifiedも吐いてしまうと
いうことは避けられると思います

あとネスケはETagに対応してないみたいですが 専用ツールについては
作者さんたちにお願いしてETag対応にしてもらうと(w


話は変わって>>167の付け足し OpenSSLで MD2/MD4/MD5/SHA1 出すと
いうのをやってみた 結論的には......これじゃダメだね(w

% time ./test md2
...メチャ遅くて終わるまで待てなかった(w
% time ./test md4
md4 = 2882041ac5dabc1417ee2d6af4359a7f
4.75u 0.01s 0:04.73 100.6%
% time ./test md5
md5 = ceeaea6c91f07e47c0c4828bc481901f
6.42u 0.01s 0:06.44 99.8%
% time ./test sha1
sha1 = 7fcc4d8c84772fa6d9050abe80820b8e4038d6a9
12.92u 0.02s 0:12.91 100.2%

174 :166 :01/09/11 16:19
本当、申し訳ない。書きこむ前にftp://210.170.170.118/incoming/
をチェックしたんだけど、使えなくて。
変更は、かぶらない限り全然後でもかまわないし、
他にやっていることがあるなら、是非そちらを優先して。

で、不具合(「全部読む」が出ないとか)と、
#ifdef SEPARATE_CHUNK_ANCHOR
化をして、
read.c 11-Sep-2001 09:05 52k
に対してdiff取ったんだけど、
169d168
< #ifdefLATEST_ANCHOR
こんな形式のヤツでいいのかな?
インデントがつぶれるのも不安だし。

もし、それでよければ、そいつ(190行程)をコピペして
前スレに貼るけど。
前スレの944の追加と合わせれば、
ちゃんと動くと思う。

って、もう寝てるか。
それと、CRCの計算等には、全然ついて行けないので、ごめんなさい。
さらに、timeの出力の意味すらしらない。

175 :|  - -) :01/09/11 16:37
diff があるなら -c or -u オプションつきでとってください... patch 当てやすいので。
あと、できるなら mimencode してくれるといいです。
# そのまま貼り付けはインデント崩れるしuuencode は &ltとか出てきてやばい

176 :166 :01/09/11 16:41
すんません、ど素人で。
mimencodeってWin上でどうやったらできます?
何のソフトで変換すればいいんだろう・・・

177 :166 :01/09/11 16:43
すみません、とりあえずgoogle行きます

178 :|  - -) :01/09/11 16:44
>>176
むー。Windowsか。メールソフトで
メールを作成→添付ファイル→送信せず保存→(メールの)ソースを見る
とかやればできないこともないけど...

diffがあるということはcygwin使っているのかな...?

179 :166 :01/09/11 16:48
>cygwin
そうです。かなり古いバージョンだと思うけど。

180 :- :01/09/11 16:58
ttp://www.cc.rim.or.jp/~ikuta/mime_pls/

mime_plsをとってきて、中に入ってる(はず)のwbodyってスクリプトで
MIMEに変換できた・・・はず。

181 :デフォルトの名無しさん :01/09/11 17:05
MIMEってBASE64 encodingのことかな。
これだと確かに[A-Za-z0-9+/]しか使わないから化ける危険少ないかな。
分量増えるからencodeかけるまえに圧縮してくれるといいかも?

182 :166 :01/09/11 17:12
皆さん、どうもです。
いろいろやってみます。
(メーラー添付はタブが残ってたので)
次からの事もあるので、何とかそれなりに簡単で安全な方法を探します。
(とりあえず>>180を落としてみた)

CVSの更新は続けちゃってください。
変更点は自分ではわかっているので、
安定していそうな頃を見計らってdiff -cした結果をどっかに貼ります。

183 :166 :01/09/11 17:37
何とか出来たかも。
前スレ944と951(difs.txt.gz)で
動いてくれることを祈ってみたり。
(-DSEPARATE_CHUNK_ANCHOR)

うまくいってたら、皆さんに大感謝。

184 :デフォルトの名無しさん :01/09/11 17:50
>>183
diffの出力をgzipしてmime encodeしたんですね。
diffの改行コードがCRLFなのに最初ひっかかったYO(笑)
とりあえず手元では当たった。

185 :|  - -) :01/09/11 17:53
>>183
done. あと CGIVER がいつまでたってもver14なのは変なので変更。
こんなの作ってみた→ http://piza2.2ch.net/test/read.cgi/tech/984182993/488

186 :デフォルトの名無しさん :01/09/11 17:57
first_line()とlast_line()を
#ifdef SEPARATE_CHUNK_ANCHOR
で囲まないとwarningが出るね。使ってないって。

187 :|  - -) :01/09/11 18:02
>>186 done.

188 :166 :01/09/11 18:17
125さん、|  - -) さん、180さん、181さん、
本当にお手数おかけしました。
ありがとうございました。
今後、大きい変更があったら、7行スレのを使わせてもらいます。

189 :デフォルトの名無しさん :01/09/11 18:22
今回の変更の説明をconfig.txtに記入キボー

?SEPARATE_CHUNK_ANCHOR
※CHUNK_ANCHORが必要
内容の説明キボー

?CHUNKED_ANCHOR_WITH_FORM
※CHUNK_ANCHOR定義時にのみ有効
select form形式で CHUNKED_ANCHORを表示する
「掲示板に戻る」「レスを全部」「最新レス」との統一が取れていない

190 :デフォルトの名無しさん :01/09/11 18:36
>>189
こんなところ?

▲SEPARATE_CHUNK_ANCHOR
※CHUNK_ANCHORが必要
続くchunkへのanchorは先頭ではなく末尾に表示する

▲CHUNKED_ANCHOR_WITH_FORM
(略)

191 : ◆D69Zsbfg @夜勤 ★ :01/09/11 18:38
いままでのところ ver5.20 の感想。

転送量は、機能が増えたのに 増えも減りもしなかった。
CPU等への負荷は、若干上がった。

という状況です。(piza2 , cheese/tako , saki)

で、お願いなんですが、実はいろいろ変更が予定されていまして、
今 read.cgi で使われている、各フォルダ名を ヘッダーで #define
するような形にして欲しいのです。

具体的に言うと、
dat
temp (仮称 : dat -> temp -> kako のような流れに改造中)
kako (kako以下のフォルダの生成は関数の方がいいかも)

temp に .dat があるときは現在このようなメッセージを出しています。
『隊長! スレッド 999973555.dat は、HTML化されるのを待っているようです。
しばらく待つしかないようです。』

ご検討のほど、よろしくお願いいたします。

192 : ◆D69Zsbfg @夜勤 ★ :01/09/11 18:39
× kako以下のフォルダの生成は
○ kako以下のフォルダ名の生成は

193 :125 :01/09/11 19:02
2220,2221d2155
< #ifndef SEPARATE_CHUNK_ANCHOR
< /* 初期化した数値を再び使うのはダイジェスト関係だけのはず */
SEPARATE_CHUNK_ANCHORで括るのは間違い。
out_resN = 0;を残すかコメントアウトするかはどうでも良いが
conditionで括る程のものではない。

/* out_resN = 0; ダイジェスト用に再初期化 */

ぐらいで、いいんじゃない。

>>174
寝たんじゃない、眠けに耐えながら仕事してたんだ。
ってことで、おやすみ〜。
起きたときに新バージョンがインストールされてるといいな〜。

194 :369 ◆3XTuRnAc :01/09/11 20:03
えと、すんません、IP変わりました。
今日の午前1時か3時ぐらいにIPが替わった模様です。

新しいIPは
210.170.170.18
です。

195 :153 :01/09/11 20:33
おお、夜勤さん自ら要望に来てる

196 :デフォルトの名無しさん :01/09/11 20:47
/tech/dat/1000035521.dat
↓俗に言うdat落ち
/tech/temp/1000035521.dat
↓html化
/tech/temp/kako/1000/1000035521.dat(.html)
って形になるのかな?

すると、
read2ch.h
#define DAT_DIRNAME "dat/"
#define TEMP_DIRNAME "temp/"
#define KAKO_DIRNAME "kako/"
/* .datのディレクトリ構成
 /tech/dat/1000035521.dat
 /tech/temp/1000035521.dat
 /tech/temp/kako/1000/1000035521.dat(.html)
*/
それと、dat直読み禁止=.cgi化と仮定して、
#define DAT_EXTNAME ".dat"
って感じ?

197 :デフォルトの名無しさん :01/09/11 20:48
r2chhtml.h
R2CH_HTML_ERROR_5_DAT
 ・・・"スレッド %s" DAT_EXTNAME "</a> を"・・・
R2CH_HTML_ERROR_5_NONE
 "<a href=\"/%s/" TEMP_DIRNAME KAKO_DIRNAME "\">過去ログ倉庫</a>にも"・・・
/* 使われてないけど */
#define R2CH_HTML_ERROR_999_1
 ・・・
 "<a href=\"/%s/" TEMP_DIRNAME KAKO_DIRNAME "%s/%s.html\">過去ログ倉庫"・・・
 ・・・

read.c
main()
  sprintf(fname, "../%.256s/dat/%.256s.dat", zz_bs, zz_ky);
→ sprintf(fname, "../%.256s/" DAT_DIRNAME "%.256s" DAT_EXTNAME, zz_bs, zz_ky);

html_error()
  sprintf(doko, "../%.50s/kako/%.50s/%.50s.html", zz_bs,
   zz_soko, tmp);
→ sprintf(doko, "../%.50s/" TEMP_DIRNAME KAKO_DIRNAME "%.50s/%.50s.html", zz_bs,
   zz_soko, tmp);

  sprintf(doko, "../%.50s/kako/%.50s/%.50s.dat",
   zz_bs, zz_soko, tmp);
→ sprintf(doko, "../%.50s/" TEMP_DIRNAME "%.50s" DAT_EXTNAME,
   zz_bs, tmp);

あと、これ、まずいんじゃないかな?(9月9日問題か?)
倉庫ディレクトリは4桁に増えると予想してるんだけど。
html_error()
  strncpy(zz_soko, tmp, 3);
→ sprintf(zz_soko, "%d", atoi(tmp) / (1000 * 1000));

198 :デフォルトの名無しさん :01/09/11 20:50
html_error()の後半は、
→ sprintf(doko, "../%.50s/" TEMP_DIRNAME KAKO_DIRNAME "%.50s" DAT_EXTNAME,
   zz_bs, tmp);
だった。

199 :デフォルトの名無しさん :01/09/11 20:53
いや、これも違う。
もう一度よく考える。
→ sprintf(doko, "../%.50s/" TEMP_DIRNAME KAKO_DIRNAME "%.50s/%.50s" DAT_EXTNAME,
   zz_bs, zz_soko, tmp);

200 :デフォルトの名無しさん :01/09/11 20:55
>>196

/tech/dat/1000035521.dat

/tech/temp/1000035521.dat

/tech/kako/1000/1000035521.dat(.html)

ではないかと思われ。
それにこのほうが #define いじりやすそう。

201 :デフォルトの名無しさん :01/09/11 21:03
俺もそう思って書きなおしてた>>200

/tech/dat/1000035521.dat
↓俗に言うdat落ち
/tech/temp/1000035521.dat
↓html化
/tech/kako/1000/1000035521.dat(.html)
で、

read2ch.h
#define DAT_DIRNAME "dat/"
#define TEMP_DIRNAME "temp/"
#define KAKO_DIRNAME "kako/"
#define DAT_EXTNAME ".dat"
/* .datのディレクトリ構成
 /tech/dat/1000035521.dat
 /tech/temp/1000035521.dat
 /tech/kako/1000/1000035521.dat(.html) */

r2chhtml.h
R2CH_HTML_ERROR_5_DAT
 ・・・"スレッド %s" DAT_EXTNAME "</a> を"・・・
R2CH_HTML_ERROR_5_NONE
 "<a href=\"/%s/" KAKO_DIRNAME "\">過去ログ倉庫</a>にも"・・・
/* 使われてないけど */
#define R2CH_HTML_ERROR_999_1
 ・・・
 "<a href=\"/%s/" KAKO_DIRNAME "%s/%s.html\">過去ログ倉庫"・・・
 ・・・

read.c
main()
  sprintf(fname, "../%.256s/dat/%.256s.dat", zz_bs, zz_ky);
→ sprintf(fname, "../%.256s/" DAT_DIRNAME "%.256s" DAT_EXTNAME, zz_bs, zz_ky);

html_error()
  sprintf(doko, "../%.50s/kako/%.50s/%.50s.html", zz_bs,
   zz_soko, tmp);
→ sprintf(doko, "../%.50s/" KAKO_DIRNAME "%.50s/%.50s.html", zz_bs,
   zz_soko, tmp);

  sprintf(doko, "../%.50s/kako/%.50s/%.50s.dat",
   zz_bs, zz_soko, tmp);
→ sprintf(doko, "../%.50s/" KAKO_DIRNAME "%.50s/%.50s" DAT_EXTNAME,
   zz_bs, zz_soko, tmp);

倉庫ディレクトリは4桁に増えると仮定して、
html_error()
  strncpy(zz_soko, tmp, 3);
→ sprintf(zz_soko, "%d", atoi(tmp) / (1000 * 1000));

202 :201 :01/09/11 21:08
まーた間違えた。
html_error()の後半
  sprintf(doko, "../%.50s/kako/%.50s/%.50s.dat",
   zz_bs, zz_soko, tmp);
→ sprintf(doko, "../%.50s/" TEMP_DIRNAME "%.50s" DAT_EXTNAME,
   zz_bs, tmp);

203 :デフォルトの名無しさん :01/09/11 21:20
もしかしたら、read.cgiでtempだけでも読めるように
規制を緩める可能性もあるのかな?

だとすると、あらかじめ dat_out()に
if (isdigit(*zz_ky)) {
 threadStopped = 1;
 /* 過去ログはFORMもRELOADLINKも非表示にするため */
}
を入れておいたほうがいいかもしれない。

204 :203 :01/09/11 21:22
if (!isdigit())

205 :名無し娘。 ◆vP.bOZFQ :01/09/11 21:42
>夜勤さん
.datへのアクセスはどのような形で許容されることになるのでしょう。
read.cgiからraw=xxx.yyy機能だけ切り出して別CGIを用意した方がいいのでしょうか。
あぼーん検出も差分(圧縮)転送もなかなかいい具合ですよ♪>raw=xxx.yyy機能

あと、「投稿日」消滅が確定的ならば、「名前」も無くしちゃっていいと思います。
むしろすっきりするかと。
「xxx :name :yy/mm/dd hh:mm」
の形式で、どうでしょうか。

206 : ◆D69Zsbfg @夜勤 ★ :01/09/11 21:54
>>205
まだ、なにも決まったわけではないのですが、
dat の直読みは、転送量の節約を鑑みて、できなくする方向です。
で、read.cgi がそのまま その機能を代行するようになると思います。
ディレクトリ構成は劇的に変わる予定ですので、試行錯誤をしたいので
出来れば #definr DAT "dat" 等は、サーバ内での相対パス、絶対パス
どちらが入れられても良いように意識していただけるとありがたいです。

なにせ、key が 10 桁になったり、dat を落とすにしても、一人一人は
少ないのですが、数千人が一度に集中したりしているので、いろいろ
改造が必要なんです。。。 よろしくお願いします。

207 :名無し娘。 ◆vP.bOZFQ :01/09/11 21:55
もひとつ、CHUNK_ANCHOR と CREAT_NAME_ANCHOR 関連の方向性で案(ほとんどがいしゅつ)を
提示します。方針を決めておかないとさらに混乱しそうなので、当面の方向性を
確定させないとと思います。いかがでしょうか。

・CHUNK単位のリンクはページ冒頭でなくページ下部で提供する
・CREAT_NAME_ANCHOR はお蔵入りさせる
・>>xxx は旧来通り st=xxx&to=xxx&nofirst=true にする。 >>xxx-yyy も同様。
・LINKTAGCUT は config.txt の通りの動作をすることにして、採用する。
 >混雑時間帯に >>000 形式のレスへのリンクを削除。
 >「レスを全部読む」の増加への対策として、
 >表示範囲外のリンクは削除しないように変更。

208 :名無し娘。 ◆vP.bOZFQ :01/09/11 22:06
>>206
了解です。

.dat をHTML化して提供する場合は、/dat/行き or /kako/行きした .dat に
ついても、read.cgi が全面的にカバーしようと思えば可能です。
# 現在は、過去落ちすると鯖側で .dat と .html の両方を提供していますが、
# .html を作らなくても read.cgi がどうにかできるということです。
# もちろん、このあたりは負荷との相談になるでしょうが。。。

一方で、HTML化されていない生の .dat を必要とするのは、おそらく専用ツールだけ
ですが、専用ツールとのやりとりに(いろんな機能を持って重たくなっている)
read.cgiを走らせるのは非効率ですので、生dat吐きに特化したCGIを別途用意する
ことも考えて良いと思います。
夜勤さんにそのおつもりがあれば、このスレで対応できると思いますが、
いかがでしょうか。

209 :外出ですか? :01/09/11 22:42
これ↓
http://ton.2ch.net/test/read.cgi?bbs=sec&key=996966367&st=40&to=40&nofirst=true

前スレ上げちゃいました。ごめんなさい。

210 :デフォルトの名無しさん :01/09/11 22:48
>>209
imgタグが貼れてるんですね。ていうかbbs.cgiの問題ですよねこれ?
それともread.cgiのbuffer overflowでも突いたのかな? (^^;

211 :デフォルトの名無しさん :01/09/11 22:59
bbs.cgiのホールだって、そのスレでフィーネが言ってた気がしたけど。

212 :デフォルトの名無しさん :01/09/11 23:05
CGIのホールだとは言ってるけど、どのCGIだとは言ってないよね。

213 :名無し娘。 ◆vP.bOZFQ :01/09/11 23:07
今日は速報板等々で夜勤さん大変そうだし、転送量もアレでしょうから、
おやすみしましょうか。。。。

214 :デフォルトの名無しさん :01/09/11 23:47
この事件で転送料が又跳ね上がっちゃいますね

215 :デフォルトの名無しさん :01/09/11 23:55
夜勤さんたら、まだ2chになってないサーバーまで突っ込んじゃてる。
ニュース速報板が4つもあるし。
今日は無理でしょうねえ。

216 :デフォルトの名無しさん :01/09/12 01:39
臨時サーバーで掲示板に戻るがうまくいかないね。
相対pathに変えた方がいいよね。

217 :(゚Д゚)ハァ?スレ発起人@批判要望板 ◆2Pees222 :01/09/12 04:48
>>209-212
http://teri.2ch.net/accuse/kako/998/998399444.html

218 :名無し娘。 ◆vP.bOZFQ :01/09/12 17:14
>>216
鯖がいくつもありますので、そのたびに設定を変えるのは最小限にとどめると
すると、#define すべきなのは >>191 >>200-201 に加えて
・test へのpath
・板 へのpath
でしょうか。piza2など既存の鯖の多くでは、両方とも "" になります。

219 :デフォルトの名無しさん :01/09/12 17:22
旅客機テロの影響か書き込みがパタリと止んでいますが…。
1つ提案です。
REQUEST_METHODがHEADのときは、本体を読み出して
解析しても無駄なのでLast-ModifiedとContent-Lengthを
吐くだけにしましょう。

220 :デフォルトの名無しさん :01/09/12 23:21
絶対pathでも相対pathでも対応可能にするには、
sprintf(buff, "%s%s", *TEMP_DIR == '/' ? "":"../", ...)
のように、強引にやる方法もあるけど、
それよりも、夜勤さんにしろひろゆきにしろ、わかってるんだから、
#define TEMP_DIR "../%s/temp/"  /* %s に板名がはいる */
のように、フォーマット文字列をdefineした方がやりやすいでしょ。
変更個所は>>201-202と同じで。

>kako以下のフォルダの生成は関数の方がいいかも
ということは、kako以下の仕様も変更するかもしれないってことかな?
なら、
/* buffに、倉庫のサブディレクトリ名を生成する
両端の'/'はつけないこと。
例 key="999888777"のとき、buffには"999"を入れる */
#define kako_dirname_copy(buff, key)\
 strncpy((buff), (key), 3)/* 3桁固定 */
/* 999の次を桁にする場合は
 sprintf((buff), "%d", atoi((key)) / (1000 * 1000))
 にする */
のようなものを、そのままread2ch.hに入れてしまえばよさそう。

221 :名無し娘。 ◆vP.bOZFQ :01/09/12 23:45
実装・検討待ちの案一覧

ETag
 >>137 >>143 >>167-169 >>173

HEADリクエストに対しては Last-Modified と Content-Length を吐くだけにする
 >>219

CHUNK_ANCHOR NAME_ANCHOR
 nofirst=true をつけない("最新レス50"にも)
 アンカーへのリンクは冒頭でなく下部に & target="_blank" する
 >>xxx はCHUNK単位で呼び出さない & nofirst=true をつけない
  >>76

URL記述に対するリンク設定も時間帯によらせる
 http://piza2.2ch.net/test/read.cgi?bbs=tech&key=1000035521&st=817&to=817&nofirst=true

「名前:」も「:」だけにする

</dl>するタイミング
 >>126

#define Katjusha_Beta_kisei されていない(元はdefineされていた)

dat,temp,kako
 dat,temp,kako,test,板 のpathをdefineできるようにする
 kakoへのpathは関数で生成する
  >>191 >>196-202 >>216 >>220
 dat,temp,kako を read.cgi で読む
  >>203-208
 datの一部についてのLastModを求める
 ツール作者さんに対応お願い
  * raw=xxx.yyy の形式でリクエスト。 xxx=最終レス番号, yyy=そのときのサイズ。
  * 一行目はステータス:
  * [+OK] の場合は差分のみを送信する。
  * [-INCR] (Incorrect)の場合はすべてのデータを送信する。
  * [-ERR (テキスト)]の場合はなんかエラーが起きた。

condition一覧/SETTING_R.TXT記述一覧
 http://www.gedoh.org/aki/2ch/current/bbs/config.txt
 CUT_DATE_STRINGをON固定にする
 GZIP/ZLIBを整理
 追加すべきもの
  CAUTION_FILESIZE xx, MAX_FILESIZE_BUSY (xx)(デバッグ用)
  SEPARATE_CHUNK_ANCHOR(CHUNK_ANCHORが必要), CHUNKED_ANCHOR_WITH_FORM(CHUNK_ANCHOR定義時にのみ有効)
   >>189-190
  CM_BBSPINK, LOGLOGOUT x, TYPE_TERI, Katjusha_Beta_kisei
  RAWOUT
   rawmode時に圧縮対応していないと弾かれる

222 :名無し娘。 ◆vP.bOZFQ :01/09/12 23:45
NN4.72でgzip圧縮&&Content-LengthがあるとLast-Modifiedが無効
 http://piza2.2ch.net/test/read.cgi?bbs=tech&key=1000035521&st=872&to=872&nofirst=true

mmap時にlockすべきか
 http://piza2.2ch.net/test/read.cgi?bbs=tech&key=1000035521&st=139&to=139&nofirst=true
 http://piza2.2ch.net/test/read.cgi?bbs=tech&key=1000035521&st=425&to=425&nofirst=true

FORCE_304_TIME を鯖負荷に応じて動的に変更する

deflate
 そのうち対応

キャッシュであぼーんされたレスが見える?(詳細不明)
 http://teri.2ch.net/test/read.cgi?bbs=saku&key=996761078&st=408&to=408&nofirst=true

223 :名無し娘。 ◆vP.bOZFQ :01/09/12 23:49
あと、>>207 についてのご意見をお願いしますです。

224 :125 :01/09/12 23:50
とりあえず、あらかた組み込んだ。
#define DAT_DIR "../%.256s/temp" 方式
CREAT_NAME_ANCHORはoffにした。

SEPARATE_CHUNK_ANCHORの動きが気に入らない。
特に、busyの時が不自然かな。

tempやkakoのチェックが面倒だった。

225 :125 :01/09/12 23:52
書き間違いごめん
#define DAT_DIR "../%.256s/dat/"

226 :125 :01/09/12 23:56
>HEADリクエストに対しては Last-Modified と Content-Length を吐くだけにする
Content-Lengthを吐くためには全部やってみないと算出できない。
ZLIBでgzipの時にデータを吐かなくすることは可能。

227 :名無し娘。 ◆vP.bOZFQ :01/09/13 00:40
>>221
>CHUNK_ANCHOR NAME_ANCHOR
> >>xxx はCHUNK単位で呼び出さない & nofirst=true をつけない
訂正。この場合は nofirst=true をつけるべきです(現状のまま)。

>>224-226
おつかれさまです。

228 :デフォルトの名無しさん :01/09/13 01:04
「削除」はするけど「書き換え」はしないという方向かな?
基本的には賛成。
ただ、文字数を考えるとUSE_PATHの時は書き換えてもいいかも
(target="_blank"も結構長さを食う原因だけど)

229 :125 :01/09/13 01:12
Etagですが、ZLIB+gzip使用ならgzipが算出したCRC32をそのまま使う手もあります。
サーバー負荷は減らないが、転送量は減らせるでしょう。
ただ、対応部分のdatが何も変わっていなくてもhtml化の表現が変わると
無効になってしまいます。
23時に突入した時とか、レスが増えてanchorが増えた時とか。

>>222
NN4.xに対応するworkaroundは導入されてます。

230 :名無し娘。 ◆vP.bOZFQ :01/09/13 02:34
>>228
表示中のページ内に該当レスがある場合にのみ「削除」をする、
あとはなにもしない、ってことになります。>>207
target="_blank"がないのは、特に >>xxx の場合は不便なのでぜひ付けて欲しいです。
その他の場合(冒頭部のCHUNK、最新レス50、etc.)はつけない方がいいのかも。。。
>>229
同じことを raw=xxx.yyy の時にやる場合は、html化後の表現には左右されませんよね。
# html化しないんだもの(笑
raw=xxx.yyy ではないときに Etag をはくのは、raw=xxx.yyy なときと比べると
おまけかなと思っているので、それでもよいと思いますです。

231 :125 :01/09/13 03:11
>>230
あれ?Etagの目的は、
 ブラウザで部分読みの場合に出力に変化がないにもかかわらず
 新レスのせいでIf-Modified-Sinceが成立しなくなる。
の対策じゃなかったけ。
ついでにあぼーんチェックの強化に使おうというのは主目的ではなかったはず。

232 :名無し娘。 ◆vP.bOZFQ :01/09/13 08:09
>>231
失礼しました。私の勘違いです。

そもそも、raw=xxx.yyy の時に同一性チェックを行うのは、304を返すためではないので、
304を返すためにおこなうチェック(部分読みの時の同一性チェック)とは方向性が違いましたね。
# 具体的には、後者の場合、転送内容は「鯖側で同一性チェックにかけられる部分」に
# 確定している。前者の場合、転送内容は「.dat全部」か「鯖側で同一性チェックに
# かけられ*なかった*部分」のどちらかになる。
# 前者の場合(rawmode)の同一性チェックは gzip/zlib しないで行うべき、
# という認識で正しいですか?

233 :デフォルトの名無しさん :01/09/13 10:57
webブラウザでver5.20を見てみての>>207さんへの意見です
CHUNK単位のリンクは冒頭のままでよいかと思いますが、
・各CHUNK表示の下部に「次の50レス」へのリンクがほしいです
 最新表示の「新レスの表示」と同じ形式がよいと思います
・表示レス数50以下のCHUNKはいらないのではないでしょうか
 [(レス数-1)/50]*50-49 がトップにくるCHUNKまででよいと思います

234 :デフォルトの名無しさん :01/09/13 11:33
批判要望では、CHUNK単位のリンクが先頭にあると
読み終わった後でいちいち先頭まで戻るのがめんどくさい
という意見が出ていました。

235 :デフォルトの名無しさん :01/09/13 12:18
やはり一番下に前後CHUNKに移動する手段はほしいですね。
そうすることで一つひとつのページのバイト数は多少増えるかも
しれないけど、適切な誘導で無駄なページの閲覧を減らせるの
ならば、結果的に転送量の抑制にもつながるのではないかと。

236 :デフォルトの名無しさん :01/09/13 13:13
あ、>>235は「CHUNK単位のリンクに加えて」という意味です

237 : ◆D69Zsbfg @夜勤 ★ :01/09/13 14:52
999999999 以前のやつは、いままで通り
http://kaba.2ch.net/news/kako/

1000000000 以降のは、こんなディレクトリ構成考えてます。
http://kaba.2ch.net/news/kako/10/000/
つまり今よりは複雑になるので、#define じゃやりにくい
ということです。他の dat落ち、html化等のcgi も随時改造中
ですので、kakoフォルダのロケーションは関数化していただけると
ありがたいです。

注文多くて、すみません。よろしくお願いいたします。

238 :デフォルトの名無しさん :01/09/13 16:51
やはりCHUNK_ANCHORは下にあったほうがいいという意見が
多いですね。

762 名前:名無しさんの声 投稿日:01/09/13 16:44 ID:a2dTsqos
"1- 51- 101- 151- 201- 251- 301- 351- 最新レス50"
って部分"新スレの表示"の左側にも付けてもらえませんかね?
いちいち上まで戻して次の50表示するの面倒です。

239 :デフォルトの名無しさん :01/09/13 17:18
なるほろ。こんな感じ?

/* keyはkey=../kako/xxx等の場合でも、最後の"/"の次の位置が入る。
 普通は数値のみ(の先頭)が入っている。
 現在は、
 "999888777" → "999"
 "1000999888777" → "10/000"
 "1234999888777" → "12/234" */
void create_kakodirname(char *buff, const char *key)
{
 int tm = atoi(key) / (1000*1000);
 if (tm >= 1000) { /* 1000 Over */
  sprintf(buff, "%d/%d", tm / 100, tm % 1000);
 } else { /* 994-999 */
  sprintf(buff, "%d", tm);
 }
}

240 :デフォルトの名無しさん :01/09/13 17:23
夜勤さんがさらにいじりやすい(read.c内の位置を探すのが面倒)ように、
read.cの一番最後に置くか、
↑を全部#ifdef READC_MAINで囲んでread2ch.hに置いて、
read.cを
#define READC_MAIN
#include<read2ch.h>
にしておくのがよい?

241 :デフォルトの名無しさん :01/09/13 17:24
read.c内で一箇所に固めておくに一票

242 :239 :01/09/13 17:25
コメント滅茶苦茶だった・・・

243 :239 :01/09/13 17:58
コメントはともかく、動作がおかしいのはまずい。ってことで、
  sprintf(buff, "%d/%03d", tm / 100, tm % 1000);

244 :デフォルトの名無しさん :01/09/13 18:48
>>nnn形式のリンクをクリックするリクエストって、
全体からするとかなり低い割合なのかな?
すると、転送量に占める割合は、さらに極僅かかな?

>>nnnをクリックして読む場合って、
スレの別の部分を読んでいて、そこから参照するだけだから
書きこんだり、続きを読んだりする事ってほとんどないはず。
すると、1レス分の表示をするために沢山のリンクを提供して
javascriptでNAMEやMAILを取って、FORMを表示するのって、
(1レスを読むためだけには)すごい無駄な気がする。

refererを調べれば参照が元スレ(or index.html)かはわかるから、
その場合で、かつstとtoが同じでnofirst=trueの場合には、
レスの本文だけに特化して、それを返してもよさそう。

CHUNKや「次のnレス」を辿る場合にはカット出来ないから、
>>nnn-mmm形式のリンクにも対応するには、
stやtoの数値を見て判断するとか、
stとtoの差が10以内だったらカットするとか。

いずれにしても、最初に書いたように
変更個所が多岐に渡る割に、効果は不明だけど。

245 :7743 :01/09/13 22:13

倒れる
ソニック

246 :名無し娘。 ◆vP.bOZFQ :01/09/13 23:24
>>245
0x7cのテスト??

247 :ghanyan :01/09/14 00:32
マイナーな2chブラウザを作っている、ghanyanです。
今回、まず初取得時にread,cgiのRAWモードを使おうと思ったのですが、
http://piza2.2ch.net/test/read.cgi?bbs=tech&key=982853418&raw=0.0
では、スレにある\x00の連続が削られてしまい、read.cgiのリザルトコードを
除いた部分が元のdatファイルと一致しません。 これが一致してもらわないと、
過去ログあたりがみんな無効になったり、更新時にはread.cgiを介さない場合に
とても困るんですが。 (URL:http://www.geocities.com/ghanyan/ )

248 :名無し娘。 ◆vP.bOZFQ :01/09/14 00:53
>>247
ご報告ありがとうございます。確認しました。
rawout時には.datをいじくらないようにしないといけないですね。

249 :デフォルトの名無しさん :01/09/14 00:57
printfだから\0を含む行を正しく出力できないわけね。
zlibにはバイナリ出力用の関数ってあるの?
pPrintf(pStdout, "%.*s", BigLine[i+1] - BigLine[i], BigLine[i]);

250 :デフォルトの名無しさん :01/09/14 01:09
こうすればOK?
if (gzip_flag)
gzwrite(pStdout, BigLine[i], BigLine[i+1] - BigLine[i]);
else
fwrite(pStdout, 1, BigLine[i+1] - BigLine[i], BigLine[i]);

251 :125 :01/09/14 02:27
テロ以来コードをcommitする人がいなくなっちゃたな。
私しか差ワット欄。

>>237,239-243あたり
kako_dirname()をread.cの最後に付けた。
>>247-250
dat_raw_out()のデータ出力をprintf系からwrite系に変えた。

252 :125 :01/09/14 02:39
いいかげんに上部と下部に付けるanchorを決めたいところだが。
上:掲示板に戻る 1- 最新レス50
下:次の50レス 1- 51- 101- ... 最新レス50

批判は出るだろうが、bbs=tech&key=xxxxだけの時は、1-50表示にすると
転送量減るんじゃないか。
スレの紹介で範囲を指定しないことが多いわりに全部読むことは少ないと思うが。
全部読みたきゃ、st=1を指定しなさいということで。
削除人は困るのかな?

253 :デフォルトの名無しさん :01/09/14 02:45
>>252
上は現在の範囲より前だけ
下は現在の範囲より後ろだけ
のほうが節約できると思うけどセコすぎ?

254 :デフォルトの名無しさん :01/09/14 03:11
>>253
それすでに実装されてるよ。
SEPARATE_CHUNK_ANCHOR

255 :125 :01/09/14 03:14
>>253
下から上に読む人がどのくらいいるかによるんじゃないかな。
50もさかのぼりながら読むようなら、次は1から読みたくなるんじゃ
ないかと思うけど。

途中から読みたいことがそんなになければ、

上:掲示板に戻る 1- 前の50レス 次の50レス 最新レス50
下:1- 次の50レス 最新レス50

なんてのもありだと思う。

256 :125 :01/09/14 03:17
>>254
実装されているかどうかじゃなくて、推奨設定を決めたい。
いつまでもテスト段階じゃしょうがないでしょ。

257 :デフォルトの名無しさん :01/09/14 03:22
>>252
>批判は出るだろうが、bbs=tech&key=xxxxだけの時は、1-50表示にすると
>転送量減るんじゃないか
 これ名案だと思う(笑)
様子を見るためにクリックしたが、最後まで読む気ないけど全部
表示されるってパターンは割とありそう。

>>255
さかのぼるってのは相対的にかなり少ないんじゃないかと思うけどどうなのかなあ。
古い順に読むのに比べて。

258 :デフォルトの名無しさん :01/09/14 03:25
>>252
>批判は出るだろうが、bbs=tech&key=xxxxだけの時は、1-50表示にすると
うーんしかし、もともとテレホタイムは全部表示しないようになってるような。
ピーク転送量(=テレホタイム)の削減目的では、何も変わらないか。

259 :デフォルトの名無しさん :01/09/14 03:25
>様子を見るためにクリックしたが、
あるある。最新レス50だと最初のほうが読めないから
「レスを全部読む」をクリック。
ただbbs.cgi側にも「レスを最初から読む」に変えてもらうとか
協力を仰がないと「全部表示されません」という文句が
批判要望に殺到しそうな気がする(w

「さかのぼる」については、マーフィーの法則風に言うと
「自分の読みたい参照先は、常に表示範囲の1つ前である」
ので上にはほしい。下にはいらないけど。

260 :デフォルトの名無しさん :01/09/14 07:06
転送量を削減するという名目でひたすら弄ろうとしているように見受けられる。
使い勝手を犠牲にしてまで機能を制限するのは混雑する時間帯だけでいいのでは。
それも、極力操作の変更を伴わない機能制限で充分です。
8月末までの一連の対策で転送量削減の結果は出たはずです。
操作方法を著しく変えて不便を利用者に強いてまで、これ以上の転送量を削減する
要望が管理側から出ていたでしょうか?
開発者はどこを向いて誰のために開発しているの?

261 :デフォルトの名無しさん :01/09/14 08:33
>8月末までの一連の対策で転送量削減の結果は出たはずです。

何寝ぼけたこと言ってんの?
板閉鎖と過去ログ閲覧禁止と強制IDでようやく目標に達しただけなのに。
自分のいる板が閉鎖されてないから他のことはどうでもいいってのが見え見え。

326KB
新着レスの表示

スレッドリストへ戻る 全部 前100 次100 最新50

0ch BBS 2004-10-30