W.Deeの2004年8月の日記

kikyou.info»日記

誠に勝手ながら、kikyou.infoは2017年12月いっぱいをもって閉鎖します。ながらくありがとうございました。

最新月 : 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年8月31日

吉里吉里2 2.23 beta 4 出しました

Additive Alpha 関連の画像演算ルーチンのうちよく使いそうな物をアセンブラで書きました。Additive Alpha はやっぱり演算が単純でいいですね。KAG3の方も、メッセージレイヤのほうは Additive Alpha で表示するようにしました。

今はバイリニア補間を書いてます。C言語で試しに書いたルーチンは重いです。最低でもMMXが使えないと厳しそうですが、いまどきMMXが使えないCPUも無いでしょう。

Layer.faceとLayer.holdAlpha関連がわかりづらいので、ここらへんを整理したいです。もしかしたら下位互換性が少し損なわれるようなことになるかもしれません。

2004年8月26日

PukiWikiとmod_encoding

個人的なプロジェクトの情報管理の為にPukiWiki を導入しようと思ったのですが、全角文字を含むいくつかのページがうまく編集できないのです。

PukiWiki mod_encodingで検索したり、PukiWikiのFAQ「BracketNameの日本語名が文字化けする」を見ると、mod_encoding が悪さをしているようです。

mod_encodingは、kikyou.infoでWebDAVを使う為にApache2のモジュールとして入れてあります。検索した結果で見つけた解決策のとおり、 <Location> 指令で場所を指定し、WebDAVを使うディレクトリ以外には mod_encoding が作用しないようにしてみたのですが、そもそも <Location /> 〜 </Location> で EncodingEngine On 指令 (mod_encodingを有効にする指令) を囲っただけですべてのディレクトリで mod_encoding が作用しなくなってしまいます。なんどもいろいろ条件を変えて繰り返してみたのですがうまくいかず。ディレクトリごとに設定って変更できないんでしょうか。

mod_encodingがそもそも何をやっているのかというと、ファイル名に関して、サーバ側とクライアント側の文字コードの違いを吸収する為に文字コードの変換を行っています。これは、リクエストURI(とリクエストヘッダの一部)中の %記号 のエスケープを解除してから、クライアント側の文字コードをサーバ側の文字コードに変換しています。

どうも問題なのは、これが リクエストURI の '?' 以降 (通常 Query String になるところ) 以降も変換を行ってしまい、これにより PukiWiki に正しい BracketName が伝わらないといった物のようです。

しょうがないので'?' 以降を変換しないようにするパッチを作りました。mod_encoding for Apache2 20040616版 (2004/06/16) に対してのパッチですが、mod_encoding.apache2.20020611a-2 (2002/6/20?) やそれ以前のバージョンでもいけるはずです。aprの使い方とかよく分かってないですが、たぶんこれでいいと思います。

これでやっとPukiWikiがまともに使えるようになりました。めでたしめでたし。

最初探したときに既存のパッチ無いかと思ってたらNamazu-win32-users-ja(旧)アーカイブにありました _| ̄|○

2004年8月23日

2.23 beta 3 出しました

先日2.23 beta 3 を出しました。加算アルファ合成(ltAddAlpha)関連の改修が主ですが、下位互換性は保たれているはずです。

加算アルファ合成のメリットは前にも書いたかも知れませんが、アルファ合成と加算合成の両方を一度に計算でき、通常のアルファ合成に比べて演算が単純で高速という物です。ただし、beta3では、まだ加算アルファ合成関連の低レベルな演算ルーチンはすべてCで記述されてるため通常のアルファ合成よりも遅いです。これからその最適化を行いたいです。

画像フォーマットコンバータに、ltAddAlpha用画像の出力機能を追加しました。Photoshopデータや他のソフトが出力したPNGをltAddAlpha形式に変換できます。

でもそれだけだと、普通のアルファ合成を加算アルファ合成に変換しただけで表現力に違いがありません。加算アルファ合成はアルファ合成と同時に加算合成もできるのがメリットなのですが、これに対応しているグラフィックソフトは見かけたことがありません。

