前述の「安定版」「開発版」の件もあって、Subversionを本格的?に使い始めました。

とは言っても前からSubversionは入れてはいて、ちょくちょく使い方のテストをやっていたんですが、やっと使い方のコツをつかんだような。

サーバはApache2に載せてsv.kikyou.infoに入れて、クライアントはTortoiseSVNで。こちらも使いやすくていい感じです。

安定版系統と開発版系統を分けることを考えています。安定版は安定性を追求するバージョン、開発版は新機能を追求するバージョンです。

開発版で機能が安定してきたら安定版に機能を移します。安定版で出たバグは開発版でも該当すれば修正しますし、その逆もありえます。

具体的にどうするかはまだ決まってません。

毎度のこととなってしまってますが、リリース後にバグを見つけると凹みます。

2.22 rev.2 を公開しました。パッド関連の修正が主です。

うまく動いているようです。

ご利用の方には既にメールでお知らせしましたが、Webスペースの方もこちらのhttpd(files.kikyou.info:1026)を使って頂くようになります。

2.22を公開しました。

主なハイライトはTLG6対応、パッド対応、ファイル破損チェックツール同梱ぐらいで、今回は割と地味なリリースかも知れません。

とはいっても、数々のバグが修正されていますから、2.20をお使いの方は2.22にバージョンアップすることをお勧めします(その場合はKAGも必ず3.22にしてください)。

パフォーマンス関連では、画像キャッシュに使用する容量を従来の約半分にしました。従来の使用量だと他のアプリケーションを圧迫するほどで、「重い」と言われる原因だったり、あまつさえ、一見、際限なくメモリ使用量が増えていくように見えるので、メモリリークと間違われていたりしていました。2.22ではかなり改善されるのではないかと思います。

クッキーを使った分割ダウンロード制御を組み込んでみました。

いま主流だと思われるダウンローダーであるIrvineもFlashGetもクッキーに対応し、またデフォルトでクッキーの機能が有効のようです。

クッキーによる制御のロジックは、以下の通りの簡単なものです。

まず、クッキーを送ってこないクライアントにはランダムに生成された文字列をクッキーとして送ります。以後、そのクライアントはその文字列をクッキーとして送ってくるので、クライアントを識別できるようになります。

同じクッキーを持ったクライアントが、同じファイルを同時にダウンロードしようとしている場合は、最初に接続された接続だけが許可され、他の接続は拒否されます(403 Forbidden)。

基本的にはこれだけです。

ただ、クッキーの機能を無効にしてあるクライアントやクッキーの機能が無いクライアントについての考慮も一応あります。クッキーを送ってこないクライアントからRange付きでリクエストが来た場合、サーバはそのクライアントのIPアドレスと同じIPアドレス、同じ対象ファイルへの接続がないかを調べます。無かった場合、Rangeが有効になります(206 Partial Content)。あった場合、Rangeは無視され、ファイルの先頭からデータを送ろうとします(200 OK)。

今のところうまくいっているように見えます。現状では「吉里吉里ダウンロードページ」にあるファイルにこの制限がかかっていますので、分割ダウンロードができないはずです。

……FlashGetがうまくCookieを解釈してくれないです。なんでだろう……クッキーを送り返してきません。まあ分割ダウンロードはどっちみちできないのですが。まあいいか。。。

2005年3月13日の日記でこのmathopdに対するパッチを公開しています

15日のコメントにも書きましたが、軽量・高速の httpd (Webサーバソフトウェア) である mathopd を、ファイルダウンロード専用に立ち上げてみました。

小さいサイズで高速ながら、柔軟な設定ができる httpd のようです。

ダウンロードみたいな単純なアクセスでは、Apacheにやらせるよりは負荷が少なさそうです。Listenするポートを分けたので帯域制限もやりやすそうですし。

でも最終的には接続してきたユーザごとの帯域制限・接続数制限をしなければ意味ないかも。最終的にはそこまでもっていきたいです。mathopdはシングルプロセス・シングルスレッドの構造なので改造はしやすそう。

15日のコメントに書いた「今のkikyou.infoみたいにとくに速度制限をかけていないサーバでは回線速度的には大した負荷にはなりません。」というのはkikyou.infoの帯域が、ダウンロードするユーザの帯域よりも十分に大きい場合の前提で、です。幸い今はこれがおおむね成り立っています。kikyou.infoの帯域が厳しくなったとき、10接続した人のパケットが1接続したひとのパケットの10倍流れてるんじゃ困りますね。

