檜山正幸のキマイラ飼育記 このページをアンテナに追加 RSSフィード

キマイラ・サイトは http://www.chimaira.org/です。
トラックバック/コメントは日付を気にせずにどうぞ。
連絡は hiyama{at}chimaira{dot}org へ。
蒸し返し歓迎!
このブログの更新は、Twitterアカウント @m_hiyama で通知されます。
Follow @m_hiyama
ところで、アーカイブってけっこう便利ですよ。

2008-12-19 (金)

「Erlang 30% + JavaScript 60% + 未知成分 10%」セミナー状況

| 10:34 | 「Erlang 30% + JavaScript 60% + 未知成分 10%」セミナー状況 - 檜山正幸のキマイラ飼育記 を含むブックマーク

明日やります。だいたい会場のキャパシティ程度は集まりそうです。が、僕が多少誤解していた点があって、普通に気分よく座れる人数は十五、六人程度。これは空間(部屋)の都合ではなくて、主に机の都合です。空間のほうはすごく広くて、30人、40人でも平気なくらいの広さがあります。倉庫の片隅に机と椅子があるようなイメージです。

したがって、「ちゃんとした机や椅子がなくてもいいや」ってことであれば、今からでも当日でもどうぞ。ただし、まったく連絡なしだとチョット困るので、メール連絡(hiyama{at}chimaira{dot}org)はお願いします。

質疑応答やディスカッションの時間を多く取って、セミナーつうよりカジュアルな勉強会っぽい感じでやります。資料やデモの準備は不十分ですが、心の準備は十分ですから大丈夫です。(オイッ)

SaitoAtsushiSaitoAtsushi 2008/12/21 11:27 アニメ「シュガシュガルーン」のオープニングテーマソングの「ショコラに夢中」が「夢みるシャンソン人形」をモチーフにしているそうです。

m-hiyamam-hiyama 2008/12/22 08:36 SaitoAtsushiさん、
そうなんですか。40年以上たっても色あせないのはすごいですね、シャンソン人形。

2008-12-12 (金)

「未知成分 10%」セミナーの申し込み

| 10:37 | 「未知成分 10%」セミナーの申し込み - 檜山正幸のキマイラ飼育記 を含むブックマーク

料金支払いとかの類<たぐい>にすると、特定商取引法に基づく表示とかプライバシーポリシー云々とか書かないとダメのような気がするので(よくは分かってませんが)、とりあえず「寄付」でやってみます。次のURLの「寄付」ボタンが申し込みです。ペイパル・アカウントはなくても大丈夫です。

スタンダード寄付、デラックス寄付、カスタム寄付の3コースがあるのでお好きなコースを選んでください*1。ちなみに、これら3コースの差は特にありません

既に寄付くださった方、どうもありがとうございます。(なんか結局手数料が43円かかって、スタンダードだと正味半分になっちゃう ^^;)相変わらずメールのみの受け付けも継続してますけどね :-)

*1:カスタム寄付は動くかどうか未確認です。

bonotakebonotake 2008/12/12 13:31 日本人は他の国の人に比べてタダ乗り大好きらしいですから、日本だと難しいかも。

自分が買う立場に立ったとしたら…期待以上で良い評価をいれたらおまけ(よりadvancedな内容、あとがき、追補、蛇足、errata :) など)が読める、とかなら、余分にお金払います。うわー小市民。
あるいは、定価以上の支払い分は続編への先行投資になる、とか。著者に続編出版の義務はあるわけじゃなくて、あくまでそういう気持ちの表現として。

m-hiyamam-hiyama 2008/12/12 14:18 bonotakeさん、
> 日本人は他の国の人に比べてタダ乗り大好きらしいですから、日本だと難しいかも。
ただ乗りつうか、安くなる手段があれば何でも利用しちゃうってことですかね。
評価を集めるのに、値段という要因を絡めたら、歪んでしまうのは、まー当然か。
どうしたら正直な評価を集めることができるんだろう。

> おまけ(よりadvancedな内容、あとがき、追補、蛇足、errata :) など)が読める、とかなら、余分にお金払います。
それ、おまけを別売しているってことじゃ?

> 定価以上の支払い分は続編への先行投資になる、とか。
これは、バージョンアップに対して若干の対価を取れば同じじゃないですか。もっとも、「先行」という点では「期待してます」の表明にはなるかも。

bonotakebonotake 2008/12/12 15:00 > それ、おまけを別売しているってことじゃ?
まぁそうです。でも、面白かったからこそ、おまけとか続きとか買おうと思うわけで。

