Real-time IP Messaging is the technology that lets people and devices online to be synchronized in real time, anywhere in the world. Real-time IP Messaging powers chat, geolocation tracing, smart homes, financial data, multiplayer games, and a lot more.
While the underlying technology is critically important to building today’s most popular apps, the terminology around real-time messaging (AKA IP Messaging) can be confusing. This guide will help you sort it all out and consider important questions like:
Early attempts to build low-latency IP Messaging used a technique called polling. This approach required each device (phone, browser, sensor, etc.) to “ping” servers on a predetermined interval like once every 5 seconds to check for any new updates.
This “polling” model was effective at small scale, but developers quickly found it cost prohibitive – in terms of bandwidth, infrastructure, and development – to scale. Not to mention, it was incredibly taxing on mobile devices’ batteries.
While a surprising number of “real-time” messaging features still use a request/response model, more modern IP Messaging designs maintain an always-on connection to each device (sort of like a dialtone). This always-on connection allows data to be “pushed” to devices automatically, with no need to continually ask a server for updates.
This approach dramatically reduces the cost, complexity, and security risk of a real-time messaging solution at scale. It also significantly reduces roundtrip message latency by cutting down on the “chattiness” of the communication. As a rule of thumb, messages should traverse the messaging service anywhere globally in under ¼ of a second.
Why? Because in order for a human to perceive an interaction as “real-time”, it must happen within that magic ¼ second timeframe. If latency extends much beyond that timeframe, users will perceive a poor, laggy experience.
A key tenet of a true IP Messaging solution is that it cannot be device specific. A usable IP Messaging solution needs to work on just about any device that can make a TCP/IP connection to the Internet.
It’s also important for a real-time messaging network to be agnostic to the data format. Whether the data is plain text, JSON, XML, or a proprietary format, IP Messaging systems work best when they can support any format.
Real-time messaging services (like PubNub) and open-source projects (like Socket.io) use the powerful Publish/Subscribe messaging pattern to structure communication between the devices at points A and B.
Publish/subscribe enables IP messaging solutions to deliver low-latency communication and eliminate the need to constantly poll servers.
The device listening for a message.
This could also be anything with an IP address.
Pub/Sub messaging uses channels – sometimes called “Topics” – to get messages to the right devices.
A subscribing device subscribes to a channel and a publishing device publishes into a channel. When a message is sent to a channel, the subscribing devices receive it automatically.
In many older Pub/Sub models, channels were “heavyweight”, and had to be configured beforehand. So only a small number of channels were feasible.
For Internet-scale use cases, each user may need a channel, so millions of channels are often required. That’s why modern IP Messaging systems are designed to support unlimited channels created on the fly without prior declaration.
Real-time applications have quickly become mission-critical for their users. Imagine trying to track an approaching Uber driver with a 30-second lag.
No, thanks - we'll open our Lyft app instead.
As with any mission-critical system, developers need to design for a consistent experience: reliability in the face of data center failures, and scalability to any number of devices, everywhere in the world.
Therefore, IP messaging solutions should operate with minimal overhead when passing messages through the service. Passing a message through PubNub, for instance, often adds as little as 4 milliseconds of latency to the end-to-end transaction.
The real performance bottleneck in an end-user's latency experience then becomes the proximity to the service's nearest Point of Presence (POP). With PubNub, all data that is published replicates automatically to multiple points of presence around the globe, meaning that all your users get a consistent, real-time experience - no matter where in the world they are.
Reliability is also a challenge. If all the real-time data streams are flowing through a single data center, a single regional outage can bring a real-time application to its knees. Even a backup region may not help, since diverting devices to the backup region can mean data loss and long recovery times.
Between the latency and reliability challenges of IP messaging, architects have started to think about building IP messaging services as a network instead of a cloud service or platform.
Rather than running IP Messaging servers in a single “hot” region, IP Messages are replicated as they are published across many global Points of Presence (POPs) simultaneously.
Devices automatically connect to the nearest POP, and if a POP fails, devices gracefully re-route to the next-closest POP. Any data they missed during the disconnection is cached and delivered instantly when they reconnect.
This “Network Paradigm” delivers an IP Messaging design that operates like a Content Delivery Network (CDN), except designed for 2-way data streams (i.e. “data in motion”) instead of cached data (i.e. “data at rest”).
Since IP messaging covers a large number of use cases across many different industries, the design patterns, system architecture, and features used will vary from customer to customer.
Chat apps powered by IP messaging will differ somewhat from apps powering a connected home device, even though they both use the same underlying IP Messaging technology.
No matter your use case, a few key capabilities you should look for in any real-time IP messaging service are:
Any IP messaging technology or service should be able to get a message from point A to point B in under ¼ second, period.
But don’t take our word for it – try it yourself and monitor the results!
Performance and reliability is at the center of the user experience; look for multiple redundant points of presence and very high SLAs (but don’t be fooled by 100% uptime guarantees).
It’s also a good idea to take a look at the vendor’s status page to get a sense of recent service outages.
The simple volume of messages exchanged across your IP messaging solution should make it clear that powerful and trustworthy security features are a must-have.
Even if you aren’t exchanging Personally Identifiable Information (PII) over the service, at the very least it makes sense to be protected to ensure a consistent user experience and a loyal, trustful user base.
Your app is going to grow, so it’s wise to plan for that growth from the beginning.
It can be a massive waste of time to re-engineer a solution when growth happens, because that’s the exact time you should be focused on improving the app, not stressing out over the back-end infrastructure. Look for a vendor with a proven ability to scale with your aspirations – and pricing that makes sense for both today and tomorrow.
So far so good! Now that we’ve covered the essential features of an IP messaging solution, let’s go over some more advanced features.
Unless you’re building the simplest of real-time apps, you are going to benefit from at least a few of these advanced real-time IP messaging features. They save you time, simplify development, and abstract away common real-time problems.
Developers can simplify their architecture through introducing namespaces to channels or topics via “wildcard” subscription, remote management of client subscription logic, and persisted subscription lists.
Need to subscribe to every device in San Francisco or California? Save yourself from providing a lengthy delimited list of every channel by subscribing to ‘california.*’ or ‘california.sanFrancisco.*’. Also, don’t leave it in the hands of your clients to control which channels they are subscribed to!
Your backend server or other authorized entity should be able to remotely manage what channels any device is subscribed to. Is there a common set of channels every user of a particular group needs to subscribe to?
Perhaps every member of a marketing project needs to subscribe to the status feeds of the project stakeholders. Simply add each stakeholder’s status-feed channel to a common list, let’s call it ‘marketing-project-302-feed’, and have every member subscribe to the list.
At some point in your development, you will almost certainly want to do something with your messages in between points A and B. It may be transforming a message’s content, setting up if/then rules to govern routing behavior, or filtering messages along some parameters.
An IP Messaging Network should be able to allow you to add logic into the data flow without noticeably increasing latency – otherwise you’ll need to introduce another network hop by running this logic on your own servers.
Besides the performance hit, you will find that routing all messages back through your servers incurs a cost, scalability, and operations challenge – ultimately pulling resources away from what matters most: your core platform.
It’s much better to have this relatively simple business logic run within the walls of your real-time messaging service.
PubNub BLOCKS extends the power of the PubNub Data Stream Network by making the network programmable. It allows developers to easily deploy app logic on the PubNub network to modify messages without the need to manage their own infrastructure. Instead of simply transferring messages between publishers and subscribers, the network executes customer-specific code to act on those messages. That code might run geofencing logic, filter messages to the right subscriber based on some conditional logic, or translate a message from French to German by calling a third-party API like IBM Watson. Best of all, PubNub delivers a broad catalog of open-source blocks for developers to use and customize, further reducing the time it takes to build their features.
Check it out at www.pubnub.com/products/functions/
Because real-time messaging usually runs across multiple device types (mobile, server, browser, or embedded), system-wide knowledge of individual device states is incredibly important. Knowing “presence” – whether a device is online or offline – can be used just as easily for a user status in a chat room as it can to know whether a home automation device is functioning properly.
Other device states might also be useful to monitor, such as the inventory stock of a product, latest bid price for an auction, position of cursors in a collaborative document, location of a package being delivered, sensor readings from a phone’s gyroscope, or the temperature of a thermostat.
Monitoring these is conceptually similar to monitoring online/offline states, and any real-time messaging service should give developers the ability to monitor both Presence and customizable state information.
With the rapid pace of technology in the modern world, it should go without saying that the services we use as developers should be flexible enough to accommodate both what we’re trying to accomplish today and a solid set of future use cases.
IP messaging services designed to work in one way and one way only might work at the moment, but we’ll be searching for yet another bolt-on technology when our needs change a few months from now.
A better option is to think ahead and account for both known and unknown future projects, then pick a solution that will maximize your flexibility and adaptability.
Put these down in the “nice to have” column, but the quality of open source projects that an IP messaging service provides can demonstrate their commitment and ability to help out customers in more ways than just their core service.
Throughout our history as a company (dating back to 2009), we’ve seen thousands of companies, both small and large, be successful using the PubNub network as their IP messaging solution, and more than a few - hundreds, actually - have migrated to PubNub from homegrown solutions.
Rather than spell out all the technical details of why it almost never makes sense to build your own solution for IP messaging anymore, we put together a list of 20 questions to ask yourself before taking on a home-grown project that we’ve seen spiral wildly out of control more times than we’d like.
As is often the case with new waves of technology, real-time messaging is currently undergoing a broad conversation on standardization and codification of communication protocols.
While it might be a fun academic exercise to learn about and debate the ins and outs of every protocol available, it doesn’t help us build amazing products that users love.
Here’s what we’re here to tell you after doing this stuff for over 7 years: the protocol doesn’t really matter.
It shouldn’t matter to developers what protocol(s) a real-time messaging service uses under the hood as long as it: