search

Juerd / Net-MQTT-Simple

Net::MQTT::Simple - Minimal MQTT version 3 publisher
10 stars 7 forks source link

Coexistence with non-blocking I/O event loop? #25

Open Yenya opened 10 months ago

Yenya commented 10 months ago

Hello,

thanks for this module, it works for me!

I wonder if Net::MQTT::Simple could be modified to work over a connection provided by an existing non-blocking event loop, preferably something like Mojo::IOLoop::Client, https://metacpan.org/pod/Mojo::IOLoop::Client .

Can this module do only message parsing and delegate I/O to some other entity?

Thanks,

-Yenya

Juerd commented 10 months ago

It should definitely be possible to abstract I/O out, but I don't have the time to look into that. Is this something you'd be able to do? I wouldn't mind reviewing and maybe merging a good pull request. (Merging would of course depend on quality and backwards compatibility.)

Yenya commented 10 months ago

@Juerd: Thanks for the reply. I will look at it, if I manage to find some free time :-).

kc2zgu commented 4 weeks ago

Related: is it easy to add a method for returning the socket filehandle so that an existing loop can poll it for activity? The application would then call tick(0) when input is received. This is a pretty common idiom for networking libraries (libmosquitto even provides a function to do this for using MQTT from C). It's likely possible to poke around in the object structure and get the socket directly, but an official API would be more reliable.

Juerd commented 4 weeks ago

Not very easy, since this module manages its own connections internally. There is no socket after object construction yet, and the socket may be replaced in between calls of tick(). One thing that comes to mind is to add a method to register callback functions to handle new socket creation; the supplied function would be used to add the new socket to the set of descriptors to select/poll. But I don't know how to actually recognise disconnection and trigger reconnection in that case.

I'm open to suggestions as long as they're compatible with the automatic reconnection paradigm.

kc2zgu commented 4 weeks ago

I forgot it reconnects internally, so that simple approach wouldn't work. A callback is probably the best way to do it then, but I'd have to look at the implementation a little bit to figure out how it would work.