Publish/Subscribe API for FreeRTOS SDK (legacy)
New SDK available
The FreeRTOS SDK is built on C-Core (legacy), which is still supported. If you are starting a new project, use the new C SDK.
Publish
The pubnub_publish() function is used to send a message to all subscribers of a channel. To publish a message you must first specify a valid publish_key at initialization. A successfully published message is replicated across the PubNub Real-Time Network and sent simultaneously to all subscribed clients on a channel.
Messages in transit can be secured from potential eavesdroppers with SSL/TLS by setting ssl to true during initialization.
Publish anytime
It's not required to be subscribed to a channel in order to publish to that channel.
Message data
The message argument can contain any JSON serializable data, including: Objects, Arrays, Ints and Strings. data should not contain special FreeRTOS classes or functions as these will not serialize. String content can include any single-byte or multi-byte UTF-8 character.
JSON serialize
It is important to note that you should JSON serialize when sending signals/messages via PUBNUB.
Message size
The maximum number of characters per message is 32 KiB by default. The maximum message size is based on the final escaped character count, including the channel name. An ideal message size is under 1800 bytes which allows a message to be compressed and sent using single IP datagram (1.5 KiB) providing optimal network performance.
If the message you publish exceeds the configured size, you will receive the following message:
Message too large error
1["PUBLISHED",[0,"Message Too Large","13524237335750949"]]
To calculate payload size, use the message size calculator.
Need larger messages?
PubNub supports payloads larger than the standard limit, but raising it requires verifying compatibility with your use case.
Talk to our team to discuss increasing the message size limit for your use case.
Message publish rate
Messages can be published as fast as bandwidth conditions will allow. There is a soft limit based on max throughput since messages will be discarded if the subscriber can't keep pace with the publisher.
For example, if 200 messages are published simultaneously before a subscriber has had a chance to receive any messages, the subscriber may not receive the first 100 messages because the message queue has a limit of only 100 messages stored in memory.
Publishing to multiple channels
It is not possible to publish a message to multiple channels simultaneously. The message must be published to one channel at a time.
Publishing messages reliably
There are some best practices to ensure messages are delivered when publishing to a channel:
- Publish to any given channel in a serial manner (not concurrently).
- Check that the return code is success (for example,
[1,"Sent","136074940..."]) - Publish the next message only after receiving a success return code.
- If a failure code is returned (
[0,"blah","<timetoken>"]), retry the publish. - Avoid exceeding the in-memory queue's capacity of 100 messages. An overflow situation (aka missed messages) can occur if slow subscribers fail to keep up with the publish pace in a given period of time.
- Throttle publish bursts in accordance with your app's latency needs, for example, Publish no faster than 5 msgs per second to any one channel.
Publishing compressed messages
Message compression lets you send the message payload as the compressed body of an HTTP POST call.
Every PubNub SDK supports sending messages using the publish() call in one or more of the following ways:
- Uncompressed, using HTTP GET (message sent in the URI)
- Uncompressed, using HTTP POST (message sent in the body)
- Compressed, using HTTP POST (compressed message sent in the body)
This section outlines what compressing a message means, and how to use compressed messages to your advantage.
Compressed messages support
Currently, the C and Objective-C SDKs support compressed messages.
Message compression can be helpful if you want to send data exceeding the default 32 KiB message size limit, or use bandwidth more efficiently. Compressing messages is useful for scenarios that include high channel occupancy and quick exchange of information like ride hailing apps or multiplayer games.
Compression trade-offs
-
Small messages can expand - Compressed messages generally have a smaller size, and can be delivered faster, but only if the original message is over 1 KiB. If you compress a signal (whose size is limited to 64 bytes), the compressed payload exceeds the signal's initial uncompressed size.
-
CPU overhead can increase - While a smaller payload size is an advantage, working with compressed messages uses more CPU time than working with uncompressed messages. CPU time is required to compress the message on the sending client, and again to decompress the message on the receiving client. Efficient resource management is especially important on mobile devices, where increased usage affects battery life. Carefully consider the balance of lower bandwidth and higher speed versus any increased CPU usage.
-
Using Compression - Compression methods and support vary between SDKs. If the receiving SDK doesn't support the sender's compression method, or even if it doesn't support compression at all, the PubNub server automatically changes the compressed message's format so that it is understandable to the recipient. No action is necessary from you.
Messages are not compressed by default; you must always explicitly specify that you want to use message compression. Refer to the code below for an example of sending a compressed message.
1struct pubnub_publish_options opt = pubnub_publish_defopts();
2opt.method = pubnubSendViaPOSTwithGZIP;
3pbresult = pubnub_publish_ex(pn, "channel_name", "{\"message\":\"This message will be compressed\"}", opt);
4}]
Method(s)
To Publish a message you can use the following method(s) in the FreeRTOS SDK:
1enum pubnub_res pubnub_publish (pubnub_t *p, const char *channel, const char *message)
1enum pubnub_res pubnub_publishv2 (pubnub_t *p, const char *channel, const char *message, bool store_in_history, bool eat_after_reading)
prequired#- Pointer to Pubnub Client Context
channelrequired#- Pointer to
stringwith thechannelID (or comma-delimited list ofchannelIDs) topublishto. messagerequired#- Pointer to string containing
messageto publish in JSON format. store_in_historyrequired#- If false,
messagewill not be stored inhistoryof thechannel eat_after_readingrequired#- If true,
messagewill not be stored for delayed or repeated retrieval or display