それではあまりにも素材が作りにくいので、ltAddAlpha形式(加算アルファ合成形式)を出力に選んだ場合は、Photoshop形式読み込み能力が拡張されます。具体的には、「通常」レイヤーの上に「覆い焼き(リニア)」が重なっている構造のPhotoshop形式を読み込み、加算アルファ合成用データとして出力することができるようになります。「覆い焼き(リニア)」は加算合成の事です。

加算アルファ合成をどう使うかというのはぱっと思いつきにくいのですが、強い光を反射してフレアの掛かったような金属体など、不透明で光の表現がある素材に適していると思います。

画像フォーマットコンバータで、TLG5/6画像に「タグ」として「mode」を入れられるようになりました。「タグ」はKAGの「タグ」とは違って、いわゆる画像そのものに対する情報(メタデータ)です。今のところ制定されている仕様では文字列情報として「名前=値」のペアを格納できます。これに伴い、Layer.loadImagesメソッドがこのタグ情報を含んだ辞書配列を返すようになりました。

KAGではさらに、ここに入っている情報がimageタグの属性省略時の値になります。画像フォーマとコンバータがTLG5/6に入れる「mode」はKAGのimageタグの「mode」属性に対応しています。mode属性はレイヤの表示方法(完全不透明か、アルファ合成で表示するのか、加算アルファ合成で表示するのか)を指定する物ですので、結果的に、KAG のimageタグでmode属性を省略した場合、その画像に含まれる情報に従って、適切な表示方法で表示されることになります。

画像フォーマットコンバータが現状格納するのはmode属性だけです。原理的にはleftやtopなど、他のKAGのimage属性に対応する情報も入れることができるのですが、これを編集できるようなツールは作っていませんし、作る予定も今のところはありません。

  • 2004-08-23 22:38 イルク : 失礼します。吉里吉里2 version 2.22 rev.4のファイルバージョンが2.23.4.864となっていますが、これでよろしいのでしょうか? 最新の2.23 beta 3が2.23.3.866でしたので、2.22 rev.4では2.22.4.864になるのではと思うのですが、どうなのでしょうか?
  • 2004-08-24 10:16 W.Dee : ああ、それはミスしていました。ご指摘どうもありがとうございます。

2004年8月12日

今後の事

今後ですが、どうしましょうか………。

  • 帯域制限を行っていないプロバイダあるいは帯域制限を行わないサービスに乗り換える</li>
  • 他のサーバ屋さんにミラーして頂く</li>

この両方あるいはどちらかを行わないとなりません。

前者はお財布と相談です。納得できる価格で、いいサービスがあれば良いのですが。上にも書きましたが、地域IP網の構造上の問題もあるので、地域IP網を使っている限り超えられない問題もあるようです

kikyou.infoの運営は趣味であって、これ自体はなんら利益を生んでいませんから、これに出費できる額には限りがあります。正直言えば、今のBフレッツベーシック+ASAHI-NETの接続料で手一杯です。広告収入は見込めるほどページビュー無いんじゃないかと思います(未確認)。できればバナー広告は無しでいきたいなあと希望です。

後者はツテかなぁ、と思いますが知り合いにそのような方が居ないのが悲しいところです。

何かよい方法ないでしょうか。どなたか良いお知恵をお貸しくださると幸いです。

  • 2004-08-16 21:11 W.Dee : その後、ご丁寧な説明をいただけたので、プロバイダ乗り換えは無しの方向で行こうと思います。やはりFTTHごときで無茶をしすぎた感もあります。ファイルのミラーリングについては、もし「してもよいですよ」とおしゃる方が幸いにも多ければそうしますが、そうでなければ、こちらでも別手段を執る方向で考え中です。
お詫び

今回は早急に対処できるような物ではなさそうなので、これは皆様にお詫びするしかありません。

この度はご迷惑をおかけし、大変申し訳ありませんでした。

  • 2004-08-12 22:23 通りすがり from 2ch 自宅鯖板 : BitTorrent を使ってみてはいかがですか? Tracker を建て、あるいはどこかに建ててもらい、kikyou.info 機では帯域制限をかけたクライアント (Seeder) を動かす。UNIX USER 5 月号の「Setting Up FreeBSD 第 23 回 rsync と BitTorrent を利用したファイル公開サーバー」が参考になるかもしれません。
  • 2004-08-12 22:31 通りすがり from 2ch 自宅鯖板 : コメントするとこ、もいっこ下だった… orz
  • 2004-08-12 22:51 W.Dee : こんばんは。ありがとうございます。BitTorrentを立てることは面白そうだなとは思っていました。ただ、FedoraやKnoppixならばともかく、ここで提供しているファイルをダウンロードしているのは、ほとんどがライトユーザで、BitTorrentでどれほど効果があるのかはわかりません。もちろんやってみないとわからないというのはありますが、帯域削減という目的においてはほとんど役に立たないのではないか、と、現時点では予想しています。
で、また帯域制限喰らってます

_| ̄|○

15:00で解除はされたのかも知れません。上記の「回避策」を行ったのでそれよりも前にデータは快適に流れ出していました。その2時間ぐらい快適な回線状況の後、また帯域制限をくらいました。今度は個別のポート単位ではなさそうです。上り1MB/secほどで制限されています。

上記「回避策」はちょっと横暴すぎだったかも。

ASAHI-NETサポートからメール来ました

要約すると

  • 一時間平均で24Mbpsに及ぶデータの転送が行われた為、帯域を制限した
  • ASAHI-NETでは、お客様に対して実用上十分な帯域を保持した上での、自動化された管理システムによる帯域制限を行っている
  • 08/12 15:00に解除予定
  • 基準値(今回は24Mbps)はその時点でのネットワークの状態によるため、固定された値があるわけではない(一時間平均上りが10Mbpsを超えても制限の対象となる可能性がある)

とのことです。

「実用上十分な帯域」ということではこちらとの認識の違いがあるようです。

もっとも、もともとサーバ公開用途ではないサービスですから認識の違いはあって当然なのかもしれませんが、加入当初(2年ぐらい前)はこういう話は聞いたことがなかったので寝耳に水です。

これが「ベストエフォート」における「ベスト」かというとちょっと疑問が残ります。

お詫びの一言も返信メールに入ってないですし、文句を言っても改善されるような物でもなさそうなので、プロバイダ乗り換え時期なのかな、と思います。

24Mbps/hourでは他のユーザの速度低下などの影響があるとのことです。これは地域IP網の構造上の問題で、特定のプロバイダに依存しない話らしいです。だとすると24Mbps/hourで制限がかかるというのも故あっての事か。参考:http://pc5.2ch.net/test/read.cgi/network/1052354767/353-364 しかしいったん制限がかかると約8Mbps/secの状態が長時間続くのは勘弁。

  • 2004-09-01 17:50 すまいりー : Bフレビジネス契約(=月35000円)で全く同じパターンで制限掛けられましたよ。仕事のファイルのやりとりで。払う金違えど同じ制限。客をなめとんのかと。。
  • 2004-09-01 18:40 すまいりー : あ、言いたかったのは、地域IP網の構造上の問題じゃなく、特定のプロバイダの”努力の”問題だってことですw
ASAHI-NETによる帯域制限その後

制限がかかっているのが、ダウンロード用httpdを走らせている8080番ポートだけだと言うことに気づいたので、ポート8081〜8088で走っている同じhttpdのアドレスにランダムでリダイレクトするように設定し、とりあえずは帯域制限を回避できるようになりました(13:00頃)。ポート単位やプロトコルの種類を見ての制限はしてないとの事です。私の勘違いだった模様。

ポート8081〜8088なんていうヘンピな番号なので、ファイアーウォールによっては空いていないかも知れません。

どうしてもダウンロードできないという方は :808X のつかないアドレスでアクセスしてくだされば、一応ダウンロードはできます。

ご迷惑をおかけ致します。

2004年8月11日

続く続く

帯域グラフ

ASAHI-NETカスタマーサポートにメール

埒があかなかろう、と思い、ASAHI-NETのカスタマーサポートにメールしました(17:10)。

