目次
05日 GIF データの XMP Data チャンク構造
07日 風邪ひき
10日 CentOS 7 上の ndjbdns の落とし穴
11日 ジュラシックパーク
22日 CentOS7 の nginx で https / http2 対応
27日 ダイナマイト刑事
仕事で GIF のデータチャンクなんて覗いている。
WEB の画像の多くが GIF だった時代なんかに、GIF をいじるプログラムは何度か作ったことがある。
画像データを直接いじったりするのはご免蒙りたいが、無駄なデータを削除したり、著作権表記のコメントを入れたりね。
今回はそれとも違う理由でデータを覗くプログラムを作っているのだけど、上手く動かないから直接バイナリエディタでファイルを開いたりしながらデバッグしていた。
動かなかったのは自分の勘違いだった。その話はいいんだ。
今日書きたいのは、Photoshop なんかで作った GIF ファイルには XMP というデータが含まれていて、このデータ構造が面白かった、ということ。
XMP は、画像に関する様々なデータを、人間に可読、かつコンピューター処理もしやすい形で、様々な画像フォーマット内に埋め込むための統一された方法。
Adobe が提唱していて、誰でも使ってよいらしいのだけど、Adobe 以外に使っている人がどれほどいるのかは不明。
多くの人にとっては画像に関するデータは EXIF があればいいよ…となりそうだけど、EXIF は JPEG と TIFF にしか埋め込めない。
XMP は、もっと多くの画像ファイルに埋め込めるようにしてある、という点で、一定の利点はある。
で、GIF にも埋め込めるわけだけど、その前に XMP データについてざっと解説しておこう。
まず、XMP は先に書いたように「人間に可読」だ。
テキストファイルになっている。
コンピューターにも処理しやすいように、XML と呼ばれる形式で書かれる。
もっと言えば、XML によって記述される、RDF と呼ばれる形式に従っているのだけど、そういう細かなことはこの際どうでもいい。
XML は < > の記号をやたらと使って書く。HTML の中身を見たことがある人ならわかると思うけど、親戚関係だ。
で、XMP は必ず「<?xpacket ~ ?>」という文字列で囲まれている。
画像ファイルをテキストとみなして検索し、この部分を取り出せばよい。画像ファイルの構造なんて知らなくても扱えるので、お手軽だ。
ところで、GIF ファイルには、コメントとして文字列を埋め込む機能がある。
なーんだ、簡単。じゃぁ、XMP もコメントとして書けばいいわけだ。
…ところが、そうはいかない。
GIF は内部でチャンク(データのまとまり)構造を取っているのだけど、基本的に次のような構造なのだ。
・何を示すチャンクであるかの ID 1バイト
・そのチャンクに必要なデータ 数バイト(ID ごとに構造が決まっている)
さらに、必要に応じてチャンク内のブロックが作られる。
ブロックの数は任意だ。なくてもいいし、何個続いてもかまわない。
・データ長 1バイト
・データ長の長さのデータ
データ長が 0 の時、ブロックはそれで終わりだということを意味する。
逆にいえば、0 にならなければ、いくらでもブロックを続けてよい。
ここで重要なのは、データ長が1バイトだということで、データの長さは最大 255バイトとなってしまう。
先に GIF ファイルにはコメントを埋め込める、と書いたのだけど、255 文字で一区切りだ。
それ以上のコメントが入れられないわけではなくて、内部で複数のブロックに区切って格納される。
でも、先に書いたように、XMP はファイル構造を知らないでも取り出せるテキストとして埋め込まれる。
それでは GIF ファイルのコメントとして適した形にならない。
ここでちょっと工夫が必要になるわけだ。
さて、GIF における XMP の構造。ちょっとした Hack だ。
まず、「データ長1バイト」なんて気にせず、データ長の部分からいきなりテキストファイルを書き始めてしまう。
XMP は結構長くて、普通は 255 文字なんかに収まらないけど、最後まで一気に書ききる。
XMP の先頭は < なので、ASCII コードに従ってデータの長さは 60 ということになる。
GIF フォーマットを読むつもりで見ると、そこまでテキストを読み飛ばして…次の「文字」の文字コードが、次のブロックの長さ、ということになる。
一応、可読テキストなので ASCII コードの「 0 」、いわゆる null 文字は入らない。
だから、チャンクが終了してしまうことはなく、テキストはちゃんとチャンク内に格納されていることになる。
でも、こうやって読み飛ばしていくだけでは、いつかテキストの終わりを飛び越えてしまうだろう。
もちろん、その通り。
XMP テキストは、<?xpacket ~ ?> で囲まれている、と書いたのを思い出してほしい。
最初と、最後にこの文字列が付いている。
逆にいえば、XMP テキストを取り出したい人にとって、その外側にあるデータは関係がない。
そこで、GIF ファイルの XMP データは、テキストの直後に 255 から 0 に至る、1つづつ数の減る 256 byte のデータが埋め込まれている。
GIF ファイルのつもりで読んでいると、いつか XMP テキストの終わり飛び越し、このデータの中に着地する。
データは、1バイト進むたびに、1数値が減っている。
だから、その数値の分だけ先に進むと、どこから始めたとしても、必ず同じ場所にたどり着くことになる。
そして、その数値は「0」だ。
先に書いた通り、データ長が 0 の時は、チャンクの終了を意味している。
そのため、XMP を格納したチャンクは、ここで終わる。
先に書いたように、僕のプログラムミスで GIF ファイルを覗くプログラムがうまく動かなかった。
デバッグのためにバイナリエディタで直接観察したら、こんな構造のデータがあった。
255byte でブロックを作る、という規則を無視して入れられた、とても長いテキストデータ。
最初は、こいつが悪さをしていて自分のプログラムが動かないのではないかと疑った。
でも、他のプログラムは正しく画像を出しているのだから、問題はないはず。
次に考えたのは、XMP 用に特別な構造の追加仕様があって、僕のプログラムがそれに対応できていない、ということ。
でも、これも違う。後から追加するデータ仕様が、それ以前のプログラムの動作と非互換なわけがない。
そう思って冷静に動作を考えたら、上に書いたような巧妙な構造が見えてきた。
この構造の欠点は、256byte も無駄なデータを詰め込んでいることだ。
でも、そもそも XMP 自体が、画像だけを見たい人にとっては「無駄なデータ」だ。
データを入れたい人にとっては必要があるから入れるのであって、その場合は 256byte くらいは誤差範囲だろう。
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
風邪を惹いて、治るまで1週間かかった。
どうも体調悪いな、と思ったのは先週末。金曜日か、その前日だったか。
金曜日は出かけないといけない用事があったので、外出した。まぁ、外出できる程度の「調子悪い」だった。
9月の22日から家族旅行に行っていたけど、実はこの直前に長男が「風邪っぽさ」を訴えていた。
少し喉が痛く、調子が悪いという。
でも、旅行は長男も楽しみにしていたし、思い切って出かけた。
ユネッサンに行ったのだが、長男が少し「寒い」と言っていて、暖かいコーヒー風呂に浸かってばかりいたのも、実はこのせいかと思う。
でも、その後熱が出ることもなく、風邪は治った。
この1週間後くらいに、妻も喉が痛いと言っていた。
こちらも熱が出ることもなく、すぐに治った。
長男の後、長女も少し風邪気味を訴えていたのだけど、こちらは1日程度で治った。
だから、僕も風邪気味だけどすぐに治るよね、くらいに思っていた。
これが、土曜日はもう少し体調を崩す。
夕方ごろ、なんか気分が悪くなって起きていられなくなった。
しばらく寝ころんでいたら少し回復し、水をたくさん飲んで飴玉なめたら気分がすぐれたので、エネルギー切れだったのかな、とも思った。
日曜日はそれほど高くはないが熱が出て、一日中寝ていた。
夕方には熱が下がってきて、あぁよかった、週末だけで治まった、と思ったのだけど…
月曜日、熱は微熱程度なのだけど、体がだるくて、起きていられない。
仕事はあったのだけど、少しやっては寝て、という状況。
火曜日も似た感じ。幸い、大急ぎの仕事はなかったので少しづつ進める。
水曜日は熱が下がっていたのだけど、仕事先とビデオ会議。寝るわけにはいかない。
辛いので、要件が終わったところで早めに終わりにしてもらった。
でも、どうやら水曜日がヤマだったようだ。
木曜日は、午前中辛くてやはり寝ていたのだけど、午後からは何とかなった。
そして今日、金曜日。
多少体はだるい。でも、寝ないで一日過ごせた。
多分家族がかかった風邪と同じなのだけど、なぜ僕だけ悪化したのだろう。
体力が落ちているのかな…とも思う。
基本的に兼業主夫で、つらくても朝早起きなので体が休まっていなかった可能性はある。
まぁ、だるくて仕方ないので風邪の間は早めに寝てはいたのだけど。
ともかく、明日から連休なので、ゆっくり休んで体調を整えよう…
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
CentOS 7 のサーバーを構築しているのだけど、djbdns に「落とし穴」があったので記して置く。
djbdns は DNS サーバー。
DNS サーバーのプログラムとしては BIND が有名なのだけど、前世紀からセキュリティホールが多すぎることが問題となっていた。
djb こと「ダニエル・ジュリアス・バーンスタイン」がそれに腹を立て(?)、セキュリティ問題が出ない DNS として作ったのが djbdns だ。
BIND はその後、一度全面的に作り直されて「BIND 9」となった。
セキュリティ問題は多少は改善したらしいのだけど、根本的にはやはり変わっておらず、セキュリティアップデートを繰り返している。
つい先日も、非常に重大な脆弱性が見つかっている。
djbdns は、2001 年に公開されてから、セキュリティパッチが当たったのは 2009 年の1度だけ。
実のところ、BIND に限らず、DNS サーバーはセキュリティアップデートが多いソフトの一つだろう。
というのも、DNS の仕組みそのものがあまり良い設計ではなかったから。
インターネットに悪人はいない、という思想で設計されてしまった。
実際、悪人がいなければうまく動くし、現在のインターネットは DNS なしには考えられない。
でも時々、ソフトではなく、DNS の規格自体にセキュリティ問題が見つかる。
こうなると、BIND に限らず、DNS サーバープログラムが軒並みアップデートしたりする。
でも、この場合も djbdns だけは大丈夫、ということが多い。
最初から規格を信じていないし、自分が作ったプログラムすら信用しない、という姿勢で作られているため、そもそも問題が出にくいし、問題が出た場合でも影響が非常に少なく、セキュリティホールになりにくい。
…と、ここまで書くといいことづくめのようだ。
でも、そんなにいいものなら皆が使うだろう。
実際には、多くのサーバー管理者が敬遠して使わないような、ひどい部分のあるソフトなのだ。
セキュリティが強固な代償として、プログラムをインストールし、設定するのが非常に厄介だ。
たとえば、どんなサーバープログラムでも、そのサーバーの「設定」を行うファイルを持つものなのだけど、ファイルの読み込みって実はセキュリティホールになりやすい。
そこで、設定ファイルを読み込むプログラムと、実際に動作するプログラムが分離している。
そして、このプログラム自体が、問題の出やすい「設定ファイルの文法解釈」を行わないようになっている。
具体的にいうと、ファイル名がそのまま設定項目で、ファイル内は1行だけ、というのが基本。
設定のためのディレクトリの中に、多数のファイルが入れられた状態となる。
管理する立場になると、設定項目を一覧することもままならない状態。
プログラムをサーバーとして動作させるときは、万が一停止した場合に備えた仕組みが必要になるのだけど、その仕組みも別のプログラムになっている。
DNS の「問い合わせ」に応対するプログラムと、「解決」を行うプログラムも別になっている。
そして、万が一脆弱性により「乗っ取り」が起こった場合でも問題が起きないように、これらのプログラムの権限は分離している。
UNIX では権限はユーザーに付随するものなので、サーバーを動かすためだけに、複数のユーザーを登録する必要がある。
BIND より信頼のおけるものだとしても、この複雑至極なインストール方法と設定方法が嫌われていて、あまり使われないソフトの一つだ。
#あと、勘違いも多い。
最後のアップデートが 2009年、と聞くと、開発が停止していてセキュリティホールだらけなんじゃないか、と思う人が多いようだ。
上に書いたように、セキュリティチェックは頻繁に行われていて、アップデートがないのは何も問題がないから。
開発はもちろん継続していて、報告があればいつでもアップデートされる。
さて、そんな高性能だけどインストールと設定が厄介な djbdns が、コマンド一発でインストールされ、使えるとしたらどうだろう?
CentOS 7 には、djbdns の改良版である n-djbdns (New djbdns)が提供されている。
yum install ndjbdns でインストールできる。
改良版と書いたけど、改良かどうかはわからない。
動作権限はあまり細かく分かれていないので、万が一問題が生じた際の保証はない。
もっとも、「万が一のために」動作権限が分離されているのだけど、過去にそういう万が一が報告された例はないから、これはこれでいいかもしれない。
設定ファイルも、ごく普通のものになったので設定しやすい。
先に書いたように、ファイルの読み込みはセキュリティホールになりやすいのだけど、どうも n-djbdns では、設定ファイルを読み込むプログラムだけを改良して、その部分を使いやすくしたようだ。
これは設定ファイルの読み込みだけなので、サーバーのセキュリティ問題は出にくそうだ。
とはいえ、「文法解釈」という、複雑で問題が出やすいものを導入してしまったのは事実で、djbdns よりはセキュリティの強度が落ちるかもしれない。
先に書いた、サーバーとして動作させるための仕組みは、djb が専用に作ったものではなく、CentOS7 が使用する systemd に任せる形になった。
systemd 自体が複雑すぎて、セキュリティホールの温床になりそうだ、という批判はあるのだけど、それはまた別問題。
まぁ、複雑怪奇で使われにくい djbdns を、使いやすいようにうまくまとめてある印象。
しかし、最初に書いたように、一つ落とし穴があった。
axfrdns の設定方法がわからない。
DNS サーバーは、普通2台を一組にして設定する。
DNS は非常に重要なものなので、万が一片方が停止しても、もう片方で運用を続けられるようにだ。
このとき、メインにデータを設定すると、もう1台に自動的にデータが転送される。
でも、データを転送したいのであれば、ファイル転送の仕組みを使えばよい。
UNIX には scp という、非常に優れたファイル転送コマンドがあるから、それを使えば解決だ。
…と、djbdns では考えている。
BIND では、このために専用の仕組みを用意していて、「ゾーン転送」と呼ばれる動作が行われる。
djbdns と BIND を混ぜて使うような特殊な状況だと、ゾーン転送にも対応しないといけない。
このための仕組みが、axfrdns だ。なくても良い存在だ。
でも、僕はまさに bind との連携をしないとならない、という事情があった。
その axfrdns が使えない。
よくわからないよ? と思ってネットで情報を探したのだけど、そもそも djbdns で axfrdns を使っている人も少ない状態。
ましてや、まだそれほど普及していない n-djbdns では設定例が全く見つからない。
そして見つけたのが 2013 年の、n-djbdns 開発の掲示板ログ。
ここで、やはり axfrdns の設定ができない、という質問に対し、n-djbdns の作者(djbdns からの改良者)が、axfrdns を自身が使っていないため、機能を理解していないと認めている。
ただ、認めて終わりではなくて、要望を受けて改良しているんだ。
設定がちゃんとできるようになり、起動も可能となった、ようだ。
でも、この時点では CentOS 6 の時代なのね。
まだ systemd はなくて、別の方法で起動を行う設定ファイルが紹介されている。
さらに、axfrdns の設定で「本当に」必要なことが、この方法では満たせない、という報告がある。
起動できなかったのが起動は出来るようになった。でも、それでは役立たないのだ。
こちらについては「将来のバージョンで対応するかもしれない」という形で終わっている。
CentOS 7 の起動スクリプトは、この掲示板で示された CentOS 6 用のものを systemd に移植するような形になっていた。
ただ、CentOS 7 特有の問題により、何か違う問題が起きているようだ。
というのも、起動を試みても失敗するから。
なにか専用の設定を行えば起動できるのかもしれないけど、起動したとしても、先に書いたように「動くけど役立たたない」可能性が高い。
先に書いたように、axfrdns は、djbdns にとって必須の機能ではない。むしろ使わないほうが良いくらいだ。
セキュリティホールの多い BIND ではなく、djbdns を気軽に使いたい、という人にとっては、CentOS 7 で yum 一発でインストールできるのは良いことだと思う。
axfrdns 相当の機能が必要な場合は、残念だけど BIND を使うか、素の djbdns を自分でインストールすることになるようだ。
僕は以前のサーバーで、素の djbdns を使っていたので、後者を選ぼうと思う。
同じテーマの日記(最近の一覧)
関連ページ
CentOS7 の nginx で https / http2 対応【日記 16/10/22】
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
僕がセガに在籍している間に発売されたので、確か社内テストプレイ筐体で遊んだことがある。
たしかAM3研(当時)のゲームなので、僕はちっとも知らないです。
なのになぜ書くかというと、Twitter でジュラシックパーク(1994)の話題が出ていて、そこで参考にされたページを読んだから。
このページ見ると、ガンシューティングとして「やりがいがない」という評価。
理由として次のような説明になっています。
シューティングゲームの醍醐味と言えば?
ハイスコアにタイムアタック…様々あるが、その答えの前提にあるのはノーダメージやノーコンティニュー、すなわち ワンコインクリア ではないだろうか。
(中略)
だが、この「ジュラシックパーク」というゲーム
どう足掻いてもダメージを回避出来ないポイントが存在する。
それも一カ所、二カ所ではなくいくつも。
敵の攻撃力自体はそれほど高くないものの、1Pの場合は 明らかにこちらを殺しに来てるとしか思えない数の敵が押し寄せてくる 上に、攻撃を回避する手段は存在しないため、ワンコインクリアは 不可能。
これは紛れもない事実です。その意味では、残念ながらガンシューターの人から「つまらない」と言われても仕方がない。
もう一つ、上のページにも書かれていますが、ジュラシックパークは「レールチェイス」というゲームが元にあります。
レールチェイスのゲームシステムで、当時話題の映画とタイアップしたのがジュラシックパーク、と考えていい。
じゃぁ、そのレールチェイスの評価はどうかというと、こんなページがありました。
アーケードゲームでの醍醐味、1コインクリアが絶対にできないという鬼畜な難易度…というか致命的な欠陥。1人プレイだと反対側の端まで照準が届かず、敵を必ず撃ちもらす。
絶対クリアできない、という点を除いて考えてもゲーム自体の難易度は半端ではない。兵隊は早めに始末しないと勝手にダメージを受ける(ビーストバスターズと同じ)。しかし1回しか攻撃しないので大したことは無いと思いきや、これが面が進むごとに大量に出て来て、ひどい時には2人プレイでさえも捌ききれない勢いとなる。しかも時によっては障害物や、爆弾などと重なって余計回避不能なことになることがしばしば。
酷評されています。
実際、どちらのゲームもゲームが好きな人の間での評価は低いですし、僕も社内テストで遊んだ際に「面白くないゲーム」という印象でした。
でも、レールチェイスは評価の高いゲームで、後に2などのシリーズも出ています。
(これも社内で遊んだ覚えあり)
ジュラシックパークもレールチェイスの人気があったから作られたゲームで、やはり結構高評価だったはず。
ここでいう「高評価」というのは、ゲームマニアの評価じゃないです。
マニアからの評価は、上に挙げた通り散々なもの。
でも、ゲームっていうのはマニアだけの文化じゃないです。
そして、後々まで語るのはマニアだけです。
だから、誰かが記録しておかないと、後に「評価が低かったのになぜか繰り返しシリーズが出た作品」とされてしまう。
これが、自分が一切かかわっていないし、開発過程を見てすらいないのに急に記録しておこうと思った理由です。
レールチェイスの宣伝チラシがネット上にありました。
裏面の説明を読むと「アベック客やグループ客をターゲットとした」という文章から始まります。
下の方にも、大きめの赤い文字で同じことが書いてあります。
ジュラシックパークの宣伝チラシも、同じサイトにありました。
ここにも「カップルで楽しめる2P同時プレイ」「カップルやグループ客のリピート性を高める」と書かれています。
チラシに明記しちゃうくらい、アベック・カップル狙いです。
当時はゲームセンターは「誰でも遊びに来られる明るい場所」を目指していましたし、実際デートでゲームセンターに来る人もいました。
でも、ゲームセンターに来ても実は遊べるゲームが少ない、というのが問題だったのね。
当時の人気は対戦格闘。もちろん、カップル共にゲーム大好きなマニアだというのなら、二人で格闘ゲームやってもかまいませんよ。
でも、先に書いたように「誰でも遊びに来られる」場所を目指しているのだから、彼はゲーム好きでも、彼女はそうでない、という場合のほうが多かった。
ジュラシックパークが狙っているのは、こうしたお客様。
先に書いた通り、初めて遊んだときは「面白くないゲーム」という印象でした。
たしか周囲にそう言ったんじゃないかな。
そうしたら、その時一緒にいた企画の先輩が「このゲームは、狙ってこうしているからこれでいいんだよ」と理由を教えてくれました。
▼ゲームが好きな人は、上達によって「長時間遊べるようになる」ことを喜ぶ。
でも、ゲーム初心者は、激しいゲームを長時間遊ぶと疲れを感じる。
だから、短時間に楽しさを凝縮し、プレイ時間は誰がやっても同じ程度、という方がいい。
▼「ゲームを遊んだら面白かった」と感じることが重要で、上手下手はどうでもいい。
だから、激しく敵を撃ちまくる、という「体験」が中心で、敵からの攻撃を相殺するとか避けるといった概念はなくていい。
ゲームの上手下手に関わらず、ゲームオーバーになる地点も大体同じ。
▼ゲームが上手な彼氏だけプレイが続いて、彼女は隣で見ているだけ…という状況は、見ている側も遊んでいる側もつまらない。
だから、プレイヤーごとのライフとかはなくて、一蓮托生。終わるときは二人同時にゲームオーバー。
(普通のガンシューでは、プレイヤーごとに「ライフ」があり、なくなるとゲームオーバー。
しかし、このシリーズでは二人共通なので、自分のあずかり知らない理由でゲームオーバーになる)
▼こんな内容だから、1P側と2P側で「難易度」が違うのも当然。
2人同時プレイの場合、理想的には2人が対等な立場であるべきだが、このシリーズは2P側が極度に優遇されている。
ゲームっていうのは、達成すべき目的があって、その目的に立ちはだかる障害があれば成立する。
…これは僕の持論なのだけど、そう思っています。
その観点でいうと、実はジュラシックパークやレールチェイスは、ゲームではない。
ゲームなのだから「ゲームオーバーにならないこと」を目的だと考えると、1コインクリア不可能、つまり絶対に目的を達成できないのでは、ゲームとして成立しない。
でも、先輩の話をきいた上でこのゲームを「再分析」すると、目的の「読み取り方」を勘違いしていたとわかります。
レールチェイスは「レール」の名前の通り、ジェットコースターなのです。
デートで遊園地に行って、カップルでジェットコースターに乗る。それを気軽に街角のゲームセンターで体験させてくれるのが、レールチェイスです。
だから、遊園地のジェットコースターに「ゲーム性がない」と怒る人がいないように、レールチェイスにゲーム性を求めることが間違えている。
もちろん、ゲーム風の味付けはありますよ。
でも、それは「ゲームを遊んでみたい」という、ゲーム慣れしてない彼女に満足してもらうためのもの。
つまり、「彼女の接待」がゲームの目的です。ゲーム自体は手段にすぎず、目的ではありません。
だから、「ゲーム風」ではありますが、マニアが喜ぶようなものではないのです。
誰が遊んでも同じあたりでゲームオーバーとなってしまう、というのも、ゲーム慣れしていない人には激しい展開が続きすぎると疲れてしまうから。
ちょっと物足りないくらいでゲームオーバーにすると…もう少し続けたい、と彼女が言って、彼氏が財布を出してコンティニューするでしょう。
どんなに下手な人でも、一定時間は遊ばせてくれるゲームなのだから、お金を出すことにも安心感がある。
たった 100円の追加投資で楽しい時間を共有できるというのはカップルにとってうれしいことですし、収益が上がるお店にとってもありがたいこと。
無限にお金がかかるんだったら彼氏にとっても痛い出費ですが、ゲーム自体にはエンディングがあるため、投資額の上限も見えています。
つまり、誰もがうれしい構造。
これが、このゲームが高評価で、シリーズが続いた理由です。
残念ながら、現在はテレビゲーム文化は下火だと思っています。
デートコースにゲームセンターを組み込む人もあまりいないので、こうしたゲームは出てこなくなった。
でも、「文化」を維持するには、多様性こそが重要だと思っています。
特に、ゲームは遊びなのだから、皆が同じ方向を向かない、遊び心こそが一番大切。
すべてのゲームが「マニアが満足する構造」を目指すようになってしまったら、それこそ文化の終焉です。
ジュラシックパークのようなゲームが「つまらないゲームだった」というマニア目線だけで語られることのないように、この記事を残しておこうと思います。
#つまらない、と語る記事を揶揄するものではないです。
マニア目線で「つまらない」という事実を残しておくのだって大切。
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
すこしまえに、CentOS7 の ndjbdns を使うと一部機能が使えない、という話を書いた。
今度は nginx の同様な話。
CentOS 7 では、nginx の yum パッケージがあるのだけど、これで http2 を使おうと思っても使えない。
じゃぁ、nginx を作り直せばいいんだな…と思って自分で構築しても、やっぱり使えない。
nginx はエラーを出さないが、ただ http2 が使えない。
エラーが出ないので原因に気付くのに時間がかかった。
結論から言えば、CentOS 7 の OpenSSL のバージョンが古い
1.0.1i 以降の OpenSSL がないと http2 を使えないのだけど、CentOS 7 のバージョンは 1.0.1e だ。
ちなみに、この日記執筆時点の最新版は 1.0.2j 。
nginx のソースと、OpenSSL 1.0.2j のソースを /usr/local/src に置き、nginx の configure に以下を加える。
--with-openssl=/usr/local/src/openssl-1.0.2j/
--with-http_ssl_module
--with-http_v2_module
これで CentOS 7 の nginx でも http2 通信ができるようになる。
2018.11.16 追記
8月に、WEBで使用される新しい暗号技術、TLS 1.3 の策定が完了、公開されました。
これに伴い、各種ブラウザでも TLS 1.3 の実装が行われています。
この記事は、TLS 1.2 時代のもので、次第に古くなる可能性があります。
とはいえ、古いブラウザのために TLS 1.2 はまだ残されますし、現状では下の設定でもセキュリティ評価は A+ (最高ランク)になります。
追記時点での、OpenSSL の最新版は 1.1.1 だ。
これを使えば、自動的に TLS 1.3 に対応し、使用できる場合は使用される。
その際の設定などは、この記事の設定のままでいいはずだ。
(まだ試していない。)
さて、今まで http だった当サイトも、https に対応した。
SSL の対応状況を調べてくれる、Qualys SSL LABS でチェックしながら対応を進めた。
このページ、最高評価は A+ だ。
そして、このページで A+ を取るための方法、と書かれたページはたくさんある。
でも、それらのページを参考にしても A+ は取れない。
SSL に進展があったり脆弱性が見つかったりすると、チェック内容は変更されるためだ。
まぁ、A+ を取ることが正義ではないので、A- くらいとれていれば十分じゃないかな、と思う。
でも、例えば「設定が間違えていてアクセスできないブラウザがある」とかだと残念だ。
チェックはしておいた方がいいだろう。
そして、設定の中で一番重要になるのが、ssl_ciphers の設定だ。
これは OpenSSL に指示する、使っても良い暗号化形式のリストだ。
クライアントは、このリストの先頭から順に、自分が使える暗号形式を探す。見つけられればその形式でアクセスを行う。
どの暗号形式を許可するか?
これによって、安全性も大きく左右されるし、設定を間違えるとアクセスできないブラウザも出てくる。
目安としては、先に書いた SSL LABS のチェックを作っている人たちが、チェック項目の意味を解説しているページがある。
このページは、暗号に脆弱性が見つかる、などの状況変化により書き換えられる。
なので、以下の内容は記事執筆時点 (2016.10.22) のものだとお断りしておくのだけど、このようなことが書いてある。
・公開暗号鍵を 2048bit にすること
・SSL v2 / v3 には脆弱性があるから使わないこと。
・TLS v1.0 はあまり使用すべきではないが、まだ必要。
・TLS v1.1 と v1.2 は問題ないが、できることなら v1.2 を使うこと。
他にもいろいろあるのだけど、ssl_ciphers の設定に関係するのは以下のようなものだ。
・匿名 ADH は使用しない。
・NULL 暗号は使用しない。
・56bit 以下の弱い共有暗号鍵を使用しない。
・RC4 は安全ではない。
・3DES は遅く、弱い。
・出発点としては RSA および ECDSA を使うようにするとよい。
さて、具体的に ssl_ciphers をどのように設定すべきだろう。
そもそも、ssl_ciphers は「どうやれば」設定できるのだろう?
構築時に OpenSSL のソースを組み込んだことを思い出そう。
ssl_ciphers は、OpenSSL が解釈できる文字列で指示を与える。
指示にあるように「RSA および ECDSA を使う」のであれば
RSA ECDSA
と併記すれば良い。
試しに、openssl コマンドで、この指定を試してみよう。
openssl ciphers -v 'RSA ECDSA'
と併記すると、これらに関係する暗号の一覧が示される。
中には RC4 という文字列を含む暗号名も見られる。
これは「安全ではない」と示されているので、除外したい。
この場合は
RSA ECDSA !RC4
のように指定する。! は「除外する」という指定だ。
56bit 以下の弱い共有暗号鍵を使用しない、という指示もある。
実は、これは HIGH という表記で「128bit 以上」だけを選び出せる。
HIGH
この指定を行えば、RC4 は最初から除外されている。
実際には、ここを出発点とするといいだろう。
HIGH の一覧を出してみると、暗号名の後ろに Au=None と書かれているものがある。
「匿名のADHを使用しない」と指示にあるが、Au=None というのが「匿名」を意味している。
Au は Authorize 、認証の意味で、これが None 、つまり「認証しない」という、匿名を意味している。
これは、Au が NULL である、という表現をする。指示の際は aNULL 。
先ほどの指示からこれを除外しよう。
HIGH !aNULL
これだけで、とりあえず目的は達成できる。
他の設定も適切なら、A+ 評価を得られる。
でも、評価ページの詳細を見ると、いくつかのクライアントでアクセスができないことがわかる。
解消できるものならば、解消したほうがいいだろう。
まずは、次の2つだ。
Chrome 49 / XP SP3
Firefox 47 / Win7
どちらも同じエラーを出して、接続できていない。
SSL で使う暗号には、暗号利用モードと呼ばれる概念がある。
古い https 通信では CBC と呼ばれるモードを使う。
この方法は、直前の暗号文を鍵の一つとして使う。つまり、先頭から順番にしか暗号化できない。
でも、http2 では、1つのコネクションで複数のデータリクエストを並列に受付られる。
ということは、並列に暗号化を行う必要がある。CBC ではない方法を使わないといけない。
しかし、https では、クライアントが使用できる形式のうち、サーバーから渡されたリストの先頭に近いものを優先して使う決まりになっている。
サーバーが、クライアントが使える暗号形式の中で、CBC のものを先に渡してしまったために、それを利用しようとして http2 での通信ができなくなった、というのがアクセスできなかった理由だ。
評価サイトで、クライアント名の部分のリンクを辿ると、そのクライアントの詳細な性能が出てくる。
使用できる暗号化の形式もわかる。
とりあえず、上記二つのクライアントでは CBC 以外として AESGCM の形式を理解できる。
そこで、これらを優先して渡すことにする。
AESGCM HIGH !aNULL
これでいい。
いや、まだだ。
IE 8 / XP がアクセスできていない。
えー、もう XP はサポート範囲外だし、IE 8 なんて誰も使ってないからいいでしょ。…とも思う。
まぁ、無視してもいいと思うのだけど、乗り掛かった舟だから対応してみよう。
こちらも、使用できる暗号形式を見る。
うわ…さすがに古いので、セキュリティ的に問題がある暗号形式ばかりだ。
実用上、使えるものが 3DES しかない。
3DES は「遅く、弱い」とされているのだけど、脆弱性があるわけではないので、対応してみよう。
間違えて他のクライアントが使うと困るので、リストの最後に追加する。
AESGCM HIGH !aNULL 3DES
これでもまだ、対応できていないクライアントが2つある。
IE 6 / XP
Java 6u45
この2つへの対応を行うと、セキュリティ上問題が生じてしまうので、残念ながら切り捨てよう。
IE 6 / XP は、SSL には対応しているが、上位規格である TLS には対応していない。
SSL には脆弱性が見つかっているため、使用してはならない。
Java 6u45 は、公開暗号鍵として 1024bit までしか受け付けない。
1024bit では強度に問題があるため、2048bit を設定することが推奨されている。
とりあえず、話としてはこれで終わりなのだけど、この設定をしても妥当ではない場合もあり得るので説明しておこう。
OpenSSL は、バージョンによって、もしくはコンパイル時のオプションによって、使用できる暗号が異なる。
ここに書いた内容は、冒頭で書いたように 1.0.2j を前提としている。
SSL LABS で、各ブラウザが利用できると表示される暗号名は、OpenSSL のものとは違う。
でも、最後に16進で暗号を示す番号が書かれている。
OpenSSL でも、-v ではなく、-V (大文字)オプションを使うとこの番号を表示できる。
番号を頼りに、適切な暗号形式を探すといいだろう。
そしてこれが一番大切なことだけど、最初に書いた通り、時代と共に適切な暗号は変化する。
もしここに書いてある内容で十分でなかったら、その時点での推奨される方法を SSL LAB のブログで調べるといいだろう。
そして、除外すべきものを除外する。HIGH の指定を使っているので、おそらく「追加すべき」はあまりないと思うが、必要なら追加する。
SSL LAB のページは、一度評価を行うと、しばらくはその結果をキャッシュしている。
そのため、こちらが設定を変化させて、確認しようとリロードしても、評価を行ってくれない。
これは、ページ左上にある「Clear cache」のリンクに飛べば、再評価してもらえる。
最後に、もう一度まとめておこう。
2016.10.22 時点での最良の ssl_ciphers 指定は
ssl_ciphers 'AESGCM HIGH !aNULL 3DES';
となる。
2016.10.25追記
SSL/TLS で使われる暗号について、わかりやすい説明をしているページを見つけた。
いろんなページを読んで理解して説明を試みたのだけど、長くなってしまうので書くのを辞めた部分。
専門的でわかりにくいかもしれないけど、なんとなく頭に入れてから設定を行うと、いろいろとわかってくると思う。
同じテーマの日記(最近の一覧)
関連ページ
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
モップ!柱時計!コショウ!
1996年のいつ頃出たのかよく覚えていないのですが、公式サイトによれば7月ということになっていますね。
セガのアメリカ子会社、セガ・オブ・アメリカでも、ゲームを作ってはいました。
でも、面白いゲームが作れないのね。
今は海外産の面白いゲームもたくさんありますが、この頃のテレビゲームは、日本のものが一番面白い、と自信をもって言える状態だった。
その一方で、アメリカはアメリカで独自のゲーム文化をつくっていて、モータルコンバットなんかが大ヒットしている。
あの独特のテイストは日本人には作り出せない。もう少しアメリカで受けるゲームを勉強しろ、と上層部がことあるごとに言っていた。
そして、「アメリカに行って、アメリカ人の好きなゲームを探りながら、アメリカ人にゲームの作り方を教えてこい」ということになります。
具体的にいえば、日本から1チーム、アメリカに行って、アメリカ人と協力しながらゲームを作ってこい、ということ。
中堅ヒットゲームを数本作っていた企画の人と、やはり中堅のプログラマ、それと新人で僕と同期のプログラマが1名、アメリカに長期出張しました。
アメリカで作っていたから、どうやって作ったかは一切見てません。
時々、アメリカから作成中の ROM が送られてきます。
また、時々アメリカからメンバーが帰ってきます。
(揃って帰ることもあったし、個別に来ることもあった)
アメリカから帰ってくると、大抵はお土産がありました。
なにぶん、60人くらいいる大所帯部署だったので、「全員にいきわたるように」というと、駄菓子なのね。
これが、アメリカのお菓子って美味しくない!
いや、食文化なので否定してはいけません。でも、日本人の口に合わない、というのは事実。
「好きなようにとって食べてねー」と、事務の人(以前書いた、AM1のお母さんと言われる美人)の机に置いてありました。
チュッパチャップス200本ディスプレイとか持ってくるのだけど、日本では売っていないような、アメリカ人好みのフレーバーが多いのね。
世界的に売られているお菓子なのに、なぜ日本で売っていないフレーバーなのか? というのは、推して知るべし。
自分でいうのもなんだけど、僕は味のストライクゾーン広いです。
みんなが食べないものでも、美味しくいただいてた。
ただ、ある時持ってきた駄菓子詰め合わせに入っていた「ローファットキャンディー」は美味しいと思えなかった。
小麦粉を人工甘味料と一緒に煉り合せたような、柔らかいお菓子。
食べると、口の中に粉っぽさと、不自然な甘みが広がります。
一緒に入っていたチョコとかは人気ですぐなくなったのですが、ローファットキャンディーはいつまでも残ってました。
海外留学経験のある女性の先輩は、アメリカでは人気あるお菓子なんだよー、と言いながら食べてましたけど。
…今記憶を引き出しながら検索したら、発見しました。
Twizzlersというお菓子…だったと思います。
そうか、あの不自然な甘みはリコリスか。
先に「食文化を否定してはいけない」と書いたけど、僕としてはおいしいと思えないことが悔しくて、また挑戦する機会があったら食べてみたいと思っています。
駄菓子なのだけど日本では入手困難で、高くつくので自分で買う気はしない(笑)
でも、送ってくれた人がいたら、ちゃんと食べて(全部食べ切るとは言ってない)、改めて味をレポートしますよ。
作成中のサンプル ROM から「これって、どう見てもダイハードだよね」ってみんなが思ってました。
まぁ、アメリカで作成しているチームとしてはそのつもりだったらしく、アメリカでは版権を取得して「Die Hard Arcade」の名前で発売されることになりました。
ところが、日本では版権が取れません。別の名前が必要になりました。
元々アメリカウケを狙って作ったゲーム。
チームの人もしばらく日本にいなかったので、今の日本の流行もわからない。
そこで、アメリカチームから、「日本側でタイトル案を3つ考えて」とリクエストが来ます。
最終的には、アメリカチームがその中から選ぶことになりました。
日本側でアメリカチームの窓口をやっていたのは、同期の企画A。
同期が集まって雑談をしていた時に、なんかいいタイトル思いつかないか、と相談してきました。
相談に来た時点で、悪くない案が2つ出ていた。でも、どうしてももう一つが考え付かないそうです。
同期の企画Bが、「この2つのどちらかで十分じゃん。あと1つは、絶対あり得なさそうな名前でも入れとけば、2つのどちらかに決まるよ」と言います。
あり得なさそうな名前ってどんなのだよ…と愚痴るAに対して、Bが適当に言い放ったのが「じゃぁ、『ダイナマイト刑事』」。
Bのあまりのいい加減さに、うゎ、あり得ねぇ、いくら何でもそんなひどいの怒られるだろ、と笑いながら、3つ目の案として書き加えられます。
1週間ほど後、アメリカから返事がきます。
チームメンバーの満場一致で「ダイナマイト刑事」に決まった、とのこと。
提案した企画Bが一番驚いて、なぜか周囲に謝り始めてました。
ダイナマイト刑事、というフレーズがなぜ「あり得ない」とまで言われ、選ばれたことが驚きだったのか、説明しないとわからないかもしれません。
ダイナマイト自体は明治期から日本にも入っていましたし、戦争にも工事にも使われました。
この言葉自体は馴染みのもので、取り立てて言うことはない。
でも、1950年代の戦後復興期には、大型工事が繰り返し行われます。
それらの工事ではダイナマイトも多用され、一般にも耳馴染みのある言葉になっていきます。
そして、1958年、小林旭が「ダイナマイトが百五十屯」を歌い、大ヒット。
小林旭は「マイトガイ」と呼ばれ、主演映画「爆薬(ダイナマイト)に火をつけろ」が作られるなど、「ダイナマイト」が一気に流行語になります。
僕も生まれるずっと前の話なので、細かなことはよく知りません。
でも、色気のある女性を「セクシーダイナマイト」などと呼んだのもこの頃。
#ちなみに、「トランジスタグラマー」も同じころで、対になる概念。
話は変わって、映画やテレビでは刑事ドラマというジャンルは初期からありました。
勧善懲悪はお話の基本。
連続もので、毎回悪いやつが出てきて、懲らしめる立場の人がいて…となると、警察官や探偵を主人公にするのは理にかなっています。
特に、ただの事件ではなく複雑な「犯罪」を捜査する刑事が主人公となるのは必然と言えました。
テレビが急に普及した 1960 年代からこうしたドラマは人気があり、1970年代には大ジャンルとなります。
ギャグマンガ「がきデカ」の連載開始は 1974年。
刑事ドラマのブームの先駆けとなる「Gメン'75」は1975年。
でも、1980年台初頭にはもうブームは収束しています。
1986年に「あぶない刑事」の再流行がありますが、このときは半分コメディになっている。
1996 年にもなると、「ダイナマイト」は完全に死語でしたし、「刑事」は流行を逃した言葉でした。
その言葉をあえて組み合わせた、というのが「あり得ない」と言われた理由ですし、アメリカチームに選ばれたときに、発案したことを謝っていた理由でもあります。
ちなみに、1996年の秋に、「あぶない刑事」が映画で復活し、再び流行となります。
2016年にも続編の劇場公開がありました。
他にも、刑事ドラマは以前ほどの人気ではないものの、一定の人気を持つジャンルとして残っています。
また、1997年には、SMAP が「ダイナマイト」という曲を発表。
わざと「微妙に外したダサさ」を狙った曲でしたが、面白がられて「ダイナマイト」が流行語として微妙に復活します。
今となっては「セクシーダイナマイト」って名前の洋服ブランドや音楽バンドが存在するのね。
そんなわけで、今見ると「ダイナマイト刑事」ってそれほど違和感ないんですよ。
でも、命名された当時は、明らかに「あり得ない」名前だった。そのインパクトがすごかった。
そして、そのインパクトの強さゆえに、アメリカチームも全員一致でこれを選んだのでした。
ゲーム内は、日本語版も含めてアメリカチームで作っていました。
でも、国内プロモーションは、先に書いた企画Aの担当。
このAが、当時エバンゲリオンにものすごくハマっていて、宣伝用 WEB ページとか、広告とかがすごく影響を受けている。
さすがにもう当時のページはないのですが、
waybackmachineには一部が残されています。
キャラクターの名前なんかも、全部Aが考えたのではなかったかな。
作成チームの人ではないので名前は表に出ないのだけど、ダイナマイト刑事の方向性を決めた結構重要な人物。
彼はダイナマイト刑事2の時も国内事務を担当しています。
…おっと、今 waybackmachine を見ていたら、最終選考に残った3つの名前が書かれてた。
今見ると、3つともひどいな。当時でもひどいというネタになっているけど。
さらには、その3つの名前になる前の仮タイトルも明かされていた。
仮タイトルは、悪くないけどインパクトが足りない。
3つとも「インパクト重視」で決められていたのかもしれない。
(当時聞いたかもしれないけど覚えてない)
ずっと後の話。サターン版発売に際して、アメリカチームの企画チーフが、ミニゲームを入れたいと言い出した。
サターン版持っている人は知っているね。
起動すると、まず「ディープスキャン」という、非常に古いゲームが動き出す。
ここの得点により、本編である「ダイナマイト刑事」のクレジット数が決まる。
クレジット数によってコンティニューの回数が左右されるので、結構重要。
同様の試みとしては、NAMCO がプレイステーションの「リッジレーサー」で、ロード中にギャラクシアンを遊べるようにしていた。
プレステ・サターンの前のゲーム機は、スーファミにしてもメガドラにしても、ROMカートリッジだった。
電源入れたらすぐ遊べる。
でも、プレステやサターンはロード時間が長い。これは、当時としては「許せない」ことだった。
そこで、このロード中でも楽しめるように、最初に非常に小さなプログラムをロードして動かし、そのゲームを遊んでいる裏で本編をロードする、という策。
メモリの小さなプレステでは、作るのは大変だったとおもう。
(サターンは、ゲーム中に次のデータをロードしたりするための、CDキャッシュメモリを搭載している)
もちろんナムコは特許を取っていて、他の会社が真似することは出来なかった。
たしか、初期の頃に他社が同じようなことをやって、ナムコから訴えられている。
(リンク先では訴訟例が上がっているが、その前から注意を受けてゲーム発売停止、とかあったはず)
でも、ダイナマイト刑事では、同じようなことをした。
最初は、ナムコから訴えられるんじゃないか…と心配していたけど、しばらく後にちゃんと回避していることを知った。
ナムコの特許は「ロード中の楽しみを提供する」ものだ。
でも、ダイナマイト刑事のディープスキャンは、本編でコンティニューに必要になる「クレジット」を稼ぐためのもの。
ナムコの特許は「ロード中の楽しみ」だったので、ロードが終わったあとにゲームが一区切りした時点で終了となる。
でも、ダイナマイト刑事では何度でも遊べた。「ロード中の楽しみ」を提供しているわけではない。
だから、特許には抵触していないのだ。
…もちろん、ディープスキャンのゲーム中に裏でダイナマイト刑事本編をロードしているんですけどね。
技術的に似通ったものだとしても、目的を別のものとすれば特許は回避できる、という例です。
翌日追記
書いてしまってから、法的問題なので確認しておこうと思ってナムコ特許読みました。
うーん、上に「回避している」と書いてしまいましたが、回避していると言い難いかもしれない。
上に書いた内容は、当時聞いたままです。
違うから大丈夫だったんだよ、と部内の法務関係をやっていた先輩に聞いたような覚え。
当時は特許書類なんて簡単に読めませんでしたからね。今はネットで見つけ出せますが。
ダイナマイト刑事のサターン版を作成している時点で、ナムコが特許を持っている認識は確かあったと思いますし、それでも「大丈夫」と言って作っていたはず。
そして実際、訴えられてはいません。
特許というのは、抵触したから即アウトというものではなくて、「訴えられたら」ダメなものです。
セガの法務部は、当時それほど強くなかったので、事前交渉があったようにもあまり思えない。
(でも、訴える前に「警告」されて、何か取引したために訴訟を回避できた、という可能性はあり)
僕はドリームキャストは持っていなかったので、ダイナマイト刑事2は持っていません。
でも、こちらのミニゲームは、「ロード中に入る」のではなくなっているようで、やはり特許を気にしたのかもしれません。
2016.11.27追記
十数年ぶりにサターンを引っ張り出し、ダイナマイト刑事を遊びました。
…上に書いたこと、全面的に間違えていました。
ディープスキャンは、「ロード中ゲーム」ではなくて、ダイナマイト刑事のタイトル画面から選択して遊ぶようになっていますね。
当初はロード中ゲームとして作っていた覚えがあります。発売までの間に、特許回避のために変えたのでしょう。
そして、今遊ぶとサターン版は恐ろしくテンポ悪いな…
ST-V では、ROM からのロードだったのでシーンの間がテンポ良く進むのですが、サターン版ではシーンが変わるたびにテクスチャデータなどを読み込むので、いちいちまたされてテンポが悪くなっています。
文句言いながら最後まで遊んでしまいましたが。
久しぶりに遊んでも、最後までやってしまう程度には面白いゲームでした。
同じテーマの日記(最近の一覧)
関連ページ
別年同日の日記
17年 Android Chromeでスクロールがおかしくなるバグの原因と修正
申し訳ありませんが、現在意見投稿をできない状態にしています。 |