タグ

2009年2月7日のブックマーク (6件)

  • Lingr and Comet - 技術解説編:Kenn's Clairvoyance

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

    Lingr and Comet - 技術解説編:Kenn's Clairvoyance
  • 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スレッド。 非常に活動的なコネクションを使うアプリケーションなら効率的。 実際は、そのようなアプリケーションは少ない

  • PoCo::HTTP で Comet チャットサーバを作る - daily dayflower

    せっかくのイベントドリブンフレームワークな POE ですから Comet でチャットをやってみようかと。ありきたりですが。 POE::Component::* でウェブサーバを立ち上げられるのは現在のところ, POE::Component::Server::HTTPServer POE::Component::Server::SimpleHTTP POE::Component::Server::HTTP の3つがあります。1番目は最近 inactive なのでパス。2番目は「イベントフレームワーク」への馴染みはいいんですが「Simple」じゃなくなってます。3番目はコールバック関数を登録するというお気楽スタイルなんですがちょっと雑な感じ。 今回は楽をするために3番目の PoCo::HTTP を使ってみたいと思います。id:naoya 氏も最近紹介してましたし。 URI の設計指針は, チャ

    PoCo::HTTP で Comet チャットサーバを作る - daily dayflower
  • *BSD で kqueue・kevent を使ってみよう

    *BSD で kqueue・kevent を使ってみよう select() の欠点 select() は複数のディスクリプタをポーリングできる便利なシステムコールです。 しかしパフォーマンスはよくありません。理由は以下の通りです。 ユーザプロセスは、監視対象のディスクリプタ一覧をユーザ領域からカーネル領域にコピーする必要がある。 カーネルがポーリング結果をユーザ領域に返す際もコピーしなければならない。 カーネルは、ポーリング対象のディスクリプタを知るために、配列の全要素を調べなければならない。 ユーザプロセスも、入出力可能なディスクリプタを知るために、配列の全要素を調べなければならない。 上記の作業は、select() を発行するたびに毎回行わなければならない。 select() のパフォーマンスが悪いことは広く知られていたので、 各 OS でいろいろな取り組みが行われてきました。 Sol

  • 开云·体育(kaiyun)(中国官方网站IOS/安卓通用版

    系统提示 您访问的页面未找到, 5秒后自动跳转到首页

  • Subversionリポジトリのバックアップ方法いろいろ - ぱせらんメモ

    Subversionリポジトリのバックアップ方法が色々ありすぎて何がベストなのかわからなかったので調べてまとめてみた。 ただのファイルコピー 普通にファイルシステム上でディレクトリをコピー(あるいはアーカイブ)する方法。非推奨。 誰かがリポジトリにアクセスしている最中にやると壊す可能性がある。 リポジトリディレクトリをコピーしたいならsvnadmin hotcopyを使うべき。 長所 簡単。 速い。 短所 バックアップデータの可搬性に乏しい(アーキテクチャ依存)。 リポジトリをロックしないので壊す可能性がある。 データエラーが検出できない。 svnadmin dump/load svnadminのdumpとloadを使う方法。 誰かがアクセス中でも一貫性が保たれる。 あくまで管理対象のファイルのみのバックアップなので、設定やフックなどは別途バックアップが必要となる。忘れがち。 差分バックア

    Subversionリポジトリのバックアップ方法いろいろ - ぱせらんメモ