回線負荷のグラフとともに経緯を説明した上で、以下のような内容のメールです。

  • 帯域制限はASAHI-NET側で行っている物か?
  • ASAHI-NET側で帯域制限されていないならば、どこでされているのかのアドバイスをいただきたい。
  • ASAHI-NET側で帯域制限されているならば、kikyou.infoのユーザに迷惑がかかっているので、解除して頂きたい。
  • 上り回線速度が1MB/secでは、光接続にした意味がない。
  • 他のユーザに迷惑であるというならば、こちらでも帯域制限は行えるので、他のユーザに迷惑にならない目安を教えて欲しい。

さて、どういうお返事が帰ってくる事やら。ありゃー17:00すぎちゃったから営業時間すぎちゃったかな。

ASAHI-NET に帯域制限かけられたかも

kikyou.infoがメインで使ってるインターネットプロバイダはASAHI-NETなのですが、もしかしたら帯域制限かけられちゃったかも知れません。

帯域グラフ

このグラフを見ると分かるのですが、本日の1:20ごろから上り(負のほう)がおおむね1MB/secになっています。

所々ツノのように下に伸びているのはなんだかよくわかりませんが、毎時10分ぐらいの場所にあるので、回線負荷計測の為に一時的に帯域制限を解除してるのかと思います。

帯域制限をかけらられたのは初めてなので困惑していますが、なんとかならないものでしょうかねえ。

asahi-netの帯域制限について検索すると、あーやっぱり使いすぎると制限されるのか、とか思ったり。

ちなみに今(16:00現在)は1MB/secでこちら側でも帯域制限をしています。時々こちら側での帯域制限を解除して、プロバイダ側の帯域制限が解除されたかどうかを見ているのですが、サッパリ解除されないようです。

これが続くようならば、サポートに文句をタレたいと思います。なにせ、kikyou.infoの運用に支障があるので。

いろいろとトラブルの絶えないkikyou.infoですが、皆様方にはご迷惑をおかけしますm(_ _)m申し訳ありません。

2004年8月6日

Fate/stay night プロローグ3日目、夜、屋上でゲームが落ちる件

以前、2004年2月15日の日記で不具合としてあげた「プロローグ3日目、夜、屋上でゲームが落ちる」件の原因がおおよそ判明しました。

某所の「CDレス化パッチを入れるとFateが落ちるようになる」という書き込みを見て、「CDレス化パッチ」を入手しようとしました。

Fateの場合はCDレス化はすなわちCDプロテクト回避ということになるのですが、これ自体はその用途からみてもまっとうなものじゃなくて、ファイル共有ソフトじゃないと入手できないようでした。ともかく紆余曲折して入手。

で、やっぱりこれが原因のようです。バグというか、考慮不足による物です。詳しい説明は割愛しますが、エラーを無効化しようとして吉里吉里の例外機構に手を加えたのが原因のようです。

まあ吉里吉里のせいじゃないとわかって一安心です。

それにしてもこの症状が随所で聞かれたのはともかく、公式掲示板にもこういう報告が有った上で公式のFAQにもなりました。中には裏で不正に流通していたプロテクト回避済みのゲームを使用した人もいるでしょうし、こういう事やった上でよく公式のサポートを受けようとしますよね、ホントに………。

  • 2004-08-07 14:24 薫 : 最近、多いですね。こういうマナーのないお話。先日もフリーウェアをオークションで売ろうとしたという話もあったり。こんなお話に振りまわされるのは少し哀しいですね。
  • 2004-08-09 23:53 W.Dee : こんばんは。たしかに振り回されましたね(^^; 相当時間をかけて周辺をチェックしました。例外が発生しはするが、catchされて無効とされる唯一の箇所なので、例外機構を疑ってはいました。結局はこれについては「吉里吉里外の要因」という結論に無理矢理していたのですが、当たっていたようです。でもこれのおかげでソースをじっくりと見直す機会にもなったので良かったと言えば良かったです。もちろん、だからもっとやってくれという話ではありません(汗) 振り回されたという意味では大迷惑です。