Netty-based chat System (iii) protocol customization----Message Chapter

Today we continue to discuss the agreement, today basic to a one-off chat agreement custom finished, the previous we told the login process, then the login is finished chatting, first we still use a and B as an example, a send a message to B, then the agreement of the message is as follows

Send Message Protocol:

{"id": "xxxx", "#": "MSG", "text": "Content", "to": "Receive User ID", "type": 0, "MsgId": "Message ID"

｝

ID: The ID generated by the client

#: No, we said before, it's a server-side handler.

Text: Message content

To: Indicates who is sent to

Type: Indicates the message type

MsgId: Indicates the ID of the message

There must be a lot of people later to see that there will be a problem, whether we need to from the sender is who, in fact, add it here, but it is not necessary, because if this person can send a message, then we can in the corresponding reply to store this person's information, So as long as the message is sent, the server knows who the message came from, so it does not need to be here to add from, and then the server to respond to the user whether to send the successful, return of the Protocol, we in the previous article

Auth there, with the same one is good, so now if the server found B online to notify B to receive the message, then we look at the server Notification B protocol

Protocol for server Notification B:

{"id": "xxxx", "#": "PSH"}

ID: server-generated ID

#: We use a PSH here to notify the user that you have a new message, to obtain, then B resolution to # for PSH should go to request the server to receive the message Psh=push

b Request server Receive Message Protocol :

{"id": "xxxx", "#": "Msg-syn"}

ID: Client Generation ID

#: One of the handler on the corresponding server

After the server receives this JSON, first will go to find the ID of B in the answer, and then go to Redis query chat information, add a sentence, here we store Redis, the key value is our own custom rules added, for example, if the ID of B is 1111

So I'm defining the key as user:1111:msg, so get the ID of B when I get the message.

After getting it, then we can give the message to B, then there is a protocol format for sending the message.

Send Message Protocol:

{"id": "xxxx", "fr": "Send User", "text": "Content", "Time": "Message Times", "type": 0, "MsgId": "Message ID" "LV", "100"}

ID: The server-side generated ID

FR: Send user

Text: Message content

Time: Message times

Type: Message type

MSGID: Message ID

LV: This is not very good understanding, this is the maximum score value of the message, maybe a lot of people on the score value is not clear, how to come out of this thing for no reason, let's explain, say A to B send a message

so if a 4 message is sent, the corresponding storage should be:
Score Value
zset structure: 1 MSG1
2 MSG2
3 MSG3
4 MSG4
So if User B comes to cancel, we'll find the message, send it to B, and then B, after successful, return the JSON string, the string that contains the content, whether it accepts the success, and the score value of the maximum message, which is the effect if B accepts the message successfully, We're going to delete these messages from Redis, and Redis provides a way to delete them based on score, we can erase all the messages between 0--max, and if you don't know what Redis is, if you have time, you'll put the code for the data store up, So now we know why we have to get the maximum value.

So when we send a message to B we did not end, when the B all the messages to B when the server will send a JSON data at the end, where the side contains whether all the message has been sent, and so on, and so on, if B received the data when it means that all the charge is complete, Many friends will feel very puzzled, why the last JSON inside will contain whether the message has been sent over the content, here we make a hypothesis, if the popularity of B is very hot, a lot of friends to send him a message every day, so the number of messages will be many, so when B came to the news we will not all of a sudden the news to B, Suppose B has 1000 messages, we may give B100 each time, and then add the last JSON data in the back of these 100, the inside to tell B whether the message has been all charged, B can choose according to their own choice is to continue to obtain or not to obtain, mainly to do this use, then nonsense not much to say, Let's take a look at the customization of this Protocol

{"id": "57968203", "#": "Msg-ack", "remain": 0, "LV": ["MSG": 2]}

ID: The server-side generated ID

#:msg-ack This is the end-of-expression, indicating that the message has been sent

Remain: Indicates if there is any remaining message 0 indicates that the message is all sent, 1 indicates that there is still a message unread

LV: Here we put a maximum value of the message, in fact, there is no meaning, the client will return the time to return this value, the reason for the array is that there may be a lot of other things to put on this side

When the client receives the message, it responds to the server-side, with the following protocol

The client receives the message response protocol:

{"id": "", "#": "Msg-fin", "LV": {"MSG": 2}}

ID: No, I'm not.

#:msg-fin that the get message is over, that is, B is not going to get the message,

LV: And the top is the same, if you really do not understand this temporarily can be ignored

So since a simple one-to-one chat protocol we have completed, in fact, there are many details I did not show, such as heartbeat mechanism, and for example if B is not on the line, b if online to take the initiative to get the message, there is to detect whether the user has changed the phone and so on details, This roughly said to replace the mobile phone this aspect, replace the phone we rely on when the user mobile device information and then calculate a value, each time to compare with the server, this value when the server that, in fact, after the successful login, casually find a free time can be done, also need to customize a specific JSON protocol