IP Messaging:
The Ultimate Guide
What is Realtime IP Messaging?
Realtime IP Messaging is the technology that lets people and devices online to be synchronized in realtime, anywhere in the world. Realtime 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 realtime messaging (AKA IP Messaging) can be confusing. This guide will help you sort it all out and consider important questions like:
What makes IP Messaging unique?
What features should I look for in an IP Messaging solution?
What we typically mean when we say "IP Messaging" or "realtime messaging" is using the internet to quickly push a small message to one or more devices - smartphones, browsers, and so on. These messages can be used for human communication (like online chat), or machine-to-machine control.
But we've been sending messages over the internet for a couple decades now, so what's special about IP messaging?
What Makes IP Messaging Unique?
Low Latency IP Messaging
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 “realtime” 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 realtime 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 “realtime”, it must happen within that magic ¼ second timeframe. If latency extends much beyond that timeframe, users will perceive a poor, laggy experience.
Cross-Device Compatibility
The nature of data streams almost always require patterns that involve servers, browsers, mobile devices and other kinds of devices like Arduino and Raspberry Pi boards.
Read: Getting Started with IoT in Realtime
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 realtime 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.
Publish/Subscribe Messaging
Realtime 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.
Geographic Dispersion and Latency
Realtime 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, realtime experience - no matter where in the world they are.
IP Messaging Reliability
Reliability is also a challenge. If all the realtime data streams are flowing through a single data center, a single regional outage can bring a realtime 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”).
What are Realtime
IP Messaging Features?
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 realtime 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.
- The ability to easily grant and revoke access to channels
- Time-based expiration of user access
- End-to-end encryption (typically TLS endpoint encryption passing over to AES full-message encryption)
- Self-ownership of private keys - IP messaging services should never hold your private keys
- Integration to multiple authentication services
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.
Advanced Realtime
IP Messaging Features
Unless you’re building the simplest of realtime apps, you are going to benefit from at least a few of these advanced realtime IP messaging features. They save you time, simplify development, and abstract away common realtime 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 realtime 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 realtime 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 realtime 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.
Also check out the quality and depth of technical blogs, tutorials, and demos as a way to gauge the longevity and commitment of the company behind the IP messaging service.
Should I Build an IP Messaging Solution with Open Source Tools?
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.
(Before Building an IP Messaging Solution in-House):
- Have we factored the cost of our team’s time into our ROI calculations?
- Can we achieve the economies of scale necessary to bring our per-device or per-transaction cost near or below that of a service co-locating hundreds or thousands of clients?
- How much later will our product ship if we take the time to do realtime messaging in-house?
- Do we want to take on the liability for security of the realtime messages?
- What is our plan to scale this infrastructure in line with our growth projections?
- Do we have a distributed systems expert in-house who can handle the scaling problems?
- Who on our team will be charged with keeping our realtime messaging infrastructure running after the implementation?
- Who on our team will carry the phone 24/7 to support your solution?
- How will we ensure equal or greater uptime for our realtime services as the rest of our infrastructure?
- How do we plan to handle end-to-end security and encryption?
- How will we get latency under ¼ second for all our users?
- What kind of uptime will we be able to realistically engineer?
- Will we build a solution for message caching and recovery?
- What kind of redundancy will we you build into our solution?
- Will we have a single point of presence (aka a single point of failure), or multiple?
- If we have multiple POPs, how will we keep them in sync?
- What advanced features will we need for production, and which ones are “nice to have”?
- How will we build an authentication service to use with the realtime data?
- How will we handle message catch-up for when devices go offline for an extended period of time?
- Will we be able to do any computation within our realtime messaging solution, or will we have to build out additional stream processing technology?
What’s the Best Protocol for Realtime IP Messaging?
As is often the case with new waves of technology, realtime messaging is currently undergoing a broad conversation on standardization and codification of communication protocols.
Predictably, there’s quite a bit of thrashing involved. Debates rage on whether XMPP, Comet, MQTT, Websockets, HTTP Long Polling, HTTP 2.0 or a dozen other protocols are best.
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 realtime messaging service uses under the hood as long as it:
- Always delivers messages in under ¼ second
- Provides a robust level of security and encryption
- Delivers messages reliably at scale
- Works across all the device types your application needs
- Uses Publish/Subscribe Messaging
- Address geographic latency and reliability
- Supports the advanced features you need