Re: SSL connection approaches...
Thanks for the clarification! Oh I absolutely love implementing protocols "just for fun", can't blame you for that haha. Please publish your code when it's ready, I'd love to have a look and lend a hand if needed. Cheers, AW -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: SSL connection approaches...
Hi AW, When I am NOT using SSL (but doing a local TCP connection to MQTT server), it is pure PicoLisp. Most of my needs are local, but I do occasionally each out to an internet hosted MQTT server. The MQTT client code I wrote a few years ago was in a subset of Common Lisp (small enough of a subset that it ran under a slightly modified uLisp on ESP32 microcontrollers). I wrote it mainly because the subscriber "mainloop/callback/async/etc" of other implementations wasn't of my liking and, in addition, I like exploring protocols by "implementing them" (so, this was sort of toy effort that grew into something that was solid enough to deploy and not warrant restructuring for a MQTT C lib rewrite!) (I'm also an old school Forther, so I guess that fueled some of that "roll your own" spirit that gets me into trouble sometime.) My PicoLisp MQTT client is just a port of that Common Lisp code. Done as a way to explore and learn PicoLisp as much as anything. Interestingly, my Common Lisp MQTT client code still depends on libraries that have to be downloaded and compiled (via Quicklisp) and that is a bit of a pain (usocket, ssl and things that brings with it). With PicoLisp, I just need "picolisp" and ncat/socat /todd -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: SSL connection approaches...
Hi Todd, If you're calling out to ncat/socat, then it won't be a "pure" PicoLisp client. In that case, why not simply call out to an existing C client or library such as Mosquitto: https://mosquitto.org/ ? I've been doing that since ~2016 by calling the mosquitto_pub client from PicoLisp with a specific set of arguments (some fixed, some variable). It got me up and running with MQTT+PicoLisp much faster than writing an entire client from scratch. Writing a native PicoLisp client that uses the mosquitto library might be even better than both our approaches though. Just a thought. Cheers, AW On Sat, 9 Sep 2023, Todd Coram wrote: Hi, I've been porting my "pure" Common Lisp MQTT client to Picolisp, and it has gone very well for non-SSL connections (I just used "connect"), but I am looking for a canonical way to connect to a SSL/TLS encrypted socket (no certs needed, I just need basic encryption). I've been using pipe and an external "helper" (ncat in this case but socat would be similar): (de mq-open (Host Port SSL) (if SSL (pipe (exec "ncat" "--ssl" Host Port)) (connect Host Port))) Is this a good approach? Using the FFI to call openssl library is more efficient, but I didn't want to go that path yet... Once concern I have with the above code is dealing with when a connection is dropped. My MQTT implementation currently has no "outside" dependencies (with the above exception) and I'd like to keep it as independent as possible. Am I missing an obviously better approach? /todd -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: SSL connection approaches...
Thanks Alex. My MQTT client is minimal, and the Common Lisp implementation, has been running in production for over a year. I hope to do same with the Picolisp version, which has only "ncat/socat" as a dependency, It's open source, but not ready for "release" quite yet... /todd -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: SSL connection approaches...
Hi Todd, > I've been porting my "pure" Common Lisp MQTT client to Picolisp, and it has > gone > very well for non-SSL connections (I just used "connect"), but I am looking > for > a canonical way to connect to a SSL/TLS encrypted socket (no certs needed, I > just need basic encryption). > (de mq-open (Host Port SSL) >(if SSL > (pipe > (exec "ncat" "--ssl" Host Port) ) > (connect Host Port) ) ) > > Is this a good approach? Yes, looks good. > Using the FFI to call openssl library is more efficient, but I didn't want to > go > that path yet... I would not worry about efficiency here, because just a single process is started once. > Once concern I have with the above code is dealing with when a connection is > dropped. I would use the file descriptor returned from the above function in a 'task', and close (and perhaps restart) it when reading returns NIL (EOF). ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
