Jan Lukavský <
je.ik@xxxxxxxxx> writes:
Yes, UNIX socket is no problem, or maybe gRPC? That could be efficient
enough (not available in pure C, would have to be C++ submodule, could
have C interface though), although the fork is of no big overhead
given that there is synchronous TLS handshake (and thus many cycles
between user space and kernel space and even sending data multiple
cycles over wire). My measurements didn't show any significant impact
of the forking to the number of connections per second just from the
fork. It might be a little more secure to use a more defined protocol,
though.
Fair enough about TLS/etc. I guess it just seems that forking for this
is icky, at least to me, and I realize that's a preference thing.
The plugin architecture is of course possible, but it seems a bit more
fragile - the application code might not be as well tested as
mosquitto server itself and a security or other vulnerability might
compromise the whole server. So were I implement this I would choose a
different process (fork, UNIX socket, gRPC). gRPC would be the
preferred option for me, personally.
True about plugins, but they could just be glue to RPC mechanisms.
I am not familiar with gRPC and it's dimly on my list of things to look
at but if base mosquitto w/o the cpp wrapper can be built without C++
now, it seems like a regression to require C++ for the core.
Maybe CORBA? (That's a joke.)
_______________________________________________
mosquitto-dev mailing list
mosquitto-dev@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/mosquitto-dev
