Month: December 2011

HSPでDirectSSTPを送信する

 - by Don

とある事情により3日前からHSPを勉強しています。

なんとか使い方にも慣れてきて、習作としてDirectSSTPを送信するモジュールを作ってみたので晒してみます。

dsstphsp.zip

起動のタイミングによっては送信できないこともあるので何かバグってるんだと思います。よくわかりません。

今年も残り少なくなって参りました。来年もまた良い年になるといいですね。

SSPのMD5ハッシュ値比較

 - by Don

SSPの開発者さんと話してわかったことですが、とある理由によりSSP/2.02.26 からMD5不一致エラーとなるべきファイルも特定の条件で一致とみなす変更が加わったそうです。

これにより、SSP/2.02.25 以前もしくはmateria、CROW、ninix-ayaなどSSP以外のベースウェアではMD5不一致エラーを検出してもSSP/2.02.26以降では検出されないゴーストがいくつか存在することになりました。

チェックリスト

「ウチのゴーストは最新のSSPでさえ更新できればいいのよ。古いSSPや他の処理系なんて知らないよ。」
→ Ctrl + W を押す
「mjd!?ウチのゴーストは大丈夫なの!?」
→ 次へ進む

検証方法

  1. SSP 2.2.00 Fullsetを用意
  2. ネットワーク更新エラーの検証法に従って全ファイル更新できるか確認
「よかった、MD5不一致エラーになるゴーストはいなかったんだ。」
→ おめでとうございます
「MD5不一致エラー出てるんだけど!?どうすればいいの!?」
→ 次へ進む

解決方法

とりあえず全ファイルFTPで(バイナリモードで)アップロードし直してください。

「あれ?MD5不一致エラー出なくなったぞ?」
→ おめでとうございます or 念のため次へ進む
「MD5不一致直らないんだけど…。」
→ 手作業での更新はやめて「そだて」の使い方を覚えましょう

予防方法

全ファイルFTPアップロードで解決した場合。残念ながら、あなたが利用しているサーバは腐っています。

  • サーバを引っ越す
  • あきらめる

余談

SSPはMD5不一致エラーとみなすべき?

サーバが腐っていた場合でもSSPが気をきかせて一致と判定するようSSP/2.02.26から変更が加えられました。これについては(更新履歴で触れられてすらいないことも含めて)様々思うところがあります。ただ、仕様が絡む問題はかなりセンシティブなものなので、今回はあまり触れないことにします。SSPは元々、伺かの仕様に準拠していない不完全なNARすらも無理矢理動かしてしまうことに執念を燃やしているベースウェアですし、製作者が実現したい機能を実現するという当たり前のことを尊重したいと考えます。

悪者を一つ祭り上げるとすれば、「腐ったサーバ」です。大切なゴーストの更新ファイルを置いておくものですから、サーバ選びは慎重にしましょう。

メンテナンス前後のGAE料金表比較

 - by Don

リソース消費量

Before

billing-before

billing-before

これが先週の土曜日、SiReFaSoのメンテナンス直前のリソース消費量。Frontend/Backend Instance Hours はこれ以上増える見込みはないので問題無いですが、Datastore Read Operations が無料割り当て枠の7割超えでちょっと危ないです。

After

billing-after

billing-after

これが先週とほぼ同時刻の今日のリソース消費量。省エネの努力が実って目標の50%を大きく下回りました。

レスポンス速度

Before

response-before

response-before

一度開いたページはキャッシュされるので高速ですが、新規ページを開くにはおよそ1000msかかっています。

After

responce-after

responce-after

現状維持できれば御の字くらいに考えていましたが、新規ページの作成におよそ600ms前後で以前より高速化しています。

内部的な変更点

Datastore Read Operations を減らすには、Datastoreへのアクセスを減らすためにMemcacheによるキャシュを有効に利用する必要があります。以前はリクエストがあったページの情報だけをDatastoreから取り出していましたが、今は全データをMemcacheでキャッシュし、そこからリクエストに応じてgrep検索という邪道な仕様となっています。

