SMPP协议是Short Message Peer to Peer的简称，规范上将它是一个开放式的工业标准协议。它为消息中心和短消息系统

应用端在短信数据传输时提供灵活的数据通信接口规范。不知道大家看到这些介绍是什么感觉，我看到的感觉就是云山雾罩不知所云。

下面根据我的实际开发经验，上硬货。

        我做的某运营商行业短信网关中，它与移动的短信网关接口走的是SMPP协议，它与电信的网关接口走的也是SMPP协议。当

运营商之间的短信网关互通时，也被称为“异网”互通，大都用的SMPP。如果运营商内部的短信网关互通时用的协议就互不相同了，

其中移动内部短信网关互通用的CMPP协议，联通内部短信网关互通用的是SGIP协议，电信内部短信网关互通用的是SGIP协议。

     我做的短信网关与运营商的短信中心通过TCP/IP建立连接后，然后用用BIND信令和短信网关建立连接，采用deliver或submit发送短信。

 总体消息交互图如下：

在以下语法说明中，遵从以下规则：

      A.未使用的字段，依据类型必须设置为0或NULL。

      B.消息由消息头和消息体组成

      C.状态（status)如在命令语法中未加说明       

0：表示成功   

                                          非0：表示失败

                                          1：保留。

 schedule_delivery_time：该字段表示计划下发该短消息的时间。

                         时间格式请参考前面定义的C_StringTime

                             的格式. 如不需要，可设置为NULL。

 validity_period：该字段表示短消息的最后生存期限。时间格式请

                  参考前面定义的C_StringTime的格式.如不需要，

                  可设置为NULL。

 registered_delivery_flag：该字段是注册短消息标志，它表示当

                           短消息到达最后的目的地后，是否需

                           要状态报告。

                 取值说明：

                          0：不需要

                          1：需要

                         >1：保留。

 replace_if_present_flag：该字段表示替换短消息标志。即当提交

                          的短消息的源地址和目的地址相同时，

                          是否替换存在的短消息。

                取值说明：

                        0：不替换

                           1：替换

                       >1：保留。

 data_coding       ：该字段表示数据编码方案。

         取值说明  ：

          0      缺省编码方案(7bit编码)

                4      二进制编码方案(8bit编码)

                8      UCS2编码方案（GB13000）

                其他   保留

sm_default_msg_id：该字段表示预定义短消息ID。该ID是短消息中

                   心管理者建立的预定义短消息表的索引。不想

                   发送预定义短消息时，该字段应设为NULL。预

                   定义短消息ID值从0x01到0x64。详细说明请参

                   考SMPP Applications Guide [9] - Default

                   Short Message。

sm_length      ：要发送的短消息数据内容的字节长度。

short_message  ：该字段表示短消息数据内容。最大可到160字符。

                    只有sm_length中定义的字节长度可用。此字段的数据编码格式由data_coding决定。

它的语法和SUBMIT_SM_RESP的语法消息体是一样的，只是在消息头中的Command_id是“deliver_sm_resp"。

此命令用于ESME确认和SMSC之间的连接。ESME发送一条ENQUIRE_LINK命令，SMSC响应一条ENQUIRE_LINK_ACK命令，表示ESME和SMSC之间的连接正常。此命令只有消息头，没有消息体。

此命令只有消息头，没有消息体。

例如：

0：缺省编码方案(7位)

     4：英文编码方案(不被手机支持)

     8：UCS2编码方案(比如中文编码)

此字段的说明如下：

Bit

7

6

5

4

3

2

1

0

Flag

Reserved

UDHI

Reserved

Reserved

Reserved

Delivery

Receipt

Reserved

Reserved

其中 UDHI 表示短消息内容是否有头结构。置位表示有。Delivery Receipt，在DELIVER_SM协议中使用，表示是否是此条消息是否是状态报告。

对于普通的SUBMIT_SM命令，此字段设为0。

     例如： 1 表示ISDN电话编码计划

     1：高优先级

     0：普通优先级

     >1：保留

  0：不需要

  1：需要

  >1：保留

  0：不替换

  1：替换

  >1：保留

     0          未知号码

     1          国际号码

     2          国内号码

     3          网络专用号码

     4          用户号码

     5          字母号码(按照 GSM TS03.38 7-bit 缺省字母表编码)

     6          缩写号码

     7          保留

validity_period：短消息的最后生存期限

当SMPP建链时，它有绑定的三种方式，分别如下：

Transmitter:顾名思义，这是用来发送短信的链路；但此发送短信需要辩证的看，一端是发送短信的，那么另外一端就是接收短信的。所以具体的应用场景要具体分析，不能说你的应用绑定了Transmitter的链路方式，就一定是发短信的，它也可以是指对端发短信，你的应用是来接收短信的。

Receiver:与Transmitter含义类同，它是用来接收短信的链路，但也要辩证的看。一端是接收短信，那么另外一端就是发送短信。你绑定的Receiver链路可以是接收短信，也可以是发送短信的。

Transreciver:顾名思义，这种绑定的方式既可以用来发短信也可以用来接收短信，收发都可用。这点上述的Transmitter和Receiver只能发或只能收不同。

初步进入SMPP开发的同学尤其要注意以上的差别。

硬货，如何发长短信，如何发闪信，如何发WAPPUSH短信。这三种短信除了经验非常丰富的开发者知道外，普通开发者是很难知晓开发方法的。

下面我将一一道来。

将Submit或Deliver消息中的esm_class设置为0X40，指示短信体内还有消息头。

然后短信体内增加6字节长度的长短信标识，分别是0x05,0x00,0x03和splitedRef，splitedMax，splitedSeq。

splitedRef是指短信的序列号1~255；splitedMax是指拆分长短信的条数，splitedSeq是指长短信的第几条。

后续会做一个长短信实例继续详细阐述。

SMPP发送闪信有两种方式，一种是设置可选参数，一种是设置文字的编码类型。

设置可选参数方式：

1201:1以及1204:0；其中1201参数是display_time,1204是ms_validity。规范上看设置这两个参数目前是对CDMA短信是好使的。但在移动测试时发现，GSM短信无法出现闪信效果，所以就引发了参数文字编码类型方式进行设置闪信。

文字编码类型：

如果短信采用UCS2编码，那么编码类型设置为0X18，下发的短信也可以出现闪信的效果。

发送WAPPUSH短信和长短信有些相似，它的esm_class设置为0X40，指示短信体内还有消息头。

然后将WAPPUSH短信的编码作为短信体嵌入到Submit或Deliver中就能实现了。