>「先行」という点では「期待してます」の表明にはなるかも。
映画の特報って、元々はまだできてない映画の宣伝をして、それで制作費を集めるためのもの…と聞いたことがあるんですけど、要はそういうのをイメージしてみました。

stanabestanabe 2008/12/12 15:34 よい本を作るという目的の達成のために、(後で反映された)バグ情報(タイポの指摘、論理の飛躍の指摘、より詳細なソースの追加など)を送ってくれた人には割引、というのはどうですか?

レビュー/フィードバックではなく、「バージョンアップ/メンテナンス」への貢献を価格に結びつけるほうが、よく読み込んだ人は安価に買える上に内容の反映という達成感が得られて、なにもしなかった人にもバグ修正によるハイクオリティ本の恩恵が得られて、みんなが得するような気がします。レビューとちがって恣意的な評価が入りにくいのもメリットだと思います。どうでしょう?

m-hiyamam-hiyama 2008/12/12 16:34 stanabeさん、
> よい本を作るという目的の達成のために、(後で反映された)バグ情報(タイポの指摘、論理の飛躍の指摘、より詳細なソースの追加など)を送ってくれた人には割引、というのはどうですか?
おおーッ、それはいいですね。割引のタイミングをいつにするか問題ですが、次のバージョンアップを無償にする(一般の人からは若干いただく)とか、ポイントのようなものを配るとかで対処できそう。

> よく読み込んだ人は安価に買える上に内容の反映という達成感が得られて、なにもしなかった人にもバグ修正によるハイクオリティ本の恩恵が得られて、みんなが得するような気がします。
うん、得するような気がします。ありがとうございます。

co-scheco-sche 2008/12/13 12:10 自分は、書評は単に書評であるべきだと思います。

「書評そのもの」に対する興味を惹くという点で非常に画期的だと思うのですが、ユーザーから直接見える形で金銭が絡むとm-hiyamaさんの懸念されるような悲しい事態にもなりえますし…。
数は減るかもしれませんが、「レビュー/フィードバックで一律5%割引」のようなシステムの方が公平な評価が集まるのではないでしょうか。

m-hiyamam-hiyama 2008/12/13 12:52 co-scheさん、
> ユーザーから直接見える形で金銭が絡むとm-hiyamaさんの懸念されるような悲しい事態にもなりえますし…。
ですね。評価と価格をリンクさせるのは問題アリのようです(性善説過ぎる)。

> 数は減るかもしれませんが、「レビュー/フィードバックで一律5%割引」のようなシステムの方が公平な評価が集まるのではないでしょうか。
内容が感想や意見なのか、実質的な修正や情報提供が入っているかは、著者/出版者側の判断てことですね。確かに、恣意的な批判のように見えても、当の著者がそれでインスピレーションを得るなんてこともありそうですね。

本文で言い足りなかったので補足しますが、かさばる以外に紙の本がイヤな点は、出版の時点でほぼ固定化されてしまうことです。これが、「著者は間違わない」幻想を生んで、変な権威付けにもつながっているんじゃないのかな。僕も多少は出版側での仕事をしたことがあるけど、著者間違いますって。動きが激しい分野だと、時間がたつと役立たずになるし。継続的にメンテナンスして品質を上げる必要があると思うのです。それは、読者の協力がないと難しい、少なくとも協力があれば助かりますよね。

田辺田辺 2008/12/14 23:18 結論が出ている処でなんですが、評価と価格をリンクについては、最終的な価格を売り手側が決定できないというところに問題を感じました。(オークションは別)
その点で考えられるシナリオとしては、低評価を受けた場合のリスクを見込んで標準価格を高めに設定する、ということです。

> どうしたら正直な評価を集めることができるんだろう。

何もしなくていいと思います。
楽店の場合は、変にポイントと絡めたせいで裏目ったのであって、
Amazon や 価格.com では、みんな正直に評価していると思います。
但し、評価者の母集団に偏りはあるかもしれません。

> よい本を作るという目的の達成のために、(後で反映された)バグ情報(タイポの指摘、論理の飛躍の指摘、より詳細なソースの追加など)を送ってくれた人には割引、というのはどうですか?

謝辞に名前を入れるとか、そういうお返しも効果的です。
ちょっとしたエピソードですが、Java本について、誤りをメールで翻訳者の柴田さんに指摘したところ、なんと原著者に原著の errata (Web公開版)に私の名前を入れてくれるよう働きかけて下さいました。
実際、その errata で自分の名前を目にした時は嬉しかったです。柴田さんありがとう。

> 出版の時点でほぼ固定化されてしまうことです。

