くまりゅう日記

もっと過去の日記
[.NET | BeOS | Blender | COLLADA | fossil | mono | monotone | NPR | OpenGL | PeerCastStation | Riko | Ruby | Silverlight | TRPG | XNA | ゲーム | ゲーム作り | ]

2012-02-11

日記

あーまたしばらく日記書いてないな。

書くようなことがあまりないから、というのもあるけど、主に日記を書く時間である電車の中でせっせとプログラム書いてるからでもある。

早起きしようと頑張ってるんだがあまりできてない。 帰ってくるのが23時という時点で早起きとかちょっと厳しい。 もっと早く帰るつもりでいるんだけど遅くなっちゃうんだよなぁ。 仕事がけっこうあるからなんだけど。

VPSのCentOSが古い

現在この日記があるサーバはVPSでCentOS 5.7が入ってるんですが、CentOSって6.1とかが出てるっぽいんですよね。 CentOSってRedHatクローンということもあってあんまり新しいアプリがパッケージにないイメージがあるんだけど、5.7だとPythonの2.6系もなくて困ってしまった。

というのもDropboxのクライアントがLinux版もあるというのに今更気付いて入れたのはいいものの、制御用のスクリプトがPyhton 2.4では動かないようなのでちょっとめんどくさいのであった。

Rubyは1.9.2だか3だかを自前でビルドして入れてるんだけど、Pythonは勝手がわからんのと、あんまりパッケージにない物をさくさくぶっこむのはいかがなものかということで自前ビルドはちょっと及び腰になってしまう。

CentOS 6系ならPython 2.6系のパッケージがあるみたいなんだけど、CentOS 5.xから6.xへのアップグレードは再インスコしかないようだ。これはきつい。しかもVPSだから自由にOSが選べるわけでもなくて、再インスコしても6系が入るかどうかわからんのだよなぁ。というか5.7が入りそうな気がする。

じゃあいっそもっと新しいアプリが入ってそうなOSを選ぶかと思うわけだが、自由にOSが選べるわけじゃないのであまり選択肢がない。SaaSesのOsukiniサーバというとても安いVPSなんだが今のところCentOSかDebianかUbuntuしかなかった。FreeBSDねぇのか。 DebianとかめんどくさそうなのでUbuntuにするかと思ったわけだが、どちらにしろ再インスコになってとてもめんどいのでまたそのうちね。

別にIPv6使えるVPSを契約したいという予定もあって、いっそこのサーバも移行しようかと思ったがDTIのVPSはIPv6のアドレスが貰えるがスワップが使えないようなので一番安いプランはWebアプリ動かしておくにはあまり実用的でなさそうだ。というかスワップないと結構メモリあるプランじゃないと不安すぎるだろ。さくらのVPSはFreeBSDも入るがIPv6のアドレス貰えないからなぁ。IPv6はもうちょい使えるようになるまでしばらく様子見るしかねぇか。

PeerCastStation日記

IPアドレスというか接続先の管理がさっぱりわからなくなってしもうた。IPv6対応もそろそろ真面目に考え始めたんだが、そうするとアドレスがたくさんあって困りまくる。

PeerCastのプロトコルでは各ノードはグローバルなアドレスとローカルなアドレスを持つ。LAN内外で使えるようになってて、特に同じグローバルアドレスを持つノード同士が接続しようとした時には、ローカルアドレスを見てそっちに接続するようになっている。 ここにIPv6対応を入れると、IPv6専用にするわけにいかないのでIPv4のグローバル・ローカルアドレスとIPv6のグローバル・ローカルアドレスを持ってないといけないわけだ。自分のアドレスを4つも持ってないといけないのかよ。 さらに誰かに自分のグローバル・ローカルアドレスを送ろうとしたときには、相手がIPv6とIPv4どっちで接続してきたのか判別して合ってる方を返してやらないといけないわけで……。 判別しないで計4つのアドレスを常に渡してあげることもできるんだが、ちょっとIPv6のリレーとIPv4のリレーは分離したいのでIPv6のリレー内に下手にIPv4のアドレスを渡したくない。

今考えてるIPv6対応はシンプルで、

  • IPv6で配信したチャンネルはIPv6でしかリレーできない。
  • IPv4で配信されたチャンネルはIPv4でしかリレーできない。
  • 混在することがないのでIPv4しか接続できない人がリレー状況によって繋がったりつながらなかったりということはない1
  • 両方配信したければ2つチャンネル作ってください。

というもの。混在できるようにした方が作るのは簡単だけどユーザー的にはよくわからんことになるから避けたい。

あ、よく考えたらこれ実現するにはチャンネル自体にIPv6かIPv4かという情報が必要だなぁ。というかチャンネル毎にリレープロトコルの情報を持って、IPv6は従来のプロトコルと内容はほぼ同じだが別なプロトコルとして作らないといけないって感じか。その方向で整理して考えなおすか。IPv6は別プロトコルとした方がプロトコル自体の改造もしやすいな。

当初はあるプロトコルでリレー受信してきたチャンネルを別なプロトコルでリレー送信することもできちゃう!的なことも考えていたし、まあ普通にやればできるんだけど、混在の問題があるから実用的には無理があるわな。

いっそPeerCastインスタンスをIPv6モードとIPv4モードで分けて2つ立ち上げようかとも考えたんだが、localhostとか名前で引いてプレイヤーがIPv6のインスタンスに繋いできたときにIPv4のインスタンスでリレーしてるチャンネルに繋がらなくなるのでやめた。リレーはIPv6とIPv4で分けたいけど視聴はどちらからでも許可したいのだわ。

方針が決まったのでIPv6対応は落ち着いて放置しておける。先にJavaScripterになってhtmlベースのUI作らないと。

  1. 混在しちゃうと、IPv6でだけリレー可能なノードが3つつないでるけどIPv4でリレー可能なノードは1つもつながってないので今はIPv4しか使えない人はつなげないんだけど、IPv6とIPv4両方リレーできるノードがつながってきたらIPv4でもつなげるようになって……という状況があってつなげるんだかつなげないんだかよくわからなくなる。これはIPv6のチャンネルだから俺はつなげる・つなげない!というのがはっきり分かる方がいいよね。その上でリレーが詰まってるかどうかは従来通りってことで。 


ページのトップへ | トップ «前の日記(2012-01-30) 最新 次の日記(2012-02-20)» | 編集 | kumaryu.net by kumaryu