NB模组TCP连接长时间断开问题及使用详解

llb90 发表于 2020/04/17 09:55:09 2020/04/17
【摘要】 使用NB模组建立TCP连接发送数据,受蜂窝网络波动的影响,tcp连接不稳定,时常容易断开,但是模组存在无法感知连接状态的情况,导致较长时间的数据中断(模组没有上报断开连接指示,发送数据没有报错,但是数据没有发送到服务器)。以下对NB模组TCP\UDP的使用做总结,并针对TCP数据中断的情况给出了解决方案。

前言

使用NB模组建立TCP连接发送数据,受蜂窝网络波动的影响,tcp连接不稳定,时常容易断开,但是模组存在无法感知连接状态的情况,导致较长时间的数据中断(模组没有上报断开连接指示,发送数据没有报错,但是数据没有发送到服务器)。以下对NB模组TCP\UDP的使用做总结,并针对TCP数据中断的情况给出了解决方案。

适用于M5310-A、BC28等海思模组。

使用前注意

NB模组会自动注册平台,使用前最好关闭平台注册功能。当然不关闭也是可以使用的。

  • M5310-A需要禁用LwM2M模块。LwM2M模块使用socke 0,通过NSOCR创建的socket id从1开始;禁用LwM2M后,sokce id从0开始。

AT+MLWM2MENABLE=0 //0-禁止LwM2M   1-使能
  • 移远的模组则是禁用IoT平台注册功能

AT+QREGSWT=2

UDP

1.创建socket

AT+NSOCR="DGRAM",17,6003,0

返回创建的socket id。

6003表示监听端口,可设置为0,表示任意端口;

最后的数字表示接收控制:0-无接收提醒,1-接收提醒

  • 设置为0时,收到下行数据时,模组不主动发送任何信息提示

  • 设置为1时,收到数据后,模组主动上报提示信息: +NSONMI:0,2

2.发送数据

正常发送

AT+NSOST=0,121.36.7.137,1990,3,303132

带RAI发送

AT+NSOSTF=0,121.36.7.137,1990,0x200,3,303132

发送完成后模组马上进入Idle状态,否则会等到20S的不活动定时器超时后才进入Idle。

如:

[16:36:13.873]发→◇AT+NSOSTF=0,121.36.7.137,1990,0x200,3,303132[16:36:13.936]收←◆0,3OK

[16:36:14.837]收←◆+CSCON:1[16:36:15.040]收←◆+CSCON:0   //马上进入了idle

3.读取接收数据

AT+NSORF=0,255

模组会将收到的数据逐条缓存在内存中,发送该指令后,模组返回缓存在内存中的第一条数据;继续发送,则继续返回剩下的数据。

0表示socke id,255表示读取的消息长度;

若创建socket时设置接收提醒

模组收到数据时主动上报: +NSONMI:0,2;

若模组中已经缓存有数据还未读取,则收到新的下发数据后,模组并不会上报+NSONMI:0,2指示;

//1.发送AT+NSORF=0,255 返回第一条消息AT+NSORF=0,255    //发送+NSORF:0,121.36.7.137,1990,2,1133,2OK

+NSONMI:0,2  //表示还有2字节数据可读//2.继续发送AT+NSORF=0,255AT+NSORF=0,255+NSORF:0,121.36.7.137,1990,2,1133,0OK//3.继续发送AT+NSORF=0,255AT+NSORF=0,255OK//只返回了ok,说明已经没有数据可读了

创建socket时设置无接收提醒

模组收到下发数据时无任何指示信息

//1.发送AT+NSORF=0,255 返回第一条消息AT+NSORF=0,255    //发送+NSORF:0,121.36.7.137,1990,2,1133,2OK//2.继续发送AT+NSORF=0,255AT+NSORF=0,255+NSORF:0,121.36.7.137,1990,2,1133,2OK//3.继续发送AT+NSORF=0,255AT+NSORF=0,255OK //没有数据可读,只返回了ok

TCP

1.创建socket

AT+NSOCR="STREAM",6,0,0

同创建UDP时一样,第一个0表示监听任意端口,也可指定端口;

最后一个0设置无接收提醒,1则表示有接收提醒。

创建成功,返回socket id

0OK

2.连接服务器

AT+NSOCO=1,121.36.7.137,22

连接成功后返回:

CONNECT OK

3.发送

正常发送,不指定发送序号

AT+NSOSD=0,4,FEFEFEFE

模组返回:

0,4OK

0-socket id;4-发送的数据长度

带序号发送

发送时指定发送序号,模组会返回数据发送状态

+NSOSTR:<socket>,<sequence>,<status>//status:0表示错误,1表示已发送

发送格式如下:

AT+NSOSD=0,4,01020304,0,66//参数为:socket id,长度,内容,flag(固定值0),序号(可为固定值)

模组返回:

0,4OK

+NSOSTR:0,66,1 //模组上报发送状态

说明:

  • 有时TCP连接已经断开,但是模组检测不到,不会主动上报" +NSOCLI:<socket> ",且服务器也没有断开指示;实际测试,长时间不发送数据,TCP连接会断开。在连接断开的情况下用“AT+NSOSD”发送数据分以下两种情况讨论:

    • 正常发送方式(不指定序号):该方式下发送数据模组仍会返回ok,但是数据并不会发送到服务器。该情况下用户程序无法感知连接断开,需要依赖服务器下发数据才能区分。

    • 带序号发送:该方式下发送数据,模组会返回OK,但不会上报+NSOSTR(很正常,tcp连接已经断开了嘛),继续使用该指令发送数据,模组就会返回err了。使用该指令,用户程序可以判别出tcp连接断开的情况,

      推荐使用

  • 在上述TCP连接断开的情况下,需要关闭socket、重新创建、连接才可。

  • TCP发送带RAI的方式目前不生效。

4.接收-读取模组数据

同UDP时一样

创建socket时设置无接收提醒

//第一条数据+NSORF:0,121.36.7.137,22,5,6461666473,5OK//第二天数据+NSORF:0,121.36.7.137,22,5,6461666473,0OK//没有数据可读取了,仅返回OKOK

总结

  • 使用TCP时,推荐使用带序号的发送方式,可以规避TCP连接断开后应用程序无法感知导致较长时间数据中断的问题。

  • 移远的海思平台的模组使用方式相同。

另外: 新版本的海思固件中加入了 NSOSTATUS 指令,可以查询socket的状态,推测该指令应该也可以解决连接断开的情况,需要测试验证(2020-4-5)。


【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区),文章链接,文章作者等基本信息,否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件至:cloudbbs@huaweicloud.com进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容。
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。