Web上でのアフターフォローが考えられます。
正誤表の公開は勿論の事、自身の書いた本の Q&A など実際に行っていた著者もいます。

> 読者の協力がないと難しい

現在の書籍で問題に感じるのは、Q&A、誤り報告など受け付けているかどうかと、その連絡先が目立つように記されていないことです。
前書きなどで、しっかりと謳ってくれれば有り難いと思います。

m-hiyamam-hiyama 2008/12/15 08:57 田辺さん、
> 結論が出ている処でなんですが、
いえ、結論は出てません。
> 低評価を受けた場合のリスクを見込んで標準価格を高めに設定する、ということです。
それはイヤです。
> 謝辞に名前を入れるとか、そういうお返しも効果的です。
貢献を認めるというか、心理的なものでも経済的なものでもいいのだけど、批判も含めた評価や情報提供に対して見返りがあるべきってことですよね。
> Web上でのアフターフォローが考えられます。
意外と利用されてない印象がありますが、実際はどうなんでしょう? それと、改訂版が出るあてがないと、著者もWebページをメンテナンスするモチベーションが続かない気もしますが。
> 前書きなどで、しっかりと謳ってくれれば有り難いと思います。
それもありますが、紙っていうのは、継続的なインタラクションには向かいと思います。

田辺田辺 2008/12/16 02:15 > 意外と利用されてない印象がありますが、実際はどうなんでしょう?
そうですね。フィードバックの量は、ネット上のコンテンツと比べたら明らかに少ないです。

> 著者もWebページをメンテナンスするモチベーションが続かない気もしますが。
仰るとおりです。インセンティブの問題ですね。それこそ「ただ働き」になりかねない。

> 紙っていうのは、継続的なインタラクションには向かいと思います。
これも仰るとおりです。

田辺田辺 2008/12/16 02:20 > 明らかに少ないです。
言い切っちゃっていますが、実際のところ印象だけの話です。

m-hiyamam-hiyama 2008/12/16 10:55 田辺さん、
>> 紙っていうのは、継続的なインタラクションには向かいと思います。
> これも仰るとおりです。
まず、自分でタイポ修正: 向かい → 向かない

小説とかだと、作者にたくさんのファンレターが来るのかも知れませんが、技術書なんかだと、はがきが2,3枚てな反応だったりします。一方ブログだと、こんなエントリーにさえ、これだけ(上のコメント群)の反応が付きます。この差は大きいですよ。
紙の書籍とその出版システムにも、いい点はたくさんあると思うのですが、批判や指摘を取り入れながら継続的に改善し続けるメディアにはなれないだろう、と思うわけです。

2008-12-10 (水)

告知:「Erlang 30% + JavaScript 60% + 未知成分 10%」のセミナーやります

| 17:44 | 告知:「Erlang 30% + JavaScript 60% + 未知成分 10%」のセミナーやります - 檜山正幸のキマイラ飼育記 を含むブックマーク

http://d.hatena.ne.jp/m-hiyama/20081120/1227159984 :

全体で90分、質疑応答でだいぶ時間を使ったので、スライドにあることを全部しゃべったわけではありません。特に、後半の Web Communication Channels は簡単なデモをしただけでした。機会があれば、もう少し説明したいと思っています。

「ちゃんと準備をしてから」とか言っていると来年になりそうなので、年内にやります。12月20日(土曜)午後にやります。

  • 日時:2008年12月20日(土曜日) 14:00 15:00 より
  • 時間:150分程度を予定
  • 場所:(株)シンメトリック(安達ビジネスパークビル)3F
  • 最寄り駅:小田急・代々木八幡駅、千代田線・代々木公園駅
  • 地図:Googleマップ
  • 定員:20人(空間と椅子に起因する上限値です)
  • 申し込み:メール、またはPayPal寄付
  • 必要なもの:なし

内容的には、次のエントリ(時間順)で書きかけになっているようなことです。

申し込みは、subjectに文字列「参加希望」を含めて、hiyama{at}chimaira{dot}org にメールください。本文はなくてもかまいません(あってもいいです)。[追記]檜山が目で見て手で返答するので、処理が遅くなることもあります。ご了承ください。[/追記]

面倒でまだセットしてないのですが、明日とかに有料にしますよ([追記 date="翌日"]やっぱり面倒だー、法律で決められた文面とか必要なのかも。[/追記])。これ、煽りとかじゃなくて、PayPal課金を試したいので、申し込み=PayPal送金 にします。ただし、金額は任意ですけど。

[追記 date="2008-12-12"]結局、申し込みは寄付方式にしました→詳細。あと、メールだけでもOKです。[/追記]

