CMPP2.0 protocol SP end · NET development (transfer)

CMPP2.0 protocol SP end · NET development

TNT

Introduction: This article describes the problem that the CMP2.0 protocol SP end .NET implementation requires attention, and provides solutions and references to make an interpretation reference for the CMPP protocol.

Keywords: CMPP 2.0 SMS ISMG Socket Thread Thread Synchronization .NET Event Model

I. Introduction to the CMPP Protocol

China Mobile Communications Internet SMS Gateway Interface Agreement (China Mobile Peer To Peer CMPP) is an official agreement between SMS participation nodes in China's mobile phone network. As a member of the Dream Network, the Value Value Service Manager of the Mobile Network To implement the SP portion according to this protocol specification, you can transfer your own SMS through the data channel of the mobile GSM network to the final mobile phone user.

In fact, the agreement specifies 3 aspects:

. Interface protocol between the Internet SMS gateway (ISMG) of the Internet SMS, ISMG

. Interface protocol between ISMG (such as mobile provinces, short message exchange between the city) is performed between ISMG)

. Interface protocols between ISMG and the Gateway Name Server GNS, DNS Servers on the Internet, such as SMS across provinces require GNS help to point out how the current ISMG will pass SMS.

Among them, the secondary side belongs to the internal implementation of the mobile short message system. For SP, it is probably "transparent" to look at it. Just achieve the correct interaction of SP with ISMG, you can implement access mobile dream network SMS system. We care about the development details of the SP end.

Second, CMPP interactive mode

From the perspective of mobile phone users, there are two named methods according to the initiation / reception path of SMS:

MT (Short Message Mobile Terminated, SMMT), SMS Receive, SMS Send from SP to mobile phone users.

Mo (Short Message Mobile Orig Inn, SMMO), SMS Send, SMS Sends from the mobile phone user to the target SP.

These two types of SMS interactions, from the SP side, all of which belong to the Socket Transfer Application, the CMPP protocol is the application of the TCP / IP protocol as the underlying load protocol, which belongs to the TCP / IP protocol stack.

SP is connected to the interactive connection of ISMG and short connections.

The so-called short connection is a connection, transmits a message, then wait for the reply to remove the connection, obviously, the efficiency is very low, so, it is basically not considered (the actual application movement does not allow SP to use short connections, just do not understand why To write a document? Is ISMG will need?)

The so-called long connection is the SP established with the ISMG connection, and then continuously sends the packet (one CMPP message) to the ISMG, which is sent to send the next message to the ISMG response message returned without waiting for a message. At the same time, wait for the message to return information or wait for the ISMG to send to the SP. The transmission with the receiving message is not necessarily synchronized, and actually uses asynchronous (simultaneous duplex) mode. In terms of efficiency, it is clear that the asynchronous mode of the full duplex can meet the practical application needs.

The long connection mode data transmission process is demonstrated as shown below (from the official documentation of CMPP2.0).

Third, SP end development

Message classification

First, the CMPP message in the figure has many kinds of SPs to communicate these messages between ISMG. In general, the other party often needs to reply to a response (ResP) class message. Note that most of these messages have directionality, that is, only can only be taken from one end to the other, and in reverse direction, some (a few) can be emitted at both ends. The following information is primarily derived from the mobile document, but it is clear and supplemented to everyone's confusion or source document explanation. See the table below:

