blocking socket support about mqtt-c

[BloodyF]

Thank you all,
I will implemented a fd select() to call mqtt_sync.

[Josh798]

I'm not Liam, but I don't think one exists natively. However, you possibly could implement one by polling the socketfd in your mqtt_client instance using poll, select, or epoll if your platform supports it. Once one of those functions indicates that socketfd has data to be read, you could then call mqtt_sync.

[LiamBindle]

I don't think this is a priority at all. In fact, I'm not actually sold on it being a good idea at all.

I'm going to close this issue for the time being, but if anyone does want this functionality, feel free to reopen 😄

[LiamBindle]

Yeah, @Josh798 is correct. Currently, no, but it probably wouldn't be much work to add. Unfortunately though, right now I don't have the capacity to do this myself.

MQTT-C currently supports non-blocking sockets because mqtt_sync is intended to be called in a busy loop. Part of the reason for this is MQTT-C can run in single-threaded applications (no OS), and doing that with non-blocking sockets is considerably easier than with blocking sockets.

One thing though—you don't need to call mqtt_sync very frequently. For QoS 0 mqtt_sync only needs to be called about as frequently as you expect traffic. For higher QoS's you should be calling mqtt_sync a few times per second.

[LiamBindle]

Great, that would be awesome!

Looking forward to your PR.

Liam

[LiamBindle]

Hi, Just wondering how you're making out with this. Are you still working on this?

[Josh798]

If nobody is currently working on this, I can take a shot at this in my spare time. But, my spare time is quite limited at the moment, so I might be a while if so.

[M1cha]

@LiamBindle I need this functionality because I'm working with single-threaded applications with an event loop(interrupts from timers, uart, network, internal threads, etc send events to the loop to unblock it for one iteration).
I like that concept because it allows me to not worry about thread-safety while still having low cpu-load when there's nothing todo.

I've already started working on it but I'm not sure how this could be merged because it needs quite a few changes to the way mqtt-c works. You can take a look here:
https://github.com/M1cha/MQTT-C/tree/eventloop

[LiamBindle]

Hi Michael,

Oh cool! Let me know how it goes!

Down the road, if you do want to merge it into the official MQTT-C repo, you could define a flag in the PAL that indicates if the network callbacks are blocking or non blocking. Then, in the MQTT-C source code handle the two separately. That would be my recommendation, but I good with whatever you decide to do.

The two benefits of merging it into the offical MQTT-C repo would be helping other users (there's been a handful of people that want to use blocking sockets) and benefiting from upstream developments. For example, if someone were to add MQTT-SN or MQTT 5 support, you/the users your dev supports could quickly benefit from that.

Anyways, hope it's going well! Let me know if you need a hand with anything!

Liam