ここから下(続き)は、PTTのときのスライド原稿の一部です。これに沿ってやる気はありませんがやるかもしれません、多少の参考にはなるでしょう。


ことの発端

  • Webアプリケーションとはいうが…
  • 作る(or 作らせる)のはWebサイト所有者
  • ブラウザ利用者はサイトと独立にアプリケーションを作れないの?

ブラウザ上のアプリケーション

  • GUIはHTMLレンダリングエンジン
  • 実装言語はJavaScript
  • ストレージがない
  • 実は自発的に通信もできない
  • Ajaxは?
  • サイトに依存し縛られる

通信機能とストレージ

  • 中立な中継サイトを設けて、できるだけ透過的にブラウザ-ブラウザ通信をサポートする。
  • 永続的なストレージも提供する。
  • クロスドメインHTTP通信が必須
  • 現状、変な方法しかない -- 悲しいがしょうがない
  • 逆方向(サーバー --> ブラウザ)通信も必要 -- COMET
  • 参考: http://d.hatena.ne.jp/m-hiyama/20080528/1211950144

別な動機

  • サーバー側もJavaScriptで書けたらいいじゃない?
  • -- 既にあるけどあんまり流行ってない
  • JavaScriptプログラムがローミングしたら面白いのでは?
  • そりゃ無理でしょ
  • JavaScriptの小さな小さなサブセットくらいなら、、、、
  • この未練は今でも尾を引いている

Erlangがお手本

単に実装言語としてだけでなく、分散モデルも借用。

Erlang WCC
分散ノード ブラウザもノード
プロセス エージェント(動作主体)
PID エージェントID(AID)
メッセージ マイクロ・メッセージ
ターム JSONデータ
gen_server Call RGenic Call
gen_server Cast RGenic Cast

アリモノをツギハギ

  • JavaScriptのイベントモデルはW3C DOM3から
  • 外部からのコールバックはActionScriptのExternalInterface
  • データ形式は徹底的にJSON、ただし抽象的データ形式として
  • OMG IDLのサブセットで仕様記述の予定(全然できてない)

100%コンフォーマントはめざしてないが、それでも標準と折り合いを付けるのは大変。用語の混乱やネーミングの理不尽さに泣く、泣く、泣く。

COMET

  • 原理は簡単
  • やってみると、ブラウザごとの挙動の違いに泣く
  • JavaScriptのシングルスレッドにも泣く -- IOブロックとかsleepしてポールとかができない
  • On Demand JavaScript方式(a.k.a JSONP)とCOMETを組み合わせて、なんとか双方向通信、… くっ、苦しい。

COMETは資源を消費する

いっぱいプロセスやスレッドがいるぞーー。が、Erlangなら、、、

Erlangで作って感じたことは

  • たしかに考えやすい、作りやすい
  • 他の言語とものすごく変わるわけではない
  • スレッドのような難しさはない
  • 静的な型概念、型チェックがないのは痛いときもある
  • YAWSというプラットフォームもあることだし、Webアプリケーションには向いているのではないか
  • 逆に、Web的手法がErlangプログラミングに生かせることもある
  • テンプラもよろしくー
  • 500メッセージ/秒くらいはさばけそう
  • フォールトトレランスや実行時コード置き換えは今後
  • 最近やっと「不要なことは書かない」「いさぎよく死ぬ」「一人で死ぬ」が分かってきた。これは、Erlangのポリシーで納得が難しい部分。

アプリケーション

  • ジャンケン大会が最初設定した目標だった
  • 多人数でやるクイズやゲーム
  • 同時アンケート/投票
  • ブラウザ・サーバー(「神社」とか)
  • ブラウザ不在時はスクリプトで動く(と、いいな)

問題

  • クロスドメイン通信とか、技術的基盤があやしい
  • セキュリティ : よくわかんない
  • モラル : これも問題になるかもしれない
  • クラスター構成 : まだやってないので未知
  • 監視 : ライブラリがあれども事例が見つからない

2008-12-06 (土)

メーセージ配送の一般論

| 16:14 | メーセージ配送の一般論 - 檜山正幸のキマイラ飼育記 を含むブックマーク

Erlangは、プロセス指向とか並列指向とか形容されますが、メッセージ指向とも言えます。Erlangのメッセージ通信がなかなかに便利なので、これをErlang外の世界まで拡げて使いたいという願望が湧きます。それで、いろいろと試行錯誤してきたのですが、現状における一般的な枠組みを記しておきます。一般的すぎて具体性に乏しいきらいはありますが、具体例はおいおい追加します。