Message Name Transfer Direction Explanation Description CMPP_CONNECT SP --- àISMG CMPP_CONNECT operation The purpose is to register with ISMG as a legitimate SP identity. This message needs to issue verification information to ISMG. The verification mode uses MD5 encryption password mode. If the registration is successful, it is established The connection of the application layer (otherwise ISMG will disconnect the socket immediately), then the SP can receive and send SMS through this ISMG. ISMG responds to SP requests with a CMPP_CONNECT_RESP message. The specific algorithm implements reference CMP2.0 documentation and attachment code of this article. CMPP_CONNECT_RESP SPß --- ISMG ISMG Reply to the CMPP_CONNECT message (whether it is verified); if it is not passed, reference information is included in the message, but the ISMG will disconnect immediately. CMPP_ACTIVE_TEST SPßàismg Both parties can be issued, and the purpose is to maintain the communication link of both parties when there is no other message, avoiding the system that the communication channel has been closed. Each entity that receives this message should return CMPP_ACTIVE_TEST_RESP messages to "ritual" means that their own communications, maintain data connection validity. However, according to netizens, some manufacturers are implemented by ISMG, just send this message waiting for SP to answer CMPP_ACTIVE_TEST_RESP to determine the validity of the data link, and ignore the SP's CMPP_ACTIVE_TEST message (some overbearing?) This is worth noting, don't implement it just Send and do not respond to this message, avoid data connection failure. CMPP_ACTIVE_TEST_RESP SPßàism Reply to the CMPP_ACTIVE_TEST message of the other end of the communication. Act Reference CMPP_ACTIVE_TEST explanation. CMPP_SUBMIT SP - àISMG Sends an SMS packet to ISMG after properly establishing a data connection correctly. This news needs to be carefully studied. After receiving this message, the ISMG needs to be answered as a CMPP_SUBMIT_RESP message. If the message is not obtained within a certain time period (the reference value given for 60 seconds), the SP needs to resend this packet to ensure that the message is delivered. If the retransmission reaches 3 times, the SP should be considered that the ISMG may have failed and should stop sending this short message. CMPP_SUBMIT_RESP SPß --- ISMG This message is sent by ISMG to the SP, and returns a "receiving" (ISMG of the source CMPP_SUBMIT message) to the SP, indicating that "I ISMG has confirmed to receive this message". " After receiving this message, the SP needs to keep this "receipts" because the later ISMG will eventually report whether the message is sent correctly to the user's mobile phone. That report is to confirm the message with the "receiving" of this message. CMPP_QUERY SP --- àISMG This query is not querying a single message, which is a business situation of SMS sent to ISMG. You can check the total count, you can also classify queries. (Basically, initiating query statistics for mobile SMS business database) CMPP_QUERY_RESP SPß --- ISMG ISMG returns the query data to SP. CMPP_CANCEL SP --- àISMG SP initiated command messages that cancel a message, which contains "receiving strips" previously sent to the ISMG message so than ISMG can be determined that the message. If the message has been sent to the user, this message / command will be invalid, and ISMG returns a failure. CMPP_CANCEL_RES SPß --- ISMG ISMG Reply to CMPP_CANCEL and inform Whether to delete success. CMPP_DELIVER SPß --- ISMG When there is a MO or status report, ISMG sends this message.

Note that the data of this message can be a message sent to the SP of the user's phone, but also a response to the final state of the SP sent to the ISMG, the final state of the report SMS. CMPP_DELIVER_RESP SP --- àISMG SP Phonetic Reply Tell to receive a CMPP_DELIVER message. To point out the MSGID of the CMPP_DELIVER message of the SP report so that ISMG knows that message SP has been confirmed. CMPP_TERMINAT SPßàISMG SP and ISMG can actively send messages to each other, and this is to terminate the current data connection because some reason requires some reason. After the termination, you can send SMS data messages after re-connect (verify). CMPP_TERMINATE_RES spßàismg Notification the other party, the local end is preferably prepared to remove the connection. 2. Interaction stage

The entire CMPP protocol interacts is divided into two stages of verification. In the verification phase, send the CMPP_CONNECTION message to verify, and then enter the CMPP transaction phase by verifying (must pass the talent), you can send SMS data. The messages below the CMPP_Connection below are all messages in the transaction phase.

3. Message data structure

Each message contains two parts of the message header and the message body. The head fixed length is 12 bytes, and the length of other messages is different, but the length of the same type of message is fixed. All fields of all messages are basically three types: unsigned integer, Integer (integer), OCTET STRING, each type of concrete length, network byte order.

1, message head (3 unsigned integer fields):

4 bytes of total_length (unsigned integer), containing the length of this message (including header) length.

4-byte common_id (unsigned integer) indicating what message is that this message is, the enumeration value of the message in the table. The application determines what message this packet is based on this value, so that the remaining message body can be parsed according to the determined message type.

4-byte sequence_id (unsigned integer) indicating this packet unique number to send this message. This unique number can actually see as a flow operation number. Because we see the interactive mode, the SP sends data to the ISMG, not to wait for the ISMG reply every send one, but "one bit" sends multiple packets, and then waiting for the ISMG response. However, how do you know that the message responded is the one in the previous message before it is. This field is to solve this problem. SP sends a message in the past, waiting for the ISMG response - the response message data structure is indicated by the message that the message responds is the message sent by the message. This correspondence is dependent on Sequence_ID. It doesn't require it to be strictly unique, but in a given period of time, it must be unique (basically as long as the SP is sent in the past message). If the message that needs the SP answer, the SP must fill the sequence_id of the message sent by the ISMG to the corresponding field, indicating that this is a message response. Both SP and ISMG SEQUENCE_ID do not determine specific algorithms. SP can (but not recommended) uses the unique ID of the database as this value.

