iPod を追い抜く？, そういえば Mac は, 「グループ内の 32bit 値入力を同期させるサーバ」

iPod を追い抜く？

Sony の安藤さんが HDD ウォークマンの発表会で言ったそうですが…うーむ。ぱっと見た感じでは市場に山ほどある普通の HDD プレーヤと変わらない感じだけどなぁ。もちろん世界最小・最軽量ということはありますが、iPod くらいのサイズになってしまえばそれもそれほど大きな差別化要素になるとは思えないです。その自信の根拠はどこにあるのだろう？
iPod の利点は iTunes との連携にあるそうで、特に Music Store を使い出すと他には移れない魅力があるらしいと聞きますが、安藤さんの発言は Music Store がまだ始まっていない国内に限った話なのだろうか。SME の政治力を使って、iTunes Music Store よりも早く国内で自社のソフトと連携させたダウンロード販売サービスを開始する目処がある、とか。

そういえば Mac は

あいかわらず欲しいことには変わりないんですが、どちらにしても Tiger が出てからにしようと今は思っています。Tiger なら「おうちで 64bit OS！」と悦にひたれるし(笑。

「グループ内の 32bit 値入力を同期させるサーバ」

って、どんなイメージだ？あるクライアントから来た 32bit 長のパラメータを、グループメンバにマルチキャストするような感じ？

コメント

かぴのすくぇ (Fri, 02 Jul 2004 23:31:04)

> どんなイメージだ？

つーことでサンプルをつくってみた。こんなん↓。

http://www.h4.dion.ne.jp/~kapisan/gameserver.lzh

まいき〜 (Sat, 03 Jul 2004 01:16:44)

虎さんは10.4.1が出てからの方がいいような予感。
Konfabulator開発の会社はずいぶん怒ってたようで。まあ、当たり前か。
おいらはQuickTimeに引かれたけど、Digitune氏は何がポイント高かったすか？

Digitune (Sat, 03 Jul 2004 09:13:59)

「Tiger 待ち」の理由は、単に買ってすぐ年貢を納めるのは嫌だなぁ、ってだけの消極的な理由なのでした。普段使っているのが Linux で、いっとう最初の OS X ですら面白がって使っていた僕のことなので、OS の完成度についてはあんまり要求高くないです(^^;。

こないだの基調講演で何が一番興味深かったかと言うと…そうですね、やっぱり 64bit 化と Spotlight でしょうか。「ローカルより Google の方が快適」ってのはまさにその通りで、PC 上でのデータ管理方法を根本的に見直したいとここのところよく考えるのです。Longhorn の DB ライクファイルシステムも興味深くはあれど、既に Be などで実現されていたことでもあり、いまひとつピンと来ません。Spotlight も単なる検索技術、と言ってしまえばそれまでなんですが、アプリケーション横断的な世界が実現されている、という記述にちょっと期待しています。僕の理想としては、ローカル／リモート／アプリケーションを区別 (意識) せずに、「自分のデータ」は簡単に見付けられ、OS レベルでデータには必要な冗長性が持たされているためバックアップも不要、ローカル、リモートを意識しないで良いので個々のマシンへの依存も最低限で、それら全てをシームレスに管理出来るような世界がくると良いなぁと思っているんですが、Apple の行っている Mac と iPod の連携や今回の Spotlight などの技術は、遅々とした歩みだとしても確実に進んでいるように思えるのですね。

Digitune (Sat, 03 Jul 2004 09:37:14)

だいたい読んだ＞かぴれんじゃー。僕の認識でそんなに違ってたわけじゃないみたいね。

読んでて思い出したのが IP Messenger のプロトコル。ところで今回のサンプルが TCP ベースなのには何か意味があるのかな？普通この手の処理は UDP で書いた方がめんどくさくない＆リソース的に優しくて良いのではないかと思うんだが…(クライアントの生き死には timeout で見るしかなくなるけど)。

もう少し汎用化して、サーバは単にクライアントに対して (マルチキャスト可能な) チャネルを提供するリフレクタとしてのみ動作し、そのリフレクタプロトコルの下位にゲームプロトコルを乗せ込むようなレイヤリングの方が面白いような気がする。

Global Internet に晒すとなるとそれなりに認証をかけたいところだが、とりあえずは単純な合言葉方式でいいかなぁ。でもまぁ IP Messenger もなんの認証もしてないから、いいっちゃいいのかな。

Java で書けばすぐなんだけど、常に JavaVM が立ち上がっている、という状況もメモリ状況が厳しい我が家の PC では避けたいような気も。さて…。

p.s. あのソース buffer overflow しまくりじゃない？あと、new で allocate した構造体を free(3) で開放しちゃってもいいものなの？

かぴのすくぇ (Sat, 03 Jul 2004 23:12:49)

> TCP ベースなのには何か意味があるのかな？

ない。UDP の方が軽いんだろーが、TCP のコードなら手持ちの切り貼りで作れたのでそうしただけ。

> もう少し汎用化

とりあえずデータ長可変にすればいーさ。

> p.s. あのソース buffer overflow しまくりじゃない？
> あと、new で allocate した構造体を free(3) で開放しちゃってもいいものなの？

趣味コードはまるで読み直さないからなー。が、バッファ漏れはないつもりだが。
あと new なんて使ってたっけ(free(3)てなんだ)。記憶にないな。

ここまで雛型があれば C でそれなりのサーバ立てるのもそんなに苦じゃなかろーと思われるのでＪＶＭなど不要だろーさ。つーわけで、しくよろー。

Digitune (Sun, 04 Jul 2004 23:30:01)

> バッファ漏れはないつもりだが。

バッファ漏れといっても Heap overflow がほとんどのようだが、外部からの悪意あるデータに関して非常に脆弱なように見えるんだが、どこか大元で塞いでたりするのかな？(あんまりちゃんと読んでないので)。

> あと new なんて使ってたっけ(free(3)てなんだ)。記憶にないな。

netserver.cpp の 360 行目とか。free は普通 malloc なんかといっしょに使われる奴。なんとなく対応関係がちぐはぐな感じがして気持ち悪かったんだが、C++ の世界は良く知らないので。これでいいもんなのか？

> C でそれなりのサーバ立てるのもそんなに苦じゃなかろーと思われるのでＪＶＭなど不要だろーさ。

ちゃちゃっと作る時はどーもやっぱり Java を使ってしまうなぁ。いろいろ楽だからね…。

かぴのすけ (Sun, 04 Jul 2004 23:56:58)

> バッファ漏れといっても Heap overflow がほとんどのようだが、
> 外部からの悪意あるデータに関して非常に脆弱なように見える

セキュリティホールのことか？。そんなもん一切考えて作ってない。
だが、プロトコル的にデータ長やインデックス値がないのでバッファ
オーバランなどないはずだが。

> free は普通 malloc なんかといっしょに使われる奴

そりゃ知ってるつーの。free の引数の 3 はなんだよつーこと。
ソース見ると確かに new と free が混在しておるよーだ。が、VC 的には
混在させてもちゃんと動くらしい。本当は混在させちゃダメ。

Digitune (Mon, 05 Jul 2004 07:44:56)

> プロトコル的にデータ長やインデックス値がないのでバッファ
> オーバランなどないはずだが。

とはいえ実際に受けてるバッファが固定長ならオーバーランもするでしょ (例えば name[80])。

> free の引数の 3 はなんだよつーこと。

引数じゃなくて、man ページのトピック番号のことだな。普通に「man free」とするとトピック １ の free が出てしまうので、明示的に「man 3 free」とする必要があるので。

Digitune (Mon, 05 Jul 2004 14:26:57)

訂正。

> 引数じゃなくて、man ページのトピック番号のことだな。

トピックじゃなくてセクションだった。ごめん。

かぴのすけ (Mon, 05 Jul 2004 20:58:20)

> バッファが固定長ならオーバーランもするでしょ

なんで？。

> man ページのセクション番号

ンなもの使ってないから知らんわ。

Digitune (Mon, 05 Jul 2004 22:09:17)

> なんで？。

バッファ長以上のサイズを memcpy すりゃ溢れるでしょ、とゆー当り前のことが言いたかったわけだ。ソースをもう少しまじめに追ってみたが、確かに安直に溢れそうなところはなさそうだった。

↓こういうコードや
memcpy(name, pl->data_buf, pl->data_size);
↓こういうコード
memcpy(tmp->name, name, strlen(name) + 1);
をみて反射的に危険信号が上がったわけだが (src 側パラメータしか見てない、ってのがその手のエラーの典型的なパターンなので。ミクロなレベルで常に dest 側 max を意識するような癖がついているんだよね)、ちゃんとコントロールされているのね。言いがかりすまんかった。