内容:

  1. エージェントとノード
  2. メッセージの封筒情報
  3. メッセージ中継のアルゴリズム
  4. ノード内のメッセージ配送
  5. 循環するメッセージへの対処
  6. 通信リンクとクラスター
  7. ノードの能力と分類
  8. Erlangノードとブラウザノード

●エージェントとノード

メッセージの送信(発信、発生)や受信の主体となるナニカをエージェントと呼びます。「エージェント」という言葉に深い意味は何もありません*1。送信者、受信者となり得るモノ(thing, entity)です。比喩としては、メッセージを手紙や荷物、エージェントを人間に例えてもいいでしょう。

エージェント達が居る場所をノードと呼びます。比喩で言うなら、マンションや会社のビルがノードです。とりあえず、エージェントは、活動中に今居るノードから別のノードに移ること(ローミング)はできないとします。これを比喩で言うと、勉強中は外出禁止とか仕事中は会社のビルから出ないとか。ただし、活動を終了して、別のノードで始動することはできます。これを、ローミングと区別してリロケーションと呼びます。リロケーションの実現はけっこう難しい問題となります。

エージェントもノードもたいていは識別子を持ちます*2。それぞれ、エージェント名ノードアドレスです。エージェント名はさらに2種類あり、固有名詞に当たるエージェントIDと、役職名にあたるエージェントロール名です。エージェントIDは、大域的な一意性が保証されます*3。それに対して、ロール名はノード内でしか一意性を持ちません、「課長」とか「お母さん」みたいなもの。会社部署ごとに課長はいるし、家族ごとにお母さんはいますから、「課長」「お母さん」を大域的一意識別には使えません。1つのエージェントが複数のロール名を持ってもかまいません(「係長=宴会部長」とか)。

ノードアドレスのほうは、各ノードを一意的に識別する名前です。名前の具体的な形は規定しません。メールアドレスやインターネットドメイン名のような構文とは限りません。通し番号や乱数値でもいいのです。なんでもいいのです。何らかの構文や構造を仮定してはいけません。

今述べた、エージェント名、エージェントID、エージェントロール、ノードアドレスの値の集合をそれぞれ、AgentName、AgentId、AgentRole、NodeAddr とします。AgentName = AgentID + AgentRole となります(+ は共通部分なしの合併)。これらは、データ型の名前だと考えられます。

●メッセージの封筒情報

メッセージの本体はデータですが、送信者から受信者に配送するためのメタデータを含んでいます。データが手紙や荷物の中身だとすると、配送用メタデータは封筒に書く情報です。それらは次のとおりです。

項目名 説明 値の型
to 受信者 AgentName
dest (destination) 受信者の居るノード NodeAddr
from 送信者 AgentName
orig (origin) 送信者の居るノード NodeAddr

もちろん、これに加えてデータ本体があります。実は、メッセージ自体やデータにもIDを付けることができます。正確に言うと、IDというよりは後で照合するための参照番号です。この参照番号の型をRefとして、次の項目を追加します。

項目名 説明 値の型
ref メッセージやデータに対する参照番号 Ref

refはrefereceの略でErlangの用語に基づくものです。refの値は、返信の照合・確認のときに使われます。

●メッセージ中継のアルゴリズム

メッセージの送信者(センダー/ソースエージェント)は、ある特定の受信者(宛先/レシーバー/レシピエント/ターゲットエージェント)に向けてメッセージを送ります。メッセージがいくつかのノードを渡り歩いて目的地まで到着するとき、インターネットにおけるルーティングのような中継が必要になります。

ここで考えているメッセージは、すべての封筒情報が揃っているとは限りません。封筒情報が一部欠けているケースも考えます。中間地点でメッセージを受け取ったナニカは、次のような動作をしなくてはなりません。

if (destがある)
    destに、あるいはdestにより近いと思われるノードに
    メッセージを送る;
else // destがない
    if (toがあり、toの型がAgentId)
        toからdestを求める;
        if (成功)
            メッセージを送る;
        else //失敗 
            メッセージを捨てる;
    else if (refがある)
        refからdestを求める;
        if (成功)
            メッセージを送る;
        else //失敗 
            メッセージを捨てる;
    else
        メッセージを捨てる;

こんな動作をするナニカをルーター*4と呼ぶことにします。要約すると、ルーターはdest(ディステネーションノード指定)がないときは、to(ただし、値がID)かrefを頼りにガンバッテdestを決めろってことです。ただし、ガンバリはベストエフォートの意味なので、うまくいかないならあきらめます

