长短信模式下部分手机某些情况下接收不到飞信消息原因之分析及改进建议

[GoogleCodeExporter]

试用了一周，发现LibFetion1.0确实不错。但发现和官方版飞信��
�在一个相同的问题：
LibFetion在长短信模式下发送短信，部分手机（如Philips 
9@9R，9@9系列的多数手机存在此
问题）只响铃，但收件箱看不到任何新信息。看来这是移动��
�信接入网关上的一个小bug造成的，
但此问题可以通过LibFetion客户端程序的小小改进来避免。
详情请参见我在飞信论坛的帖子：
http://bbs.fetion.com.cn/forums/Threads/5911091.aspx

此问题飞信官网已确认，但不知为啥飞信官方版至今未改进��
�真希望LibFetion能解决此问题。

Original issue reported on code.google.com by hcx2...@gmail.com on 7 Sep 2009 at 11:14

[GoogleCodeExporter]

Hi hxc2012,
这个问题我也知道，不过没有像你一样去深入研究。（佩服��
�服）

我看了下你的建议：
       1、临时解决方法：设置飞信为“使用普通短信发送信息”，这样会保证手机能可靠接收到
飞信短信，但缺点显而易见：强制将真实长短信拆分为多条��
�通短信，接收方阅读不便。

************
目前官方版本是这样建议的，其默认设置就是 
“使用普通短信发送信息”.
************

       2、改进飞信，使其严格按照3GPP TS 03.40 V7.5.0 (2001-12)标准推荐的长短信使用场
合来发送长短信。
************
这个应该在飞信服务器端来改进，对于客户端而言，它是无��
�解决具体使用那张短信格式到手机
上的。
************

PS：
我觉得你的信息对于飞信服务器开发者来说是非常有用的，��
�基本上帮他们解决了那个长短信的BUG。

非常感谢你的建议。 

************

Original comment by libfet...@gmail.com on 14 Sep 2009 at 6:27

• Changed state: WONTFIX
• Added labels: OpSys-All

[GoogleCodeExporter]

楼主的想法是libfetion提供workaround？

Original comment by alsor.zhou on 14 Sep 2009 at 8:33

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

呵呵，真心谢谢诸位关注此问题！

>> 
这个应该在飞信服务器端来改进，对于客户端而言，它是无��
�解决具体使用那张短信格式到手机
上的。？？
>> 楼主的想法是libfetion提供workaround？

同意你的看法，这个问题最好是能在飞信服务器端（或移动��
�短信网管）上解决，但个人认为，在服务器端未
解决此问题的情况下，客户端是可以通过小改进来避免此问��
�的，原因如下：

无论“是否使用长短信”设置是用来控制在客户端对短信进��
�封包，还是控制在服务器端对短信进行封包（哪
一种不确定，我对飞信客户端与服务器端之间采用的通信协��
�不太了解），只要判断客户端判断发送内容可以
使用一条普通短信来发送，客户端都先强制将设置改为“使��
�普通短信”发送，发送完毕后，再自动改回原来
的设置。

这样改动的优点是：程序改动小，不用改变飞信通信协议，��
�便将来飞信服务器端升级解决了此问题，客户端
仍能正常工作。

Original comment by hcx2...@gmail.com on 14 Sep 2009 at 12:07

[GoogleCodeExporter]

但是有一个问题，我不太清楚SMS的协议，如果长短信在客户��
�强制截断为普通短信的话，如何控
制各短信之间到达的先后顺序？

Original comment by alsor.zhou on 14 Sep 2009 at 12:31

[GoogleCodeExporter]

”如何控制各短信之间到达的先后顺序“按发送到顺利发。

最个问题最关键的地方在：
你不知道你发送到对象的手机是否支持。

如果对方手机不支持长短信，没问题，可以分开发。
要是支持呢？ 

关键点： 如何知道对方手机是否支持。

以此在客户端是无法做到，除非把长短信给砍掉。但这对大��
�分人来说是不公平的。

所以解决点还是在服务器按”规范“发送短信

Original comment by libfet...@gmail.com on 14 Sep 2009 at 1:40

[GoogleCodeExporter]

呵呵，是的，我们最理想的case是客户端之间都是用的libfetion�
��做发送，然后就成为了
libfetion之间的通信:) 个人的意见和ddd一样，WONTFIX

不过同样感谢hcx2012的深度分析 + 1

Original comment by alsor.zhou on 14 Sep 2009 at 2:08

[GoogleCodeExporter]

请相信我，这个问题解决起来很简单，是大家把它想复杂了��
�！！

>> 
但是有一个问题，我不太清楚SMS的协议，如果长短信在客户��
�强制截断为普通短信的话，如何控
>> 制各短信之间到达的先后顺序？
>> 
”如何控制各短信之间到达的先后顺序“按发送到顺利发。
对于手机接收长短信来说，“片断短信”的到达顺序无关紧��
�，因为每条“片断短信”正文的前6个字节记录了
此长短信的标识码（以区分其它长短信）、此长短信包含“��
�断短信”的总条数及当前“片断短信”的编号。
手机接收完所有“片断短信”，会自动按正确顺序将其组装��
�一条长短信。

>> 最个问题最关键的地方在：
>> 你不知道你发送到对象的手机是否支持。
这也不是个问题，其实飞信服务器和移动短信接入网关也不��
�道用户的手机是否支持长短信（就理论而言，通
过查询手机的IME号、手机入网数据库和手机本身的说明手册��
�移动公司是可以间接确认用户的手机是否支持
接收长短信，但试想，如此复杂，除非用于刑侦......否则.....
.）。解决此问题，和发送对象的手机是否
支持长短信关系不大！

