Max message size for embedded c?

[eclipse]

Max message size for embedded c?

[rafaeldelucena]

You can define the size of the buffers

I know this problem from the ESP8266, which would fail at around120 Bytes, where I had to use a modified MQTT client (not Paho) version which streams the messages instead of sendig it as a single packet.

With the C++ Paho MQTTClient I already sent and receive more than 500 bytes using the ESP8266 v12f, only by specifying the size of the read and write buffers.

For the C Client this can be accomplished at initialization

void MQTTClientInit(MQTTClient* client, Network* network, unsigned int command_timeout_ms,
unsigned char* sendbuf, size_t sendbuf_size, unsigned char* readbuf, size_t readbuf_size);

[stozk]

Ah well thanks I'm blind... there it is... 1000 Bytes.

[scaprile]

Completely off-topic, but since you guys raised it: ESP8266 has two official SDKs, one is RTOS-based and the other is bare metal. The bare metal one requires the developer to ensure the processor has enough time to perform its wifi duties, that includes not calling C-standard library functions but os_ functions and not staying in loops lasting more than (I don't remember correctly) let's say a millisecond or two.
There are also many non-official ones and people using old and buggy SDKs too.
All libraries in the non-OS (bare metal) SDK, including the TCP/IP stack, lwIP, have been modified to fit the chip scenario. You can't expect to drop in a standard library and have it working flawlessly. That includes Paho. Besides that, it carries its own MQTT library, which I don't know how compliant and behaved it is. It is not Paho's fault, it is a working environment constraint not being honored by the developer.

[icraggs]

I'll see if I can get to add some documentation for this package.