4

SUITABLE プロトコルを使用して、インスタント メッセージング用のネイティブ モバイル アプリを開発する必要があります。また、モバイルにログインできない人が Web サイトを介してインスタント メッセージングを継続できるように、そのアプリケーションの Web サイトを開発する予定です。

後で、音声通話とビデオ通話の機能をネイティブ モバイル アプリとウェブサイトの両方に追加する予定です。

  1. さて、私の質問は、上記の状況に基づいて、どのプロトコルを使用する必要があるかということです. 私はそれについてインターネットでいくつかの調査を行いましたが、XMPP、MQTT、MUMBLE の中から選択することができません。

上記の基準で、それらの中で最も優れているのはどれですか?

  1. また、モバイル アプリと Web サイトの両方で同じプロトコルを使用する必要がありますか? （まったくわかりません）。ネイティブ モバイル アプリと Web サイトで同じプロトコルを選択するか、異なるプロトコルを選択するかは、まったく問題になりますか?

ここでは私を初心者と考えてください。

あなたの反応は私にとって本当に大きな意味があります。

私は Web 開発が初めてなので、間違っているところを修正してください。

4

2 に答える 2

6

あなたの質問 XMPP vs MQTT vs mumble への答えは、質問で説明しなかった多くの要因によって異なります。主に機能以外の要件について。

XMPP は、もともとインスタント メッセージング プロトコルとして設計された xml ベースのプロトコルです。すべてのクライアント間のプレゼンスを処理する際に、メッセージの数とサイズの点でかなりのオーバーヘッドがあります。XMPP に基づいて実装することもできます。Google トークは XMPP に基づいており、XMPP を使用して、Jingle と呼ばれる XMPP の拡張機能を使用して VOIP セッションをセットアップします。

MQTT は、汎用の低オーバーヘッド パブリッシュ/サブスクライブ プロトコルです。インスタント メッセージングの実装を特に対象としているわけではありませんが、Facebook は Facebook メッセンジャーの基礎として使用しています。MQTT は、メッセージ サイズとキープアライブ要件の点でより効率的なプロトコルであるため、非常に多数のユーザーにスケールアップする予定がある場合、またはモバイル クライアントの応答性を低くする必要がある場合は、MQTT を選択できます。 . MQTT を選択すると、標準に従うのではなく、「アプリケーション レベル」のプロトコル メッセージを自分で設計する必要があります。MQTT は、ボイス チャットやビデオ ストリームをセットアップするためのトランスポートとして確実に使用できます。

サーバー側がモバイル クライアントと Web クライアントとのやり取りを適切に処理できる限り、モバイル クライアントと Web サイトで同じプロトコルを使用する必要はありません。異なるプロトコルを選択することもできます。

于 2013-10-29T10:11:13.723 に答える
-1

Facebookメッセンジャーはボイスメッセージをサポートしています.... http://mashable.com/2013/02/21/facebook-voice-messages/

于 2013-10-20T15:08:30.003 に答える