[追記]「destに、あるいはdestにより近いと思われるノードにメッセージを送る」の部分は、もう少し手順があります。

if (destを直接知っている)
    destにメッセージを送る;
else if (destに送ってくれそうなノードを知っている)
    そのノードにメッセージを送る;
else // 書いてある送り先ノードがサッパリ分からない
    メッセージを捨てる;

[/追記]

他のノードにメッセージを送る具体的方式は色々あり得ます。IOポートみたいな出口にメッセージをポイッと投げればいいのかもしれません、他のポートノードを表現するオブジェクトやプロセスに依頼するのかも知れません。あるいはもっと複雑な手順かもしれません。とにかく、目的のノードに届くように送り出します。

●ノード内のメッセージ配送

ノード間(inter-node)配送の仕分けをしているルーターは、自ノード宛のメッセージを見つけると、他のノードに送り出すのではなくて、ノード内(intra-node)配送の担当に渡します。実装上は、ルーターがノード内配送までついでにやってしまってもかまいません。ルーターは、toを見てそれが自ノード内のエージェントだと分かったら、直接にそのエージェントにメッセージを渡すほうが早いでしょう。

ノード内配送は、toのエージェント名かrefの参照番号を頼りに行います。名前のスコープはノード内ローカルなので、エージェント名にロール名が使えます。無名のエージェント(そのノードのデフォルトエージェント)も1個だけ許されます。ノード内配送のアルゴリズムは次のとおりです。

if (toがある)
    toに対応するエージェントを探す; // toはロール名でもよい
    if (成功)
        メッセージを渡す;
    else // 失敗
        メッセージを捨てる;
else if (refがある)
    refを待っているエージェントを探す;
    if (成功)
        メッセージを渡す;
    else // 失敗
        メッセージを捨てる;
else // toもrefもない
    if (デフォルトエージェントがいる)
        メッセージを渡す;
    else // 失敗
        メッセージを捨てる;

●循環するメッセージへの対処

ノードどおしのトポロジーによっては、メッセージが無限にたらい回しされるかもしれません。こういう事態の予防や検出は難しいので、TTL(time to live)を使うのが現実的でしょう。

循環が起こりえないようなトポロジーでは、この問題を考える必要はありません。とりあえずは、十分に単純なトポロジーしか考えないとして、循環するメッセージの件は割愛します。

●通信リンクとクラスター

ノードAからノードBへとメッセージを送れる具体的・実効的・直接的な通信手段があるとき、AからBに向かう通信リンク(あるいは単にリンク)がある、と言います。リンクを絵に描くときは矢印を使うので、ノードとリンクの全体は有向グラフとして描けます。ノードAからノードBへと向かうリンクは高々1本(あるか、ないか)なので、このグラフは多重辺を持たず、単純有向グラフとなります。

メッセージ通信に参加するノードの集合を、そのリンクも込めてクラスターと呼びます。クラスターは単純有向グラフで描けますが、リンクの向きを無視すると連結グラフになります。つまり、孤立したノードがあったり、複数の島から成ることはありません。

クラスターはグラフなので、可達性、推移的閉包、サイクル(循環)、距離(ホップ数)などの概念を適用できますが、ここでは割愛します。

●ノードの能力と分類

先に、ルーティング、つまりメッセージ中継のアルゴリズムを示しましたが、すべてのノードがルーティング機能を備えているわけではありません。むしろ、大部分のノードはルーティングしません。ルーティング(フォーワード、ディスパッチ)するノードをハブノード、ルーティングしないノードを末端ノードと呼びましょう。これはやや誤解を招きやすい用語法で(よって、変更の可能性あり)、ノードがハブか末端かは、各ノード固有の能力の問題であり、クラスターのトポロジーとは関係ありません。グラフのトポロジーからハブのように見えていてもルーティングしないノードかもしれません(その逆のケースも)。

ルーティングしないノードAに、destの値がA以外のメッセージを送ってもすべて捨てられます。つまり、末端ノードに対してdestは無意味です。さらに、ノード内配送の能力さえ持たないノードもあり得ます。1つのノードに1つのデフォルトエージェントが居るだけなら、ノード内配送は無意味です。そのようなノードにtoを付けてメッセージを送っても、捨てられるか、toが無視されてデフォルトエージェントに渡されるでしょう。

ノードのなかには、片方向のリンクしか持たないものがあります。送信だけしかできないノードは、ノードアドレスも必要としないので、アドレスを持たない(無名、住所不明)ノードかもしれません。

