Web2.0の先にあるC10K問題 ― ＠IT
個々のクライアントがサーバに要求する処理量は小さなものでハードウェアの性能上は問題がなくても、あまりにもクライアントの数が多くなるとサーバがパンクする――。これが最近Web開発者の間で話題となっている「C10K問題」（クライアント1万台問題）だ。 プロセス番号が足りなくなる パンクするのは例えばプロセス番号だ。 Ajaxの実装として最近注目されている技術に“Comet”（コメット）と呼ばれるものがある。HTTPのセッションをあえて切断せずに、サーバとクライアント間でつなぎっぱなしにするテクニックだ。Cometを使えばクライアントからのリクエストに応えるだけでなく、サーバ側からも不定期に情報を送り出すことができる。例えば、Web上でチャットサービスを実装するには、通常はクライアント側からサーバに一定間隔でポーリングすることで、ほかのユーザーの発言分をサーバから取得して表示するが、Cometの
おとこのCometアプリケーション！ 非モテのためのJetty 6 Continuation入門まとめ（前編） (recompile.net)
« 突然、有名サイトに自分の写真が掲載されていたら | メイン | おとこのCometアプリケーション！ 非モテのためのJetty 6 Continuation入門まとめ（後編：その１） » おとこのCometアプリケーション！ 非モテのためのJetty 6 Continuation入門まとめ（前編） はじめに Jetty 6には、継続（continuation）という機構が用意されました。この記事では、その応用例であるCometによるウェブアプリケーションの実装を取り上げ、解説をします。 Cometでは、サーバプッシュ型アプリケーションを実現するために、サーバに対してHTTPコネクションを張り続ける必要があります。こうした接続の手法は、従来のHTTPサーバでは想定されているものではありません。 また、Cometが提供するイベントドリブン型のウェブアプリケーションでは、サーバ側や、クライア
CNET Japan Blog - 江島健太郎 / Kenn's Clairvoyance：Lingr and Comet - 技術解説編
さて、お待たせしました。いよいよCometとLingrについての技術解説です。 ■Comet解説 さて、まずはCometとは何で、どういう背景によって生まれたのか、についての解説から始めます。 まず前提として、Webアプリケーションにおいては、通信開始のトリガーは常にクライアント側が握っています。つまりURLを入力したりボタンをクリックしたときなどに通信が発生することになるわけですが、このようなアーキテクチャは、サーバ側で発生した変化をリアルタイムにクライアント側に通知することが原理的にできないことを意味します。 チャット・アプリケーションでは、複数のユーザから不定期にメッセージが送信され、それが他の参加者に一斉に配信されなければなりません。しかし、メッセージを受け取ったサーバ側では、それをクライアントに即座にプッシュで通知する方法がないのです。 そのため、一定期間ごとにブラウザがサーバに
javeline teleportって。 - 谷本 心 in せろ部屋
S2Javelinと紛らわしいな（汗 さて、以前id:mopemopeさんに、Ajaxを使ったプッシュサーバライクな処理(Cometと呼ばれているらしい)について聞かれたので、簡単にまとめ。チャットを作るイメージで。 Client : Ajaxでサーブレットに問い合わせ。 Server : 現在までのログを返す。 Client : ログを表示。更に現在時刻を「前回問い合わせ時刻」として保持。 Client : Ajaxで再度サーブレットに問い合わせ。引数として「前回問い合わせ時刻」を渡す。 Server : 「問い合わせ時刻」以降に変更があれば、差分を返す。 Server : 変更がなければ、コネクションは繋ぎっ放し。 Server : 変更が発生したら、差分を返す。 以下、繰り返し。 これを実装したのは、もう1年以上も前になるんだけど、当時はHTML + 自前のJS + 生Servlet
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
PHPだけでリアルタイムAJAXチャットシステムを構築する方法。 - ぎじゅっやさん
