Using PubSub in live streaming applications
The live streaming market is growing exponentially fast and as per informed sources, the global Live Streaming Market is projected to reach USD 534.37 Billion by 2030, growing continually at 29.3% CAGR throughout the forecast period. This means we are going to see tremendous opportunities in this industry for developers and business owners as they incorporate various new technologies into live streaming. While cloud offerings of are becoming widely popular as a safe & stable bet for businesses, on-premises deployments and application development will continue to grow strong and remain a preference of many small and big business entities.
THE MISSING COMMUNICATION LAYER
Streaming is not just about building passive experiences like legacy television. In today’s era, most of the experiences built on top of live streaming are interactive and tend to engage users in various ways. After the fall of Flash RTMP became limited to publishing mechanisms for one – many streaming architectures. HTTP live streaming, Dash, CMAF, etc are not very suitable for interactive streaming applications due to the nature of the protocol itself and the latency they bring along. That mostly leaves us with RTSP (for mobile) & WebRTC (for mobile & desktop) for developing interactive streaming Although RTSP has low latency, it is primarily limited to the mobile ecosystem, WebRTC in many ways is a better choice therefore when it comes to building interactive streaming applications.
Most protocols unlike RTMP were designed mainly for media delivery and hence they can do little when it comes to interactivity/control messages/data communication. Popular media servers such as Flash Media Server, Wowza Streaming Engine etc, that supported RTMP earlier had incorporated SharedObjects – built on top of RTMP for real-time communication between clients and servers. Since the demise of Flash, the client-client & client-server communication has been left in limbo. Technologies such as AJAX and WebSockets have been used to fill this void and to be honest, have been successful to some extent. WebRTC has introduced data channels to solve the issue of coordination (control messaging) and data communication. However, the issue here is that unless you are active in a WebRTC session, data channels cannot do much. So that means WebSocket and AJAX are still your best bet inside/outside the streaming session. In fact, You can use Websockets with some custom coding to build your own functional PubSub system easily.
PUBSUB TO THE RESCUE
PUBSUB (Publish-Subscribe) paradigm is a popular asynchronous communication pattern used in a lot of communication systems these days. PubSub provides message storage along with a real-time delivery pipeline. PubSub services are usually offered over different protocols such as WebSocket, MQTT, etc.
Unlike AJAX’s long polling mechanism, PubSub systems are usually based on sockets & follow a publish-subscribe philosophy which does not waste time & resources looking/polling for a message on the server or from other clients. Instead, a PubSub client simply subscribes to the message channel and gets back to doing other important tasks. when a message intended for the client arrives in the channel, it can then spend resources to process it.
ANATOMY OF THE PUBSUB MODEL
The PubSub system can be broken up into the following components:
- PUBLISHER: A Publisher (also referred to as
producer) is the creator/generator of a message. the publisher creates and publishes a message on a specific topic without knowing anything about the receivers of the message. - SUBSCRIBER: A subscriber (also referred to as
consumer) is the receiver of a message. The subscribers listened to a specific topic for messages. when messages arrive the subscriber is notified and it can then consume/process the messages. - MESSAGE: A message is nothing but a data payload that is transmitted by a publisher to a topic.
- TOPIC: A specific data bucket that temporarily holds messages before the consumers consume them. A topic acts special category/route for messages. Each topic has its own list of subscribers to which messages are to be delivered.
BENEFITS OF PUBSUB
LOOSE COUPLING
The asynchronous mechanism of “fire and forget” on the publishing side and “subscribe and get back to other tasks” on the subscription side ensure that the publisher and subscriber are not too involved or even aware of each other.
EASE OF SCALABILITY
PubSub systems are typically built on top of a middleware that provides the messaging service over a certain protocol. These middlewares are popularly called message brokers. To scale the communication, therefore, the middleware itself can be scaled through various techniques (horizontally or vertically) without disturbing the operational logic or the fundamental behaviour of PubSub that is already in place. Most of the PubSub middlewares also support clustering for better stability.
LANGUAGE INDEPENDENT
PubSub pattern is language-independent. That means irrespective of what programming language is used on your client side and server side, the fundamental behaviour of the mechanism remains unaffected. However, there will always be different SDKs/libraries/APIs that will help you integrate PubSub into your client or server. For example, AWS provides libraries for Python/Java/.Net, etc to help integrate its cloud-based message broker service (Amazon MQ).
A VIBRANT TOOL TO BUILD CLIENT-SERVER COMMUNICATION
Owing to loose coupling, PubSub becomes an automatic choice for integrating system components on the server side, building collaboration between different types of clients and even creating efficient workflows in the traditional client-server communication space.
SERVER INTEGRATIONS – WORKFLOWS & INTRA-SYSTEM COMMUNICATION
Using PubSub you can build server side workflows that connect different components through the common messaging-based two-way communication pipeline. You can also integrate local workflows with cloud-based services. A very good example of this is the AWS EventBridge.
Now let us get back to our problem domain. Say you have a live streaming system with a publisher, multiple subscribers, a streaming server, an application server, and optionally a business server. If I were to ask you to connect these systems to each other with proper boundaries and security, all of a sudden it will all seem very overwhelming with different programming languages, different platforms, different types of clients, different APIs, etc. However, if you were to use a PubSub based system, you are free from the differences highlighted above.
Each component can communicate with another component without caring about the language, platform, and other complexities.
The media server can use a special PubSub topic to notify the subscribers of changes in the publisher’s stream state. That way they will know when to subscribe and when to sit idle, instead of polling for the stream state. Similarly, the application server will also use the same topic for the stream state to update the UI on the application server to reflect the stream’s state. The business server can track usage & other statistics from the media server in real-time through a different topic.
CLIENT INTEGRATIONS – COORDINATION, COLLABORATION & COMMUNICATION
Talking about the client side of things, the most common issues that we face when developing live streaming systems are building coordination, communication & collaboration in-between clients & the client-server interface layer.
The most common use case of intensive client-client communication would be conferences and other similar collaborative applications, where the importance of communication & collaboration cannot be overstated. In such applications, there is usually one or more administrator clients who can add/remove other clients, mute/unmute their audio/video devices, send group messages to all connected clients & allow/disallow specific permissions to participant clients. Some of these administrative activities require client-server communication in real time whereas others require direct client-client communication. Collaboration applications such as shared whiteboards or multiplayer games beg for low latency and responsiveness at the same time. Needless to say PubSub is a good fit here.
For real-time communication between participant clients, applications also use text chats apart from voice. Here again, the PubSub system provides unparalleled options for developing chatrooms. Each conference chat can have its own specific global topic for sending & receiving messages. Private chats or Direct Messages between clients can be achieved via sub-topics or by creating separate topics.
CLIENT – SERVER INTEGRATIONS
As mentioned earlier, for the entire system to function as a single unit there needs to be properly synchronized communication between the client and the server. Clients need to receive important control messages & communication from the server continuously. Control messages will help the server manage the client like an administrator/coordinator while important communication in form of notifications will keep the client better engaged.
POPULAR PUB-SUB MESSAGING SYSTEMS
CLOUD
- Amazon MQ: Amazon MQ is a managed message broker service for Apache ActiveMQ and RabbitMQ offered on Amazon cloud. It offers advanced management and scaling options with a pay-as-you-go model.
- Google Pub/Sub: Pub/Sub is managed service offered on GCP which gives you the features & functionalities of a PubSub system. It is advertised for data integration pipelines and is said to be equally effective as a messaging-oriented middleware for service integration.
- Azure Web PubSub: Azure Web PubSub is a managed service by Microsoft Azure built on top of WebSockets and touts features like low latency, high availability, and support for a wide variety of client SDKs and programming languages.
- Hive MQ Cloud: Hive offers PubSub through MQTT protocol which was originally designed for IoT communication but can be extended to web browsers, native mobile clients, or even servers with proper wrappers.
ON-PREMISES
- RabbitMQ: RabbitMQ is one of the most popular open-source message brokers which is used worldwide by small startups and large enterprises. It is lightweight & hence easy to deploy on-premises and in the cloud. It supports multiple messaging protocols. It is deployable in distributed and federated configurations to meet high-scale, high-availability requirements.
- Apache Kafka: Kafka is a heavy-duty, enterprise-grade distributed data store optimized for ingesting and processing streaming data. Kafka combines messaging, storage and data stream processing to allow storage and analysis of both historical and real-time data, making it a better choice for enterprises well ahead of RabbitMQ.
- Eclipse Mosquitto: Mosquitto is an open-source MQTT-based message broker meant primarily for IoT communication. It is supported by a well-developed community and is available for a wide range of platforms.
- EMQX: Emqx is a PubSub system for IoT devices over MQTT. It offers Cloud as well as On-Premises deployment options.
The above mentioned are just few handful of technologies that we have highlighted. There many more platforms, services and programs that can help you build the PubSub system you want for your specific needs. We encourage you to explore them on your own.
CONCLUSION
PubSub is not a new communication pattern. It has been there with us for years. However nowadays with the popularity of protocols like WebSockets, MQTT, etc, PubSub has become mainstream. That said it is important to understand that despite a lot of advantages it is still not suitable for scenarios such as:
- Video/Audio streaming
- CPU-intensive background processing
As with any other system, the usefulness of the system depends on a thorough knowledge of its strengths & weaknesses as well as your experience of working with such systems. That said PubSub is here to stay and is going to be a large part of the event-driven architectures of the future.
While every streaming architecture can be unique with its own set of challenges, We believe the PubSub system is a pattern that can greatly benefit the streaming industry in building responsive inter-component communication on the server as well as engaging interactions & communication between users on the client side.