「内部配送もできない、送信しかできない、アドレスを持たない」といった非力なノードもクラスターのメンバーとして許すのは、メッセージ通信への参加の敷居を出来るだけ下げたいからです。

Erlangノードとブラウザノード

ノードやエージェントの実体は何であるか? -- 何でもいいのです。あまり具体化してしまうと適用範囲や発想が狭まるのがイヤなんですが、そうはいっても具体例がないと実感がわかないので、2種類のノードを紹介します。

ひとつはErlangのERTSです。この例は、発想の源泉なのでトリビアルと言えます。ノードは単にErlangノード。ノードアドレスはErlangノード名。通信の基盤層はEDP(Erlang Distribution Protocol)です。メッセージは特定の(前もって約束された)形式を持つErlangタームで、エージェントはほぼプロセスです。

「ほぼ」と言ったのは、「エージェント=プロセス」ではないからです。エージェント名(通常は人間可読文字列)はPIDとは別に用意するので、エージェント名とPIDとの対応がどこかに必要です。また、エージェント名が指す実体が単一のプロセスである必要もなく、複数のプロセスの連合体でもかまいません。逆に、1つのプロセスが複数のエージェントの役割を果たすこともできます。時間と共にエージェントの実体であるプロセスがすり替わっても問題ありません(エージェントの同一性/寿命とプロセスの同一性/寿命はまったく別物です)。

Erlangノードをハブノードにしたいなら、ルーティング機能をErlangで実装しますが、Erlangだけの世界では特に原理的問題はないと思われます。

さて、ブラウザノードですが、これは、実行中のブラウザインスタンスを1つのノードとみなすものです。ノードアドレスは動的に割り当てるしかありません(ノードの寿命は短い)。ブラウザは当然ながらEDP通信はできないので、メッセージはテキスト形式にエンコードしてHTTPに乗せます。ブラウザ内に居るエージェントは、JavaScriptで実装されたプログラム/オブジェクトとなります。通常、ブラウザノードはルーティングしません(出来ないとは断言しませんが)。内部配送は出来るかもしれないけど、保証の限りではありません。

ErlangノードとErlangで実装されたエージェントは、安定した長い寿命の名前(アドレス、ID、ロール名)を持つことができ、ディスクやデータベースも自由に使えます。それに対して、ブラウザノードとブラウザ内エージェントは永続性のある資源を何も持てません。これではまともなことが出来ないので、ブラウザ内に棲息するエージェントにも永続性のサポートをしましょう、ということになります。-- そこらへんのハナシはこの次。

*1:「エージェント指向」なんて言葉がありますが、一切関係ありません。

*2:後で述べるように、無名のエージェント、無名のノードも認めます。

*3:大域的とは言っても、インターネット全体ではなくて、ある限定的な範囲です。

*4:個人的には、メッセージングサーバーと呼んでいるのですが、ルーターのほうが親しみがあるでしょうから、ここではルーターと呼びます。

jj1bdxjj1bdx 2008/12/06 23:51 現在の(R12B5)Erlang nodeは他のノードのメッセージの中継の機能までは持っていないですね.基本的に直接つながる(TCPでもUNIX socketでもいいんですが)のが前提です.ですからフォワーディングノードをErlangで書くとなると結構大変かも.

m-hiyamam-hiyama 2008/12/08 08:52 jj1bdxさん、
> フォワーディングノードをErlangで書くとなると結構大変かも.
Erlangの観点から真面目に考えると大変ですが、当面の目的は、Erlangノード(ハブ)を中継しての「ブラウザ<-->ブラウザ」通信です。すごく単純化すれば、なんとかなるかと。

2008-07-23 (水)

何の準備もなしに、どこにいようとも、ブラウザとブラウザが直接通信できるよ

| 10:43 | 何の準備もなしに、どこにいようとも、ブラウザとブラウザが直接通信できるよ - 檜山正幸のキマイラ飼育記 を含むブックマーク

「ウチのワカイシがやっていること」で紹介したシステムを公開しました。

http://www.microapplications.net/download.html から libwcc-js-0.01.zip をダウンロードすると、そのなかに通信ライブラリが入っています。この通信ライブラリで、他のブラウザやサーバー側機能(Junctools)と通信ができます。