2, the message body. The length of the message body is different depending on the message, the length is different. Other Reference Mobile Documents "China Mobile Communication Internet SMS Gateway Interface Protocol (V2.0)", focusing on 2 important messages data structures: cMPP_SUBMIT Message:

Field Name Length (BYTE) Type Description MSG_ID 8 Unsigned Integer Information ID, should be generated by the SP side ISMG itself, fill in the blank, is used for ISMG transmission. SP submission should be left blank. PK_TOTAL

1 unsigned integer

The total number of information in the same MSG_ID, starting from 1. If a message length is more than a text message, you may need to break up into a plurality of messages, then this multiple messages belong to a full message, so you can numbered a plurality of SMSs obtained by this to decompose, then how many bars need to be composed SMS, how much is it.

PK_NUMBER

1 unsigned integer

The information serial number of the same MSG_ID starts from 1. Number determines the relative position of the message. Registered_delivery

1 unsigned integer

Whether to return status confirmation report: 0: No need 1: Need 2: Generate a SMC bill (This type of SMS is only available for gateway, does not send to destination terminals). In general, it is necessary to confirm the report. The SMC bill also needs to return a successful report. This message is used for monthly SMC, when you send a message to the mobile ISMG, the mobile billing system will deduct the user's information fee at one time, but this message will not be sent to the user's mobile phone. But attention, some ISMG vendors (very likely to move) to implement this news, if you do not send any messages of this monthly type of message to the user's mobile phone, it does not take a deduction behavior. Movies will think that this is a "generation charge" behavior that belongs to violations will affect the cooperation between the same move. MSG_LEVEL

1 unsigned integer

The information level, the priority of information. However, in practice, ISMG is not distinguished from priority. The service_id 10 OCTET STRING business type is a combination of numbers, letters and symbols. This represents a SMS classification that the business is issued. This field can be found to know the traffic of each service item, which is conducive to statistical and billing and settlement. FeE_USERTYPE

1

Unsigned integer

Billing User Type Field 0: Billing on the destination terminal MSISDN; 1: For the source terminal MSISDN fee; 2: For SP charging; 3: Meet this field is invalid, please refer to the fee_terminal_id field. Fee_Terminal_ID

twenty one

Unsigned integer

The number of the billing user (such as this byte fills down, indicating that this field is invalid, please refer to the Fee_USERTYPE field to the fee_usertype field, this field is 0, 1, 2 time mutual exclusive) TP_PID

1

Unsigned integer

GSM protocol type. For details, please refer to 9.2.3.9 TP_UDHI in GSM03.40.

1

Unsigned integer

