---
source_url: https://www.pubnub.com/docs/sdks/mbed/api-reference/publish-and-subscribe
title: Publish/Subscribe API for Mbed SDK
updated_at: 2026-06-16T12:51:37.766Z
sdk_name: PubNub Mbed SDK
---

> Documentation Index
> For a curated overview of PubNub documentation, see: https://www.pubnub.com/docs/llms.txt
> For the full list of all documentation pages, see: https://www.pubnub.com/docs/llms-full.txt


# Publish/Subscribe API for Mbed SDK

PubNub Mbed 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 mbed classes or functions as these will not serialize. String content can include any single-byte or multi-byte UTF-8 character.

:::warning 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

```c
["PUBLISHED",[0,"Message Too Large","13524237335750949"]]
```

For further details, check [Calculating Message Payload Size Before Publish](https://support.pubnub.com/hc/en-us/articles/360051495932-Calculating-Message-Payload-Size-Before-Publish).

:::tip Need larger messages?
Our platform is optimized for payloads up to 32 KiB. PubNub supports larger messages, but increasing the limit requires a verification of compatibility with your use case.
Talk to [our team](https://www.pubnub.com/company/contact-sales/) 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.

:::note 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.

```c
struct pubnub_publish_options opt = pubnub_publish_defopts();
opt.method = pubnubSendViaPOSTwithGZIP;
pbresult = pubnub_publish_ex(pn, "channel_name", "{\"message\":\"This message will be compressed\"}", opt);
}]
```

### Method(s)

To `Publish a message` you can use the following method(s) in the mbed SDK:

```c
enum pubnub_res pubnub_publish (pubnub_t *p, const char *channel, const char *message)
```

| Parameter | Type | Required | Default | Description |
| --- | --- | --- | --- | --- |
| p | pubnub_t* | Yes |  | Pointer to PubNub context. Can't be NULL |
| channel | const | Yes |  | Pointer to `string` with the `channel` ID (or comma-delimited list of `channel` IDs) to publish to. |
| message | const | Yes |  | Pointer to `string` containing `message` to `publish` in JSON format. |

```c
enum pubnub_res pubnub_publishv2 (pubnub_t *p, const char *channel, const char *message, bool store_in_history, bool eat_after_reading)
```

| Parameter | Description |
| --- | --- |
| `p` *Type: pubnub_t* | Pointer to Pubnub Client Context |
| `channel` *Type: const char* | Pointer to `string` with the `channel` ID (or comma-delimited list of `channel` IDs) to `publish` to. |
| `message` *Type: const char* | Pointer to string containing `message` to publish in JSON format. |
| `store_in_history` *Type: bool | If false, `message` will not be stored in `history` of the `channel` ID |
| `eat_after_reading` *Type: const char* | If true, `message` will not be stored for delayed or repeated retrieval or display |

### Sample code

#### Publish a message to a channel

```c
pubnub_publish(
    ctx,
    "my_channel",
    "\"message\""
);
pbresult = pubnub_await(ctx);
if (PNR_OK == pbresult) {
    /* Published successfully */
}
```

:::note Subscribe to the channel
Before running the above publish example, either using the [Debug Console](https://www.pubnub.com/docs/console/) or in a separate script running in a separate terminal window, [subscribe to the same channel](#subscribe) that is being published to.
:::

### Rest response from server

The function returns the following formatted response:

```json
[1, "Sent", "13769558699541401"]
```

### Other examples

#### Publish a JSON serialized message

```c
pubnub_t *ctx = pubnub_alloc();
if (NULL == ctx) {
    puts("Couldn't allocate a Pubnub context");
    return -1;
}
pubnub_init(ctx, "demo", "demo");
pubnub_publish(ctx, "hello_world", "{\"msg\": \"Hello from Pubnub C-core docs!\"}");
pbresult = pubnub_await(ctx);
if (pbresult != PNR_OK) {
    printf("Failed to publish, error %d\n", pbresult);
    pubnub_free(ctx);
    return -1;
}
```

#### Publish with cipher key

```c
res = pubnub_publish_encrypted(pbp, chan, "\"Hello world from crypto sync!\"", cipher_key);
if (res != PNR_STARTED) {
    printf("pubnub_publish() returned unexpected: %d\n", res);
    pubnub_free(pbp);
    return -1;
}
```

#### Publish with cipher key using pubnub_publish_ex

Using this method you can reuse the `cipherKey` from the options.

```c
struct pubnub_publish_options opt = pubnub_publish_defopts();
opt.cipher_key = my_cipher_key;
pbresult = pubnub_publish_ex(pn, "my_channel", "42", opt);
```

## Subscribe

This function causes the client to create an open TCP socket to the PubNub Real-Time Network and begin listening for messages on a specified `channel` ID. To subscribe to a `channel` ID the client must send the appropriate `subscribe_key` at initialization. By default a newly subscribed client will only receive messages published to the channel after the `pubnub_subscribe()` call completes.

:::note Retrieving messages
Typically, you will want two separate contexts for publish and subscribe. When changing the active set of subscribed channels, first call `pubnub_leave()` on the old set.
The `pubnub_subscribe()` interface is essentially a transaction to start listening on the channel for arrival of next message. This has to be followed by `pubnub_get()` call to retrieve the actual message, once the subscribe transaction completes successfully. This needs to be performed every time it is desired to retrieve a message from the channel.
:::

:::warning Unsubscribing from all channels
**Unsubscribing** from all channels, and then **subscribing** to a new channel Y is not the same as subscribing to channel Y and then unsubscribing from the previously-subscribed channel(s). Unsubscribing from all channels resets the last-received `timetoken` and thus, there could be some gaps in the subscription that may lead to message loss.
:::

### Method(s)

To `Subscribe to a channel` you can use the following method(s) in the mbed SDK:

```c
enum pubnub_res pubnub_subscribe (pubnub_t *p, const char *channel, const char *channel_group)
```

| Parameter | Description |
| --- | --- |
| `p` *Type: pubnub_t* | Pointer to PubNub client context. Can't be NULL. |
| `channel`Type: const char* | The `string` with the `channel` ID (or comma-delimited list of `channel` IDs) to subscribe to. |
| `channel_group`Type: const char* | The `string` with the channel `group` name (or comma-delimited list of channel `group` names) to subscribe to. |

### Sample code

Subscribe to a channel:

```c
pubnub_subscribe(
    ctx,
    "my_channel",
    NULL
);
pbresult = pubnub_await(ctx);
if (PNR_OK == pbresult) {
    char const *message = pubnub_get(ctx);
    while (message != NULL) {
        message = pubnub_get(ctx);
    }
}
```

### Rest response from server

The output below demonstrates the response format to a successful call:

```json
[[], "Time Token"]
```

### Other examples

#### Subscribing to multiple channels

It's possible to subscribe to more than one channel using the [Multiplexing](https://www.pubnub.com/docs/general/channels/subscribe#channel-multiplexing) feature. The example shows how to do that using an array to specify the channel names.

:::note Alternative subscription methods
You can also use [Wildcard Subscribe](https://www.pubnub.com/docs/general/channels/subscribe#wildcard-subscribe) and [Channel Groups](https://www.pubnub.com/docs/general/channels/subscribe#channel-groups) to subscribe to multiple channels at a time. To use these features, the *Stream Controller* add-on must be enabled on your keyset in the [Admin Portal](https://admin.pubnub.com).
:::

```c
pubnub_t *ctx = pubnub_alloc();
if (NULL == ctx) {
    puts("Couldn't allocate a Pubnub context");
    return -1;
}
pubnub_init(ctx, "demo", "demo");
pubnub_subscribe(ctx, "hello_world1,hello_world2,hello_world3", NULL);
pbresult = pubnub_await(ctx);
if (pbresult != PNR_OK) {
    printf("Failed to subscribe, error %d\n", pbresult);
    pubnub_free(ctx);
    return -1;
}
else {
    char const *msg = pubnub_get(ctx);
    char const *channel = pubnub_get_channel(ctx);
    while (msg != NULL) {
        printf("Got message: %s on channel %s\n", msg, (NULL == channel) ? "" : channel );
        msg = pubnub_get(ctx);
        channel = pubnub_get_channel(ctx);
    }
}
pubnub_free(ctx);
```

#### Subscribing to a Presence channel

:::warning Requires Presence
This method requires that the Presence add-on is [enabled](https://support.pubnub.com/hc/en-us/articles/360051974791-How-do-I-enable-add-on-features-for-my-keys-) for your key in the [Admin Portal](https://admin.pubnub.com/). For information on how to receive presence events and what those events are, refer to [Presence Events](https://www.pubnub.com/docs/general/presence/presence-events#subscribe-to-presence-channel).
:::

For any given channel there is an associated Presence channel. You can subscribe directly to the channel by appending `-pnpres` to the channel name. For example the channel named `my_channel` would have the presence channel named `my_channel-pnpres`.

```c
// Sync

char *presence_channel = malloc(strlen(channel) + strlen(PUBNUB_PRESENCE_SUFFIX) + 1);
strcpy(presence_channel, channel);
strcat(presence_channel, PUBNUB_PRESENCE_SUFFIX);
pubnub_subscribe(
    ctx,
    presence_channel,
    NULL
);
pbresult = pubnub_await(ctx);
if (PNR_OK == pbresult) {
    char const *presence_event = pubnub_get(ctx);
    while (presnce_event != NULL) {
        presence_event = pubnub_get(ctx);
    }
}
```

#### Sample Responses

#### Join event

```json
{
    "action": "join",
    "timestamp": 1345546797,
    "uuid": "175c2c67-b2a9-470d-8f4b-1db94f90e39e",
    "occupancy": 2
}
```

#### Leave event

```json
{
    "action" : "leave",
    "timestamp" : 1345549797,
    "uuid" : "175c2c67-b2a9-470d-8f4b-1db94f90e39e",
    "occupancy" : 1
}
```

#### Timeout event

```json
{
    "action": "timeout",
    "timestamp": 1345549797,
    "uuid": "76c2c571-9a2b-d074-b4f8-e93e09f49bd",
    "occupancy": 0
}
```

#### State change event

```json
{
    "action": "state-change",
    "uuid": "76c2c571-9a2b-d074-b4f8-e93e09f49bd",
    "timestamp": 1345549797,
    "data": {
        "isTyping": true
    }
}
```

#### Interval event

```json
{
    "action":"interval",
    "timestamp":1474396578,
    "occupancy":2
}
```

When a channel is in interval mode with `presence_deltas` `pnconfig` flag enabled, the interval message may also include the following fields which contain an array of changed UUIDs since the last interval message.

* joined
* left
* timedout

For example, this interval message indicates there were 2 new UUIDs that joined and 1 timed out UUID since the last interval:

```json
{
    "action" : "interval",
    "occupancy" : <# users in channel>,
    "timestamp" : <unix timestamp>,
    "joined" : ["uuid2", "uuid3"],
    "timedout" : ["uuid1"]
}
```

If the full interval message is greater than `30 KB` (since the max publish payload is `∼32 KiB`), none of the extra fields will be present. Instead there will be a `here_now_refresh` boolean field set to `true`. This indicates to the user that they should do a `hereNow` request to get the complete list of users present in the channel.

```json
{
    "action" : "interval",
    "occupancy" : <# users in channel>,
    "timestamp" : <unix timestamp>,
    "here_now_refresh" : true
}
```

#### Subscribe to a channel group

:::note Requires Stream Controller add-on
This method requires that the *Stream Controller* add-on is enabled for your key in the [Admin Portal](https://admin.pubnub.com/). Read the [support page](https://support.pubnub.com/hc/en-us/articles/360051974791-How-do-I-enable-add-on-features-for-my-keys-) on enabling add-on features on your keys.
:::

```c
enum pubnub_res res;

for (;;) {
  res = pubnub_subscribe(pn, NULL,  channel_group);
  read_response(pn, res);
}
```

#### Subscribe to the Presence channel of a channel group

:::note Requires Stream Controller and Presence add-ons
This method requires both the *Stream Controller* and *Presence* add-ons are enabled for your key in the [Admin Portal](https://admin.pubnub.com/). Read the [support page](https://support.pubnub.com/hc/en-us/articles/360051974791-How-do-I-enable-add-on-features-for-my-keys-) on enabling add-on features on your keys.
:::

```c
enum pubnub_res res;

for (;;) {
  res = pubnub_subscribe(pn, NULL, "family-pnpres");
  read_response(pn, res);
}
```

#### Using cipherKey with subscribe

For subscribe, you don't use the cipher key at subscribe, but, when you get the received messages after the subscribe transaction has finished:

```c
char msg[MAX_MSG_LEN];
pbresult = pubnub_get_decrypted(pn, my_cipher_key, s, sizeof s);
if (PNR_OK == pbresult) {
    /* Use the message in `msg` */
}
```

or, for a different usability/safety trade-off:

```c
pubnub_bymebl_t msg = pubnub_get_decrypted_alloc(pn, my_cipher_key);
if (msg.ptr != NULL) {
    /* use the message in `msg.ptr` */
    free(msg.ptr);
}
```

## Unsubscribe

To `unsubscribe`, you need to cancel a subscribe transaction.

* If you configured SDK to be thread-safe, you can cancel at any time, but, the cancelling may actually fail - that is, your thread may wait for another thread to finish working with the context, and by the time your cancel request gets processed, the transaction may finish.
* If you configured SDK to not be thread-safe, the only safe way to do it is to use the sync interface and: Set the context to use non-blocking I/O., Wait for the outcome in a loop, checking for pubnub_last_result() - rather than calling pubnub_await()., If a condition occurs that prompts you to unsubscribe, call pubnub_cancel()., Wait for the cancellation to finish (here you can call pubnub_await(), unless you want to do other stuff while you wait).

:::warning Unsubscribing from all channels
**Unsubscribing** from all channels, and then **subscribing** to a new channel Y is not the same as subscribing to channel Y and then unsubscribing from the previously-subscribed channel(s). Unsubscribing from all channels resets the last-received `timetoken` and thus, there could be some gaps in the subscription that may lead to message loss.
:::

### Method(s)

To `Unsubscribe from a channel` you can use the following method(s) in the mbed SDK:

| Parameter | Description |
| --- | --- |
| `p` *Type: pubnub_t* | Pointer to Pubnub Client Context. |

### Sample code

Unsubscribe from a channel:

```c
pbresult = pubnub_subscribe(
    ctx,
    "my_channel",
     NULL
);

/* If we don't set non-blocking I/O, we can't get out of a blocked read */
pubnub_set_non_blocking_io(ctx);

/* Can't use pubnub_await() here, it will block */
while (PNR_STARTED == pbresult) {
    pbresult = pubnub_last_result(ctx);
    /* Somehow decide we want to quit / unsubscribe */
    if (should_stop()) {
        pubnub_cancel(ctx);
        /* If we don't have anything else to do, it's OK to await now,
        but you could again have a loop "against" pubnub_last_result()
        */
        pbresult = pubnub_await(ctx);
        break;
    }
}
if (PNR_CANCELLED == pbresult) {
    puts("Subscribe cancelled - unsubscribed!");
}
```

### Rest response from server

The output below demonstrates the response to a successful call:

```json
{
    "action" : "leave"
}
```

### Other examples

#### Unsubscribing from a channel group

```c
pbresult = pubnub_subscribe(ctx, NULL, "my_channel_group");
/* If we don't set non-blocking I/O, we can't get out of a blocked read */
pubnub_set_non_blocking_io(ctx);
/* Can't use pubnub_await() here, it will block */
while (PNR_STARTED == pbresult) {
     pbresult = pubnub_last_result(ctx);
     /* Somehow decide we want to quit / unsubscribe */
     if (should_stop()) {
         pubnub_cancel(ctx);
         /* If we don't have anything else to do, it's OK to await now,
          * but you could again have a loop "against" pubnub_last_result()
          */
         pbresult = pubnub_await(ctx);
         break;
     }
}
if (PNR_CANCELLED == pbresult) {
    puts("Subscribe cancelled - unsubscribed!");
}
```