关于嵌入式mqtt的一些疑问，求助资深前辈（文字较多）

15284083060

问题是这样的，嵌入式底层在采集完成数据之后会存储在4G模块里面，然后通过服务器的指令将文件上传，有一种情况是在网络状况不好的时候依然需要上传这些数据，这个时候文件上传就会超时，就是这个超时之后设备出现某些异常（比较明确的现象是设备网络不正常了，没有上传，mqtt下发的的指令也没回），首先设备是在正常运行的，至少看门狗在运行，但是推送消息失败，一开始我觉得是因为推送文件超时导致某处的信号量没释放，在一下次获取的时候阻塞了任务，这种情况我不是很确定，因为查阅了所有的信号量都是成对使用的，然后我突然想起一个关键的点，就是mqtt的keepalive配置，这个点配置的是20秒，文件上传超时时间是90秒，我查阅资料：如果服务器在保持活动时间段的1.5倍内没有收到来自客户端的消息，那么它将断开客户端连接，就像客户端发送了断开连接消息一样。keepalive的时间文档上默认是120秒，所以这个过程极有可能造成mqtt断开，但是我不知道这个时间配置成默认的120米秒会有什么意想不到的情况，写这么多，主要是想项大家请教一些经验

jermy_z

那要看MQTT的服务器是怎么配置的，是多久被踢下线。如果是被踢下线，可以从服务器修改这个时间，或者多次失败之后，客户端重新连接服务器

15284083060

通过反复的现场还原测试，发现是因为信号量阻塞的导致的，在文件上传失败之后，信号量被阻塞(推送消息的函数会用到这个信号量)，与mqtt的交互超过了20s，断开mqtt连接，推送是用到的软件定时器，此时软件定时器任务被阻塞，但是另外一个任务里面会喂狗，所有设备不会重启，相当于死机状态，现在这个信号量释放直接相关的RT_thread  AT组件还需要学习才能尝试找出这个信号量阻塞根本原因