ReverseHttp Introduction Polling for updates is bad. We’ve known this for about as long as computers have existed. So why are so many web-based services (SUP, RSS and Atom feeds, Twitter, etc.) based around polling? The answer lies, first and foremost, in the asymmetry of HTTP. The web is split into two pieces: programs that make requests, and programs that handle them. It’s very rare to see a sin
これは技術的に相当面白い。勘違いがありそうな気もするので、間違った記述があればコメントなりTwitterなりでご指摘いただきたい。これまでのWebはプル型がメインだった。それはRSSフィードなどWeb2.0が騒がれるようになっても変わらず、Cometでも接続していなければ意味がない。 Reverse HTTPのデモ そんな制限を超えるのがWebHooksだ。そしてWebHooksを使いつつ、リアルタイム連携を強めたのがReverse HTTPだ。 今回紹介するオープンソース・ソフトウェアはReverse HTTP、リアルタイムWebを実現するソフトウェアだ。 Reverse HTTPではデモが用意されている。一つはテキストエリアが表示され、その文字を書き換えると別URLの表示がリアルタイムに書き変わるというものだ。ユーザが入力した情報を読み取る部分と、その結果を別な画面に反映するという二つ
上を行くかどうかは知りませんが :-p Ajaxはクライアントの都合でサーバーに通信を仕掛けるpull型の通信ができ、Cometはサーバーが好きなタイミングでクライアントへデータを送りつけるpush型の通信ができるわけですが、新たに双方向の通信ができる技術を開発しました。 具体的には、JavaScriptとサーバーの間で双方向のRPCができます。すなわち、サーバーからクライアント側のJavaScriptのメソッドが呼べるし、逆にクライアント側からサーバー側のメソッドを呼ぶこともできます。 サーバー側で call("addMessage", "Hello!") とやると、JavaScript側の function addMessage(msg) { ... } という関数が呼ばれたりします。 この技術を使って、試しにチャットシステムを作ってみました ＞ デモ （ソースコード）*1 リアルタイ
JavaScript - サーバー間で双方向のRPC通信を行う技術は「Aerial」（エアリアル）という名前になりました*1。アイディアを出していただいた皆様、ありがとうございましたm(_ _)m Aerialは、通信にFlashを使い、JavaScriptとサーバープログラムとの間で双方向のRPC呼び出しを行う技術です。つまり、サーバー側からJavaScriptのメソッドを呼び出したり、逆にJavaScriptからサーバー側のプログラムを呼び出したりします。 サーバーから直接JavaScriptのコードを呼び出したり、逆にJavaScriptからサーバー側のメソッドを呼び出したりできるので、通信の内容を意識する必要がなく、バグの混入を抑えます。RPC成分入り！ ライブラリを開発するときも、HTTPやブラウザ間の実装の違いを意識する必要も無く、ごく普通のTCP接続で通信を行うので、Come
この記事は，日経ソフトウエア2007年1月号，連載「簡単実装で学ぶWeb技術2006」の第7回「Comet――プッシュ型のWebアプリケーションを作る」の再録です。記事は執筆時の情報に基づいており，現在では異なる場合があります。 こんにちは，結城浩です。 今回は，サーバーからデータをプッシュするタイプのWebアプリケーションを作成する技法の「Comet」を紹介します。簡単なチャット・プログラムを通してCometの仕組みを学びましょう。 Cometとは 通常のWebアプリケーションは，クライアント（Webブラウザ）から送られてくるリクエストを受け取って動作します。つまり，WebアプリケーションはユーザーがWeb上のリンクをたどったり，ボタンを押したりすることをきっかけに動くのです。ここで，動きの主導権はクライアント側にあります。クライアントがサーバーから情報を「引き出す」ことによって動作する
さて、お待たせしました。いよいよCometとLingrについての技術解説です。 ■Comet解説 さて、まずはCometとは何で、どういう背景によって生まれたのか、についての解説から始めます。 まず前提として、Webアプリケーションにおいては、通信開始のトリガーは常にクライアント側が握っています。つまりURLを入力したりボタンをクリックしたときなどに通信が発生することになるわけですが、このようなアーキテクチャは、サーバ側で発生した変化をリアルタイムにクライアント側に通知することが原理的にできないことを意味します。 チャット・アプリケーションでは、複数のユーザから不定期にメッセージが送信され、それが他の参加者に一斉に配信されなければなりません。しかし、メッセージを受け取ったサーバ側では、それをクライアントに即座にプッシュで通知する方法がないのです。 そのため、一定期間ごとにブラウザがサーバに
Comet については、普及するかどうかという以前に、どう使えばいいのか、正しく使った場合に何をどこまでできるのか、という理解が共有されていないように思います。なので、(あくまで私見ですが) 使用したスライドの一部を公開したいと思います。よろしければごらんください。 サイボウズラボの奥さんによる Comet のサーバー周りの資料。すばらしい。C10K に対してどのようなアーキテクチャをとるのが良いかとの考察が特に勉強になりました。 また、問題や改善すべき点があれば、教えていただければ幸いです。 というので問題、改善すべきというわけではないですが Perl 周りの話で少し補足を。 資料中の「初心者へのオススメが PoCo::Server::HTTP でパフォーマンスが欲しい人には Sys::Syscall qw/:epoll/」の点。おそらく Perl でも epoll を使えますよというこ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く