社会的関係にあるインスタント・メッセージングは、一般的に2つの種類、単一のチャットやグループチャットに分割し、複数のデバイスを有していてもよく、ユーザが同時にログイン
実質的に限り対応関係として、
ユーザ装置との間の関係
用户<-1---------------*->设备
ユーザー・グループのメンバーシップ
用户<-*---------------*->群组
メッセージ送信処理：
シングルトーク：AがBにメッセージを送信
A----send msg----> server ----deliver msg--> B
グループチャット：グループ1メッセージに送信される（ユーザA、B、C、D）
|----deliver msg--> B
A----send msg---> server -->|----deliver msg--> C
|----deliver msg--> D
唯一の理想的な状態トップ、およびマルチデバイスの問題があり、ユーザーがオンラインであるかどうかを検討していない、オフラインメッセージ（ない架空の保存されたオフラインチャットメッセージ）を保存するためにどのくらいの時間、オフラインメッセージを保存するかどうかを検討する必要があり、その後オンライン考えます
唯一のオンラインかどうかを検討し、マルチデバイス髪型メッセージのプロセスを考慮していません。
シングルトーク：AがBにメッセージを送信
| B 在线 |--- 直接 deliver msg--> B
A----send msg----> server --| |
| B 离线 |--- 等待上线 deliver msg--> B
グループチャット：Aは、（ユーザA、B線、Cオフライン、D線）グループ1にメッセージを送信しています
|---- 直接 deliver msg--> B
A----send msg---> server -->|---- 等待上线 deliver msg--> C
|---- 直接 deliver msg--> D
プロセスの上のマルチデバイスにもあまり異なっていると、事実を考慮すると、単に利用者を置くなどの複数のデバイスに設定する必要がありますが、全体のモバイルインターネットモデルのコンテキストで、手に携帯電話若干異なっています基本的に、携帯電話APP、ブラウザ、デスクトップアプリケーションメッセージとして、オフライン少しを必要とする場合、ユーザーにサードパーティの連絡先情報を使用してのビューのユーザエクスペリエンスの観点から、等号の場合には、ユーザの携帯電話番号または携帯電話装置を描きます通知、SMS、メール、主流またはAPPのなど、もちろん、メッセージ通知
だから、アカウントにオフラインメッセージ通知、追加のシミュレーションの場合は、ユーザー・グループの退会メッセージアラートです
シングルトーク：AがBにメッセージを送信
| B 在线 |--- 直接 deliver msg -----------> B
A----send msg----> server --| |
| B 离线 |--- 第三方触达 -----> 上线 deliver msg--> B
グループチャット：Aが（A、Bラインは、Cオフライン思い出さないユーザー、Dビープ音）グループ1にメッセージを送信しています
|---- 直接 deliver msg --> B
A----send msg---> server -->|---- 等待上线 deliver msg --> C
|---- 第三方触达 -----> 上线 deliver msg --> D
OK、からかいのビジネスモデルは、MQTTプロトコルを見て、機能が提供さEMQTT
MQTTについては、抜粋を紹介するモデルをパブリッシュおよびサブスクライブ
MQTT設計原理：
- 合理化、オプション機能を追加しないでください。
- センサ間のメッセージングを容易にするために、（パブ/サブ）モードをパブリッシュ/サブスクライブ。
- これにより、ユーザーは動的テーマ、ゼロ運用コストを作成することができます。
- 伝送効率を向上させるために最小限の量を転送します。
- 低帯域幅、高遅延、ネットワークおよびアカウントへの不安定性の他の要因。
- これは、継続的なセッション制御をサポートしています。
- クライアントコンピューティング能力の理解が低いかもしれません。
- サービス品質管理。
- 不明な架空のデータではなく、柔軟性を維持し、データ転送の種類や形式を強制
パブリッシュ/サブスクライブ・モデルを
そして、パブリッシャとサブスクライバの間であることを意味要求/パターンが異なっている。この同期に答える、パブリッシュ/カスタム情報（出版社）のクライアントクライアントの普及との関係をデカップリングモードおよびサブスクライブ・メッセージング（加入者）、およびあなたは直接の接触を確立する必要はありません。比喩、あなたがいない携帯電話で友人まで、お友達を呼んで、我々は交換を開始できるようにする必要があり、それは典型的な同期要求/応答シナリオであり、あなたは良い電子製の電子メールのメーリングリストを送信するために友人が、同じではありませんなぜ、なぜ、友人はそれが行きたいメッセージを表示するのは自由です、典型的な非同期が公開された/シナリオを購読するメール。
テーマ
MQTTは、主題情報によって分類され、そのように、ワイルドカードを介して濾過することができます。
- 建物-B /床5：5デバイス層Bのフロアを表します。
- + /床5：5の任意の床層のデバイスを表します。
- 建物-B /＃：F、Bは、すべての機器を表します。
EMQ
はじめに
EMQ 2.0（アーラン/エンタープライズ/弾性 MQTTブローカー）は、大規模な接続性と分散クラスタをサポートアーラン/ OTPプラットフォームの開発言語に基づいており、オープンソースのサブスクリプションモデルMQTTメッセージサーバを発表しました。
完全な非同期アーキテクチャ
非同期TCPコネクションハンドリング、非同期テーマ（トピック）サブスクリプション、非同期メッセージリリース：EMQメッセージサーバは、完全な非同期のErlang / OTPプラットフォームアーキテクチャに基づいています。このようなTCP接続のようなリソース負荷限界同期設計の一部のみがデータベーストランザクションを作成して実行Mnesia。
Erlangの一連の流れる非同期サーバーEMQメッセージの内部のMQTT加入者（加入者）に発行者（出版社）からのメッセージは、メールボックスを処理します。
---------- ----------- ----------
Publisher --Msg-->| Client | --Msg--> | Session | --Msg--> | Client | --Msg--> Subscriber
---------- ----------- ----------
ソース公式サイトemqtt
ユーザーは、ユーザーと話題の関係に加入し、実際のサーバーをemqttにログオンした後に保存されたセッションに頼ることで、あなたははっきりしていないセッションのユーザーの次のログは、まだ現在のサブスクリプションの関係を維持しないと、ユーザーのQoSを落とした後、1と2のメッセージは、サーバー上に保存されますあなたがメッセージを受信する前に、ユーザーが再度ログインする終わり、。
設計と実装
以下のようにインスタントメッセージングサービスを設計することができます
ユーザーA：
iPhone {
デバイスID： 'デバイス、iPhone '
ユーザーID： '111'
}
アプリ{
デバイスID：「デバイス・アプリ 」
ユーザID：「111」
}
アンドロイド{
デバイスID：「デバイス、アンドロイド 」
ユーザーID：「111」
}
ユーザB：
{
デバイスID： 'デバイスB'
のユーザID： '222'
}
ユーザC：
{
デバイスID： 'デバイス-C'
ユーザーID： '333'
}
グループ1：[ユーザA、ユーザB、ユーザC、]
シングルチャット：
ユーザーがメッセージを受信し、自分の関連トピックをサブスクライブ
A 订阅 'user/111/#'
B 订阅 'user/222/#'
C 订阅 'user/333/#'
ユーザーは、このようなBへのメッセージとして、他の人のトピックにメッセージを投稿します：
A 发消息给 B ----> 发布消息到 'user/222/inbox/111'
A 申请加 B 为好友 ----> 发布消息到 'user/222/application/111'
グループチャット
のユーザーが参加するための独自のグループに関連するトピックをサブスクライブするために、メッセージを受け取ります
A 订阅topic ----> 'group/1/#'
B 订阅topic ----> 'group/1/#'
C 订阅topic ----> 'group/1/#'
メッセージを送ります
A 发消息到 Group1 ----> 发布消息到 'group/1/inbox/111'
B 发消息到 Group1 ----> 发布消息到 'group/1/inbox/222'
C 发消息到 Group1 ----> 发布消息到 'group/1/inbox/333'
プラスグループ、招待
A 申请加入群聊 Group1 ----> 发布消息到 'group/1/application/111'
B 邀请 C 加入 Group1 ----> 发布消息到 'group/1/invitation/333/from/222'
招待を受けた（受信が許容されないことに留意されたいです）
A 订阅topic ----> 'group/+/invitation/111/from/+'
B 订阅topic ----> 'group/+/invitation/222/from/+'
B 订阅topic ----> 'group/+/invitation/333/from/+'
アプリケーションを受けたメイングループ（ノート受諾が受信されません）
A 订阅topic ----> 'group/1/application/+'
マルチデバイスログイン
A-iPhone 设备登录设置 session-id 为 device-a-iPhone
A-iPad 设备登录设置 session-id 为 device-a-iPad
A-Android 设备登录设置 session-id 为 device-a-Android
- サブスクリプションの操作として再びセッションとを作成していない場合は、ログオンする前に、関連するセッションがあるかどうかを確認することができ、もちろん、また機器を購読することによって区別することができます
この時点で、基本的な送信してもらうために受信、オフラインメッセージに関して、サードパーティのサービスはセッションを処理するために、独自のプラグインを開発するために必要ですが、ユーザーが切断メッセージを受信されます