W.Deeの2004年6月の日記

kikyou.info»日記
最新月 : 2008年10月
2003年 [             3    4    5    6    7    8    9   10   11   12  ] 月
2004年 [   1    2    3    4    5    6    7    8    9   10   11   12  ] 月
2005年 [   1    2    3    4    5    6    7    8    9   10   11   12  ] 月
2006年 [   1    2    3    4    5    6    7    8    9   10   11   12  ] 月
2007年 [   1    2    3    4    5    6    7    8    9   10   11   12  ] 月
2008年 [   1    2    3    4    5    6    7    8    9   10   11   12  ] 月
2009年 [   1    2    3    4    5    6    7    8    9   10   11       ] 月
前月の日記  次月の日記

2004年6月23日

Subversion始めました

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

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

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

安定版と開発版

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

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

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

吉里吉里2 2.22 rev.2 公開

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

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

2004年6月20日

分割ダウンロード禁止httpd

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

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

吉里吉里2 2.22 公開

2.22を公開しました。

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

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

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

2004年6月18日

mathopd改造

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

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

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

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

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

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

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

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

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

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

  • 2004-06-18 11:18 W.Dee : クッキー無し、同じIPアドレス、同じファイル、Range指定ありの場合は200 OKではなくて503 Service Unavailableを返すようにしました。FlashGetはIEのクッキーをつかうのかな。クッキーを送ることはできても、受け取ることはどうもできないようです。

2004年6月17日

軽量・高速 httpd

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

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

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

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

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

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

  • 2004-06-17 15:31 W.Dee : ああ、そういえばクッキーという奥の手が。

2004年6月15日

分割ダウンロード

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

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

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

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

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

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

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

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

ですから、

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

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

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

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

  • 2004-06-15 11:31 シルク : お世話になっております。分割ダウンロード…サーバーに負担をかけるのですね。うちのDLページにも注意書きをしておこうと思います。
  • 2004-06-15 19:05 L.Entis : うわっ! なんだか泥臭いことやってられますね…。(色々な意味で尊敬(^^;) 単純に同一IPからの接続数を制限するだけだと、やっぱり問題あるんでしょうか…?いえ、そういう方面は素人なのでよく分からないのですが…
  • 2004-06-16 01:24 W.Dee : どうもですー > シルクさん
  • 2004-06-16 01:28 W.Dee : 同一IPアドレスからの制限だと、サーバ側から見たときの「見た目」が同一IPアドレスになる、NATやproxyで問題が起きます。実際は複数の人(コンピュータ)がダウンロードしているのにもかかわらず、サーバ側からは同一のIPアドレスからアクセスされているように見えます。たとえば一つのIPアドレスを同時10アクセスに制限すると、最初に分割ダウンロードで同時10アクセス分を確保した人がダウンロードを終了しないと他の人はいっさいダウンロードできないことになります。 > L.Entisさん
  • 2004-06-16 08:13 L.Entis : ああ、そうですね~。Range ヘッダの有無+同一IPか…、特定のディレクトリのファイルへのアクセスに限定して制限するとか…(そんなことできるのかな?(^^;)、なんにしても、大変ですね…
  • 2004-06-16 21:06 薫 : お世話になってます。分割Downloadは確かにサーバーに負担かけますよね。今までINSだったのでレジゅーム機能を使うためにDownloadツールは使ってましたが、分割なしでDownload数はひとつと気をつけてはいたんですが。これってどうなのでしょう。どちらにしても分割しても転送されるデータは決まってますから、劇的に早くなるわけではないんですから、やっぱり迷惑をかけないようにするのはマナーだと思います。
  • 2004-06-16 23:15 W.Dee : こんにちは。分割ダウンロードは、今のkikyou.infoみたいにとくに速度制限をかけていないサーバでは回線速度的には大した負荷にはなりません。いくら搾り取ろうとしても出ない物は出ないからです。ただサーバ側は、10分割している場合は単純に計算して分割しない場合の10倍の負荷がかかるわけです。まあモラルですかねえ。。。私はダウンロードするときは「同時2接続ぐらいはやらせてよ」とか思ったりしますが(汗) > 薫さん
  • 2004-06-16 23:22 W.Dee : 分割ダウンロードの問題はいずれはダウンロード速度制限と一緒に考えることになると思います。希に、うちでホストしている作品がニュース系サイトなどで採り上げられると急激な回線負荷がかかることがあります。負荷の軽くて回線速度制限のできるthttpdを試してみたんですがディレクトリのマッピングがうまくいかず断念。ファイル拡張子やディレクトリごとにアクセス制限がかけられるといいのだが……ソース変えるしかないかな。
  • 2004-06-17 00:19 W.Dee : なんとなく mathopd ( http://www.mathopd.org/ ) を見つけたので使ってみようかと。サイズも小さくて高性能 ( http://www.acme.com/software/thttpd/benchmarks.html 参照) の割に設定が柔軟なのがいいです。これ単体では帯域制限はできませんが、それはカーネルのQoS パケットスケジューラでなんとかなりそう。しばらくの間はこれでしのぐかも。

2004年6月14日

共有スペースアドレス変更について

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

いままで

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 の時は表示されてました。

2004年6月13日

サーバメンテナンス

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

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

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

ご迷惑をおかけします。

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

  • 2004-06-13 20:57 W.Dee : PostgreSQLテストー

2004年6月10日

コミックマーケット66吉里吉里関連作品サークル

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

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

kikyou.infoメンテナンス

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

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

ご迷惑をおかけします。

液晶ディスプレイのドット抜け(第4回)

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

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

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

  • 2004-06-12 05:48 夢見人 : はじめまして、ドット抜け無しおめでとうございます。液晶ほしいですけど、未だにドット抜けが怖くて購入にいたってなかったのですが、参考にして購入してみたいと思います。