在同事那里找到一篇好文章，来源于网上，但现在找不到连接了，作者如果不同意转载，请留言删除文章！
移动梦网和联通在信都是构建在有中国特色的短信网关部件基础上的，亚信为中国移动设计的CMPP协议规范，中国联通的SGIP规范都是为这个短信网关提供的互联网接口标准，可以看出二者都是借鉴GSM SMPP协议的两种简化版。
CMPP提供了基于TCP的长连接接口和短连接接口标准，SGIP提供了基于TCP和HTTP/TCP的短连接接口标准。CMPP中的短信网关为TCP服务器，通过接收SP发起的TCP连接来发送MT/MO/Report/Resp等消息。SGIP中发送MT/MTResp时是短信网关为TCP服务器，发送MO/MOResp/Report/ReportResp时短信网关作为TCP客户端。
从CMPP协议的文字内容来看，目前所有的短信网关的设计和实现都不标准。这是很有中国特色的，中国人不擅长搞统一的技术标准和规范，任何两个系统之间无论什么接口私下定义一下，就成了。西方人做研究搞技术，涉及到两个对象（包括人）打交道的，就定义一大堆标准和规范，约束各方。大家严格地遵守规范，如果有异议，就有人提议修改标准。很少私下去违反约定的标准来实现某个系统。在通信领域，好不容易出了个协议标准，居然连设计这个标准的厂家也不遵守。中国的法律成千万，遵纪守法的意识折腾那么多年还是上不来。
短连接的标准很简单，建立连接后，发送包，接收响应，发送接受，几个来回，关闭连接就成了。长连接标准需要有链路检测的维持机制（其实这个思想来自不可靠的链路通信，如在数据报基础上保障可靠传输的sync机制）、超时重传和差错重传机制、保障有序的传输机制、重复抛弃（duplication removal）机制、流量控制的滑动窗口(Sliding Window)机制。
CMPP协议文字内容中，每个建立起来的TCP长连接，既可以发送MT的Submit消息，也可以从网关侧发送MO的Deliver/StatusReport消息，每个连接的作用都是同等的。而在实现网关时，为这个问题出了很多个实现方法：亚信网关只允许一个TCP链接来发送MO消息，可以有多个连接来发送MT消息，区分MT链接和MO链接的方法是依据开始发送Connect时的协议版本号，为0是MT，为1是MO。巨搞笑！我真服了亚信那帮人！自己搞的标准，自己不遵守，作为中国的第一大电信集成商，不知道拿什么到Nasdaq上市的。亚信网关还好，什么阴私克、东软的网关，稀奇古怪的东西就更多了。让人怀疑，这不仅仅是技术素养问题了。
反正这么烂的玩意，有些运营商也用，唉，运营商的技术人员素质更差。我到现在都没有弄懂，运营商反复强调他们网关的接受短消息速度是最大每秒10条？要让所有的SP那里限制发送速度。这个数据，不知道他们是怎么得出的？这种政式的命令，让我无数次骂那个作出这么荒谬要求的**的祖宗。你网关处理速度慢，这是一个典型的技术问题，你那边服务器忙不过来，你协议里定义的滑动窗口机制是干吗用的？就是专门用来解决流量控制目的用的。有谁听说过，美国国防部弄出TCP协议后，服务器那边接收不过来，要求客户端限定死，每秒钟最多只能发送多少个数据包没有？这些运营商的技术素养，离国际化的大型企业差的太远太远，还到处臭摆自己500强，真是丢中国人的脸！
最后的结局是各个SP的开发人员，不断地开发好几家网关的接口，就跟求爷爷似的，听着这几个网关供应商和运营商那帮弱智的训斥。
设计CMPP协议模块，需要考虑如下几个需求：
（1）可以人为配置的多个TCP连接，来发送和接受消息（移动最多可允许一个SP建立15个连接）。系统初启时，自动地启动指定个数的连接。运行过程中，任意一个连接崩溃时，自动恢复。
（2）类似心跳消息的长连接维持机制，为每个连接，在最后一个消息的处理结束前，重新启动一个60秒的定时器。如果期间有消息来往，停止定时器，处理完消息后，继续启动定时器。如果60秒超时，重新启动定时器，连续三次超时，关闭这个链接，重新启动建立过程。
（3）超时重发和差错重传。超时重发的原理是发送每个MT消息后，启动一个60秒的定时器，等待网关返回应答。如果超时，继续发送，连续3次都超时都没有应答，关闭连接，启动链路恢复过程。并将这条消息保存到回收队列中，千万别抛弃。差错重传是接受到错误的应答，并且这个错误是由对等通信双方的协议层产生的，那么重新发送这条消息。
（4）滑动窗口机制。可以实现流量控制和有效的负载均衡。滑动窗口大小为16条消息。采用异步方式，一次发送16条消息，并等待应答，每成功一个应答，窗口缩小，然后再从缓存取一个发送，填满窗口。准确的说，CMPP协议中定义的滑动窗口概念不准确，应该叫缩放窗口。因为它并没有实现序列控制问题，只是起到流量控制和异步高效快速发送的目的。相对于Stop-Wait机制来说的。
（5）重复丢弃机制。如果接受到的MO消息是一条重复的，就丢弃这条消息，不能将这条MO消息交给上层。如何判断是重复的呢？通过每条消息的序列号。当然如果网关不维持这个序列号的唯一性和有序性，你只能干瞪眼。
（6）上接口缓存和回收队列。从上层接受短消息，保存到缓存里，这个缓存不要做的太大，超过一定量时，让上层发送短消息接口阻塞。而将缓存技术单独用一个模块来实现。回收队列是储存每个链路崩溃时，处于滑动窗口中等待应答的消息。
（7）有序控制机制。是保障先来的消息，先发送出去，后来的后发，严格地保障先后顺序。是通过序列号和滑动窗口来保障的。实际应用中，倒是不那么严格地关注顺序发送问题。
以上7点是这个协议模块的核心问题。如果，一个CMPP协议模块没有解决这些问题，那是一个残缺不全的实现，上不了桌面的东西。