GSM protocol type. For details, please refer to 9.2.3.23 in GSM03.40, only 1 bit, right align MSG_FMT 1 Unsigned Integer Information Format 0: ASCII String 3: SMS Writing Card Operation 4: Binary Information 8: UCS2 Code 15: GB Chinese characters This determines the byte content of the MSG_Content field to decode / encode / encoded in any code. MSG_SRC 6 OCTET STRING Information Source (SP's corporate code), for example 919000. FeetyPE2 OCTET STRING Target 01: "Billing User Number" free 02: "Billing User Number" Press the Composition Fund 03: "Accounting Household Number" Press the package monthly information fee 04: "Billing user The number of information fees of the number "05: The charge for" accounting household number "is implemented by the SP. The usual value is 02, pay attention to this is a string, not integer. Feecode

6 OCTET STRING TEL code (in units), such as "0050" represents RMB 0.50.

Valid_time 17 OCTET STRING Savory Validity Period, Follow SMPP3.3 Protocol AT_TIME 17 OCTET STRING Timer Send Time, Follow SMPP3.3 Protocol. This field allows SMS to give mobile phone users at a prescribed time. Under normal circumstances, it is retained as an empty string. SRC_ID 21 OCTET STRING source code or prefix is ​​a long number of service code. The gateway fills the number completely to the SOURCE_ADDR field of the SMPP protocol submit_sm message. The number eventually displays a short message on the user's mobile phone. number. In fact, it is a service code, it can be a long number DestusR_TL

1 UNSigned Integer receives the number of users (less than 100 users), usually 1. Move is an impression of a message to send multiple users. DEST_TERMINAL_ID 21 * DESTUSR_TL OCTET STRING Receives the MSISDN number of SMS, a structure similar to a string array. Affordable by DestusR_TL determines the length of this field. MSG_LENGTH 1 Unsigned Integer information length (MSG_FMT value is 0: <160 bytes; other <= 140 bytes). If it is an ASCII code, 160 English letters can be reached. The reason is because English letters only occupy 7bit, and Chinese and other double-byte code require 16 bits, while each byte is mostly occupied, there is a maximum of 140 bytes, which is 70 Chinese characters. MSG_Content MSG_LENGTH OCTET STRING Information Reserve 8 OCTET STRING

The CMPP_SUBMIT message length is variable, send the message of the SP side to the ISMG, ISMG will return a MSGID to the SP indicate this message, then (within 48 hours, but generally up to a few minutes), ISMG returns the delivery of this message report. The delivery report is submitted to SP by another important message CMPP_DELIVER:

CMPP_DELIVER's respective fields:

Field name

Byte

Attributes

description

MSG_ID

8 Unsigned Integer Information Identification The generated algorithm is as follows: 64-bit (8-byte) integer: (1) time (MMDDHHHMMMSS, ie month-time second): Bit64 ~ bit39, where bits 64 ~ bit61: binary representation; BIT60 ~ BIT56: Bi-genes in Japan; Bit55 ~ Bit51: Hour binary expression; Bit50 ~ Bit45: binary representation; bits44 ~ bit39: second binary representation; (2) SMS gateway code: Bit38 ~ bit17, send SMS gateway The code translation is integrated into this field. (3) Serial number: Bit16 ~ Bit1, the order is increased, the step size is 1, and the loop is used. If the parts cannot be filled, the left is fixed, and the right alignment is right. Dest_id 21 OCTET STRING service code, general 4-6 bits, or long number prefixed for service code; this number is a call number of mobile phone users short messages. Service_id10

Oclet string

The business type is a combination of numbers, letters and symbols.

TP_PID

1

Unsigned integer

GSM protocol type. For details, please refer to 9.2.3.9 TP_UDHI in GSM03.40.

1

Unsigned integer

GSM protocol type. For details, please refer to 9.2.3.23 in GSM03.40, only 1 digit, right align MSG_FMT

1

Unsigned integer

Information format 0: ASCII string 3: SMS write card operation 4: binary information 8: UCS2 encoding 15: GB Chinese characters SRC_TERMINAL_ID

twenty one

Oclet string

Source terminal MSISDN number (Status report to the destination terminal number of the CMPP_SUBMIT message)

Registered_delivery 1 unsigned integer

Whether to report 0: Non-status report (MO SMS) 1: Status Report This field determines that the CMPP_DELIVER message is that the mobile phone uplink a message to the SP or the message sent before the ISMG sent before the SP report is finally delivered. MSG_LENGTH

1

Unsigned integer

Message length. It refers to the length of the MSG_Content field.

MSG_CONTENT

MSG_LENGTH

Oclet string

Message content. If the message is not a status report, then in accordance with the MSG_FMT indicate the contents of the string of specific encoding.

Reserved 8 OCTET STRING Reserved

If it is a report, then MSG_Content will explain the status report structure:

Field name

Byte

Attributes

description

MSG_ID 8 Unsigned Integer Information Identification SP SMS (CMPP_SUBMIT) When the ISMG connected to the SP is Msg_ID. This MSGID actually sent a ISMG number that returned in the CMPP_SUBMIT_RESP message after the SP was sent before the cMpp_submit message. Supper, according to this MSGID, you can know the message finally determined delivery. STAT 7 OCTET STRING Send SMS response results, the meaning is the same as the STAT field as the STAT field in the SMPP protocol, see below. SP determines the processing status of the reported CMPP_SUBMIT message based on this field. Submit_time 10 Oclet String Yymmddhhmm (YY is the last two 00-99, mm: 01-12, dd: 01-31, hh: 00-23, mm: 00-59) DONE_TIME 10 OCTET STRING YYMMDDHHMM DEST_TERMINAL_ID 21 OCTET STRING Destination Terminal MSISDN Number (SP Send CMPP_SUBMIT Message "SMSC_SEQUENCE 4 UNSIGNED INTEGER The message identifier in the message body of the SMSC sends a status report. About the State field, as explained below:

Message status final status Description Delivered Delivrd message arrived at the target Expired Expired message expired DELED DELETED message Deleted Undeliverable Undeliv message Unreported Accept ACCEPTD Message Approve Unknown Unknown Unknown State Rejected Rejectd Message Bomb Back

Other message structures, specifically explained the CMPP protocol in the moving.

4. Safety verification

The CMPP protocol passes the verification message in CMPP_Connect. Verify that the message is a 9-byte 0 movement given the password of the current timestamp byte the byte after the MD5 algorithm. Timestamp is a month-time second, 10 digits. The code algorithm is as follows:

Private Byte [] getmd5code ()

{

Byte [] buf = new byte [6 9 _password.length 10];

Byte [] s_a = encoding.ascii.getbytes (_systemid); // is the corporate code

Byte [] S_0 = {0, 0, 0, 0, 0, 0, 0, 0}; // 9 bytes of 0, this is the right complement 0

Byte [] s_p = encoding.ascii.getbytes (_password); // password

this._timestamp = getTimeSTAMP (); // Assignment string when obtaining authentication code

Byte [] s_t = encoding.ascii.getbytes (_TimeStamp); // 10 string byte array

S_A.copyTo (BUF, 0);

S_0.copyto (buf, 6);

s_p.copyto (buf, 6 9);

s_t.copyto (buf, 6 9 _password.length);

MD5 md5 = new md5cryptoserviceProvider (); // creation MD5 category

Return (md5.computehash (buf, 0, buf.length);

}

The GetTimeStamp function returns a string such as "0710125959" (July 10:59 59 seconds), and the detailed code is slightly, interested, please see the attachment code of this article.

5. Vendor API problem

In Guangdong, Guangdong Mobile, Guangdong Mobile, provides Huawei's CMPP protocol in the early days of the CMPP protocol. However, after the development test, it is found that Huawei's API has at least several problems: Huawei's API, within the interior of the CMPP, the transaction phase is divided into several function implementations, where the SMS to ISMG function will be sent in a function, and the function description of SubmitAexexex appears.

2, CMPP interaction is asynchronous, requiring multi-thread implementation while sending, while receiving feedback information. This API should be internal to maintain a thread to perform CMPP_SUBMIT messages, but Huawei API waits for ISMG to return CMPP_SUBMIT_RESP to return (for message simultaneously returning) by empty cycle. After testing, it takes about 200 milliseconds, which cannot meet the system requirements at the high performance demand occasion of actual SP.

3, receiving SMS must rely on the program to first issue a function HasDeliveRMessage call, get messages can be obtained through the getDeliversmex function, clearly, this way is inefficient, and it is easy to generate a message packet loss, showing some MO messages, SP Not receive. Moreover, it is doubtful that you can't open a thread to make judgments and receive MO's actions. Once you use threads in actual development, you will have a memory protection error (probably conflict with the API itself. ).

4, return error code, often is a set of errors for Huawei (probably the API design this API in order to adapt to SMGP CMPP and other protocols), and often changes, very hurt.

Based on the above reasons, I think I have developed a SP end program in accordance with the CMPP protocol, comparing the needs of general SP.

Fourth, C # implementation

1, CMPP protocol Implement CMPPCLIENT

Through research, the author wrote a set of CMPP SP end programs (CMPPCLIENT) with C #. In order to achieve the related class, it is also necessary to write some auxiliary classes, and first solve the conversion problem between the data structure of the CMPP protocol is the conversion problem between the data of C #.

CMPP's OCTET STRING is actually equivalent to Byte [] in C., all CMPP messages outlet string fields out of CMPP_SUBMIT and CMPP_DELIVER's MSG_Content fields, others can be considered as ASCII encoding, so all can be used in system.text.encoding .Ascii performs encoding and decoding; for the MSG_Content field, there is a typical information transmission. So the default / decoding should be encoding.default, what is the actual code, and the MSG_FMT field indicates that the body is the code.

For the unsigned integer and the interger field, you need to convert according to the network byte order of the network byte and the X86 machine, and I have designed a tool class to use some conversion methods:

Public class biconvert // byte shaping conversion class network format Convert to memory format

{

Public Static Byte [] INT2BYTES (UINT I) / / Network subordinate bytes of shaping data

{

Byte [] t = bitconverter.getbytes (i);

BYTE B = T [0];

T [0] = T [3];

T [3] = B; b = T [1];

T [1] = T [2];

T [2] = B;

Return (T);

}

Public Static uint Bytes2uint (Byte [] BS, int StartIndex) // Returns the integer number of the byte array representative, 4 byte lengths

{

Byte [] t = new byte [4];

For (int i = 0; i <4 && i

{

T [I] = BS [StartIndex I];

}

BYTE B = T [0];

T [0] = T [3];

T [3] = B;

B = T [1];

T [1] = T [2];

T [2] = B;

Return (BitConverter.touint32 (t, 0));

}

Public static uint bytes2uint (byte [] bs) // No starting index

{

Return (Bytes2uint (BS, 0));

}

}

Second, in order to realize the "full duplex" of the transmit and receive data, it is necessary to design the read and packets of the at least two threads handle Socket. In addition, in order to automatically implement the maintenance of the data link, and the automatic data package reunion is automatically implemented, I also increased a value-behind thread and automatically handle the above issues. See the posts in detail. In addition, there are a lot of time related fields, but these time related fields are not encoded in a unified specification, this requires a careful study agreement or implementation code.

Third, in order to resolve / encode the data package, I will implement the message involved in the SP side in the form of a class. According to the specific message type, the data packet byte is resolved to a specific message; on the other hand, when sending When some messages, each field of the message is "assembled" zygroup arrays according to the type and encoding type, so that Socket can send it.

Its fourth, in order to achieve a timely manipulation of short messages, I have used the C # event trigger to meet the purpose of the message notification, and also design a set of event parameters, and the specific listener for the event can master the information you need.

Its five, you need to pay attention to synchronization problems between multi-threaded rooms.

Sixth, fill in the cMPP_SUBMIT message requires paying attention to the content encoding, the billing field is correctly filled

2, event model

In general, more than ten events have been realized, and these events are:

When the CMPP_DELIVER message is sent by a short message delivery report, a message delivery report event occurs:

Public Delegate Void ReportEventHandler (Object Sender, ReportEventAndler (Object Sender, when the CMPP_DELIVER message is sent by the user's mobile phone MO short message, other programs can get the text, mobile phone number, SP service number, etc. information:

Public Delegate Void SmseventHandler (Object Sender, Smseventargs E); When ISMG issues a CMPP_TERMINATE message, the specific response, I will automatically reply in the specific implementation, generating this event, only to external programs (this event intercepter) Expressing this news, you need to perform "Good Life" operation:

public delegate void TerminateEventHandler (object sender, TerminateEventArgs e); SP when the active connection is terminated message sent CMPP_TERMINATE, ISMG will respond CMPP_TERMINATE_RESP message, receives this response indicates this event public delegate void TerminateRespEventHandler (object sender, TerminateRespEventArgs e);

The following two events occur for link hold messages CMPP_ACTIVE_TEST and CMPP_ACTIVE_TEST_RESP:

Public Delegate Void TesteventHandler (Object Sender, Testargs E);

Public Delegate Void TestrespeventHandler (Object Sender, Testrespeventargs E); After the SP issues a CMPP_CONNECT message, ISMG verifies, then issues a CMPP_CONNECT_RESP message, and this event is activated:

Public Delegate Void ConnectrespeventHandler (Object Sender, ConnectRespeventargs E);

The SP cancels an end message, and when you issue CMPP_CANCEL, the ISMG responds to this message to return to the CMPP_CANCEL_RESP message, activate the event:

Public Delegate Void CancelrespeventHandler (Object Sender, Cancelrespeventargs E); After SP SMS, ISMG returns a CMPP_SUBMIT_RESP message, including "Receiving" (MSG_ID), triggered this event:

Public Delegate Void SubmitrespeventHandler (Object Sender, Submitrespeventargs E);

After the query ismg returns the message, it happens:

Public Delegate Void QueryrespeventHandler (Object Sender, Queryrespeventargs E); After the SP verification is passed, the application logic needs to be notified, I hereby add this event:

Public Delegate Void LogonsucceventHandler (Object Sender, Eventargs E); // When successfully logging in

The following event is not based on the CMPP message, but determines the trigger event based on the SP with the ISMG message queue scan:

Public Delegate Void SocketCloseDeventHandler (Object Sender, Eventargs E); // When the socket is detected

Public Delegate Void FailediteMdeleteDeventHandler (Object Sender, WaitingQueueItem (// When a message exists in a waiting queue more than 60 seconds without response

These events default implementation ensures that SP end CMPP clients are automated for ISMG, and provide trigger events to ensure that the system of this client class can detect the internal state of the SP end through the event, and acquire interactive information.

On the other hand, since most events occur after the data package reaches the process, it is virtually necessary to process the event program must "quickly" resolve, or simply convert the message to the message form that can be temporarily processed, further procedure. CMPP SP ends must meet a large number of short message application requirements, you must strictly control the message interaction processing logic should not be too complicated, especially do not design a large number of I / O processing; if you are dealing, it is best to use asynchronous threads. 3, in order to improve efficiency, open 3 threads:

Recvismgmsgthread is used to process messages that receive ISMG sent, and trigger the corresponding events based on messages.

Sendspmsgthread is used to handle packets to ISMG. Note that some messages (such as CMPP_ACTIVE_TEST) are generated by the system. In addition, some messages need to be returned to ISMG immediately after receiving the ISMG, then these messages enter the internal maintenance message queue (_outseqqueue). This queue will automatically order the message, all the messages you need to send, enter this queue, the thread constantly removes the required message from the queue, converts into a packet, sent to the ISMG via Socket.

DEAMONTHREAD is used to monitor whether the data connection socket is available, whether you need to issue a test packet for maintaining data connections; some messages have been sent, and the time specified by the protocol still does not receive the ResP message, then you need to send the message from the queue already sent from the queue already sent Extraction, re-add to the send queue, wait for the queue after waiting.

You can analyze the code provided carefully and study the specific implementation.

V. Problem

According to your own experience, I feel that the following points are important for the development of the entire system:

1. Be sure to understand the agreement correctly.

When many netizens exchanged, they always complained that the agreement was abused, but in fact, many reasons belong to themselves did not know the agreement. From my contact mobile ISMG, it should be said that the implementation agreement is still strictly complied with CMPP description. Pour, some netizens develop simulators are not very standard (not criticism, solemn statement), you need to pay attention to it when you are developing.

2, multithreaded mutual exclusion problem.

A number of threads involve some queues, need to be synchronously locked, otherwise it is easy to cause problems. An abnormality also needs to be captured in time, and recorded as an error message, it is easy to exclude the bug.

3, control the data packet flow direction and processing time.

Since the design goals are high performance, you should pay attention to the processing of Socket data reading and writing, pay attention to some event processing not too much consumption system resources, avoiding the data packets and causes data loss. Especially in data busy moments often reduce the throughput of ISMG to decline, and it is necessary to consider traffic control in this case. Sometimes, you can't expect ISMG as you wish to respond to you in time, and more common is that ISMG does not return the ResP type packet at all. In addition, this Agreement handles the data transmission and reception using blocking socket, and some netizens suggest that I use asynchronous non-blocking socket, I think that asynchronous non-blocking Socket will be better.

4, service monitoring problem.

Due to some accidents, it is often caused by the data connection, which is that the mechanism for retaining the connection is required. The example I gave did not solve it, I hope other people will correct.

5, byte order problem.

This problem is often caused by people who initially contact Socket programming. However, the basic data type of the CMPP protocol design is simple, and only the reference can be resolved in accordance with the reference.

6. Application issues for specific protocols.

This example is just a class that implements the CMPP protocol in accordance with the protocol, and the complete SP end program needs to be combined with the actual requirements, transformation or reuse of its company. Limited to the space, the paper can only list the key segment, detailed detail, refer to the downloaded code (note). This article is only for discussion development of the CMPP2.0 protocol, please download from the mobile dream network (http://www.monternet.com/monEditor/cs/sp/cmcc/). Other technical references can be obtained at the following, or check the textbook to obtain further detailed description: Paradise Bird Exchange Forum (http://www.spzone.net/bbs/index.asp)

9CBS Community Mobile Platform (http://community.9cbs.net/expert/forum.asp?url=/expert/forumslist.asp?roomid=63&typenum=1&whichpage=1)

SP Forum (http://www.spforum.net/jishu/index.asp)

If you find that there is a problem with my instance (I think that it is a certain amount), please let me know myjobsdk@yahoo.com.cn.

Postscript: Now CMPP3.0 is also the mobile MISC platform version of the need to order the relationship determination can be charged. However, it is not the focus of this article.

Copyright Notice: 9CBS is this BLOG managed service provider. If this paper involves copyright issues, 9CBS does not assume relevant responsibilities, please contact the copyright owner directly with the article Author.