タグ

cometに関するyoheiのブックマーク (5)

  • A Million-user Comet Application with Mochiweb, Part 1

    A Million-user Comet Application with Mochiweb, Part 1 In this series I will detail what I found out empirically about how mochiweb performs with lots of open connections, and show how to build a comet application using mochiweb, where each mochiweb connection is registered with a router which dispatches messages to various users. We end up with a working application that can cope with a million c

  • TheC10kProblem - 「C10K問題」(クライアント1万台問題)とは、ハードウェアの性能上は問題がなくても、あまりにもクライアントの数が多くなるとサーバがパンクする問題のこと

    TheC10kProblem - 「C10K問題」(クライアント1万台問題)とは、ハードウェアの性能上は問題がなくても、あまりにもクライアントの数が多くなるとサーバがパンクする問題のこと 目次 この文書について C10K 問題 関連サイト まず読むべき I/O フレームワーク I/O 戦略 1. 各スレッドが複数のクライアントを受け付ける. そしてノンブロッキング I/O と レベル・トリガ型の完了通知を利用する. 伝統的な select() 伝統的な poll() /dev/poll kqueue() 2. 各スレッドが複数のクライアントを受け付ける. そしてノンブロッキング I/O と 変更型の完了通知(readiness change notification)を利用する. kqueue() epoll リアルタイム・シグナル fd 単位のシグナル (Signal-per-fd)

  • Kazuho@Cybozu Labs: Comet の正しい使い方

    « 「スーパー技術者争奪戦」 | メイン | JavaScript から Flash の便利な機能を使う方法 » 2007年02月23日 Comet の正しい使い方 今日会社の勉強会で Comet について話す機会がありました。 Comet については、普及するかどうかという以前に、どう使えばいいのか、正しく使った場合に何をどこまでできるのか、という理解が共有されていないように思います。なので、(あくまで私見ですが) 使用したスライドの一部を公開したいと思います。よろしければごらんください。また、問題や改善すべき点があれば、教えていただければ幸いです。

  • 米Infoteria,Web向けチャット・サービス「Lingr」のWeb APIを近く公開

    インフォテリアの子会社である米Infoteriaは1月26日までに,同社が開発するWeb向けチャット・サービス「Lingr」をWeb APIとして公開する見込みだ。同社代表の江島健太郎氏が,誌記者に語ったもの。APIの名前は「Lingr API」になる模様。 Lingrの特徴は,Webアプリケーションの応答性を改善する「Comet」と呼ぶ技術を利用していること。HTTPのレスポンスを,サーバー上のデータに変更があるまで待たせておくことで,WebサーバーからWebブラウザへの擬似的なプッシュを実現する。ユーザーは,画面の再読み込みやポーリングによるデータのチェックが必要ない,応答性の良いアプリケーションを利用できる。HTTPのみを使って通信するので,通常のWebブラウザだけでサービスを利用できるのも利点だ。 Lignr APIの提供形態や利用方法などについては,1月24日現在では明らかにな

    米Infoteria,Web向けチャット・サービス「Lingr」のWeb APIを近く公開
    yohei
    yohei 2007/01/26
  • CNET Japan Blog - 江島健太郎 / Kenn's Clairvoyance:Lingr and Comet - 技術解説編

    さて、お待たせしました。いよいよCometとLingrについての技術解説です。 ■Comet解説 さて、まずはCometとは何で、どういう背景によって生まれたのか、についての解説から始めます。 まず前提として、Webアプリケーションにおいては、通信開始のトリガーは常にクライアント側が握っています。つまりURLを入力したりボタンをクリックしたときなどに通信が発生することになるわけですが、このようなアーキテクチャは、サーバ側で発生した変化をリアルタイムにクライアント側に通知することが原理的にできないことを意味します。 チャット・アプリケーションでは、複数のユーザから不定期にメッセージが送信され、それが他の参加者に一斉に配信されなければなりません。しかし、メッセージを受け取ったサーバ側では、それをクライアントに即座にプッシュで通知する方法がないのです。 そのため、一定期間ごとにブラウザがサーバに

  • 1