为了把这个问题彻底说明白，我需要先确认一个信息，还先��
�大家帮忙：
当前飞信客户端发送长短信时，是客户端根据“是否使用长��
�信”设置把短信内容拆分为“普通片段短信”后
再发送给飞信服务器；还是客户端直接把短信内容和“是否��
�用长短信”设置发送给飞信服务器，然后由服务
器来拆分。无论上述那种情况，飞信服务器最终都要通过移��
�的短信网关将信息发送给手机。这样以来，就可
能存在第三种情况，客户端和服务器端都未对长短信进行拆��
�，而是短信网关进行拆分的（下文暂不讨论此情
况，若真是这种情况，考虑到成本，移动解决此问题的可能��
�不大）。

时间不早了该回去了，明天有空的话我给出程序改进的伪代��
�。

Original comment by hcx2...@gmail.com on 15 Sep 2009 at 3:51

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

个人推测是上述第二种情况，即由飞信服务器对长短信进行��
�分，下面给出相应的客户端改进伪代码：

if ( ClientCurrentMsgSetting 为 使用普通短信 )
{
    按现有方法发送所有短信;
}
else  // ClientCurrentMsgSetting 为 使用长短信
{
    if ( TheTotalBytesNumber_of_message <= 140 ) // 一条普通短信的最大容量为140字节
    {
        SetMsgSetting 为使用普通短信;
        按现有方法发送该短信;
        SetMsgSetting 为使用长短信;
    }
    else
    {
        按现有方法发送该短信;
    }
}

需要注意的是:
1、计算 TheTotalBytesNumber_of_message 时，短信的实际内容应为: 
"飞信昵称:"+"用户输入的内
容";
2、当前飞信采用的“片段短信”的最大容量为140-6=134字节。�
��试的结果是，只有在使用长短信发送 
TheTotalBytesNumber_of_message < (140-6) 
字节的短信时存在接收不到的问题。

Original comment by hcx2...@gmail.com on 16 Sep 2009 at 1:54

[GoogleCodeExporter]

“还是客户端直接把短信内容和“是否使用长短信”设置发��
�给飞信服务器，然后由服务
器来拆分。”

是这种情况，最终的选择发送模式是在服务器那里。

客户端是不提供拆分的。但客户端可以帮助服务器拆分，当��
�户没有选择 长短信发送模式“.

所以我觉得在客户端那也许是无能为力。

具体服务器那里是在网关拆分还是服务器拆分，这我也不清��
�了。 :-)

Original comment by libfet...@gmail.com on 16 Sep 2009 at 2:29

[GoogleCodeExporter]

hcx的想法是在本地发送的时候就强制把长短信一律切为普通��
�短信，但这个实际上会有一些副作
用，本来支持长短信的手机也一律接受短短信。在comment 
9的回复里面，“对于手机接收长短信
来说，“片断短信”的到达顺序无关紧要”， 
那如果我们把长短信切为短短信再发送的话，接收方
还能组装为长短信么？如果不能，如何保证各个短信之间到��
�的先后顺序？

Original comment by alsor.zhou on 16 Sep 2009 at 5:09

[GoogleCodeExporter]

>> 
具体服务器那里是在网关拆分还是服务器拆分，这我也不清��
�了。 :-)
其实不用关注这个问题，Comment 11 
给出的伪代码虽然是针对第二种情况给出的，但对于 Comment 9 
给出
的三种情况都是有效的。

>> 
hcx的想法是在本地发送的时候就强制把长短信一律切为普通��
�短信，但这个实际上会有一些副作
用，本来支持长短信的手机也一律接受短短信。
你理解错了，我的意思不是“一律”（是我没有写清楚？）��
�因此不存在你所说的“一些副作用”，也不存在
“把长短信切为短短信再发送的话”引起的问题。

看来，我有必要在伪代码上加上更详细的注释了：
======================================================================
if ( 客户端当前设置为使用普通短信 )  // 
保留用户选择使用那种方法的权利
{
    按现有方法发送所有短信;  // 不用改变任何底层通信协议
}
else  // 客户端当前设置为使用长短信
{
    if ( TheTotalBytesNumber_of_message <= 140 ) // 一条普通短信的最大容量为140字节
    {
        // 发送内容能由一条普通短信容纳，故先自动切换为普通短信模式
        临时设置客户端为使用普通短信发送;

        按现有方法发送该短信;  // 不用改变任何底层通信协议

        // 发送完毕，再自动将设置恢复到使用长短信模式
        恢复客户端设置为使用长短信;
    }
    else
    {
        // 采用此方式发送的短信至少为141+6=147字节，显然大于140-6=134字节，
         // 从而回避了飞信服务器的bug
        按现有方法发送该短信;  // 对于真正的长短信(>140字节)保留了长短信发送方式
    }
}

需要注意的是:
1、计算 TheTotalBytesNumber_of_message 时，短信的实际内容应为: 
"飞信昵称:"+"用户输入的内
容";
2、当前飞信采用的“片段短信”的最大容量为140-6=134字节。�
��试的结果是，只有在使用长短信发送 
TheTotalBytesNumber_of_message < (140-6) 
字节的短信时存在接收不到的问题。
======================================================================

总结一下，引用comment 5 
的话：这样改动的优点是：程序改动小，不用改变飞信通信��
�议，兼容性好，即
便将来飞信服务器端升级解决了此问题，客户端仍能正常工��
�。

好了，没有以外的话，这是我的最后一个回复（见谅了）。��
�想，我已经尽力把这个问题的原因及解决方案说
清楚，具体能否改进就看各位的了。若大家实在觉得没必要��
�那也就作罢，没关系的！

Original comment by hcx2...@gmail.com on 16 Sep 2009 at 7:22