To create an instant messaging server with emqtt

Instant messaging in social relations generally divided into two types, single chat and group chat, and the user may have more than one device simultaneously log

Substantially as far as the correspondence relationship

The relationship between user equipment

用户<-1---------------*->设备

User group membership

用户<-*---------------*->群组

Message transmission process:

Single talk: A sends a message to B

A----send msg----> server ----deliver msg-->  B

Group Chat: A Group1 is sent to the message (user A, B, C, D)

                            |----deliver msg-->  B
A----send msg---> server -->|----deliver msg-->  C
                            |----deliver msg-->  D

Top only an ideal state, and did not consider whether the user is online, there is the problem of multi-device, consider online then have to consider whether to save offline messages, how long to save offline messages (not imaginary stored offline chat messages)

Only consider online or not, does not consider the process of multi-device hairstyles message:

Single talk: A sends a message to B

                            | B 在线 |---   直接  deliver msg-->  B
A----send msg----> server --|       |
                            | B 离线 |--- 等待上线 deliver msg-->  B

Group Chat: A sends a message to Group1 is (users A, B-line, C off-line, D-line)

                            |----   直接  deliver msg-->  B
A----send msg---> server -->|---- 等待上线 deliver msg-->  C
                            |----   直接  deliver msg-->  D

Considering the fact, with multi-device on top of the process is also not much different, just put the user should be set to multiple devices like, but in the context of the entire mobile Internet model is slightly different, a cell phone in hand basically draw the user's mobile phone number or cell phone device in the case of the equal sign, from the user experience point of view of using third-party contact information in case users need a little off-line, such as mobile phone APP, browser, a desktop application message notification, SMS, mail, etc., of course, message notification of the mainstream or APP

So the offline message notification into account, an additional simulation case is the user group unsubscribe message alerts

Single talk: A sends a message to B

                            | B 在线 |--- 直接     deliver msg   ----------->  B
A----send msg----> server --|       |
                            | B 离线 |--- 第三方触达 -----> 上线 deliver msg-->  B

Group Chat: A sends a message to Group1 is (users A, B-line, C offline not remind, D Beep)

                            |---- 直接                 deliver msg -->  B
A----send msg---> server -->|---- 等待上线              deliver msg -->  C
                            |---- 第三方触达 -----> 上线 deliver msg -->  D

OK, teasing business model look MQTT protocols and functions provided EMQTT

About mqtt publish and subscribe model to introduce an excerpt

MQTT design principles:

  • Streamlining, do not add optional features.
  • Publish / Subscribe (Pub / Sub) mode, to facilitate messaging between the sensors.
  • It allows users to dynamically create a theme, zero operational costs.
  • To transfer the amount to a minimum in order to improve transmission efficiency.
  • The low bandwidth, high latency, network and other factors of instability into account.
  • It supports continuous session control.
  • Understanding of client computing capacity may be low.
  • Service quality management.
  • Unknown hypothetical data, not force types and format of data transfer, maintaining flexibility

Publish / subscribe model

And request / answer this synchronization patterns are different, publish / Custom mode decoupling the relationship between client clients dissemination of information (the publisher) and subscribe messaging (subscribers), which means that between publishers and subscribers, and You do not need to directly establish contact. Figuratively, you call your friends, not until a friend on the phone and we have to be able to start the exchange, it is a typical synchronous request / response scenario; and a friend to send an email mailing list is not the same, you made a good electronic Mail the why why, friends are free to view the message it wants to go, is a typical asynchronous publish / subscribe scenario.

theme

MQTT is classified by subject matter information, and can be filtered through a wildcard, such as:

  • building-b / floor-5: 5 represents the device layer B floor.
  • + / Floor-5: 5 represents the device of any floor layer.
  • building-b / #: F, B represents all equipment.

Above excerpt know almost columns MQTT Beginners

EMQ

Introduction
EMQ 2.0 (Erlang / Enterprise / Elastic MQTT Broker) is based on Erlang / OTP platform development language that supports large-scale connectivity and distributed clusters, released an open source subscription model MQTT message server.

Full asynchronous architecture

EMQ Message Server is based on the full asynchronous Erlang / OTP platform architecture: asynchronous TCP connection handling, asynchronous theme (Topic) subscription, asynchronous message released. Only part of resource load limit synchronous design, such as a TCP connection Mnesia create and execute database transactions.

MQTT a message from the publisher (Publisher) to subscriber (Subscriber), in the interior of the asynchronous server EMQ messages flowing through a series of Erlang processes Mailbox:

                  ----------          -----------          ----------
Publisher --Msg-->| Client | --Msg--> | Session | --Msg--> | Client | --Msg--> Subscriber
                  ----------          -----------          ----------

Source emqtt official website

After the user logs on to emqtt actual server, subscribe to the relationship between the user and the topic is to rely on the saved session, you do not clear session user next logs still retain the current subscription relationship, and after dropping the user QoS 1 and 2 messages will be saved on the server end, when the user logs in again before you can receive messages.

Design and Implementation

So instant messaging services can be designed as follows

User A:
the iPhone {
Device ID: 'device-a-iPhone '
User ID: '111'
}

iPad {
Device ID: 'device-a-iPad '
User ID: '111'
}
the Android {
Device ID: 'device-a-android '
User ID: '111'
}

User B:
{
Device ID: 'device-b'
User ID: '222'
}

User C:
{
Device ID: 'device-c'
User ID: '333'
}

Group1: [User A, the users B, user C,]

Single chat:

Users subscribe to their own related topic, receive messages

A 订阅 'user/111/#'
B 订阅 'user/222/#'
C 订阅 'user/333/#'

Users post messages to other people's topic, such as A message to B:

A 发消息给 B     ----> 发布消息到 'user/222/inbox/111'
A 申请加 B 为好友 ----> 发布消息到 'user/222/application/111'

Group Chat
users to subscribe to a topic related to their own group to join, receive messages

A 订阅topic ----> 'group/1/#'
B 订阅topic ----> 'group/1/#'
C 订阅topic ----> 'group/1/#'

Send a Message

A 发消息到 Group1 ----> 发布消息到 'group/1/inbox/111'
B 发消息到 Group1 ----> 发布消息到 'group/1/inbox/222'
C 发消息到 Group1 ----> 发布消息到 'group/1/inbox/333'

Plus group, invite

A 申请加入群聊 Group1 ----> 发布消息到 'group/1/application/111'
B 邀请 C 加入 Group1 ----> 发布消息到 'group/1/invitation/333/from/222'

Receiving an invitation (note that the reception is not acceptable)

A 订阅topic ---->  'group/+/invitation/111/from/+'
B 订阅topic ---->  'group/+/invitation/222/from/+'
B 订阅topic ---->  'group/+/invitation/333/from/+'

Main group receiving application (note acceptance is not received)

A 订阅topic ---->  'group/1/application/+'

Multi-device Login

A-iPhone 设备登录设置 session-id 为 device-a-iPhone 
A-iPad 设备登录设置 session-id 为 device-a-iPad
A-Android 设备登录设置 session-id 为 device-a-Android

  • Can determine whether there is relevant session before logging on, if not create session and again as subscription operation, of course, can also be distinguished according to subscribe equipment

At this point the basic send and receive to get, offline message regarding third-party service is required to develop their own plug-ins to handle the session but the user receives a disconnect message

Guess you like

Origin blog.csdn.net/weixin_33893473/article/details/90965067