【雪だるま】bbsd⇔各cgi間のI/F仕様について考え・詰めていくスレッド

[1 root▲ ★ NG NG]

雪だるま作戦において開発をすすめている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に持たせたい・持つべきな機能をあぶり出し、実装仕様を詰めていくことを目標にしています。

[73 root▲ ★ NG NG]

さて、いよいよ「詰めていく」をはじめようかと。
まずは、

[1-2] 1-A-b IDを作るための種ファイル 一

についてです。

IDの種は、板ごとにファイル(以下、種ファイルと呼ぶことにします)で持っていて、
そのフォーマットは、

YYYY_MM_DD<>xxバイトのバイナリ

となっています。
# YYYY になったのは、今日からです(w。

<> はセパレータです。
ようは、「日付」と「xxバイトの種」を、
板ごとに一セット、ファイルで記録していると考えていただければ、よいと思います。

(続く)

[74 root▲ ★ NG NG]

で、bbs.cgiは、このような動作をするようです。

まずbbs.cgi船が出航すると、
いっとう最初の初期化のところで、種ファイルのチェックにいきます。

で、種ファイルがない(最初の状態)、あるいは読み込んだ種ファイルの
日付が今日じゃなかったら、bbs.cgiは種ファイルを作り直して、
作った日付と新しい種をファイルに記録して、以降その種を使います。
この時、xxバイトの種が変わります。つまり、IDが変わります。

で、読み込んだ種ファイルの日付が今日だったら、
読み込んだ種をそのまま使います。つまり、IDは前と変わらないわけです。

で、このファイルは基本的にbbs.cgi船の出航時にしか読み込まないようになっています。
(おじさんならではの、無駄なI/Oをできるだけ少なくする工夫)
つまり、船の再利用(2回目以降の実行)の時は、既に読んでいる種ファイルの
日付(2回目以降の実行なので、既にメモリ上にあります)のチェックだけをして、
2回目以降に起動された時の日付と比較しています。
その結果「まだ同じ日付」だったら、今メモリ上にある種を使い回すことにして、
ファイルの作り直し・読み直しをしません。
日付が違っていたら、作り直しをします。

ということで、日付が変わったら、その時点で船が生きていてもIDだけは変わるように、
私の知らない間に、いつの間にか改良が施されていたようです。

[75 root▲ ★ NG NG]

で、雪だるま環境では、この種ファイルは、複数あるフロントエンドで
同じものを共有する必要があります。
でないと、担当したクライアントごとに、IDが変わってしまいます。

しかも、0:00になったことをbbs.cgiが検知すると、
ファイルを更新する操作がかかります(サブルーチンになっています)。

なので、雪だるま環境では、こんな動きになると思います。

・bbs.cgiは最初のいっぱつめでbbsdに「板名」「今日のID種ちょうだい」と言う
・bbsdは「その板の今日のIDの種はこれだよ」と、16バイトのバイナリをbbs.cgiに返す
・bbs.cgiはディスク上(メモリディスクがベター)に、今まで同様に記録する
・bbs.cgiの動き的には、あとは今までと一緒

(続く)

[76 root▲ ★ NG NG]

ということでbbsdでは、

・bbs.cgi に該当リクエストを聞かれた時点で、
もしファイルがなければ、public_html/板名/md5.cgi などという名前で、
>>73 のフォーマットのファイルを作成する

・もし>>73のファイルが既にあり、今日の日付だったら、
その中身の種を返す

・日付が変わっていたら、ファイルを作り直して、作り直した結果の種を返す

のように動く API を、一つ用意していただくとよいと思うです。

種は例えば /dev/random いくばくか読むなどして、16バイトのバイナリを、
板ごとにユニークに作っていただければよいです。

まずはこんなところで。

[77 root▲ ★ NG NG]

>>76 補足
> ・bbs.cgi に該当リクエストを聞かれた時点で、
> もしファイルがなければ、public_html/板名/md5.cgi などという名前で、
> >>73 のフォーマットのファイルを作成する
作成したうえで、呼び出し元に種を返さないといけませんね。はい。

そんでは、今日はねるです。

[78 root▲ ★ NG NG]

> [1-9] 1-A-c スレッド立てすぎです、のための記録用ファイル 一

のところを少しずつ読みはじめています。
ふーむ、、、。

[79 root▲ ★ NG NG]

簡単にいえば、行単位でのスタック処理ですね、これ。

> [1-10] 1-A-d timecount/timecloseのための記録用ファイル 一

も、同じようなスタック処理の様子。

汎用スタックルーチンを bbsd 側で作ってもらうのが、よさげな予感。

[80 root▲ ★ NG NG]

スタックというか、FIFOか。
少なくとも [1-9] はそういう動き。

[81 root▲ ★ NG NG]

[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から削除する

[82 root▲ ★ NG NG]

FIFOファイルは、以下のフォーマットにしていただけるとありがたいです。

登録キー,登録データ
登録キー,登録データ
...
(FIFO段数分これが存在)
登録キー,登録データ

登録データとしては、, や ( ) が入ったりすることもありえます。

[83 root▲ ★ NG NG]

これで、bbsd で「スレッド立てすぎです」のためのFIFOを一元管理し、
各フロントエンドの bbs.cgi からスレ立て時に問い合わせることになります。

まだきちんと読んでいませんが、timecount/timeclose のところも
基本的にはこれまたはこれのバリアントで、いけるような気がしています。

[84 root▲ ★ NG NG]

…さて、とりあえず今日はこのぐらいで。

[85 root▲ ★ NG NG]

ただ、バリアントとはいえ、微妙なことはいくつかしているようです。
たぶん、FIFOとはいえ、[1-10] は [1-9] ほど簡単な構造ではないですね。

いずれにせよ、以降は明日以降とゆうことで。

[86 root▲ ★ NG NG]

で、基本路線を書いておこうと。
基本的には、

dat直読みやsubject.txtはApacheの機能で、

すべてのフロントエンドで共有しなければいけないデータで、
かつすばやい同期・反映・浸透が求められるものは bbsd で一元管理し、

すべてのフロントエンドで共有しなければいけないデータで、
バックエンドからゆっくり同期すればいいもの(例: SETTING.TXT やキャップデータ)は、
rsync とかでゆくーり配る

別のマスターから配布しているもの(Rock54のデータとか)は、基本的に今までどおり

といったかんじで。

[87 root▲ ★ NG NG]

【スレ立て規制】　mesh だけ規制強化する?
http://qb5.2ch.net/test/read.cgi/operate/1086942520/
http://qb5.2ch.net/operate/kako/1086/10869/1086942520.html

を、教えてもらいました。< スレ立て規制