Message Publish

The foundation of all our PubNub offerings is the ability to send a message that will be delivered anywhere in less than 30ms. Below, we will walk you step by step through different ways of sending a message.

icon

Need help. Flat tire. Kansas City.


A PubNub Message can contain any kind of serializable data, like objects, numbers and UTF-8 encoded strings. Its format may be plain text, a URL-encoded object, or most commonly, JavaScript Object Notation (JSON). The max size of a message is 32 Kibibytes (KiB). You can check the size of your message payload using our message size calculator.

Receiving messages

We hope you already know you need to add a listener to receive and handle incoming messages, signals, and events.

If you're new to PubNub, make sure to check out how to set up your account as well.

Send messages​

The primary means for sending messages is using the Publish API. You may only send a message to one channel at a time. If you want to publish to multiple channels, you must create a channel group.

PubNub's network supports sending unlimited publishes without waiting for response on the same TCP socket connection.

pubnub.publish(
  {
    channel: "my_channel",
    message: {"text": "Hello World!"}
  },
  function(status, response) {
    console.log(status);
    console.log(response);
  }
);

When you publish a message to a channel, you're asking PubNub Platform to deliver that message to everyone who is subscribed to that channel.

A PubNub message may be sent as plain text, URL-encoded object, and most commonly, JSON. For more information, refer to message types.

As you can see, in the above publish method we specify the channel on which to send the message, the message content we want to send and a way to capture the server response, which in most languages is an asynchronous callback. A successful response looks like this:

[1,"Sent","14375189629170609"]

The response has three parts:

  1. success flag: 1 = success, 0 = failed
  2. response message: Sent or Failed
  3. publish timetoken: exact timestamp of the message which is a 17 digit value to the nearest 10th nanosecond (can be converted to UNIX epoch by dividing by 10000).

The publish timetoken can be used later to retrieve (or augment) that message using Message Persistence.

HTTP Streaming and pipelining

For more information about streaming and pipelining, refer to this gist.

Send announcements to all users​

You can send announcements to all users, or a limited set of users, in your application by using a channel to which the announcer has read/write access, and to which all other users have read-only access.

Once you have the channel set up, you can display any messages sent on the channel as announcements. Users with read access can subscribe to the channel to receive announcements, but can't send messages on the same channel.

pubnub.publish({
  message: {
    type: 'announcement',
    text: 'Hello, this is an announcement'
  },
  channel: 'ch-1',
}, (status, response) => {
  // handle status, response
});

Message specifications​

The message property can contain any JSON serializable data (JSON isn't required, just recommended and is typical in most use cases), including: Objects, Arrays, Integers and Strings. String content can include any single-byte or multi-byte UTF-8 character.

JSON Serialization

There is no need to serialize your JSON object when sending messages via PubNub Platform. PubNub SDKs does that for you.

Delivery​

Though we provide as much information about the delivery as possible, PubNub is not a guaranteed message delivery service, as there is no way to guarantee that the network connection between the subscribers and PubNub has not been interrupted.

For example, while the Sent status code returned to the message publisher does not guarantee that the message is delivered, it does mean that the PubNub Network has received the message and has already sent it along to all currently connected subscribers.

We are constantly adding features which improve deliverability but the quality of service of the last mile of connectivity is not within PubNub's control.

Subscribers with troubled connections or that were offline by intention can still retrieve missed messages. For more information about status codes, and retrieving missed and historical messages, refer to Connection Management and Message Persistence.

Order​

As long as the publisher sends messages at a slower rate than the consumer can receive them, you can assume with high confidence that messages will be kept in order.

However, PubNub doesn't guarantee that messages are stored or sent in the exact same order in which they're published. If your application requires messages to be processed in the same order they were published, we recommend adding a sequence field to the message payload and use it to order messages by.

Message size limit​

The maximum number of characters per message is 32 KiB. The maximum message size is based on the final escaped character count, including the channel name.

If the message you publish exceeds the configured size, you'll receive the following message:

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

If you expect your messages will be pushing the size limit, check the size of your message in our payload size calculator.

Payload Size: 0.00 KiB (0 bytes)

For more information on calculating payload size within your application, refer to our knowledge base.

Receive messages​

To receive a message, your client should implement a message listener and subscribe to a channel in which the message is being published.

Send signals​

Signals are ideal for high-volume, low-cost use cases. They're intended for sending small bits of data where the last sent data is the only important piece of information. For example, chat typing indicators, live GPS location updates, and sensor updates from IoT devices.

icon

Sounds like a solution: How we used PubNub to jazz up in-store audio experiences

Messages vs signals​

Signals are similar to regular messages, with the following exceptions:

FeatureSignalsMessages
Payload size
Limited to 64 bytes (64B)
Up to 32 kilobytes (32KB)
Cost efficiency
Cost less than standard messages
Generally more expensive than signals
Persistence
Cannot be saved in Message Persistence (past signals cannot be accessed)
Can be saved and accessed through Message Persistence
Push Notifications
Cannot trigger Mobile Push Notifications
Can trigger Mobile Push Notifications
Use case suitability
Best for non-critical data streams, like geolocation updates
Suitable for critical and non-critical use cases
Metadata support
Do not support metadata
Support metadata
Channel separation

Signals and messages should be sent on separate channels to improve connection recovery behaviour.

Sending a signal is similar to publishing a message:

let gps = ["35.9296","-78.9482"];

pubnub.signal(
  {
    channel: "locations.route1",
    message: gps
  },
  function(status, response) {
    console.log(status, response);
  }
);

The Signal response may not be as important to your application and could be omitted, but is dependent on your use case.

Receive signals​

To receive a signal, your client should implement a signal listener and subscribe to a channel in which the signal is being sent.

Publish with message filters​

Message Filters allow a client to send messages to only those clients that satisfy the conditions of the filter. To use Message Filters, it's important to include filtering conditions when publishing a new message. The meta parameter isn't a part of the message data and allows subscribing clients to filter based on the included information.

Filtering origin

The filtering takes place server-side.

To include metadata that can be used for message filters, prepare the data and pass it to the publishing function.

User ID / UUID

User ID is also referred to as UUID/uuid in some APIs and server responses but holds the value of the userId parameter you set during initialization.

pubnub.publish(
  {
    channel: "chats.room1",
    message: "Hello to everyone (except me)",
    meta: {
      userId: pubnub.getUserId()
    }
  },
  function(status, response) {
    console.log(status, response);
  }
);

In the above example, the metadata will allow the client to filter messages based on the User ID of the sender.

To learn more about the filter options, refer to the table in the Message Filters section.

Last updated on
Related Resources
On this page