new features/添加新特性
As a client developed in accordance with the standard MQTT protocol, you may need to add new features on some platforms or meet some more convenient needs. You can speak freely here. This project will continue to be maintained.
作为一个按照标准MQTT协议开发的客户端,可能在某些平台上需要添加新的特性,或者满足某些更方便的需求,可以在这里畅所欲言,本项目将持续维护。
机缘巧合下,看见了有微信推文说这个工程特别厉害,设计思路特别优秀.本着想要学习与提升的目的阅读了这个项目. 在阅读了作者的README与代码后,想向作者确认一个细节问题. 关于 mqtt_yield_thread 这个线程里的 mqtt_yield 函数,其工作方式是一直以cmd_timeout为时间单位来检测是否有各种类型的报文要处理是吗? 即, 即使没有报文要处理,还是会计时检测.
机缘巧合下,看见了有微信推文说这个工程特别厉害,设计思路特别优秀.本着想要学习与提升的目的阅读了这个项目. 在阅读了作者的README与代码后,想向作者确认一个细节问题. 关于 mqtt_yield_thread 这个线程里的 mqtt_yield 函数,其工作方式是一直以cmd_timeout为时间单位来检测是否有各种类型的报文要处理是吗? 即, 即使没有报文要处理,还是会计时检测.
是的,因为内部线程一直会在运行的,当没有数据传输的时候,依旧还是需要保持活性的(keep-alive),否则服务器会认为你是断开了,当然啦,内部已经实现保活机制了的,你不用担心。只是线程会阻塞cmd_timeout时间单位,然后看看是否需要keep-alive,然后再次进入休眠状态。
相当完美的库啊
想请教一个问题,在异步publish的时候,里面有buffer机制嚒? 就是说,调用者只管异步publish数据到buffer(线程安全的),而库自己去维护这个buffer,当网络ok的时候,自动把数据发送到服务器
想请教一个问题,在异步publish的时候,里面有buffer机制嚒? 就是说,调用者只管异步publish数据到buffer(线程安全的),而库自己去维护这个buffer,当网络ok的时候,自动把数据发送到服务器
是线程安全的,在多线程publish操作buff的时候,是通过互斥锁保护的,这些是mqttclient内部的处理,无需用户去关注哈。
想请教一个问题,在异步publish的时候,里面有buffer机制嚒? 就是说,调用者只管异步publish数据到buffer(线程安全的),而库自己去维护这个buffer,当网络ok的时候,自动把数据发送到服务器
是线程安全的,在多线程publish操作buff的时候,是通过互斥锁保护的,这些是mqttclient内部的处理,无需用户去关注哈。
牛牛牛哈哈
今天又来逛了一圈,我去,又完善了这么多,自动生成代码都有了,666啊。
今天又来逛了一圈,我去,又完善了这么多,自动生成代码都有了,666啊。
哈哈哈哈,玩起来嘛~
大佬,有windows平台的代码么?
大佬,有windows平台的代码么?
暂时没有哦~
膜拜大佬!!!
刚熟悉这个库,关于收发 buf 大小有点疑问,向您请教。
- 创建客户端时在
mqtt_init中动态申请了读写缓存的大小,按照mqtt_defconfig.h中的配置,默认值为 1024 。后续设置读写buf大小只是改变了结构体变量值,并没有重新刷新buf的大小,这个是否该重新刷新更合适? - 实际应用场景下,如需要接收
64K的报文,这种情况下改了MQTT_DEFAULT_BUF_SIZE也不能够成功,您有处理过这种场景么?
膜拜大佬!!! 刚熟悉这个库,关于收发
buf大小有点疑问,向您请教。
- 创建客户端时在
mqtt_init中动态申请了读写缓存的大小,按照mqtt_defconfig.h中的配置,默认值为 1024 。后续设置读写buf大小只是改变了结构体变量值,并没有重新刷新buf的大小,这个是否该重新刷新更合适?- 实际应用场景下,如需要接收
64K的报文,这种情况下改了MQTT_DEFAULT_BUF_SIZE也不能够成功,您有处理过这种场景么?
已解决哈,感谢提出~当时看到了,忘了回复了