关闭

CMPP/SGIP协议设计与实现

标签: tcp服务器负载均衡技术人电信
1419人阅读 评论(0) 收藏 举报
分类:

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协议模块没有解决这些问题,那是一个残缺不全的实现,上不了桌面的东西。

0
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:7167次
    • 积分:83
    • 等级:
    • 排名:千里之外
    • 原创:0篇
    • 转载:5篇
    • 译文:0篇
    • 评论:2条
    文章分类
    文章存档
    最新评论