タグ

vivverに関するkanbayashiのブックマーク (13)

  • Ruby で MessagePack-RPC - Blog by Sadayuki Furuhashi

    高速なオブジェクトシリアライズ形式 MessagePack をプロトコルに採用したRPCライブラリをリリースしました。 Ruby を使って簡単にRPCサーバーやクライアントを実装できます。 msgpack-rpc MessagePack-RPC プロトコルは既にkumofsやクラスタ管理ツール「clx」などで利用しており、高速なサーバーの実装にも便利ツールの実装にも、幅広く使えるシンプルなプロトコル仕様になっています。 clxを使うと複数のサーバーをグループに分けて、同じグループに属するサーバーに対して同じコマンドを実行できます。コマンドは並列して実行されるので、ファイル転送(rsync)のような時間のかかるコマンドでも快適に使えます。 clxのコアは汎用的なRPCサーバーで、RPC以外の機能はすべてモジュールとして実装されています。モジュールは起動時に登録できるほか、実行中でも追加でき、

    Ruby で MessagePack-RPC - Blog by Sadayuki Furuhashi
    kanbayashi
    kanbayashi 2009/12/08
    MessagePackって、こういう風に使えるのね。 <- MessagePackとMessagePack-RPCを混同してた
  • 54行で分散KVSを実装する(レプリケーション機能付き) - Blog by Sadayuki Furuhashi

    Ruby と MessagePack-RPC があれば、簡単なkey-valueストレージは簡単に作れます。54行で書けます(レプリケーションと負荷分散機能付き。サーバー38行、クライアント16行)。 簡単なKVSをベースにして、ログ集計や遠隔デプロイ、遠隔管理機能などの機能を追加していけば、ちょっと便利なサーバープログラムをサクサク自作できるハズ。 この分散KVSは、(keyのハッシュ値 % サーバーの台数)番目のサーバーにkeyを保存します。また、サーバーの名前順でソートしたときの「次のサーバー」と「次の次のサーバー」にデータをレプリケーションします。 すべてのサーバーで同じ設定ファイルを使います。サーバーごとの設定は引数を自分のホスト名に書き換えるだけなので、デプロイが容易です。 MessagePack-RPC for Ruby を使うと、分散しないkey-valueストレージ*1は

    54行で分散KVSを実装する(レプリケーション機能付き) - Blog by Sadayuki Furuhashi
    kanbayashi
    kanbayashi 2009/12/08
    Message Packって、こういう風に使えるのね。
  • ネットワークプログラムのI/O戦略 - sdyuki-devel

    図解求む。 以下「プロトコル処理」と「メッセージ処理」を分けて扱っているが、この差が顕著に出るのは全文検索エンジンや非同期ジョブサーバーなど、小さなメッセージで重い処理をするタイプ。ストリーム指向のプロトコルの場合は「プロトコル処理」を「ストリーム処理」に置き換えるといいかもしれない。 シングルスレッド・イベント駆動 コネクションN:スレッド1。epoll/kqueue/select を1つ使ってイベントループを作る。 マルチコアCPUでスケールしないので、サーバーでは今時このモデルは流行らない。 クライアントで非同期なメッセージングをやりたい場合はこのモデルを使える: サーバーにメッセージを送信 イベントハンドラを登録;このときイベントハンドラのポインタを取っておく イベントハンドラ->フラグ がONになるまでイベントループを回す イベントハンドラ->結果 を返す 1コネクション1スレッ

    ネットワークプログラムのI/O戦略 - sdyuki-devel
  • memcachedプロトコルのストリームパーサ - Blog by Sadayuki Furuhashi

    memcachedクライアントはほとんどの言語で実装されており、key-valueベースの何かを作るときにはmemcacheプロトコルをサポートしておくと、クライアントを実装する手間が省けるのでイケてます。 しかしmemcachedのテキストプロトコルのような「行」が主体となっているプロトコルは、スレッドを使った実装では比較的簡単に処理できるのですが(fgets(3)を使うなど)、selectやepollなどを使ったイベント駆動型の実装では非常に面倒なことになります。(一度パースしてみて、どうも全部データが到着していないようなら一度状態を変数に保存して、次にデータが到着したら変数から状態を復元して…) イベント駆動型の実装では、データを次々に投げ込んでいくと内部の状態が遷移していき、ゴールの状態にたどり着くとパース完了、という状態遷移型のパーサが必要になります。そこで、Ragel Stat

    memcachedプロトコルのストリームパーサ - Blog by Sadayuki Furuhashi
  • Aerial(エアリアル) - Ajax/Cometの次を行く リアルタイム双方向RPC - Blog by Sadayuki Furuhashi

    JavaScript - サーバー間で双方向のRPC通信を行う技術は「Aerial」(エアリアル)という名前になりました*1。アイディアを出していただいた皆様、ありがとうございましたm(_ _)m Aerialは、通信にFlashを使い、JavaScriptとサーバープログラムとの間で双方向のRPC呼び出しを行う技術です。つまり、サーバー側からJavaScriptのメソッドを呼び出したり、逆にJavaScriptからサーバー側のプログラムを呼び出したりします。 サーバーから直接JavaScriptのコードを呼び出したり、逆にJavaScriptからサーバー側のメソッドを呼び出したりできるので、通信の内容を意識する必要がなく、バグの混入を抑えます。RPC成分入り! ライブラリを開発するときも、HTTPやブラウザ間の実装の違いを意識する必要も無く、ごく普通のTCP接続で通信を行うので、Come

    Aerial(エアリアル) - Ajax/Cometの次を行く リアルタイム双方向RPC - Blog by Sadayuki Furuhashi
  • Comet/Ajaxの上を行く技術 - Blog by Sadayuki Furuhashi

    上を行くかどうかは知りませんが :-p Ajaxはクライアントの都合でサーバーに通信を仕掛けるpull型の通信ができ、Cometはサーバーが好きなタイミングでクライアントへデータを送りつけるpush型の通信ができるわけですが、新たに双方向の通信ができる技術を開発しました。 具体的には、JavaScriptとサーバーの間で双方向のRPCができます。すなわち、サーバーからクライアント側のJavaScriptのメソッドが呼べるし、逆にクライアント側からサーバー側のメソッドを呼ぶこともできます。 サーバー側で call("addMessage", "Hello!") とやると、JavaScript側の function addMessage(msg) { ... } という関数が呼ばれたりします。 この技術を使って、試しにチャットシステムを作ってみました > デモ (ソースコード)*1 リアルタイ

    Comet/Ajaxの上を行く技術 - Blog by Sadayuki Furuhashi
  • Cobbler

    Cobbler Cobbler has moved to fedorahosted.org/cobbler. Your browser is being redirected.

  • Cobbler - mizzy.org - Trac

    Cobbler が素敵すぎる ネットワークインストール環境がさくっと構築できる Cobbler がおもしろそうなので触ってみたメモ。参考にしたサイトは以下の通り。 サーバの構築を簡単にするためのステップ (その5:Cobber編 Part1 ) サーバの構築を簡単にするためのステップ (その6:Cobber編 Part2 ) PXEネットワークインストール(Cobbler) cobbler_top - Cafe Chantant Info Repositry - Trac 以下、Fedora 7 で Cobbler を動かしてみたメモ。 インストール yum で一発インストール。 $ sudo yum install cobbler 設定 cobbler check コマンドを実行すると、見直すべき設定ポイントを教えてくれる。親切。 $ sudo cobbler check The fol

  • 分散ファイルシステム/ブロックデバイスをまとめる - Blog by Sadayuki Furuhashi

    昨日KLab勉強会#2の資料を公開しましたが、その中で動的な分散ファイルシステムを設計していると書きました。分散ファイルシステムというのは既にいろいろ存在しているわけですが、情報が分散していてサッパリ分からないので、このあたりでまとめてみたいと思います。 間違っていたり古かったりするに違いないので、正確な情報は家の情報を参照してください。 ファイルシステムレイヤー NFS GFS(Global File System) OCFS GlusterFS Lustre 下位レイヤー Filesystem Block Device Block Device Filesystem Block Device 読み込み ○ ○ ○ ○ ○ 書き込み ○ ○ ○ ○ ○ アクセスの冗長化 × ○ ○ ○(負荷分散と排他) × データの冗長化 下位レイヤーに依存 下位レイヤーに依存 下位レイヤーに依存 ○

    分散ファイルシステム/ブロックデバイスをまとめる - Blog by Sadayuki Furuhashi
  • IPAX2007の資料を公開します - Blog by Sadayuki Furuhashi

    6月28日から29日に行われたIPAX 2007に出展しました。その際の資料を公開します。 ポスター(PDF 3.1MB) PDFプレゼンテーション(PDF 3.1MB) 対話型プレゼンテーション 高解像度版(QuickTime 11.2MB) 対話型プレゼンテーション 通常版(QuickTime 1.6MB) VIVERの表面的な動作のみ紹介しています。詳しく踏み込んだ内容については、KLab#2勉強会の資料と説明(KLab勉強会#2の資料を公開します - DSAS開発者の部屋)をご覧ください。

    IPAX2007の資料を公開します - Blog by Sadayuki Furuhashi
  • WikiForme - 自分用Wiki記法パーサ - Blog by Sadayuki Furuhashi

    はてな記法、PukiWiki記法、tDiary記法などなど、世の中「なんとか記法」が溢れているわけですが、往々にして「自分にぴったり合う記法なんてどこにも無い!」という結論に達する場合が多く、結果として「なんとか記法」の乱立を生んでいるのではないでしょうか。 というわけで、自分専用のWiki記法を簡単に作れるカスタマイザブルパーサ WikiForme を作ってみました。乱立乱立! 記法を統一しようなんてムリですよね。もはや宗教論争です。自分専用の記法があればいいんです。 ※2007/09/23: バージョン 0.3をリリースしました > WikiForme 0.3 リリース! - 構造化Wiki記法パーサ ※2007/09/13: バージョン 0.2をリリースしました > WikiForme 0.2 - 構造化Wiki記法パーサ ※2007/08/08: バージョン 0.1をリリースしまし

    WikiForme - 自分用Wiki記法パーサ - Blog by Sadayuki Furuhashi
  • みんなでターミナル Partty! 0.1リリース! - Blog by Sadayuki Furuhashi

    1つのターミナルを複数の人で同時に操作できるソフトウェア Partty のバージョン0.1をリリースしました! 万が一Parttyをご存じない方は、こちらをご覧ください。 ダウンロード: partty-0.1.tar.gz コンパイル LinuxMac OS Xで動作することを確認しています。LinuxではMakefileを以下のように修正してください。 # for Linux -#LDFLAGS += -lutil +LDFLAGS += -lutil そしてmakeしてください。 $ makeうまくいけばparttyという名前のバイナリができます。うまくいかなかったら、いろいろいじってみてください。 使い方 * Partty Host (create new session) [listen on TCP ]$ partty host # use default port [2577

    みんなでターミナル Partty! 0.1リリース! - Blog by Sadayuki Furuhashi
  • NBD + Device Mapper + OCFS2 + 動的にノードを追加 - Blog by Sadayuki Furuhashi

    最近のトレンドであるクラスタファイルシステムの一つ「OCFS2」を、4+1台のPCで動かしてみました。(1台は後から追加) ディスクの共有には今流行の「iSCSI」ではなく、Linuxの知られざる古参機能「NBD」(Network Block Device)を使用。NBDを4台のマシンで動かして、それをDevice Mapperを使ってRAID 0アレイにして、それをOCFS2で共有します。(mdadm RAID1はうまくいかず) NBDはiSCSIと似た感じのもので、サーバーにあるファイルやブロックデバイスをクライアント側でブロックデバイスとして認識できます。V-FIELDを開発する前はVIVERで使っていました。RAID 0にするには素直にmdadmを使えばいいのですが、普通だと普通なので。 ディストリビューションはMandriva Linux 2007.1、カーネルはディストリビュー

    NBD + Device Mapper + OCFS2 + 動的にノードを追加 - Blog by Sadayuki Furuhashi
  • 1