Real-Time Web Test - Does your browser supports WebSockets?
This test was created to study implications of using WebSockets in real-life scenarios. Having WebSockets supported in your browser doesn't guarantee they will work for you. Antiviruses, firewalls and HTTP proxies may interfere WebSocket connections, sometimes rendering them useless. On this page you can see how well WebSockets can work with your Internet Connection, your Antivirus and all other s
第1回 クラウドとリアルタイムWeb | gihyo.jp
近年、HTML5やJavaScriptを活用したWebアプリケーションが増えるのと同時に、今まではネイティブなアプリケーションが常識であったデスクトップアプリケーションにもHTML5の波がやってきました。 具体的な例としてはWindows 8で追加されたWindowsストア アプリでは、HTML5とJavaScriptを利用したアプリケーションの開発がサポートされています。 HTML5で開発できる領域は広がっていますが、切っても切れない関係なのがサーバとの通信です。そして、その通信を見ていくと、最近ではユーザが能動的に情報を取りに行くスタイルではなく、FacebookやTwitterに見られるようなサービス提供側から情報がリアルタイムで配信されるスタイルが増えつつあります。 図1 Facebookメッセンジャーの入力中表示 これらのリアルタイム通信はサーバとの接続を常時行っておく必要がある
キスで学ぶPush実装技術
彼女とMacBookを並べてコーディング。 ようやくRailsの開発を一人で出来るようになった彼女が、俺に突然質問を投げかけた。 「ねぇ、WebサービスのPushってどうやって実装するの？」 「一般的には３つの方法がある。」と俺は答えた。 「クールな順にWebSocket、次にコメット、最後にポーリングだよ」 彼女は目を輝かせながら「それでそれで？！」と説明を求めてくる。 「ポーリングは、一定の時間ごと、たとえば３秒ごとにAjaxでサーバにリクエストを送って新着の情報が無いか問い合わせて、もし新着があれば処理を、なければスルーして次の問い合わせに備えるPush通知の実装だ。手軽に実装できる反面、新着がない多くの時間常にリクエストを送り続けることになるので無駄が多い。大規模なサービスで実装すれば、それだけでDDoSっぽくなっちゃう。また、リアルタイムも厳密には実現できなくて、MAXでポーリン
ついにRFCに登場！Webサーバとの双方向通信を実現する「WebSocket」 - builder
次世代のWebアプリケーションの中核を担う技術として「HTML5」に注目が集まっているが、それと並んで期待されている技術に「WebSocket」がある。 IETFとW3Cによって仕様の策定が進められており、最初の提案以来幾度もの改訂を経て、2011年12月11日にそのプロトコル仕様がRFCのProposed Standard（RFC 6455）となった。 AjaxからComet、そしてWebSocketへ WebSocketはウェブサーバとブラウザが直接コネクションを張って双方向通信するための技術規格である。HTTPとは異なる独自の軽量プロトコルによって通信を行うため、オーバーヘッドが小さく、長時間に渡って通信する場合でもHTTPコネクションを占有する必要がないというメリットがある。 WebSocketが生まれた背景には、サーバとブラウザがもっとリアルタイムに通信して情報の配信や更新を行え
次期Jetty×CometDがWebSocketで高い性能 | エンタープライズ | マイコミジャーナル
Jetty provides an HTTP server, HTTP client, and Servlet container. 次期リリースとなる「Jetty 7.5.0」と「CometD 2.4.0」の組み合わせは、WebSocketを活用したサーバ/ブラウザ間双方向通信を実現するにあたって魅力的な選択肢になる可能性がある。双方ともまだスナップショットの状況にあるが、スナップショット版を使ってラフなベンチマークを実施した結果がPrelim Cometd WebSocket Benchmarks - Webtide Blogsに掲載された。あまり現実的なベンチマークではないが、WebSocketトランスポートの性能がロングポーリントランスポートと違ってスケールしていることが示されており興味深い。 JettyはJavaで実装されたHTTPサーバ/Servletコンテナ。軽量で高速という
Jetty 6.0 Continuations、まとめ - FAX
Jetty 6.0 Continuations、まとめ 技術 Jetty 6 Continuations(継続) - Ajax対応！ このエントリは、上記エントリのまとめだ。私の思う要点は、以下2点。 クライアントのリアルタイムの更新を行う、大規模アプリケーションの作成には工夫がいる。 Gregさんの問題定義と解決が正しいとすると、Javaだけでなく、他の言語にも応用ができる。 JettyはAjaxアプリケーション向けに、JSP抜きの構成を提供している。 これは、先日の「エンタープライズAjaxアーキテクチャ」に対応する。EJBも、JSPも捨て、J2EEはサーブレットのみの時代まで戻るということだ。 問題とJettyの解決策 従来のモデル 1ユーザー(コネクション)あたり、1スレッド。 非常に活動的なコネクションを使うアプリケーションなら効率的。 実際は、そのようなアプリケーションは少ない
Jetty 6 Continuations - Ajax対応！ - FAX
Jetty 6 Continuations - Ajax対応！ 翻訳 (via こんな毎日・・・) 原文：Jetty 6.0 Continuations - AJAX Ready! 著者：Greg Wilkins Jetty 6.0.0 alpha 3がリリースされました！ サーブレット2.4のサーバが400kのjarと、たった140kの依存ライブラリに収まっています。(さらにJSPが必要な場合でも、たった2.6Mです！！)。 小さくて、速くて、簡潔で魅力的な点は全く損なわずに、スケーラブルなAJAXアプリケーションを構築するための、Continuationsと言う新機能をJetty6はサポートしました。Continuationsは、スレッドを使わずに非同期イベントの待機を実現します。 コネクション単位スレッド スケーラブルなサーブレットサーバを構築する上で、主要な課題の1つにスレッドとコ
おとこのCometアプリケーション！ Jetty 6 Continuation入門まとめ（後編：その２） (recompile.net)
« おとこのCometアプリケーション！ 非モテのためのJetty 6 Continuation入門まとめ（後編：その１） | メイン | example.com にAレコードが振られているどころかApacheが元気に稼働中である件 » おとこのCometアプリケーション！ Jetty 6 Continuation入門まとめ（後編：その２） このエントリーは、前回からの続きです。 サーバの実装 クライアント側の実装は、 リクエストを発行してから、カウンターの値が返ってくるまで待つlong-pollの仕組み ユーザからのイベントをうけて、カウンターの値を増加させるようにリクエストする仕組み というふたつに分類することができました。サーバ側についても、それぞれに対応するかたちで実装していきます。 Jetty 6では、Ajaxアプリケーションのために、org.mortbay.util.ajax.
おとこのCometアプリケーション！ 非モテのためのJetty 6 Continuation入門まとめ（後編：その１） (recompile.net)
« おとこのCometアプリケーション！ 非モテのためのJetty 6 Continuation入門まとめ（前編） | メイン | おとこのCometアプリケーション！ Jetty 6 Continuation入門まとめ（後編：その２） » おとこのCometアプリケーション！ 非モテのためのJetty 6 Continuation入門まとめ（後編：その１） このエントリーは、前回からの続きです。 サンプルアプリケーション それでは、Cometの実装をみていくことにしましょう。サンプルアプリケーションを用意しましたので、まずは大まかにサンプルアプリケーションの動作を確認してください。 サンプルアプリケーションは、サーバプッシュ型カウンターです。サーバ側に保存されているカウンターの値が増えると、そのイベントがクライアント側へと伝えられ、クライアント側の表示が更新されます。クライアントの動作に
おとこのCometアプリケーション！ 非モテのためのJetty 6 Continuation入門まとめ（前編） (recompile.net)
« 突然、有名サイトに自分の写真が掲載されていたら | メイン | おとこのCometアプリケーション！ 非モテのためのJetty 6 Continuation入門まとめ（後編：その１） » おとこのCometアプリケーション！ 非モテのためのJetty 6 Continuation入門まとめ（前編） はじめに Jetty 6には、継続（continuation）という機構が用意されました。この記事では、その応用例であるCometによるウェブアプリケーションの実装を取り上げ、解説をします。 Cometでは、サーバプッシュ型アプリケーションを実現するために、サーバに対してHTTPコネクションを張り続ける必要があります。こうした接続の手法は、従来のHTTPサーバでは想定されているものではありません。 また、Cometが提供するイベントドリブン型のウェブアプリケーションでは、サーバ側や、クライア
ピーエーネット技術研究所：技術レポート
まえがき 近年Ajax技術を利用した、リッチなWebアプリケーションが次々と登場しています。 皆さんも知っている通り、Ajax技術とは、要は「画面表示と非同期でサーバからのデータ受信を可能とする」技術のことです。 バックグラウンドでデータ要求／受信を行い、受信終了後にダイナミックに表示を切り替えます。これにより、非常に柔軟にUI を構築することができるという利点があります。 さて、ここで注目したいのは「データ受信」についてです。通常HTTPでのデータ受信は、クライアント主導です。つまり、「クライアントからデータ要求して、サーバがその結果を返す」と言う一連の流れで、データ受信を行なっているわけです。 では、下記のような要求を満たすアプリケーションを作成する場合を考えてください。 要求１：データ更新が秒単位で行なわれる。クライアント情報も秒単位で変化させたい。 要求２：いつデータ更新が発生する
CNET Japan Blog - 江島健太郎 / Kenn's Clairvoyance：Lingr and Comet - 技術解説編
さて、お待たせしました。いよいよCometとLingrについての技術解説です。 ■Comet解説 さて、まずはCometとは何で、どういう背景によって生まれたのか、についての解説から始めます。 まず前提として、Webアプリケーションにおいては、通信開始のトリガーは常にクライアント側が握っています。つまりURLを入力したりボタンをクリックしたときなどに通信が発生することになるわけですが、このようなアーキテクチャは、サーバ側で発生した変化をリアルタイムにクライアント側に通知することが原理的にできないことを意味します。 チャット・アプリケーションでは、複数のユーザから不定期にメッセージが送信され、それが他の参加者に一斉に配信されなければなりません。しかし、メッセージを受け取ったサーバ側では、それをクライアントに即座にプッシュで通知する方法がないのです。 そのため、一定期間ごとにブラウザがサーバに
Jetty 6.1.0 - Ajaxマルチメッセージング、非同期SSL、Grizzly対応も (MYCOMジャーナル)
Mort Bay Consultingは6日(米国時間)、Jetty Web Containerの最新版「Jetty 6.1.0」を公開した。JettyはJavaで開発されたWebサーバ。Apache License Version 2.0のもとで公開されているオープンソースソフトウェアで、Apache Tomcatなどと同じく、FLOSS実装のWebアプリケーションサーバとして代表的なもののひとつだ。6.1.0は安定版と位置付けられ、Java 1.4および1.5で動作、HTTP/1.1 RFC2616、Servlet 2.5、JSP 2.1/2.0に対応している。 6.1.0で実施された変更は、コアプロトコルエンジンの最適化・洗練、非同期SSLのサポート追加(新しいSSLコネクタの追加)、入出力性能を向上させた新しいAJP13コネクタの採用、Grizzly NIOライブラリを活用したGr
“「5分で作るチャット」を実際にやってみた”をやってみた « ku
Comet勉強会#1発表資料-Hello, world! を読んで、一年の間にCometどうなったんだろうと思ってCometのことを調べました。その一環で 「5分で作るチャット」を実際にやってみた - Spirit of Apprenticeship (みならいだましい) をやってみたのの自分用メモです。勉強会参加したかった！ いちおう一年前の話題によくあがっていたころに調べて、けっきょくIRCサーバとおなじものをHTTPになじむように実装し直すかんじなんだろうと理解したことにしていたものの、じっさい調べてみたら目からウロコなこと多数。 Meteorのページの解説が教科書的でわかりやすい 調べていて最も役に立ったのは pure perl のcometサーバ実装の Meteor のページでした。Cometサーバを設計実装する上での検討すべき点と実装上の困難についてとてもよくまとまっていて、読
Kazuho@Cybozu Labs: Comet の正しい使い方
« 「スーパー技術者争奪戦」 | メイン | JavaScript から Flash の便利な機能を使う方法 » 2007年02月23日 Comet の正しい使い方 今日会社の勉強会で Comet について話す機会がありました。 Comet については、普及するかどうかという以前に、どう使えばいいのか、正しく使った場合に何をどこまでできるのか、という理解が共有されていないように思います。なので、(あくまで私見ですが) 使用したスライドの一部を公開したいと思います。よろしければごらんください。また、問題や改善すべき点があれば、教えていただければ幸いです。
Web2.0の先にあるC10K問題 ― ＠IT
個々のクライアントがサーバに要求する処理量は小さなものでハードウェアの性能上は問題がなくても、あまりにもクライアントの数が多くなるとサーバがパンクする――。これが最近Web開発者の間で話題となっている「C10K問題」（クライアント1万台問題）だ。 プロセス番号が足りなくなる パンクするのは例えばプロセス番号だ。 Ajaxの実装として最近注目されている技術に“Comet”（コメット）と呼ばれるものがある。HTTPのセッションをあえて切断せずに、サーバとクライアント間でつなぎっぱなしにするテクニックだ。Cometを使えばクライアントからのリクエストに応えるだけでなく、サーバ側からも不定期に情報を送り出すことができる。例えば、Web上でチャットサービスを実装するには、通常はクライアント側からサーバに一定間隔でポーリングすることで、ほかのユーザーの発言分をサーバから取得して表示するが、Cometの
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Real-Time Groupware in the Browser: Testing the Performance of Web-Based Networking
IBM Developer
IBM Developer