今のところ、吉里吉里関連のファイルのダウンロードは mathopd につながるようになっています。調子がよければ、Webスペースの方のユーザさんにも mathopd を使って頂くようになるかも知れません (アドレスが変わります)。

分割ダウンロードは困った物ですね。分割ダウンロードは、 一つのファイルを等分割し、それらを同時にダウンロードを行うものです。

Irvineなどのダウンロードツールによるものだと思うのですが、無駄にサーバ側のリソースを喰うので、正直いえば使用は控えて頂きたいです。

同時80分割を見かけたときはさすがにあきれました。そんなに分割数を多くしても速くならんて。

まあここで言ってもしょうがないので、これに対処するにはサーバ側で何らかの措置を行わないとなりません。

Apacheのモジュールを書くことを含めて構想しています。やりたいことは以下の通りです。

• 分割ダウンロードを禁止したい
• 普通にダウンロードレジュームをする人に迷惑をかけたくない(分割ダウンロードを禁止するにはダウンロードレジュームを禁止するのが手っ取り早いが、このサイトは大きなファイルを配布することがあるのであまりやりたくない)
• proxyを使用している人に迷惑をかけたくない(単純な接続元アドレスによる接続数制限はやりたくない)
• Apacheにパッチしたくない(面倒だから)

分割ダウンロードを行うクライアントは、Range: リクエストヘッダを使ってリクエストを送ってきます。Range リクエストヘッダにはファイルの取得の開始のバイトオフセットが指定されています (取得の終了のバイトオフセットはどうも送られてこない)。

ファイルを等分割してダウンロードするのが分割ダウンロードなので、この取得開始のバイトオフセットは、おおむね「ある数」の倍数で送られてきます。「ある数」は、対象ファイルのファイルサイズを分割数で割った数です。

ですから、

• 同一IPアドレス(proxy転送元アドレスが分かるときはそれも考慮に入れる)
• 取得開始のバイトオフセットがなんらかの数の倍数付近
• 取得開始時間がおおむね同じ

という条件で接続を切断すればなんとか行けるじゃないかなと思っています。

Range リクエストヘッダ付きで送られてきたら、サーバ側では最初の1バイトをクライアントに送ったあと20秒ほど待ちます。すると大体クライアント側からの接続がそろいます。そうしたら、Range: ヘッダを見て、どうも分割ダウンロードっぽかったらそれらを強制的に切断します。しばらくの間は、同一IPアドレスからの、そのバイト数付近からのダウンロード再開はできなくします。

………できたら面白いけど、モジュール書くの面倒っすね………書いたこと無いし。こういう風に構想するのはできるけど手を動かす時間はおそらくなさそうだし。

利用者の方にはメールをお送りしましたが、共有スペースのアドレスに変更があります。

いままで

https://sv.kikyou.info:12443/workspace/ID/

にアクセスして頂いていましたが、これからは

https://sv.kikyou.info/workspace/ID/

に変わります(:12443が無くなる)。

またまたご迷惑をおかけすることになり申し訳ありません。

とりあえずWebスペースと共有スペース、メールは復活しました。

あとはいろいろサーバ管理ツールを入れなければ。

……にしてもApache2でWebDAVを有効にしたのはいいんですが、WebDAVフォルダにあるファイルの日付時刻がExplorerから見られない(日付時刻自体がExplorer上に表示されない)のは何故なんだろう(Linux, Apache 2.0.49, mod_dav, mod_dav_fs)。Apache 1.3.x + mod_dav の時は表示されてました。

すみません、13日中に終わらないかも知れません。

現在(午後9時)時点ではDNSとWebは復帰していると思います。

しかしWebスペース・共有スペース提供サービスがまだです。あとメールも復帰していません。

ご迷惑をおかけします。

完了の報告はここ(日記)で行います。

コミックマーケット66吉里吉里関連作品サークル (吉里吉里情報局さん)

出展を予定されている方は、是非登録してみてください。

各ページの上部に告知されているとおり、今月の13日にサーバのメンテナンスを行う為、サービスを停止します。

メンテナンスというか、ハードウェアとOSの入れ替えです。結構大がかりになるので、もしかしたら一日では足りずに、来週の週末にまたサービス停止、ということになるかも知れません。

ご迷惑をおかけします。

ついにドット抜けのないディスプレイ獲得できました。

長かった。同型の液晶ディスプレイ４台目ということになります。

時間経過によってドット抜けが出ることがあるということでしばらく様子見。