791
社区成员
发帖
与我相关
我的任务
分享发布《中国移动通信CMPP2.0短消息网关开发接口库》！
欢迎试用
《中国移动通信CMPP2.0短消息网关开发接口库》
本接口是用VC6.0遵循中国移动通信标准CMPP2.0协议开发的短消息网关接口，
目的是简化SP接入移动短消息网关的复杂度。
本接口对网络通信和CMPP2.0协议进行了高度封装，连接过所有类型的移动网关，
但暂时不支持CMPPE(东软格式，但东软也支持标准CMPP),
本接口还提供了网关的部分功能接口,可以很方便地用来开发模拟网关)，
接口库就提供了一个功能完整的模拟网关源码！接口包含两个示例工程，一个是客户端，通过CMPP2.0连接网关，演示了登录、MT、MO的全过程；一个就是模拟网关，可以接收用户的登录，接收MT请求，同时还可以主动批量下发MO消息。
更新历史:
2003-08-08 V1.3
1. 增加了对cmpp_recv函数的返回值CMPP_RECVTIMEOUT的说明。
2. 修改了cmpp_login_value_set()函数,去掉了一个参数。
2003-07-23 V1.22
1.增加了两个函数(cmpp_submit_sm_set_msgsrc和cmpp_submit_sm_set_srctermid)，可以分别用来设置Src_Id和Msg_src。
根据移动的要求(升级后的网关)，sp下发消息时,Src_Term_Id和Msg_src必须为该连接的对端的SP的服务代码和企业代码
(见《关于SP下发数据格式的规范》).
2003-07-08 V1.2
1.修正了cmpp_login_value_set函数的一个bug。
2003-06-07 V1.1
1.增加了网关接收部分的接口，同时新增了详细使用手册和模拟网关的源码,并且在真实环境中测试通过!
2003-04-25 V1.0
1.0发布。
作者: princetoad
Email:princetoad@tom.com
Homepage:http://gmm.nease.net
1.3版下载地址：http://gmm.nease.net/CMPP.rar
1.22版下载地址：http://skybird.9s9s.com/upload/upfile/2003723956540.rar
1.21版下载地址：http://www.csdn.net/cnshare/soft/17/17025.shtm
1.2版下载地址：http://skybird.9s9s.com/upload/upfile/2003781329230.rar
1.1版下载地址：http://www.vckbase.com/code/listcode.asp?mclsid=9&sclsid=917
本接口库有偿提供源码，请联系作者，princetoad@tom.com。
或到中国共享软件注册中心注册。
注册地址：http://www.softreg.com.cn/shareware.asp?id=11530
同时提供中国联通SGIP1.2接口库，更多详情请访问作者主页!
下载：http://gmm.nease.net/SGIP.rar
注册地址：http://www.softreg.com.cn/shareware.asp?id=11517
《中国移动通信CMPP2.0短消息网关开发接口库》
本接口是用VC6.0遵循中国移动通信标准CMPP2.0协议开发的短消息网关接口，
目的是简化SP接入移动短消息网关的复杂度。
本接口对网络通信和CMPP2.0协议进行了高度封装，连接过所有类型的移动网关，
但暂时不支持CMPPE(东软格式，但东软也支持标准CMPP),
本接口还提供了网关的部分功能接口,可以很方便地用来开发模拟网关)，
接口库就提供了一个功能完整的模拟网关源码！接口包含两个示例工程，一个是客户端，通过CMPP2.0连接网关，演示了登录、MT、MO的全过程；一个就是模拟网关，可以接收用户的登录，接收MT请求，同时还可以主动批量下发MO消息。
更新历史:
2003-08-08 V1.3
1. 增加了对cmpp_recv函数的返回值CMPP_RECVTIMEOUT的说明。
2. 修改了cmpp_login_value_set()函数,去掉了一个参数。
2003-07-23 V1.22
1.增加了两个函数(cmpp_submit_sm_set_msgsrc和cmpp_submit_sm_set_srctermid)，可以分别用来设置Src_Id和Msg_src。
根据移动的要求(升级后的网关)，sp下发消息时,Src_Term_Id和Msg_src必须为该连接的对端的SP的服务代码和企业代码
(见《关于SP下发数据格式的规范》).
2003-07-08 V1.2
1.修正了cmpp_login_value_set函数的一个bug。
2003-06-07 V1.1
1.增加了网关接收部分的接口，同时新增了详细使用手册和模拟网关的源码,并且在真实环境中测试通过!
2003-04-25 V1.0
1.0发布。
作者: princetoad
Email:princetoad@tom.com
Homepage:http://gmm.nease.net
1.3版下载地址：http://gmm.nease.net/CMPP.rar
1.22版下载地址：http://skybird.9s9s.com/upload/upfile/2003723956540.rar
1.21版下载地址：http://www.csdn.net/cnshare/soft/17/17025.shtm
1.2版下载地址：http://skybird.9s9s.com/upload/upfile/2003781329230.rar
1.1版下载地址：http://www.vckbase.com/code/listcode.asp?mclsid=9&sclsid=917
本接口库有偿提供源码，请联系作者，princetoad@tom.com。
或到中国共享软件注册中心注册。
注册地址：http://www.softreg.com.cn/shareware.asp?id=11530
同时提供中国联通SGIP1.2接口库，更多详情请访问作者主页!
下载：http://gmm.nease.net/SGIP.rar
注册地址：http://www.softreg.com.cn/shareware.asp?id=11517
...全文
请发表友善的回复…
发表回复
Tom4 2003-12-02
- 打赏
- 举报
CMPP2.0 API升级到V2.00.
更新内容:
1.一下子升级到了2.0,所有代码全部重写，全部模块后台运行，使用异常简单，兼容多种类型移动网关,包括单连接，双连接，双端口等各种类型。
免除了重新开发的烦恼。
下载地址：
http://hp2.xilu.com/~princetoad/software/CMPP2.0_API_V2.00.rar
绝对好用！！！不好用的话可以骂我，哈！
更新内容:
1.一下子升级到了2.0,所有代码全部重写，全部模块后台运行，使用异常简单，兼容多种类型移动网关,包括单连接，双连接，双端口等各种类型。
免除了重新开发的烦恼。
下载地址：
http://hp2.xilu.com/~princetoad/software/CMPP2.0_API_V2.00.rar
绝对好用！！！不好用的话可以骂我，哈！
Tom4 2003-11-19
- 打赏
- 举报
系列讨论1：CMPP/SGIP协议设计与实现
天堂鸟“cnauth”:
移动梦网和联通在信都是构建在有中国特色的短信网关部件基础上的，亚信为中国移动设计的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协议模块没有解决这些问题，那是一个残缺不全的实现，上不了桌面的东西。
回:
搂主说得不错，鼓励一下！
个人感觉SGIP比CMPP容易，简单一点。
CMPP各网关厂商实现的不一样，但数据格式还是大体标准的，除了东软，骂过它不只一次了，不过还好现在也支持标准格式了。
亚信的connect包的Version字段不同，还有timestamp老填空。清华的MO还是MT的(一下子记不清楚了)居然不用发
connect包，发就出错，干！真是花样百出。可苦杀了大批的SP.可恶的是这帮家伙的API说明一点都不详细，没办法，只好麻
烦他们的技术支持了。
以下观点，纯属个人经验，欢迎大家交流，有问题的请大家指正！
1.移动是最多允许建立15个连接，但我发现，华为最多只允许建立两个连接，斯特奇的居然只允许一个。搂主说“亚信网关只允
许一个TCP链接来发送MO消息，可以有多个连接来发送MT消息”那是因为亚信开始的时候采用的是短连接，现在新版本的API听说
是改掉了,不过我没用过新的。
个人认为还是使用两个连接比较好处理，MO,MT各一个。
2.cmpp的连接没有必要关闭吧，没有消息的时候可以通过链路检测包来维持。可以通过一个单独的定时器实现，也可以在单个连
接中各自实现，比如说接收连接，30或60秒超时，没有收到消息，这时就可以发一个链路检测包来维持连接。
3.超时重发，我认为楼主的机制不好，因为这样效率较低。在一个连接中，发送一条消息，只有等到这条消息的应答后才能发送
下一条消息(虽然东软是这样实现的).我认为可以这样做，一条连接，分两个线程处理，发送线程只管发，发一条消息，将它既
入已发送队列；接收线程负责接收应答包，收到应答包，将它从已发队列删除。然后有一个定时器来检测已发队列，应答是否超
时，超时的话重发。
"差错重传是接受到错误的应答，并且这个错误是由对等通信双方的协议层产生的，那么重新发送这条消息"我认为这个时候幼重发的必要吗？既然出错了，以我的经验，应该是某些字段不合法，重发的话，应该还会出错。除非程序中建立了一套自动调整优化消息包字段的机制，将某些字段修改后，再发，不好做啊！
4.滑动窗口可以通过我在3中说得通过队列的方式实现，队列中的待应答消息应该是可以统计出来的。我不知道楼主是怎样实现的，你的观点好像跟你在2中的说法有冲突啊？
5.重复的情况，只可能发生在网关重发的过程中，因为Client没有正确的给出应答。同样的，判断是否是重复消息也不好判断。大家有什么好的实现方法吗？
6。“回收队列是储存每个链路崩溃时，处于滑动窗口中等待应答的消息。”不知道楼主的滑动窗口时怎么实现的，如果是全局队列的话，连接断开，消息是不会丢失的，对吗？下次联商的时候，继续发就是了。
7.顺序问题没这么复杂的。队列的话就是先进先出吗？这是最基本的啊！！
纯属个人拙见，很高兴跟大家讨论一下技术问题，多多交流！有问题清指出。
天堂鸟“cnauth”:
移动梦网和联通在信都是构建在有中国特色的短信网关部件基础上的，亚信为中国移动设计的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协议模块没有解决这些问题，那是一个残缺不全的实现，上不了桌面的东西。
回:
搂主说得不错，鼓励一下！
个人感觉SGIP比CMPP容易，简单一点。
CMPP各网关厂商实现的不一样，但数据格式还是大体标准的，除了东软，骂过它不只一次了，不过还好现在也支持标准格式了。
亚信的connect包的Version字段不同，还有timestamp老填空。清华的MO还是MT的(一下子记不清楚了)居然不用发
connect包，发就出错，干！真是花样百出。可苦杀了大批的SP.可恶的是这帮家伙的API说明一点都不详细，没办法，只好麻
烦他们的技术支持了。
以下观点，纯属个人经验，欢迎大家交流，有问题的请大家指正！
1.移动是最多允许建立15个连接，但我发现，华为最多只允许建立两个连接，斯特奇的居然只允许一个。搂主说“亚信网关只允
许一个TCP链接来发送MO消息，可以有多个连接来发送MT消息”那是因为亚信开始的时候采用的是短连接，现在新版本的API听说
是改掉了,不过我没用过新的。
个人认为还是使用两个连接比较好处理，MO,MT各一个。
2.cmpp的连接没有必要关闭吧，没有消息的时候可以通过链路检测包来维持。可以通过一个单独的定时器实现，也可以在单个连
接中各自实现，比如说接收连接，30或60秒超时，没有收到消息，这时就可以发一个链路检测包来维持连接。
3.超时重发，我认为楼主的机制不好，因为这样效率较低。在一个连接中，发送一条消息，只有等到这条消息的应答后才能发送
下一条消息(虽然东软是这样实现的).我认为可以这样做，一条连接，分两个线程处理，发送线程只管发，发一条消息，将它既
入已发送队列；接收线程负责接收应答包，收到应答包，将它从已发队列删除。然后有一个定时器来检测已发队列，应答是否超
时，超时的话重发。
"差错重传是接受到错误的应答，并且这个错误是由对等通信双方的协议层产生的，那么重新发送这条消息"我认为这个时候幼重发的必要吗？既然出错了，以我的经验，应该是某些字段不合法，重发的话，应该还会出错。除非程序中建立了一套自动调整优化消息包字段的机制，将某些字段修改后，再发，不好做啊！
4.滑动窗口可以通过我在3中说得通过队列的方式实现，队列中的待应答消息应该是可以统计出来的。我不知道楼主是怎样实现的，你的观点好像跟你在2中的说法有冲突啊？
5.重复的情况，只可能发生在网关重发的过程中，因为Client没有正确的给出应答。同样的，判断是否是重复消息也不好判断。大家有什么好的实现方法吗？
6。“回收队列是储存每个链路崩溃时，处于滑动窗口中等待应答的消息。”不知道楼主的滑动窗口时怎么实现的，如果是全局队列的话，连接断开，消息是不会丢失的，对吗？下次联商的时候，继续发就是了。
7.顺序问题没这么复杂的。队列的话就是先进先出吗？这是最基本的啊！！
纯属个人拙见，很高兴跟大家讨论一下技术问题，多多交流！有问题清指出。
hnhhcj 2003-11-16
- 打赏
- 举报
gz
oldnew 2003-11-13
- 打赏
- 举报
zubasha(小狼)
比如submit函数，每调用一次，如果成功收到response，则返回error_code = 0和msgid，如果不成功，返回error_code值
那你的就没有用户cmpp的窗口流量控制了,效率会很底哦.实际中SP采用的是异步非堵塞机制,你要是用同步堵塞的,碰到量大的那不害死人!!
比如submit函数，每调用一次，如果成功收到response，则返回error_code = 0和msgid，如果不成功，返回error_code值
那你的就没有用户cmpp的窗口流量控制了,效率会很底哦.实际中SP采用的是异步非堵塞机制,你要是用同步堵塞的,碰到量大的那不害死人!!
Tom4 2003-11-13
- 打赏
- 举报
我的网站改为http://princetoad.xiloo.com,欢迎大家对接口库多提意见，希望和大家多多交流！
林仪明 2003-11-13
- 打赏
- 举报
up
zubasha 2003-11-13
- 打赏
- 举报
另外，窗口流量控制如果封装在底层，也可以对submit函数不可见。
如果你想快，多线程调用submit函数就可以了。
不过，太多线程也不好，竞争过于激烈。速度反而不如了。这个就要看底层的API到底
是怎么写的，如果写的好，submit速度可以大大的提高！！
1秒钟能达到300条以上。
如果你想快，多线程调用submit函数就可以了。
不过，太多线程也不好，竞争过于激烈。速度反而不如了。这个就要看底层的API到底
是怎么写的，如果写的好，submit速度可以大大的提高！！
1秒钟能达到300条以上。
zubasha 2003-11-13
- 打赏
- 举报
to oldnew(男人不流氓,发育不正常)
======================================
heihei,你如果用厂商的API，那就只有同步的。
一般厂商都有两套API，一套同步的，一套异步的
同步的是给外面用的，异步的是留给自己内部用的（做测试或者给给其他模块用）
======================================
heihei,你如果用厂商的API，那就只有同步的。
一般厂商都有两套API，一套同步的，一套异步的
同步的是给外面用的，异步的是留给自己内部用的（做测试或者给给其他模块用）
zubasha 2003-11-12
- 打赏
- 举报
我不知道楼长提供的API是怎么样的，不过一般来说，
比如submit函数，每调用一次，如果成功收到response，则返回error_code = 0和msgid，如果不成功，返回error_code值
比如submit函数，每调用一次，如果成功收到response，则返回error_code = 0和msgid，如果不成功，返回error_code值
mountai 2003-11-12
- 打赏
- 举报
如果我的理解无错误的话，楼长的API好像并没有提供对CMPP_SUBMIT消息头Sequence_Id的设置？请楼长详细解释
mountai 2003-11-12
- 打赏
- 举报
例如我现在发送了100个CMPP_SUBMIT,现在收到网关回复的一个CMPP_SUBMIT_RESP,我该如何得到这个CMPP_SUBMIT_RESP对应哪个CMPP_SUBMIT?这个CMPP_SUBMIT_RESP 消息体中Msg_Id对应的序列号bit16--bit1是我在CMPP_SUBMIT消息头中Sequence_Id？还是说CMPP_SUBMIT_RESP的消息头中的Sequence_Id对应我在CMPP_SUBMIT消息头中Sequence???
mountai 2003-11-12
- 打赏
- 举报
楼长提供的API我已经拜读过了，真的好用？ 那我就提一个问题：CMPP_SUBMIT消息的消息头中有一个Sequence_Id,没有让用户进行设置，也就是说程序帮忙处理喽，可是这样的话，如果我提交了100个CMPP_SUBMIT后网关给我回复了一个CMPP_SUBMIT_RESP,我怎么知道这个CMPP_SUBMIT_RESP对应哪个CMPP_SUBMIT??
zubasha 2003-11-10
- 打赏
- 举报
cmpp30的接口库我有啊。。。。
grin.....
grin.....
zubasha 2003-11-06
- 打赏
- 举报
奸商啊。。。。。
接口库移动主页就有下载的，一般网关厂商都免费提供。。。
接口库移动主页就有下载的，一般网关厂商都免费提供。。。
oldnew 2003-11-06
- 打赏
- 举报
华为和亚信的接口库下载地址:http://www.gmcc.net/others/spjr.html
难道厂商的接口库还没有你的好吗?
而且cmpp2.0马上要升级到cmpp3.0,买了你的库用了2--3个月就不能用了,还要等你把cmpp3.0开发出来,谁知道你什么时候把cmpp3.0搞出来啊,业务是不等人的哦,SP业务停一天损失多少?全公司的大小爷们那来工钱发? 业务停个两三天,好,移动把你开除出局了.
罪过啊,玩玩倒可以,免费的东西你可以不承担任何责任.如果你要收钱,请你三思,要有足够的精力保证好你的服务.
难道厂商的接口库还没有你的好吗?
而且cmpp2.0马上要升级到cmpp3.0,买了你的库用了2--3个月就不能用了,还要等你把cmpp3.0开发出来,谁知道你什么时候把cmpp3.0搞出来啊,业务是不等人的哦,SP业务停一天损失多少?全公司的大小爷们那来工钱发? 业务停个两三天,好,移动把你开除出局了.
罪过啊,玩玩倒可以,免费的东西你可以不承担任何责任.如果你要收钱,请你三思,要有足够的精力保证好你的服务.
gujinpeng 2003-11-05
- 打赏
- 举报
接口库是什么，是做网关必须的吗？
Tom4 2003-09-30
- 打赏
- 举报
up
okdw 2003-09-11
- 打赏
- 举报
up一下，源码多少钱？
TomFan 2003-09-11
- 打赏
- 举报
SGIP和CMPP的源代码都是RMB 480元！
请先下载试用，试用满意再注册。
试用和注册地址:
（sgip）http://www.softreg.com.cn/shareware.asp?id=11517
(cmpp)http://www.softreg.com.cn/shareware.asp?id=11530
注册用户将获得免费升级，以及售后技术支持。(Emial或电话方式)
感谢你的使用，收到您注册的订单后，我将在第一时间将源码发送给您，
并会给您邮件确认。
最后，如果您注册以后感觉不满意的话，15天内无偿退款！
请先下载试用，试用满意再注册。
试用和注册地址:
（sgip）http://www.softreg.com.cn/shareware.asp?id=11517
(cmpp)http://www.softreg.com.cn/shareware.asp?id=11530
注册用户将获得免费升级，以及售后技术支持。(Emial或电话方式)
感谢你的使用，收到您注册的订单后，我将在第一时间将源码发送给您，
并会给您邮件确认。
最后，如果您注册以后感觉不满意的话，15天内无偿退款！
