【雪だるま】bbsd⇔各cgi間のI/F仕様について考え・詰めていくスレッド
■ このスレッドは過去ログ倉庫に格納されています
雪だるま作戦において開発をすすめているbbsdでは、
+- [ フロントエンドサーバlive22x1 ] -- ユーザは
[ バックエンドサーバlive22 ] -+- [ フロントエンドサーバlive22x2 ] -- live22xという代表名で
制御プログラムbbsd +- [ フロントエンドサーバlive22x3 ] -- これらにアクセス
| | | dat直読みや、
dat subject.txt subback.html bbs.cgiやread.cgiやofflaw.cgi、
書きこみログ(芋掘り)ファイルなど (こちらは基本的に書き込み操作なし)
(書き込み操作はこちらで)
# 復帰/削除cgiなどについては、さてどっちかな => 今後の課題
という形で「ユーザの相手」と「各種ファイル処理」を複数のサーバに分業することにより、
さらなるパフォーマンスの向上を目論んでいます。
つまりこの場合、dat/subject.txt/subback.htmlは
バックエンドサーバで動作するbbsdというプログラムがリクエストに応じて生成し、
更新や場合によっては削除する形となります。
ということで、bbs.cgiをはじめとする従来２ちゃんねるで動いているcgiでは、
これらが同じサーバにあるつもりでファイル操作をしていましたが、
上記に示すように、少なくとも元本は同じサーバにはなくなるため、
何らかの形で対策を考慮する必要があります。
また現在、ID生成の種やSamba24や
timcount/timeclose等の規制関係で使用している一時ファイル等、
複数のフロントエンドサーバが同じ情報を、
何らかの形で共有する必要があるものもあります。
このスレッドではこれらの処理方法や実装方法について考えながら、
bbsdに持たせたい・持つべきな機能をあぶり出し、実装仕様を詰めていくことを目標にしています。 ということでちょっとだけ覚悟を決めて、bbs.cgi を少しずつ読んでみたりしています。
私はまずは「今のbbs.cgiの実装そのままでは雪だるま仕様で動きそうもない」と思った件について、
ここにひとつずつ、書き込んでいくことにしようかなと思っています。
本業しながらなのでたぶんだらだらと進んでいくことになると思いますが、何卒ご容赦くださいです。
特に、bbsd の実装をすすめていただいている SunOS さんには、
今後ともおつきあいをよろしくお願いいたします。
で、dat直読みをどうするかについては、別スレでやりたいと思っています。
(たぶんApacheのmod_proxyを使うような気がしています) ということで、まずはぼちぼちとすすめていこうかなと。 >>1
乙です。ところでVIP運用情報にタイムリーなんか変なの もう dat は google base に投げ入れてしまえ とりあえず、パターン分けしていくです。
・ファイルの単位
A 板ごとに一つ(1単位)
B サーバごとに一つ(1単位)
...
Z その他
・更新頻度
a たまに
b 1日に1回
c 1スレ立つごとに更新
d 1書きこみごとに更新
...
z その他
(イメージをつかんだいただくための例)
1-A-a SETTING.TXT
1-B-a キャップのデータ(news18, news19を除く)
1-A-d timecount/timecloseのデータ
1-B-d Samba24のデータ
ということで要素を洗い出して、こんなふうに場合わけして、
そのうえで、
一) バックエンドで一元管理しないといけなそうなもの
二) バックエンドにある原本を、ゆっくりフロントエンドに配布すればよいもの
三) 別のところで作ったものを、フロントエンドに個別に配布すればよいもの
...
百) その他
というふうに場合わけして、上記 一) になったものを、bbsd の配下に入れることになるのかなと。 2. 恋人よ半年が過ぎ 逢えないが泣かないでくれ
ついに bbs.cgi に触れる覚悟を決めたむむむ。
しかし、そこに待ち受けていたのは巨大なカオスソース。
読み始めたむむむにはもはや引き返す道は無くなっていた。
果たして、bbs.cgi はどうなる？！
〜 第14章 むむむの覚悟 〜 今まで読んでわかったもの その1
整理番号 タイプ ファイル 分類
[1-1] 1-A-a SETTING.TXT 二
[1-2] 1-A-b IDを作るための種ファイル 一
[1-3] 1-B-a index.htmlの広告ファイル1 三
[1-4] 1-B-a index.htmlの広告ファイル2 三
[1-5] 1-B-a ●規制用ファイル 三
[1-6] 1-B-a リモホ規制用ファイル 三
[1-7] 1-B-a Rock54用データファイル 三 live22xに鯖の情報入れて置いて、板に書き込むとその鯖のdatフォルダに行くようにしたりするの？ 単位新規追加
C bbspinkのサーバごとに一つ(1単位)
[1-8] 1-C-a bbspinkのみの広告ファイル 三 >>17
んーと、そういった実装のことを考えるのは、まだまだこれからかなと。
>>15
おじさんの努力により、昔ほどのカオスじゃなくなりました。
http://b01.kakiko.com/test/read.cgi/mumumu/1118847600/ >>19
むむむさんなら「カオス」に突っ込んでくれると思った。
今は反省している。
おいちゃん頑張り過ぎなのよ(´･ω･`) [1-9] 1-A-c スレッド立てすぎです、のための記録用ファイル 一
[1-10] 1-A-d timecount/timecloseのための記録用ファイル 一 メモ:
・datそのものや、datが入っているディレクトリを直接触っているものは、
何らかの対策を行う必要あり。
例:
ごめんなさいリミッター(datの数をreaddirで数えている)
スレッドの容量による制限(unless( -s $DATAFILE <= 512000)) メモ:
・立てようとしたスレッドキーじゃないキーでスレッドが立つケースの考慮要。
例えば1100000000でリクエストしたけど、1100000001でスレッドが立つ場合。
ごめんなさいリミッター2のところともからむ。
参考:
http://qb5.2ch.net/test/read.cgi/operate/1113117347/951 あたり [1-11] 1-B-a キャップのデータ(news18, news19のみ1-A-a) 二
[1-12] 1-B-c ●でスレッド立てすぎです、またにしてくださいの作業用ファイルとフォルダ 一
[1-13] 1-B-d Samba24の作業用ファイルとフォルダ 一 datに追記する/新規作成するところは、既にbbsdにおいて実装済みですね。
で、広告関係はbbsdが読み込んでindex.htmlを作るから、バックエンド側か。
以下修正。場合わけ追加。
四) バックエンドにだけ置けばいいもの
[1-3] 1-B-a index.htmlの広告ファイル1 四
[1-4] 1-B-a index.htmlの広告ファイル2 四
[1-8] 1-C-a bbspinkのみの広告ファイル 四 で、既にわかっているものとして、
・指定したdatをageる => スレッド924で使用
・指定したdatの大きさを得る => 512k制限で使用
・指定した板のdat数を得る => ごめんなさいリミッターで使用
かな。 あと、クラシックさんが入れた板飛びチェックの部分があるか。
でもこれは、>>23 により必要ないかもです。
・指定した板名・キーを持つdatがあるか調べる => 板飛び防止策で使用 芋堀り用のログファイルデータを突っ込むところは、既にbbsdで実装済みのはず。
…とりあえず以上かな。
しばらく、本業します。 ・指定したファイルをtouchする => キャップのあぶり出しで使用
なので、>>26 も含めて、指定したファイルをtouchできる仕組みがあるといいかもです。 さて、仕事に戻る前に。
bbsd 的には、分類 一 と >>26 >>29 に対応するためのAPIを実装いただいて、
分類 四 については、こちらから情報を出して bbsd に入れていただくというのが、
よいと思いますです。
ということで、ここまでのばしておけば即死もなさげかしら。
あとは、またあとで。 …で、外から見て思いあたったところや、
これ忘れてるんじゃないの? と思ったことは、
どんどんここに書いていただけると助かりますです。
このスレの目的は個別のコミュニケーションじゃなくて、
みんなでわいわいしながらすすめていくことなんで。 (1)調べなきゃいけない項目について個別にbbs.cgiがbbsdに質問するのと
(2)書き込みデータをさっさとbbs.cgiからbbsdに渡して、bbsdが各項目をチェックする(1つでも駄目だったらエラーを返す)のと
どっちがええの？
なんでかっていうとさ、512k制限で思った。
1000超えたスレッドとかスレストされたスレッドもbbs.cgiかbbsdかで調べなきゃいけないんじゃ？ 俺の記憶だと
スレストや、レス数1000を超えたでパーミッションが落とされるんじゃなかったっけ？
エラーメッセージが1000超えとスレストは
ＥＲＲＯＲ！
ＥＲＲＯＲ：このスレッドには書き込めません。
512kだと
ＥＲＲＯＲ！
ＥＲＲＯＲ：このスレッドは512kを超えているので書けません！
どうせ書き込み時毎回サイズ調べてるんだったら、サイズオーバーを検出した時点でパーミッション落とすとか。
…なんか本題とずれちゃった >>32
たぶん、事象により個別に考える必要があるですね。
というかまさに「考えどころ」な気がするです。
指摘のとおり、1000超えやスレストのところの判定は、
unless(-w $DATAFILE) とかしているので、
何らかのAPIにより事前に判定するか(1)、bbsdがエラーを戻すか(2)、
いずれにせよどっちが必要ですね。 >>25 場合わけ修正
四) 別のところで作ったものを、バックエンドにだけ置けばいいもの >>37
こういうこと始めますよと公言して皆さんの意見も取り入れーのみたいな
基本的にrootたんが新しい事やる時は抜き打ちはない あとは、、、。各種呪文ですね。
dat、subject.txt、subback.html、index.htmlを触るものは、
何らかの対策が必要かもしれません(必要じゃないかもしれません)。
・各種呪文というか、スキルですか。
- 復帰系
- レス削除
- 透明削除
- スレ削除
- スレ移動
- スレスト・スレスト解除
- サーバまたぎ移動(もうあるのかな)
- 手動むぎゅ
自動なもの
・F22
- dat落ちの際に復帰がかかっている
- いろんなお掃除系
で、SunOSさんにここで一つ質問ですが、
現在のbbsdで「常時かかえて握っている」ファイルは、
subject,txt / subback.html / index.html の3つだけで、よかったんでしたっけか。
それとも SETTING.TXT も抱えちゃうんでしたっけ。 ほんど事情の分かっていないシロートですが。
Samba24は一部の板が違う設定になっているサーバがあるようです。
bubble4 （archivesのみ120秒、その他は30秒）
news19 （newsplusのみ120秒、その他は30秒）
tv8 （tvのみ120秒、その他は45秒）
こういう設定と「Samba24のデータ」は別物？ それとも一部の例外？ (´-`).｡ｏＯ(Rock54のファイルも抱え込むとまずいのかなぁ。。。) >>41
120秒はBe-Type2なので特別仕様じゃないかと >>43
なるほど。そういうことか。
確かに、archives@bubble4とtv@tv8は、
>BBS_BE_TYPE2=checked
ですね。
でも、newsplus@news19は
>BBS_BE_TYPE2=
みたい。ここは、さらに別の場所で設定しているのか？ >>1 乙です．
># 復帰/削除cgiなどについては、さてどっちかな => 今後の課題
bbsd に機能を実装するものはフロント側に置いた CGI から bbsd を呼んで，
bbsd に機能を実装しないものはバック側においた CGI を mod_proxy でそのまま呼ぶ，
って感じでしょうか．まぁこの点はとりあえず今後のことですね．
>>22
>ごめんなさいリミッター(datの数をreaddirで数えている)
これは，bbsd で保持している subject データと実際の dat 数に
乖離が生じるのは，サーバダウン後復帰かける前など限られた条件下のみと
思われるので，subject データからカウントする方が軽そうですが，どうでしょうか？
>スレッドの容量による制限(unless( -s $DATAFILE <= 512000))
このチェックはすでに bbsd に入ってますね（EDQUOT に相当する
エラーメッセージを返します）．
>>33-34
1000 レスや 512kB に到達した時点でパーミッションは 0555 にするようになってます．
で，このパーミッションなら dat に書き込もうとすれば自ずと EACCES になりますね．
>>40
>現在のbbsdで「常時かかえて握っている」ファイルは、
>subject,txt / subback.html / index.html の3つだけで、よかったんでしたっけか。
>それとも SETTING.TXT も抱えちゃうんでしたっけ。
「仮に他のプログラムが変更しても bbsd によって上書きされる」ということなら
subject.txt / subback.html / index.html の3つですね．SETTING.TXT は
読み込み専用なのでそういうことはありません．ただ，設定読み込みのため
mmap() したままにするので，更新時にはいったん別ファイル名でうpしてから
rename という手順でやってもらった方がいいです．
以下，とりあえず現在実装されているものを列記します．
書き込み処理:
my $errmsg = bbsd($bbs, $key, $datline, $footnote, "$logfilename:$logline");
レスの通常あぼーん:
my $errmsg = bbsd($bbs, "delete:$key", $range, "$logfilename:$logline");
レスの透明あぼーん:
my $errmsg = bbsd($bbs, "tdelete:$key", $range, "$logfilename:$logline");
スレッドのゴミ箱逝き:
my $errmsg = bbsd($bbs, "delete:$key", '*', "$logfilename:$logline");
スレッドのファイル自体削除:
my $errmsg = bbsd($bbs, "tdelete:$key", '*', "$logfilename:$logline");
スレを subject から消す:
my $errmsg = bbsd($bbs, 'purge', $keys, "$logfilename:$logline");
subject.txt 等の再生成:
my $errmsg = bbsd($bbs, 'repair', "$logfilename:$logline");
dat/*.dat から html/*.html を再生成:
my $errmsg = bbsd($bbs, 'makehtml', "$logfilename:$logline");
ステータス情報の取得:
my $statmsg = bbsd($bbs, 'stat', "$logfilename:$logline"); >>ごめんなさいリミッター(datの数をreaddirで数えている)
>
>これは，bbsd で保持している subject データと実際の dat 数に
>乖離が生じるのは，サーバダウン後復帰かける前など限られた条件下のみと
>思われるので，subject データからカウントする方が軽そうですが，どうでしょうか？
不可視スレとかよくあるから、厳密にやるならやはりdatを数えた方が
いいと思います。
削除や移動でも、subjectにスレタイが残って、datは消えてるという
パターンもあったりします。
（結局そういうのは復帰してもらってでないと直らない） >>46 ん〜と，現状で発生しているそうした subject.txt と実際の dat との
乖離というのは，スレ立てや削除・移動など subject.txt 更新のタイミングの
バッティングで発生しているのではないかと思うのですが，bbsd では
subject 更新を一元管理するため，原理的にはそうしたバッティングは発生しないはずなんです．
で，乖離が生じるとしたらサーバダウン後の復帰前などの限られた条件下だろうと． >>47
あ。。。
subject＝subject.txtと思ってました。。
すまそです。 とりあえず，今までに挙がった要実装のものはこんなところでしょうか．
>>16
>[1-2] 1-A-b IDを作るための種ファイル 一
>>21
>[1-9] 1-A-c スレッド立てすぎです、のための記録用ファイル 一
>[1-10] 1-A-d timecount/timecloseのための記録用ファイル 一
>>23
>・立てようとしたスレッドキーじゃないキーでスレッドが立つケースの考慮要。
>>24
>[1-12] 1-B-c ●でスレッド立てすぎです、またにしてくださいの作業用ファイルとフォルダ 一
>[1-13] 1-B-d Samba24の作業用ファイルとフォルダ 一
>>25
>[1-3] 1-B-a index.htmlの広告ファイル1 四
>[1-4] 1-B-a index.htmlの広告ファイル2 四
>[1-8] 1-C-a bbspinkのみの広告ファイル 四
>>26
>・指定したdatをageる => スレッド924で使用
>・指定した板のdat数を得る => ごめんなさいリミッターで使用
>>29
>・指定したファイルをtouchする => キャップのあぶり出しで使用
>>40
>あとは、、、。各種呪文ですね。 >>41 >>43-44
板別のSambaの秒数データは、bbs.cgi が持っているです。
bbs.cgiを雪だるま仕様にしても、概ねそのまま動くと思っています。
>>42
Rock54のデータ従来通り、
>>16
> [1-7] 1-B-a Rock54用データファイル 三
は、個々のフロント側bbs.cgi(の船)で抱え込めばOKと思います。
つまり、既にbbs.cgiで抱え込んでいるので、
bbs.cgiを雪だるま仕様にしても、概ねそのまま動くと思っています。 >>45
> bbsd に機能を実装するものはフロント側に置いた CGI から bbsd を呼んで，
> bbsd に機能を実装しないものはバック側においた CGI を mod_proxy でそのまま呼ぶ，
> って感じでしょうか．まぁこの点はとりあえず今後のことですね．
そういうことになりますね。
> これは，bbsd で保持している subject データと実際の dat 数に
> 乖離が生じるのは，サーバダウン後復帰かける前など限られた条件下のみと
> 思われるので，subject データからカウントする方が軽そうですが，どうでしょうか？
それで問題ないと思います。
下記にもありますが、subject.txtが信用できるなら、そのほうが軽そうです。
> >スレッドの容量による制限(unless( -s $DATAFILE <= 512000))
> このチェックはすでに bbsd に入ってますね（EDQUOT に相当する
> エラーメッセージを返します）．
了解です。
つまり雪だるま仕様では「書いてみて EDQUOT だったらこのエラーにすればよい」と。
> >>33-34
> 1000 レスや 512kB に到達した時点でパーミッションは 0555 にするようになってます．
> で，このパーミッションなら dat に書き込もうとすれば自ずと EACCES になりますね．
つまり雪だるま仕様では「書いてみて EACCESS だったらこのエラーにすればよい」と。 >>45 続き
> >>40
> >現在のbbsdで「常時かかえて握っている」ファイルは、
> >subject,txt / subback.html / index.html の3つだけで、よかったんでしたっけか。
> >それとも SETTING.TXT も抱えちゃうんでしたっけ。
> 「仮に他のプログラムが変更しても bbsd によって上書きされる」ということなら
> subject.txt / subback.html / index.html の3つですね．SETTING.TXT は
> 読み込み専用なのでそういうことはありません．ただ，設定読み込みのため
> mmap() したままにするので，更新時にはいったん別ファイル名でうpしてから
> rename という手順でやってもらった方がいいです．
なるほど。
「常時抱えて握っている」というのは、mmap() したままにする、とか、
open() したままにする、という意味でした。
個々の dat は、握らないのですね。
言い替えれば「bbsdにお伺いを立てずに今まで通り更新してもよいのか、
上記のようにアトミック性を考慮した更新をする必要があるのか、ということを
言っていました。
わかったこと: SETTING.TXT を変更する cgi は、変更する必要あり。
手でむぎゅる場合も、cp してそっちをいじって mv する必要がある。 >>45 さらに続き
> 以下，とりあえず現在実装されているものを列記します．
> 書き込み処理:
> my $errmsg = bbsd($bbs, $key, $datline, $footnote, "$logfilename:$logline");
これで、スレ立ても大丈夫なのかしら。
あと、それぞれのAPIの戻り値の意味を教えていただけると助かります。
> レスの通常あぼーん:
> my $errmsg = bbsd($bbs, "delete:$key", $range, "$logfilename:$logline");
> レスの透明あぼーん:
> my $errmsg = bbsd($bbs, "tdelete:$key", $range, "$logfilename:$logline");
> スレッドのゴミ箱逝き:
> my $errmsg = bbsd($bbs, "delete:$key", '*', "$logfilename:$logline");
> スレッドのファイル自体削除:
> my $errmsg = bbsd($bbs, "tdelete:$key", '*', "$logfilename:$logline");
削除系は、このへんを呼べばよいと。
subject.txt のつじつまは、合うのかしら。
あとは、スレスト処理ですかね。
> スレを subject から消す:
> my $errmsg = bbsd($bbs, 'purge', $keys, "$logfilename:$logline");
これは、スレ削除すると必要?
> subject.txt 等の再生成:
> my $errmsg = bbsd($bbs, 'repair', "$logfilename:$logline");
> dat/*.dat から html/*.html を再生成:
> my $errmsg = bbsd($bbs, 'makehtml', "$logfilename:$logline");
このへんは復帰処理に組み込む、ってことですね。
> ステータス情報の取得:
> my $statmsg = bbsd($bbs, 'stat', "$logfilename:$logline");
これは、何が戻って来るんでしたっけか。 >>52
>個々の dat は、握らないのですね。
握りませんです．
>>53
> > 書き込み処理:
> > my $errmsg = bbsd($bbs, $key, $datline, $footnote, "$logfilename:$logline");
>
>これで、スレ立ても大丈夫なのかしら。
>あと、それぞれのAPIの戻り値の意味を教えていただけると助かります。
これはスレ立て・レス追加兼用ですね（どちらであるかは $datline 中のスレタイフィールドに
文字列が入っているか否かで判断しています）．$errmsg とあるのはすべて，成功時は空文字列，
失敗時はそれを示すエラーメッセージとなります．ただし，スレ立ての成功時は
>>23によりスレッドキーを返すよう変更する方向となりますかね．
> > レスの通常あぼーん:
> > レスの透明あぼーん:
> > スレッドのゴミ箱逝き:
> > スレッドのファイル自体削除:
>
>削除系は、このへんを呼べばよいと。
>subject.txt のつじつまは、合うのかしら。
そうですね．subject も含めて処理します．
> > スレを subject から消す:
>
>これは、スレ削除すると必要?
上記 API によるスレ削除の場合は不要です．F22 による dat 落ちなどによる
利用を想定したものです．
> > subject.txt 等の再生成:
> > dat/*.dat から html/*.html を再生成:
>
>このへんは復帰処理に組み込む、ってことですね。
そうですね．
> > ステータス情報の取得:
>
>これは、何が戻って来るんでしたっけか。
これは各種 CGI の処理とは直接関係ないですが，チューニングなどの際に
参考になるように各種情報を返します．まぁ百聞は一見にしかずで
実際に呼んでみるとわかるかと思います． >>53
中身を見てないで、動作だけのお話しですが、
スレッド移動は、恐らくdatを移動した後、subject.txtの
一番下に、直接スレッドキー＋タイトルを書き込んでる
と思います（必ず移動後に、subject.txtの一番下に
移転したスレッドが現れますので）。
スレストは、subject.txtに対しては何もしてません（多分）。
スレ削除は、subject.txtからスレッドキー＋タイトルも
削除しているようです。 >>55
> 握りませんです．
なるほど、F22は従来通りdatを落としてよいと。
# で、つじつま合わせのためのAPIもあると(下記)。
> （どちらであるかは $datline 中のスレタイフィールドに
> 文字列が入っているか否かで判断しています）．
了解です。
新スレかどうかの判定部分ではこんなかんじ↓のことをしているので、
bbs.cgiとも親和性がよいです。
#subjectがあれば新規スレッド
if($GB->{FORM}->{'subject'} ne ""){
で、
> ただし，スレ立ての成功時は
> >>23によりスレッドキーを返すよう変更する方向となりますかね．
としていただけるとありがたいです。
> そうですね．subject も含めて処理します．
了解です。
であれば、削除後の復帰処理は要らないというか、
呪文を対応させる時はそういうふうにする必要があると。
> F22 による dat 落ちなどによる
> 利用を想定したものです．
さすがです。
> まぁ百聞は一見にしかずで実際に呼んでみるとわかるかと思います．
やってみます。
というか、ソース読んでみればいいのか。
>>56
情報提供助かります。
このへんは、対応APIを組み込めばいけそうなかんじですね。
呪文の名前とか使い方とか、全然知らない(というか、調べないようにしている)私。
# 各種呪文を誰が雪だるまに対応させるのかとか、、、。
# 呪文のを知っている人が自然にやってくれますよ、うん。
# …などと、奈良県のほうを向いて、唱えておこう。そうしよう。 編集長様降臨されませませ…
神様ほっとけ様あらいぐま様…
(；-人-)南無阿弥陀仏南無阿弥陀仏… >>65
雪だるまと言われたからこっちに来たのだろう、と ってここ雪だるまは雪だるまでも難民じゃないじゃん！
誤爆ｽﾏｿ とりあえず，仕様がはっきりしていて実装も比較的容易なものから順次やっていきます．
----------------------------------------------------------------------
指定した板の dat 数を得る:
my $ndats = bbsd($bbs, 'getndats', "$logfilename:$logline");
指定した dat を age る:
my $errmsg = bbsd($bbs, 'raise', $key, "$logfilename:$logline");
指定したファイルを touch する:
my $errmsg = bbsd($path, 'touch', $mtime, "$logfilename:$logline");
# $mtime は Unix 時間（0 なら現在時刻にする）
スレ立ての成功時はスレッドキーを返すよう変更
----------------------------------------------------------------------
ここまで実装しますた．
で，以下のはどのような仕様にするのがいいんでしょう．引数・戻り値や処理内容など......
[1-2] 1-A-b IDを作るための種ファイル 一
[1-9] 1-A-c スレッド立てすぎです、のための記録用ファイル 一
[1-10] 1-A-d timecount/timecloseのための記録用ファイル 一
[1-12] 1-B-c ●でスレッド立てすぎです、またにしてくださいの作業用ファイルとフォルダ 一
[1-13] 1-B-d Samba24の作業用ファイルとフォルダ 一 >>70
おつです、おつです。
そのへんについては、bbs.cgiで扱っている情報の種別・内容などを
書ける範囲でここに書いていくです。
今日はちと遅いので、明日以降にでも。 壁|A`).oO(なんか面白そうなスレだな・・・・見守ってみるか さて、いよいよ「詰めていく」をはじめようかと。
まずは、
[1-2] 1-A-b IDを作るための種ファイル 一
についてです。
IDの種は、板ごとにファイル(以下、種ファイルと呼ぶことにします)で持っていて、
そのフォーマットは、
YYYY_MM_DD<>xxバイトのバイナリ
となっています。
# YYYY になったのは、今日からです(w。
<> はセパレータです。
ようは、「日付」と「xxバイトの種」を、
板ごとに一セット、ファイルで記録していると考えていただければ、よいと思います。
(続く) で、bbs.cgiは、このような動作をするようです。
まずbbs.cgi船が出航すると、
いっとう最初の初期化のところで、種ファイルのチェックにいきます。
で、種ファイルがない(最初の状態)、あるいは読み込んだ種ファイルの
日付が今日じゃなかったら、bbs.cgiは種ファイルを作り直して、
作った日付と新しい種をファイルに記録して、以降その種を使います。
この時、xxバイトの種が変わります。つまり、IDが変わります。
で、読み込んだ種ファイルの日付が今日だったら、
読み込んだ種をそのまま使います。つまり、IDは前と変わらないわけです。
で、このファイルは基本的にbbs.cgi船の出航時にしか読み込まないようになっています。
(おじさんならではの、無駄なI/Oをできるだけ少なくする工夫)
つまり、船の再利用(2回目以降の実行)の時は、既に読んでいる種ファイルの
日付(2回目以降の実行なので、既にメモリ上にあります)のチェックだけをして、
2回目以降に起動された時の日付と比較しています。
その結果「まだ同じ日付」だったら、今メモリ上にある種を使い回すことにして、
ファイルの作り直し・読み直しをしません。
日付が違っていたら、作り直しをします。
ということで、日付が変わったら、その時点で船が生きていてもIDだけは変わるように、
私の知らない間に、いつの間にか改良が施されていたようです。 で、雪だるま環境では、この種ファイルは、複数あるフロントエンドで
同じものを共有する必要があります。
でないと、担当したクライアントごとに、IDが変わってしまいます。
しかも、0:00になったことをbbs.cgiが検知すると、
ファイルを更新する操作がかかります(サブルーチンになっています)。
なので、雪だるま環境では、こんな動きになると思います。
・bbs.cgiは最初のいっぱつめでbbsdに「板名」「今日のID種ちょうだい」と言う
・bbsdは「その板の今日のIDの種はこれだよ」と、16バイトのバイナリをbbs.cgiに返す
・bbs.cgiはディスク上(メモリディスクがベター)に、今まで同様に記録する
・bbs.cgiの動き的には、あとは今までと一緒
(続く) ということでbbsdでは、
・bbs.cgi に該当リクエストを聞かれた時点で、
もしファイルがなければ、public_html/板名/md5.cgi などという名前で、
>>73 のフォーマットのファイルを作成する
・もし>>73のファイルが既にあり、今日の日付だったら、
その中身の種を返す
・日付が変わっていたら、ファイルを作り直して、作り直した結果の種を返す
のように動く API を、一つ用意していただくとよいと思うです。
種は例えば /dev/random いくばくか読むなどして、16バイトのバイナリを、
板ごとにユニークに作っていただければよいです。
まずはこんなところで。 >>76 補足
> ・bbs.cgi に該当リクエストを聞かれた時点で、
> もしファイルがなければ、public_html/板名/md5.cgi などという名前で、
> >>73 のフォーマットのファイルを作成する
作成したうえで、呼び出し元に種を返さないといけませんね。はい。
そんでは、今日はねるです。 > [1-9] 1-A-c スレッド立てすぎです、のための記録用ファイル 一
のところを少しずつ読みはじめています。
ふーむ、、、。 簡単にいえば、行単位でのスタック処理ですね、これ。
> [1-10] 1-A-d timecount/timecloseのための記録用ファイル 一
も、同じようなスタック処理の様子。
汎用スタックルーチンを bbsd 側で作ってもらうのが、よさげな予感。 スタックというか、FIFOか。
少なくとも [1-9] はそういう動き。 [1-9] 1-A-c スレッド立てすぎです、のための記録用ファイル 一
これは、以下のようなFIFO用汎用APIをbbsd側で作っていただければいけると思います。
・板別FIFOへのデータ登録・チェックAPI
- 「板名」「FIFOファイル」「FIFO段数」「登録キー」「登録データ」を引数として、bbs.cgiから呼び出し
(例)
* 板名 operate
* FIFOファイル ほにゃらか.cgi (バックエンド側で public_html/operate/ほにゃらか.cgi となる)
* FIFO段数 数字(整数)
* 登録キー 数字(整数)
* 登録データ 文字列
1) FIFOファイルがなければ作成する
2) FIFOファイルがあった場合、中を調べて、
2-1) 既にFIFO中に同じ「登録キー」があったら、「もうそのキーはあるよ」をbbs.cgiに返す、
FIFOの順番はいじらない
2-2) 「登録キー」がなかったら、指定された「登録キー」「登録データ」をFIFOファイルに記録し、
「正常に登録できた」をbbs.cgiに返す
指定されたFIFO段数を超えた分は、古いものから順にFIFOから削除する FIFOファイルは、以下のフォーマットにしていただけるとありがたいです。
登録キー,登録データ
登録キー,登録データ
...
(FIFO段数分これが存在)
登録キー,登録データ
登録データとしては、, や ( ) が入ったりすることもありえます。 これで、bbsd で「スレッド立てすぎです」のためのFIFOを一元管理し、
各フロントエンドの bbs.cgi からスレ立て時に問い合わせることになります。
まだきちんと読んでいませんが、timecount/timeclose のところも
基本的にはこれまたはこれのバリアントで、いけるような気がしています。 ただ、バリアントとはいえ、微妙なことはいくつかしているようです。
たぶん、FIFOとはいえ、[1-10] は [1-9] ほど簡単な構造ではないですね。
いずれにせよ、以降は明日以降とゆうことで。 で、基本路線を書いておこうと。
基本的には、
dat直読みやsubject.txtはApacheの機能で、
すべてのフロントエンドで共有しなければいけないデータで、
かつすばやい同期・反映・浸透が求められるものは bbsd で一元管理し、
すべてのフロントエンドで共有しなければいけないデータで、
バックエンドからゆっくり同期すればいいもの(例: SETTING.TXT やキャップデータ)は、
rsync とかでゆくーり配る
別のマスターから配布しているもの(Rock54のデータとか)は、基本的に今までどおり
といったかんじで。 >>73-87 乙です．ぼちぼちやっていきます．
ところで，各データについてリブートをまたいで保持する必要があるか否か
ということについてはどうなりますでしょうか．リブートをまたいだ保持が
不要なデータについては，ファイルに記録せずオンメモリで完結させてしまった方が
簡単かも知れませんので...... >>88
基本的には、これまでここで出たものはファイルを持たせる方向でお願いしますです。 うぉ、暴発。
IDの種やスレッド立て抑制のためのデータは、さすがに揮発するとまずいです。
IDが変わってしまったり、リブート後にスレッド立ちまくりになったりしてしまうんで、、、。
明日以降ぼちぼちやっていこうと思っている、timecount/timecloseとかは、
場合によってはオンメモリだけでもいいかもしんないです。
これは私もまだ読みきってないんで、別途考慮ってかんじですか。 [1-12] 1-B-c ●でスレッド立てすぎです、またにしてくださいの作業用ファイルとフォルダ 一
[1-13] 1-B-d Samba24の作業用ファイルとフォルダ 一
これやろうかと。 [1-2] 1-A-b IDを作るための種ファイル 一 (>>73-77):
my $md5seed = bbsd($bbs, 'getmd5seed', "$logfilename:$logline");
・ $DOCUMENT_ROOT/$bbs/md5.cgi がなければ作成（"yyyy_mm_dd<>16bytes-seed"），あればそれを読み込む．
・ yyyy_mm_dd を現在の日付と比較し，同じならそのまま返し，違っていたら作り直した上で返す．
[1-9] 1-A-c スレッド立てすぎです、のための記録用ファイル 一 (>>81-82):
my $value = bbsd($bbs, 'chkthr', $file, $n, $key, $value, "$logfilename:$logline");
・ $DOCUMENT_ROOT/$bbs/$file があればそれを読み込む．
・ $key というキーを持つデータが存在すれば，それと対になって記録されていた $value を戻り値として返す．
FIFO データは変更せず．（FIFO の順番だけでなく $value も更新しないということでいいんですよね？）
・ $key というキーを持つデータが存在しなければ，それを FIFO の末尾に追加する．
FIFO 段数が $n より多ければ余剰分を先頭から順に削除．
更新結果をファイルに書き出す．空文字列を戻り値として返す．
----------------------------------------------------------------------
ここまで実装しますた．
で，念のため [1-9] の $value の最大サイズがどの程度になるか教えておいて下さい．
あと，[1-10], [1-12], [1-13] の記録データの最大サイズも同様におながいします． >>93
おつです。おつです。
> （FIFO の順番だけでなく $value も更新しないということでいいんですよね？）
よいです。
> で，念のため [1-9] の $value の最大サイズがどの程度になるか教えておいて下さい．
ホストネームの最大長 + α ぐらいでよいと思います。
安全をみて、512 Bytes とかでよいかと。
> あと，[1-10], [1-12], [1-13] の記録データの最大サイズも同様におながいします．
了解です。
仕様指定時に改めて指定させていただきますです。 >>75-76
日付を管理するサーバが複数あると誤動作の元。
bbs.cgi で日付を管理、bbsd はbbs.cgiからもらった日付と板名をキーにして
テーブル等から種を検索する方法を提案します。 >>95
bbs.cgi は複数のサーバ(live22x1〜live22x3)で動くんで、
それだと、かえって混乱しちゃうような。 >>96
live22x1〜live22x3とlive22はntpで時間合わせしてる前提なので
それほどサーバ間で時間に差があることはないので、レアケースですが、
例えば、以下の状況だと、live22x1だけ一日前の種を使うことにならない？
live22x1:
日付が変わったので bbsd を呼ぶ (2005年11月07日00:00:00)
live22:
まだ日付が変わっていない (2005年11月06日23:59:59)
他の対策としては、bbsd側の種の更新タイミングを、bbs.cgiより１分ほど
早く設定すれば回避出来なくはないかな。
>>97
なるほど、
だとすると、
> ・bbsdは「その板の今日のIDの種はこれだよ」と、16バイトのバイナリをbbs.cgiに返す
の時に、bbsdからbbs.cgiに日付と種を両方返すことにして、
bbsdから戻ってきた日付が万一bbs.cgiの意図したものじゃなかったら、
その結果は捨てることにすればいいのかな。 >>98
いい感じですね
bsd.cgi は返って来たものが意図したものと違ってたら捨てて、
何回かリトライさせればOKだと思う
ところで、bsd.cgi は絶対に種は必要なのかな。
bbsd が保持してるだけじゃ駄目？
; H"の回線が切れたので、ID変わってます ■ このスレッドは過去ログ倉庫に格納されています
