Muduo network programming example 9: simple message broadcast service

In a distributed system, in addition to common end-to-end communication, there is also one-to-many broadcast communication. When it comes to broadcast, it may be reminiscent of IP multicast or IP multicast. This is not the topic of this article. This article will talk about TCP-based application layer broadcast. As follows:

The rounded rectangle represents a program. "Hub" is a service program, not a network Hub. It acts like a Hub and hence its name. Publisher and Subscriper communicate with the Hub program through the TCP protocol. Publisher sends the message to a topic, Subscribers subscribes to the topic, and then receives the message. Publisher uses hub to broadcast messages to multiple subscribers. The advantage of this pub/sub structure is that it can add multiple Subscriber without having to modify Publisher. To a certain extent, it achieves "decoupling" (which can also be seen as a distributed observer pattern ). Because of the TCP protocol, broadcast is basically reliable. Here "reliability" refers to "more reliable than UDP", not "completely reliable ". (THINKING: How to Avoid Hub from becoming a single point of failure ?)

To avoid cross-talk, each topic must have only one publisher at a time, and hub does not provide compare-and-swap operations.

(Reliable broadcast and atomic broadcast are of great significance in distributed systems. It is based on the reliable distributed service implemented using the replicated state machine method. "reliable broadcast" involves the consensus algorithm, beyond the scope of this article .)

 

Application Layer broadcast is very useful in Distributed Systems. Here are some examples:

1. sports score broadcast. There are 8 sets of venues in the badminton competition. The scoring program of each venue sends the current score to their respective topics (venue 1st is sent to court1, venue 2nd is sent to court2, and so on ). You need to subscribe to topics that you are interested in using the SCORE program (Large Screen Display of the game field, online score broadcasting, etc.) to receive the latest Score data in a timely manner. Because this article does not implement 100% reliable broadcast, the message should be snapshot rather than incremental. (In other words, the message content is "What is the ratio of today", rather than "who scored just now ".)

2. load monitoring. Run a monitoring program on each machine and periodically publish the current load (CPU, network, disk, temperature) of the machine to the topic named hostname, in this way, the program that needs to use the data can obtain data by subscribing to the corresponding topic in the hub, without directly dealing with multiple machines. (For the sake of reliability, the messages sent by the monitoring program should contain timestamps, which can prevent stale data from even playing a heartbeat role to a certain extent .) In this way, the service programs in the distributed system can also publish their current load to the hub for load balancer and monitor to use.

Protocol
For the sake of simplicity, the muduo's hub example uses a text protocol with a division, so that telnet can be used to test the hub. The Protocol has only three commands:

Sub <topic>
This command indicates to subscribe to the <topic>. Any new topic will be sent to this tcp connection in the future. The hub sends the latest message on the <topic> to the subscriber during sub.
Unsub <topic>
This command indicates unsubscribing <topic>
Pub <topic> <content>
Send a message to <topic> with the content <content>. All subscribers that have subscribed to this topic will receive the same message "pub <topic> <content>"
Code
In the muduo example, the hub consists of the following parts:

The hub service program is responsible for one-to-many message distribution. It remembers the topics subscribed by each client and only sends messages to specific subscribers. Code see http://code.google.com/p/muduo/source/browse/trunk/examples/hub/hub.cc
Pubsub library. To facilitate the compilation of applications using the hub service, I wrote a simple client library to deal with the hub. This library can subscribe to topics, UNSUBSCRIBE topics, and publish messages to specified topics. For the code, see http://code.google.com/p/muduo/source/browse/trunk/examples/hub/pubsub.h and http://code.google.com/p/muduo/source/browse/trunk/examples/hub/pubsub.cc.
Sub sample program. The command line program subscribes to one or more topics and waits for hub data. Code http://code.google.com/p/muduo/source/browse/trunk/examples/hub/sub.cc
Pub sample program. This command line program publishes a message to a topic. The message content is specified by the command line parameter. Code http://code.google.com/p/muduo/source/browse/trunk/examples/hub/pub.cc
A program can be both publisher and subscriber, And the pubsub library uses only one tcp connection (this makes failover easier ).

Example:

Open four command line windows
Run $ hub 9999 In the first window
Run $ sub 127.0.0.1: 9999 mytopic In the second window
Run $ sub 127.0.0.1: 9999 mytopic court in the third window
Run $ pub 127.0.0.1: 9999 mytopic "Hello world. "," mytopic: Hello world. ", indicating that the message on the topic" mytopic "is received.
Run $ pub 127.0.0.1: 9999 court "13:11" in the Fourth window. Then, the third window will print "court:", indicating that you have received the message on the subject of court. The second window does not subscribe to this message, so there is no output.
With this simple pub/sub mechanism, you can do a lot of interesting things. For example, change the end-to-end communication of some programs in the distributed system to pub/sub (for example, A sent a soap request to B, B sends response back through the same tcp connection (the communication between the two can only be checked by log or intercepted by tcpdump); now A publishes A request to topic_a_to_ B, and B sends A response to topic_ B _to_a ), in this way, one more monitoring subscriber can easily view the communication between the two parties, and it is easy to perform status monitoring and trouble shooting.