new features/添加新特性 about mqttclient HOT 12 OPEN

机缘巧合下,看见了有微信推文说这个工程特别厉害,设计思路特别优秀.本着想要学习与提升的目的阅读了这个项目.
在阅读了作者的README与代码后,想向作者确认一个细节问题.
关于 mqtt_yield_thread 这个线程里的 mqtt_yield 函数,其工作方式是一直以cmd_timeout为时间单位来检测是否有各种类型的报文要处理是吗?
即, 即使没有报文要处理,还是会计时检测.

from mqttclient.

机缘巧合下,看见了有微信推文说这个工程特别厉害,设计思路特别优秀.本着想要学习与提升的目的阅读了这个项目.
在阅读了作者的README与代码后,想向作者确认一个细节问题.
关于 mqtt_yield_thread 这个线程里的 mqtt_yield 函数,其工作方式是一直以cmd_timeout为时间单位来检测是否有各种类型的报文要处理是吗?
即, 即使没有报文要处理,还是会计时检测.

是的，因为内部线程一直会在运行的，当没有数据传输的时候，依旧还是需要保持活性的（keep-alive），否则服务器会认为你是断开了，当然啦，内部已经实现保活机制了的，你不用担心。只是线程会阻塞cmd_timeout时间单位，然后看看是否需要keep-alive，然后再次进入休眠状态。

from mqttclient.

相当完美的库啊

from mqttclient.

想请教一个问题，在异步publish的时候，里面有buffer机制嚒？
就是说，调用者只管异步publish数据到buffer（线程安全的），而库自己去维护这个buffer，当网络ok的时候，自动把数据发送到服务器

from mqttclient.

想请教一个问题，在异步publish的时候，里面有buffer机制嚒？
就是说，调用者只管异步publish数据到buffer（线程安全的），而库自己去维护这个buffer，当网络ok的时候，自动把数据发送到服务器

是线程安全的，在多线程publish操作buff的时候，是通过互斥锁保护的，这些是mqttclient内部的处理，无需用户去关注哈。

from mqttclient.

想请教一个问题，在异步publish的时候，里面有buffer机制嚒？
就是说，调用者只管异步publish数据到buffer（线程安全的），而库自己去维护这个buffer，当网络ok的时候，自动把数据发送到服务器

是线程安全的，在多线程publish操作buff的时候，是通过互斥锁保护的，这些是mqttclient内部的处理，无需用户去关注哈。

牛牛牛哈哈

from mqttclient.

今天又来逛了一圈，我去，又完善了这么多，自动生成代码都有了，666啊。

from mqttclient.

今天又来逛了一圈，我去，又完善了这么多，自动生成代码都有了，666啊。

哈哈哈哈，玩起来嘛~

from mqttclient.

大佬，有windows平台的代码么？

from mqttclient.

大佬，有windows平台的代码么？

暂时没有哦~

from mqttclient.

膜拜大佬！！！
刚熟悉这个库，关于收发 buf 大小有点疑问，向您请教。

1. 创建客户端时在 mqtt_init 中动态申请了读写缓存的大小，按照 mqtt_defconfig.h 中的配置，默认值为 1024 。后续设置读写 buf 大小只是改变了结构体变量值，并没有重新刷新 buf 的大小，这个是否该重新刷新更合适？
2. 实际应用场景下，如需要接收 64K 的报文，这种情况下改了 MQTT_DEFAULT_BUF_SIZE 也不能够成功，您有处理过这种场景么？

from mqttclient.

膜拜大佬！！！
刚熟悉这个库，关于收发 buf 大小有点疑问，向您请教。

1. 创建客户端时在 mqtt_init 中动态申请了读写缓存的大小，按照 mqtt_defconfig.h 中的配置，默认值为 1024 。后续设置读写 buf 大小只是改变了结构体变量值，并没有重新刷新 buf 的大小，这个是否该重新刷新更合适？
2. 实际应用场景下，如需要接收 64K 的报文，这种情况下改了 MQTT_DEFAULT_BUF_SIZE 也不能够成功，您有处理过这种场景么？

已解决哈,感谢提出~当时看到了,忘了回复了

from mqttclient.