2

Facebook/Gmail チャットに似たものを実装しようとしています。私は彼らがコメット＆ジャバーを彼らの技術として使っていることを知っています。しかし、いくつかのことについて混乱しています。

  1. 本当にジャバーが必要ですか? 代わりに、単純な mysql テーブルを from、to、message、sent、および recd で使用できますか? mysql の使用に非効率性はありますか? パフォーマンスの低下はありますか?

  2. コメットは通常の Web サーバーを使用して実装できますか? 特別なサーバーが必要ですか? 私の知る限り、apache + phpは開いている接続が多すぎて処理できませんか? 単純なポーリングを使用する必要がありますか? システムに悪影響を及ぼすことはありますか? 通常のウェブホストですぐに使用できるものは何ですか? （チャットアプリを販売すれば、ほとんどの人に役立つはずです。）

  3. comet を実装する (現在) 最良の方法はどれですか? 無限のiframeは良い考えですか? しばらくするとphpがタイムアウトしませんか? それはクロス ブラウザ ソリューションになるのでしょうか、それとも醜いハックを書かなければならないのでしょうか? それはサーバーの負荷につながりますか？Gmail と Facebook は永遠の接続に何を使用しますか?

4

3 に答える 3

3

素晴らしい質問です。うまくいけば、これが週末にスタックで失われないことを願っています。フラッシュを使用したい場合は、kirupa に PHP とソケットの使用方法に関する優れたチュートリアルがあります。comet に関する限り、ある種のサーバー実装が必要だと思います。それが私の微弱な知識が今終わっているところです。

簡単なポーリングの例 (jquery + asp.net) http://trappedinhoth.blogspot.com/2009/04/ajax-jquery-chat-demo.html

Kirupa のチュートリアル (php5 ソケット + フラッシュ 8) http://www.kirupa.com/developer/flash8/php5sockets_flash8.htm

オープン ソースのフラッシュ チャット クライアント (Google、その他多数) https://blueimp.net/ajax/

彗星情報 http://cometdaily.com/

私はあなたの質問に実際に答えているわけではなく、より多くのリソースを示しているだけです。他の人が何と答えるのか、とても興味があります。

于 2009-05-09T19:56:31.000 に答える
2

本当にジャバーが必要ですか? 代わりに、単純な mysql テーブルを from、to、message、sent、および recd で使用できますか? mysql の使用に非効率性はありますか? パフォーマンスの低下はありますか?

はい、mysql ではなく jabber を使用する必要があります。RDBMS の使用が適していない理由の詳細については、Stonebraker らによる [The End of an Architecture Era (It's Time for a Complete Rewrite)][1] を読むことができます。

コメットは通常の Web サーバーを使用して実装できますか? 特別なサーバーが必要ですか? ... 単純なポーリングを使用する必要がありますか? システムに悪影響を及ぼすことはありますか? 通常のウェブホストですぐに使用できるものは何ですか? Gmail と Facebook は永遠の接続に何を使用しますか?

コメットは少し曖昧な用語ですが、心配する必要はありません。特別なサーバーは必要ありません。ポーリングは使用しないでください。[BOSH][2] を使用できます。これは、Facebook (およびおそらく Gmail) が使用するものでもあります。

クライアント側では [JSJaC][3] (または [Github の私のフォーク][4]) を使用し、サーバー側では [ejabberd][5] を使用します。どちらも [BOSH][6] (および [XMPP over BOSH][7]) をサポートしています。つまり、XMPP サーバーに直接 HTTP 接続を確立し、ポーリングを回避し、高いトラフィック負荷を処理できます。

これらすべてのリンクは、http://delicious.com/petef/stackoverflow-843889でブックマークされています。

于 2009-06-03T18:48:57.443 に答える
1

Jabber は (ママ) ミドルウェアとして安全に概念化できると思いますが、MySQL は確かに (永続ストア) バックエンドです。それがリンゴとオレンジです。

RDMBS の ACID 保証とそのスケーリング特性によって発生する制限を考えると、大規模な web2.0 アプリケーションはどれも、リアルタイム メッセージングのために RDBMS に依存することはできません。(関連する問題の 1 つだけを把握するために、SQL テーブルをオンザフライでパーティション分割してサーバーを追加することを考えてみてください。)

最も重要な考慮事項は、システム内のメッセージの持続性です。それらは永久に保持されるのか、それとも特定の時間枠の間だけ保持されるのか。チャット アプリケーションであることを考えると、後者である可能性が高いです。RDBMS の代わりにメモリ ベースのストアを使用しないのはなぜですか?

なぜ Jabber を使用する必要があるのですか? まあ、それは一種の標準なので、現時点では問題ではありませんが、将来的に相互運用の可能性が開かれるでしょう。

さらに重要なことは、これは長い間（インターネットの犬の年に）真剣に開発されてきたシステムであるため、（現在の時点で）そうであり、あなたが設計したものよりも成熟し続けると仮定するのは確かに公正です. 、実装、デバッグ、本番環境の準備を社内で行います。

彗星については全く無知なのでノーコメント！

于 2009-05-09T19:53:19.977 に答える