いまのところ、サンプルが2つしかなくて(随時追加予定)、お決まりのHelloWold(http://www.microapplications.net/trac.cgi/wiki/HelloWorld)、それと、別プラウザにalertを出すRemoteAlert(http://www.microapplications.net/trac.cgi/wiki/RemoteAlert)です。

RemoteAlertの実験(1台のコンピュータの場合)には、IEとFirefoxを準備してください。片一方でAlertReceiver.htmlを動かして、もう一方でAlertSender.htmlを動かします。レシーバー開始で表示されたID文字列を、コピー&ペーストでセンダーに入力すると、通信(リモートAlert)できます。このコピー&ペーストがバカみたいですが、そのうちネーミングサービスもできるでしょう(いつだかわからんが)。

ジャンクチャと呼ばれるメッセージ交換機は非力なサーバーで運用していて、しかも開発サイトと兼用なので、安定運用できるかどうかは不安です。落ちたらゴメンナサイ。

もうちょっと色々書きたいのだけど、抜歯後の消毒で歯医者に行くので、また後で。

2008-05-28 (水)

ウチのワカイシがやっていること

| 13:49 | ウチのワカイシがやっていること - 檜山正幸のキマイラ飼育記 を含むブックマーク

学生さん達に手伝ってもらっています。ジッサマの僕から見ると、彼らは子供達という感じなんだけど、「ウチの子」と呼ぶとホントの子供達と紛らわしいし、成人もしているのだから失礼でもあるし。青年達、僕の田舎の言葉でいえば「わかいし」だな。カタカナ書きでワカイシとでもしましょうかね。

そのワカイシ達がいま作っているモノがあります。ソフトウェアです。なんとか動くようですが、システムとしてはアルファ以前の段階。ですが、紹介しておきます。

一言でいえば、ブラウザ-ブラウザのあいだでの双方向リアルタイム通信を行う仕掛けです。次の図のような感じ。

通信路(リンク)は双方向で、n個のブラウザが通信(対話)に参加すれば、リンクのトポロジーはn頂点の完全グラフになります。いったん通信路が確立してしまえば、どのブラウザがどのブラウザに話しかけるのも自由ですし、同報(マルチキャスト)も行えます(同報の実装はできてないけど)。

あたかもブラウザどおしが直接に結びついているようにしたいのです。実際にはもちろん、中継のサーバーが必要です。この中継用のサーバー/サイトをジャンクチャ(juncture)と呼んでいます。ブラウザ達とジャンクチャの関係は次のようです。

ジャンクチャ(図のサイトJ)は黒子になるべきで、存在があまり表に出ないようにしています。ジャンクチャを利用するWebページは、どんなサイトからロードされてもかまいません。ローカルディスクから読み込まれたページでもOKです(だよね>ワカイシ)。もっとも、各Webページのどこか(通常はJavaScriptコード内)にジャンクチャ・サイトのURLを埋め込む必要はあります。

ジャンクチャを介して通信するWebページに必要なものはJavaScriptによる通信ライブラリです。このライブラリさえあれば(あと、ジャンクチャが動いていれば)、JavaScriptだけで分散アプリケーションを書けるはずです。アプリケーションの構造は次のような感じでしょう。

アプリケーションのロジック/アルゴリズムはJavaScriptで書くことになります。データの保存が必要になるでしょうが、それはジャンクチャ側のストレージを利用します*1 -- って、いまんところストレージは何もできてませんけど、、、

それと、サーバー側でないと実現できない機能はジャンクチャ内で動くツールとして実装します。ジュンクチャがErlangで作られているので、サーバー側ツールもErlangで書くのが自然です。「ErlangとJavaのあいだでリモートメッセージング」で紹介した方法を使えば、Javaを使うのもいいと思います。もともとは、サーバー側プログラミングもJavaScriptでと思ってましたが、ちょっと難しい。まー、JVM上のRhinoを使えばJavaScriptで書ける、と言えなくもありませんが(苦しい)。


今日の午前中、「あー腰がいてー」と言いながら、ジャンクチャ・サイトを公開するために、さくらインターネットの手続きをしました*2。あと何をしたらいいんだかよくわかってない(苦笑)のですが、ジャンクチャ・サイトが見えるようになったら告知し、通信ライブラリも公開します。

*1:ロード元のサイトにXmlHttpRequestを使って保存してもかまいません。

*2:それで、「今日はもう安静に」と思ったけど、このエントリーを書くために戻ってきたよ。

anonanon 2008/05/29 23:40 国会図書館には、本だけじゃなくて、エロゲすらあります。
http://d.hatena.ne.jp/longlow/20080222

m-hiyamam-hiyama 2008/05/30 08:39 anonさん、
あー、そういえば昔、僕の知りあいが研究のため(ジョークでも皮肉でもなくて、ほんとに学術的目的で)国会図書館にエロ本を見に行ったと言ってました。ビニール本だったかな(最近の子、いわゆる「ビニ本」て知ってるかなぁ?)
国会図書館、やるなー。