CMPP2.0 protocol SP-side · NET development

TNT



Content Description: This article introduces the issues that need to be paid attention to when implementing the CMPP2.0 protocol SP. net, provides solutions and reference opinions, and provides a reference for interpreting the CMPP protocol.



Keyword: CMPP 2.0 sms ismg Socket thread synchronization. Net event model



1. CMPP protocol Introduction

China Mobile Peer to Peer CMPP (China Mobile Peer to Peer CMPP) is an official protocol for SMS nodes in China Mobile mengnet to exchange SMS messages. As a participant in mengnet, the value-added Service Provider SP of mengnet must implement the SP according to this protocol specification, you can transmit your text message to the end mobile phone user through the data channel of the Mobile GSM network.

In fact, the Protocol regulates three aspects:

. Interface Protocol between SP and mobile Internet Short Message Gateway (ISMG)

. Interface protocols between ISMG (for example, short message exchange between mobile provinces and municipalities is implemented through ISMG)

. The interface protocol between ISMG and Gateway Name Server GNS (similar to the DNS Server on the internet). For example, cross-province text messages require GNS to help indicate how ISMG can send text messages.

Among them, the second aspect is the internal implementation of the Mobile Short message system. For SP, it can be viewed as "Transparent", as long as the correct interaction between SP and ISMG is realized, you can connect to the SMS System of the mobile Dream network. We only care about SP-side development details.



Ii. CMPP Interaction Mode

From the perspective of mobile phone users, there are two definitions of SMS initiation/receipt paths:

MT (Short Message Mobile Terminated, SMMT), SMS receiving, sms sent from SP to Mobile phone users.

MO (Short Message Mobile Originate, SMMO), SMS sending, sms sent from the Mobile client to the target SP.

The two types of SMS interaction are Socket transmission applications on the SP Side. the CMPP protocol uses the TCP/IP protocol as the underlying bearer protocol, applications on the TCP/IP protocol stack.

The interactive connections between SP and ISMG are divided into persistent connections and short connections.

