使用GTM900模块，如果TCP发送缓冲区满，需要处理一下吗？（希望APPCAT能看到这个贴子）

beihai084

大家好，我想问一个关于发送TCP消息指令，我用的是GTM900，发送TCP消息指令是：AT%IPSEND，
回复，%IPSEND:15 //注意：这个返回的buffer序号，每发送一包数据不管大小，都占用一个buffer空间。总计16个。如果返回的buffer序号在减小，表示当前的网络传送受阻，当返回的buffer序号为0时模块回复ERROR：20，这时我应该做什仏处理，是要重新建立连接吗？
现象是：我每隔30S发送一条TCP消息，有时会收到ERROR：20的信息，然后GTM模块继续发送，反回是：%IPSEND:XX　OK，但从TCP测试助手中没收到TCP数据。过一会会几条一块发到TCP测试区。
这个现像是应该是由于网络阻塞引起的，当在收到ERROR：20是，需要处理一下吗？

我是beihai084,我希望APPACT能看到这个贴子。上次的问题在你的帮助下已经解决，感谢！

Appcat

由于TCP网络的速度不稳定，可能会造成数据积压。当收到error 20时就表明GTM900B内部发送窗口被全部占用，等待发送成功后才能释放窗口，所以遇到这个错误，什么都不要做，就停下来等等好了。

USBFD

30秒发送一次，16个的话要八分钟呢！能堵那么长时间？应该把你使用环境说一下，太恶劣，看看你的天线及其附件连接导致信号太弱

beihai084

感谢

lysoft

这个方面还是OPENAT好用,一个wip_write搞定,函数返回就知道是否操作成功

Appcat

楼上，如果wip_write函数是阻塞模式，要返回才知道是否操作成功，网络塞车比较厉害的时候，你的DTU不会失去反应吗？
阻塞模式对于DTU开发者来说的确好用，但是在网络条件恶劣情况下，对用户也许是噩梦。举个例子来说，就是楼主的情况，网络阻塞导致数据包晚了几分钟才到，如果是阻塞函数，这几分钟就是在等待操作是否成功，而TCP/IP的超时机制比较宽松的，万一该数据实时要求比较高，几分钟后已经没有意义了，要送新采集的数据，这时，这个DTU就不能满足用户需求了。如果不是阻塞模式，用户至少可以选择重发或者重新连接来抛弃已经无实际意义的数据。

lysoft

OPENAT没此问题的
OPENAT OS不允许长达几分钟的阻塞的
而且OpenAT基于EVENT驱动模式,在提交Wip-Write时,其它任务是可以调度的
OpenAT不允许任意一个任务独占超过8秒钟,这会导致看门狗复位的

我用OpenAT做的DTU已经在多个行业中使用,远比华为之类的模块稳定可靠的

另外OpenAT的EVENT驱动模式和Windows的消息队列非常类似,会Win32SDK开发的人,就能比较容易了解OpenAT的流程
写惯单片机的肯定不习惯EVENT驱动模式的

USBFD

好像只有Wavecom支持吧，真有楼上说得这么可靠吗！

西门子岂不是要歇菜

wxw123321

Appcat 发表于 2009-2-20 16:25
由于TCP网络的速度不稳定，可能会造成数据积压。当收到error 20时就表明GTM900B内部发送窗口被全部占用，等 ...

Appcat你好，请教一下那要等多久才算合适啊？我发现有时候等好久都没有发出去，一直是发送窗口满了。最后主动断开链路，在次连接上就可以发送了，不知道是模块咋样了。用的是GTM900C 谢谢

Appcat

一般等够一个心跳周期就可以了。