Webアプリにリアルタイムの双方向通信が必要な場合、WebSocketを選ぶのは自然なことだと思います。では、どのツールでWebSocketサーバを構築すべきでしょうか。パフォーマンスは重要ですが、開発のプロセスも見過ごしてはなりません。パフォーマンスを基準にするだけでなく、開発のしやすさも考慮に入れるべきでしょう。今回の大合戦では、Clojure、C++、Elixir、Go、NodeJS、Rubyのそれぞれの言語によって慣用的な手法で実装されたシンプルなWebSocketサーバを比較したいと思います。 テスト内容 サーバに実装するのは、 echo と broadcast の2つのメッセージのみを扱う非常に単純なプロトコルです。echoは送信クライアントに返され、ブロードキャストは全ての接続クライアントに送信されます。そしてブロードキャストが完了すると、結果メッセージが送信者に返されます。
現在開発中のシステムにリアルタイムな処理があり、そこで socket.io を使おうかなと思ってて、そういう折にタイムリーにもこの辺りの記事がタイムラインで出てきたのでメモ代わりに自分の意見を残しておく。 blog.jxck.io qiita.com socket.io が提供してくれているもの 「ブラウザとサーバ間のプロトコル」という観点で見ると socket.io は WebSocket を基本として繋がらなかった時に XHR Long Polling や polling といった形式の代替手段を提供してくれるもの、という位置づけ。 一方で「ライブラリ」という観点で見ると socket.io はリアルタイムアプリケーションを作る際に必要になる処理をまとめて実装し、クライアントとサーバ間での EventEmitter として抽象化してくれているもの、という風になる。 もう少し噛み砕いて言
Websocket周りを使ってみたいと思っていろいろ試行錯誤をしていたのですが、PUSHERというAPIサービスを利用すると思いの外容易にWebsocketを既存のWebサービスに使えそうなので使ってみました。 （激しい一週遅れ感がありますが…。） 例えば既存のWebアプリにpush実装を行いたいために、通常は稼働中のWebサービスとは別にWebsocketサーバの実装が必要となるのですが、PUSHERを利用するとPush通知を行う部分（Websocketサーバ→ブラウザ間）の実装を代替させることができます。 Push通知を行わせたい部分でWeb側の実装でPUSHERのAPIを叩くことで、ブラウザへのWebsocketを通したPushを行わせることができるイメージになっています。 Websocketの接続数が最大20までで1日あたりのメッセージ発行数が10万回以内であれば無料で利用すること
Socket.IOBidirectional and low-latency communication for every platform PerformantIn most cases, the connection will be established with WebSocket, providing a low-overhead communication channel between the server and the client. ReliableRest assured! In case the WebSocket connection is not possible, it will fall back to HTTP long-polling. And if the connection is lost, the client will automatical
最近 SPDY と WebSocket がアツいですね。 再来週の SPDY & WS 勉強会 も、定員100名に対して 参加者が 247 名とかなりアツいことになっています。 その予習というわけでもないですが、最近 WebSocket を実サービスへの 導入方法を考えながら遊んでいたので、 WebSocket の負荷分散方法について 考えていることを書いておこうと思います。 ステートフルな WebSocket アプリケーション HTTP サービスは基本的にステートレスな実装になっており、リクエストが来るたびに DBサーバーや memcached などのバックエンドから情報を取得して返していました。 この構成では Web アプリ自体は完全にステートレス化することができているので、 負荷分散機はラウンドロビン等のアプリケーションを無視した負荷分散をすることができました。 しかし、 WebSo
ずいぶん前ですが Amon2 が WebSocket に対応したということで、今更感のあるチャットプログラムを書いてみることに。 今更とは言いつつも社内では IRC を使うことができないので、ちょっとしたメッセージがやりとりできるものを作ってみようかなと思い、そのベースとなるようなイメージで作ってみました。 オマケで以前から使ってみたいなぁと思っていた Redis や Proclet なんかも (無駄に) 使ってみました。 適当な Heartbeat で WebSocket を維持していたり、エラー処理が適当すぎて Member の一覧が嘘つきだったり *1 と、まだまだイケてない部分ばかりですが、最近時間がなかなか取れないこともあり、とりあえず動くし晒してみようかと思います。 Twincle の名前は昔テストで Twitter Client を作ったときに押さえた ID をそのまま踏襲し
ブログを下記に移転しました。デザイン変更により移転先では記事が一層読みやすくなっていますので、よろしければ移動をお願い致します。 irbから学ぶRubyの並列処理 ~ forkからWebSocketまで : melborne.github.com - 世の中は並列化花ざかりだよ 人間はシングルタスクのままなのに プログラミングするときは マルチタスクが要求されるなんて 世知辛い世の中になったものだね でも情報革命は始まったばかりだから 愚痴ってばかりもいられないよ 自分がその波にうまく乗れないとしても うまく乗ってる人の様を 間近で見てみたいと思うんだ そんなわけで.. Rubyのfork Thread Reactor EventMachine WebSocketなどの並列化について少し学んだので 自分の理解をここにまとめておくよ REPL irbはRubyにおける対話型の実行環境だよ こ
Cramp is a fully asynchronous realtime web application framework in Ruby. It is built on top of EventMachine and primarily designed for working with larger number of open connections and providing full-duplex bi-directional communication. Features Lightweight, minimal and able to handle thousands of open connections simultaneously Built in support for HTML5 technologies: WebSockets and Server-Sent
Amon2 が WebSocket に対応していた!! Amon2::Plugin::Web::WebSocket というプラグインをだしました。 Amon2 の中で非常に簡単に web socket がつかえます。 なんかよくわからん作法とかおぼえなくてもいいので楽すぎる。。 実装例は以下のとおりです。Twiggy でしかうごきません。 use strict; use warnings; use utf8; use Amon2::Lite; use Digest::MD5 (); get '/' => sub { my $c = shift; return $c->render('index.tt'); }; my $clients = {}; any '/echo2' => sub { my ($c) = @_; my $id = Digest::SHA1::sha1_hex(rand
彼女とMacBookを並べてコーディング。 ようやくRailsの開発を一人で出来るようになった彼女が、俺に突然質問を投げかけた。 「ねぇ、WebサービスのPushってどうやって実装するの？」 「一般的には３つの方法がある。」と俺は答えた。 「クールな順にWebSocket、次にコメット、最後にポーリングだよ」 彼女は目を輝かせながら「それでそれで？！」と説明を求めてくる。 「ポーリングは、一定の時間ごと、たとえば３秒ごとにAjaxでサーバにリクエストを送って新着の情報が無いか問い合わせて、もし新着があれば処理を、なければスルーして次の問い合わせに備えるPush通知の実装だ。手軽に実装できる反面、新着がない多くの時間常にリクエストを送り続けることになるので無駄が多い。大規模なサービスで実装すれば、それだけでDDoSっぽくなっちゃう。また、リアルタイムも厳密には実現できなくて、MAXでポーリン
Redmine, git, Jenkins などプロジェクト管理ツールの状態を横断的かつリアルタイムに表示するWebアプリ『Dashbozu』を作りました。 これを使えば、一つの画面でプロジェクトの”今”の状態を把握できます。 WebSocketを用いているので、ただ開いているだけで、次々と情報を得ることができます。 iPadで開きっぱなしにして、机の上に置いておくような使い方を想定しています。 なぜこれを作ったか 一般的なソフトウェア開発現場では Redmineでチケットを作成する gitでコミットを繰り返し、中央レポジトリにpushする JenkinsによるCIが実行される 結果を確認し、Redmineのチケットを閉じる という流れで作業が進んでいきます。 これらの作業の中で、開発者は「適切な」タイミングでチェックとフィードバックをすることを求められます。 例えば、チェックのタイミング
Mojolicious::LiteでWebSocketを使うまでにやったいろんなこと。 あるていど落ち着いてきたのでさらっとまとめてみる。 Mojo側でやること Client側でやること Varnishの設定を変える必要がある Androidでは対応ブラウザが少ない SoftBankは80番ポート以外かWifiでつなぎましょう Mojo側でやること webscoketメソッドを使って、websocket通信を受け付けるURLを用意。 各種イベントに対する動作を設定する。 $self->onの第1引数にイベント、第2引数に動作をサブルーチンリファレンスで渡せばいい。 $self->on(message => sub {...}); $self->on(finish => sub {...}); テスト段階での実装はとりあえずこんな感じ。 my $clients = {}; websocket
長い記事なので、先に結論だけ書いておきます。WebSocketのバイナリメッセージ機能は、これまでのインターネットのあり方をひっくり返します。「そんなの知ってるよ」という方もいるとは思います。僕も理屈では分かってたつもりだけど、実際にアプリを作ってみて、具体的にそれを感じることができたので、ちょっと長いですがどういうことなのか説明してみます。 WebSocketとは # WebSocketは、HTML5関連の中でも特に注目を集めている技術の一つです。通常のHTTP通信であればクライアントからのリクエストなしにサーバーは応答しませんが、WebSocketを使うことでクライアントとサーバーの間で双方向の通信が可能となります。これを利用することで、今後様々なリアルタイム性の高いサービスを構築することが可能になるでしょう。 そんなWebSocketですが、これまで波乱の道を歩んできました。数年前か
派手で見栄えがする大規模なプロダクトを作ろう！っていうことで、一人でフルスタックなネトゲを作っている。大きなプログラムを書いても破綻しないようにテスト書きまくってテストファーストを心がけたり、Travis-CIによる継続的インテグレーションで頑張ったり。 というわけで作っているのはMMORPGなんだけど、ここで実装するのはまあ平均的なMMORPGを想像してもらいたい。自分がやろうとしているのは、モダンなOSSとさくらの安いVPSで、独学の学生一人でもフルスタックなネトゲみたいなのが組める、ということの実証。 なんでそんなことをしているかって言うと、一応就活中で、見栄えがするアプリ提出できるとおいしいなーっていう下心。 *追記* ここでは https://github.com/mizchi/wanderer のことを言ってるんだけど大規模リファクタリング中なのでここで言ってることは半分ぐらい
[読了時間:2分] NodeJS Socket Lights from Computerlovers on Vimeo. 上のデモ動画を見て頂きたい。一つのサーバーと、28台のパソコン(OS混合)・iPadなどがリアルタイムに連携するものである。サーバーから出た指示を、クライアントが受け、その色を画面に表示する。特殊なアプリケーションを使っているのではない、クライアント側はウェブブラウザで特定のページを開いているだけなのだ。サーバーもウェブページもJavaScriptベースで、コード(プログラム)も大して複雑なものではない。 node.jsとWebSocketで何かが変わる ウェブサイトの仕組みをある程度わかっている人なら、このインパクトに驚いているのではないだろうか。サーバーからの指示をリアルタイムで受けつつ、マルチデバイス・マルチOS・マルチブラウザでありながこれだけの速度でシームレス
こんにちは、中川です。 先月無事に結婚をした開発者が一名おり、近年アシアルでは徐々に既婚者が増えてきている状況です。 ということで、結婚といえば共同作業ですよね。 今までは、一人で作業していて大変なことが色々あったと思いますが、 二人（複数）でやれば、乗り越えられることもあることでしょう。 Webアプリでも最近は、より共同作業がしやすい環境ができつつあるように思います。 そこで、今回はWebSocketを使ったリアルタイム通信でのやり取りを行い、 一緒にお絵描きができるサンプルアプリを作ってみました。 ■■■概要■■■ ・アプリ概要 ・・Canvas + WebSocket ・対応ブラウザ ・・Chrome or Safari (他、WebSocketが使えるブラウザ） ・サーバ側プログラム ・・node.js 0.2.0 ・・[email protected]
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
