v0.2.0 publish

first used in QHT SAAS Application

memo.md

@@ -1,4 +1,4 @@
-rsync -avn -C -e "ssh -p 60222" /Users/cuccpkfs/dev/project/sms/node_sms/ node@noradle.com:node-sms/
+rsync -av -C -e "ssh -p 60222" /Users/cuccpkfs/dev/project/sms/node_sms/ node@noradle.com:sms-sgip/
 
 SMG 对于来自 SP 的连接的速率控制是针对每个连接的，
 而一个 SP 最多可以开若干个到同一 SMG server 的连接。
@@ -12,3 +12,45 @@ SMG 对于来自 SP 的连接的速率控制是针对每个连接的，
 如果需要并发多个连接发送短信，就需要启动多个 SP 实例，
 到来的短信依次分配给不同的的 SP 实例好了。
 
+拆分
+=======
+
+一个内容较大的消息发送前要被切割成独立的多个消息，按照 SMPP 协议进行填充相应字段指示他们是一组。
+
+一个大的消息只有当全部子消息都收到同步回应的情况，才认为是发送成功的。
+因为差分后的子消息序列号都相连
+
+同时，对于 report 来说也是一样
+
+
+序列号
+========
+
+
+若单个SP同时建立多个连接到SMG并发发消息，那么根据序列号不重复原则，应该共享一个序列号发生器。
+考虑到序列号只是为了区分在同一发送源站同一秒内发送的消息，因此也个将并发的各个进程分配不重叠的序列号空间。
+
+序列号到达最大只后应该归0，
+因而一个拆分消息的序列号可能跨越最大序列号从而归0.
+因此，应该定时的清 0 序列号，这样来跨越最大值。
+
+发送方不应该在同一s钟内启动发送消息，再重启在发送消息，这样会使得在同一秒内两次启动发送的不同消息具有相同的序列号。
+
+需要号清零策略
+---------------
+
+方案一：
+如果设置每分钟序列号清零，那么当上一个周期最末一秒发送第一个消息，
+而在同一秒内再发送的消息，又会使用同一个序列号，从而出现问题。
+所以清零后，必须等1s钟后才允许继续发送。
+因此本方案设计较为复杂。
+
+方案二：
+
+序列号 uInt 最大值为
+> 0xffffffff
+42,9496,7295
+可以考虑当序列号大于 20,0000,0000 时就进行归零，
+但是如果是差分的情况，那么就暂不归零而等到下一个消息发送再归零，
+同一秒内，后面部分从0开始的序号号很难达到前面部分接近20万的序列号，因此很难重叠。
+因此采用方案2.

package.json

@@ -3,13 +3,14 @@
 	"name" : "sms-sgip",
 	"description" : "SGIP sms protocol(China UC) implementation for SP,SMG,GNS",
 	"keywords" : ["sms", "sgip"],
-	"version" : "0.1.1",
+	"version" : "0.2.0",
 	"repository" : {
 		"type" : "git",
 		"url" : "git://github.com/kaven276/sms.git"
 	},
 	"main" : "SGIP.js",
 	"scripts" : {
+		"deploy" : "rsync -av -C -e 'ssh -p 60222' /Users/cuccpkfs/dev/project/sms/node_sms/ node@noradle.com:sms-sgip/"
 	},
 	"engines" : {
 		"node" : ">=0.6.2"