The so-called short connection is a connection, transmitting a message, and then removing the connection after waiting for a reply. Obviously, the efficiency is very low, basically, I am not taken into consideration (the SP is not allowed to use short connections for actual app movement, but I just don't understand why I need to write documents to the mobile app? ISMG ?)

The so-called persistent connection means that the SP establishes a connection with the ISMG, and then continuously sends data packets (CMPP messages) to the ISMG. In this case, sending does not have to wait for the ISMG of a message to respond to the message, then, send the next message. At the same time, wait for the ISMG to return information or wait for the message that ISMG sends to the SP. It is not necessary to send and receive messages synchronously. the asynchronous mode is used. In terms of efficiency, it is clear that the full-duplex asynchronous mode is required to meet the actual application requirements.

As shown in (from CMPP2.0 official documentation), the data transmission process in persistent connection mode is demonstrated:

















Iii. SP-side development

1. Message Classification

First, there are many types of CMPP messages in the figure. The SP communicates with the ISMG. Generally, after these messages are sent, the other party usually needs to reply to a RESP message. Note that most of these messages have directionality, that is, they can only be sent from one end to the other, but not in the opposite direction. Some (a few) messages can be sent from both ends. The following information mainly comes from mobile documents. However, it is clear and supplemented for obfuscation or insufficient explanation of source documents. See the following table for details:

Message name
Transfer direction
Description

CMPP _ CONNECT
SP --- à ISMG
The purpose of the CMPP_CONNECT operation is that the SP registers with the ISMG as a valid SP identity. This message needs to send verification information to the ISMG, and the authentication method uses the md5 encrypted password, if an application-layer connection is established after registration (otherwise, ISMG will immediately disconnect the Socket), then the SP can receive and send text messages through this ISMG.

ISMG responds to the SP request with a CMPP_CONNECT_RESP message. For more information about the algorithm implementation, see the CMPP2.0 document and the appendix code in this article.

CMPP_CONNECT_RESP
SP certificate --- ISMG
ISMG replies to the CMPP_CONNECT message (whether or not the verification is successful). If it fails, the message contains reference information, but ISMG immediately disconnects.

CMPP _ ACTIVE_TEST
SP à ISMG
Both parties can send this message to avoid the system believing that the communication channel has been closed when no other message is sent. Every entity that receives this message should return the CMPP_ACTIVE_TEST_RESP message, and use "courtesy" to indicate that it is still communicating and maintain the validity of the data connection.

However, according to netizens, The ISMG implemented by some manufacturers only rely on themselves to send this message and wait for SP to answer CMPP_ACTIVE_TEST_RESP to determine the validity of the data link, ignore the CMPP_ACTIVE_TEST message of the SP (some overhead ?) This is worth noting. Do not send the message without responding to it, so as to avoid data connection failure.

CMPP_ACTIVE_TEST_RESP
SP à ISMG
Reply to the CMPP_ACTIVE_TEST message at the other end of the communication. For more information, see CMPP_ACTIVE_TEST.

CMPP _ SUBMIT
SP --- à ISMG
After a correct data connection is established, the SP sends an SMS packet to the ISMG. This message needs to be carefully studied. After receiving this message, ISMG must reply with the CMPP_SUBMIT_RESP message. If no message response is received within a certain period of time (the reference value is 60 seconds), the SP needs to resend the packet to ensure that the message is delivered. If no response is received after the resend reaches three times, the SP end should consider that the ISMG may have expired and should stop sending the short message.

CMPP _ SUBMIT_RESP
SP certificate --- ISMG
The message is sent to the sp by the ismg, and a "receipt" (msgid of the ismg end of the source CMPP_SUBMIT message) is returned to the SP, indicating that "I have confirmed that I have received your message ". After receiving the message, the SP needs to keep the message, because the ISMG will finally report whether the message is correctly sent to the user's mobile phone. The report confirms the message based on the message receipt.

CMPP_QUERY
SP --- à ISMG
This query does not query a single message, but queries the service status of the SMS messages sent by the sp to the ismg. You can query the total number or query by category. (Basically, query statistics are initiated on the Mobile sms business database)

CMPP_QUERY_RESP
SP certificate --- ISMG
ISMG returns the queried data to the SP.

CMPP_CANCEL
SP --- à ISMG
The Command Message initiated by SP to cancel a message contains the "receive" message that has been sent to ISMG so that ISMG can determine the message. If the message has been sent to the user, the message/command will be invalid, and ISMG will fail to return.

CMPP_CANCEL_RES
SP certificate --- ISMG
ISMG returns a response to CMPP_CANCEL and informs whether the deletion is successful.

CMPP_DELIVER
SP certificate --- ISMG
When there is a MO or status report, ISMG sends this message. Note: The data of this message can be the message sent to the SP by the user's mobile phone. However, the final status of the message sent by the sp to the ismg is returned, and the final status of the message is reported.

CMPP_DELIVER_RESP
SP --- à ISMG
The reply from the SP informs you that the CMPP_DELIVER message is received. Specify the msgid of the CMPP_DELIVER message reported by the SP so that the ISMG can know that the SP has received the message.

CMPP_TERMINAT
SP à ISMG
Both SP and ISMG can send messages to the other party. For some reason, the current data connection needs to be terminated. After the termination, the SMS data message can be sent (into the transaction phase) only after the Connection is re-established (verified.

CMPP _ TERMINATE_RES
SP à ISMG
Inform the recipient that the local end has better preparations for removing the connection.




2. Interaction stage

The interaction of the entire CMPP protocol is divided into two phases: verification and transaction. In the verification phase, the CMPP_CONNECTION message is sent for verification. After the verification is passed (it must pass), it enters the CMPP transaction phase and the SMS data can be sent. Messages below CMPP_CONNECTION in the preceding table belong to messages in the transaction phase.



3. Message Data Structure

Each message contains two parts: the message header and the message body. The fixed length of the header is 12 bytes. The length of other messages varies, but the length of the same type of message is fixed. Each field of all messages has only three types: Unsigned Integer (Unsigned Integer), Integer (Integer), and Octet String (String). Each type has an indefinite length, network byte sequence.

1. Message Header (composed of three Unsigned Integer fields ):

The 4-byte Total_Length (Unsigned Integer) contains the total length of the message (including the header.

The 4-byte Command_Id (Unsigned Integer) specifies the message, which is the enumerated value of the message in the above table. Based on this value, the application determines what messages the data packet is, so that the remaining message bodies can be parsed according to the specified message type.

4-byte Sequence_Id (Unsigned Integer) indicates the unique number of the packet sent to this message. This unique number can be viewed as the sequential operation number. After analyzing the interaction mode, we can see that SP sends data to ISMG, instead of stopping to wait for ISMG's reply every time it sends, but sending multiple data packets all at once, then wait for the response from ISMG. However, how does one know that the Response Message corresponds to the one in the previous message sent? This field solves this problem. The SP sends a message by serial number and waits for the response from the ISMG. In general, the response message data structure indicates which message the message is responded to by the SP. This corresponds to Sequence_Id. It does not need to be strictly unique, but it must be unique within a given period of time (basically, as long as the SP has not repeatedly sent messages in the past ). If a message needs to be answered by the SP, the SP must also enter the Sequence_Id of the message sent by the ISMG in the corresponding field, indicating that this is a response of a message. The Sequence_ID of the SP side and the ISMG side are not specific algorithms. SP can (but is not recommended) use the unique Id of the database as this value.



2. Message Body. The message body length varies with the message length. For other references, see China Mobile Peer to Peer (CMPP) (V2.0), here we will focus on the message body data structure of two important messages:

Message Body of CMPP _ SUBMIT:

Field name
Length (byte)
Type
Description

Msg_Id
8
Unsigned Integer
Information identifier, which should be generated by the SP-side ISMG. This field is left blank for ISMG transmission. Leave it blank when submitting the SP.

Pk_total
1
Unsigned Integer
Total number of messages with the same Msg_Id, starting from 1. If a message contains more than one short message, it may need to be divided into multiple messages. In fact, these messages belong to one complete message, therefore, you can enter the number of messages to be divided based on the number. Then, you can enter the total number of messages you need.



Pk_number
1
Unsigned Integer
Number of information with the same Msg_Id,