アクセス数への依存を断ち切ることはできましたが、今は登録データ数に比例してリソースを消費する仕様です。伺かのゴーストの全体数から考えて、登録数が4桁になるようなことはないだろうという甘い予測に基いて設計されています。仮にそこまで登録数が増えるような時代が来たとすれば、きっとその頃にはSiReFaSoはその役目を終えていることでしょう。

メンテナンス楽屋裏

 - by Don

昨日メンテナンス作業中、アクセスログを確認していた時のこと。

とりあえず100件登録し直しが完了していつもの見栄えに戻った頃です。

log-message

log-message

やたら長い検索ワードがあるなー、と思って気になってブラウザのURLボックスでデコード。

decoded-message

decoded-message

検索ワードでメッセージいただきました。ありがとうございます :)

SiReFaSoメンテナンス完了のお知らせ

 - by Don

SiReFaSoのメンテナンスが完了しましたのでお知らせします。

変更内容

駄デベWikiの方に最新の仕様を反映させておりますが、主なものを以下にご紹介します。

登録要件の厳格化

まず、SiReFaSoの登録要件である以下の3点を厳格に実装し直しました。

  1. 入手可能である
  2. 更新可能である
  3. 製作者の意志に反しない

1つ目の条件として、craftmanurlがリンク切れになっていないかどうかチェックする機能を追加しました。

2つ目の条件として、updates2.dauに定義されていながら更新ファイルが存在しなかった場合、存在してもMD5ハッシュ値が一致しない場合なども更新エラーと認識するようになりました(SiReFaSoが必要とするファイルのみで、すべてのファイルをチェックしているわけではありません)。

3つ目の条件として、登録者が登録内容を書き換えることができなくなりました。あくまでも製作者の更新用サーバーにあるファイルに記述されている内容を基に登録されます。また、巡回する毎にrobots.txtにアクセスし、それに従うように変更しました。本来検索クローラが従うべき手順です。

以上の3つの条件を満たすため、以前のSiReFaSoで後付けで実装されたものもありますが、中途半端な実装であったため、今回のメンテナンスを機にちゃんと実装し直しました。

以前のデータを登録し直す際に、前述の条件を満たさず登録出来なかったものの一覧が以下のURLにまとめてあります。

h:id:sirefaso:243585843001153319

robots.txt対応前に登録されたものや、(製作者でなく)登録者がdescript.txtを書き換えて登録したものなどが大半のようです。本来登録されるべきでなかったものについては、やむを得ないと考えます。

更新用サーバの状態によってrobots.txtの内容を正しく返さない事例を3件ほど確認しています。タイミングによっては(製作者の意志に反して)登録されてしまう可能性もありますが、その場合はそのようなサーバ(NinjaとかNinjaとかNinjaとか)を用意した製作者側が負担すべき問題であると考えます(登録作業時に1件登録されてしまいましたが、今回は手動で削除しました)。

また、サーバの応答が悪く、登録作業時に何度も失敗したのが以下のものです。

h:id:sirefaso:243603435103865141

サーバの調子が良い時に再度登録できるのを祈ることにします。

複数一括登録

今回から、一度に複数の情報を登録できるようになりました。今回の変更に合わせてSiReFaSoManagerも更新しましたが、まだ複数登録のための機能は付けていません。そういった機能を実装する場合は、Pluginという形式では厳しいとも考え、実装は未定です。

登録のためのAPIを駄デベWikiの方に掲載していますので、第三者がクライアントを製作することも可能になっています。

また、複数一括登録対応に伴い、処理時間が長くなる場合に備えて、登録時の結果の通知をクライアントからh:id:sirefasoへ変更しました。登録の受付結果自体はすぐに返されます(登録の成否はその時点ではわかりません)。

影響が大きそうな変更点として2つほど詳細を記載させて頂きました。今後は細かな既知の不具合と、今後見つかるであろう不具合の修正を行う予定です。