You are not logged in. Please login or register.
Welcome to the wolfSSL Forums!
Please post questions or comments you have about wolfSSL products here. It is helpful to be as descriptive as possible when asking your questions.
- download stable product releases.
- latest development branch on GitHub.
- wolfSSL (formerly CyaSSL) product manual and API reference.
Posts found: 3
Hi Eric and David,
Thank you for this update. I tried it, and it worked. The only thing I found was that when using a QoS of 0, MqttClient_Publish_ex will return with the length of the last chunk instead of MQTT_CODE_SUCCESS.
I also noticed that publishing data took roughly 40x more time compared to subscribing to the same data. (2.5MB, 195sec vs 4.5sec) I suspect this is because encrypting data takes more time than decrypting it?
I'm running a 32bit microcontroller (RX63N) on 96MHz, without hardware encryption.
I want to transport large payloads (files) with wolfMQTT. Receiving this data via a subscription was surprisingly easy, the data comes in in chunks which I write to a file as they come in.
But is there a similar solution available for publishing large payloads? It would be nice if I could read the data piece by piece from a file as it's sent out.
I'm building wolfMQTT using wolfSSL for an embedded controller (RX63N).
It basically works, but I still have some details to work out.
But one thing I noticed is that MqttClient_WaitMessage uses a different timeout when on a secure connection:
- On a normal connection it uses the timeout passed to the function as the second parameter.
- On a secure connection it uses the cmd_timeout_ms that was passed to the MqttClient_Init() call.
It's not a big issue at all for me, but it was a bit confusing so I mention it anyway.
Posts found: 3