Muduo Network Programming Example (ii) Boost.asio Chat server

This article describes a network service program similar to the chat server function in the Boost.asio sample code, including the Muduo implementation of the client and service side. The main purpose of this example is to describe how to handle subcontracting and to initially involve Muduo multithreaded functionality. Muduo's download Address: http://muduo.googlecode.com/files/muduo-0.1.7-alpha.tar.gz, SHA1 873567e43b3c2cae592101ea809b30ba730f2ee6, the complete code for this article can be read online

http://code.google.com/p/muduo/source/browse/trunk/examples/asio/chat/.

TCP Sub-Package

The protocol dealt with in the five simple TCP protocol does not involve subcontracting, and it is the basic requirement of network programming to do the application layer subcontracting on TCP byte-throttling protocol. Subcontracting refers to a message or a frame (frame) of data, through a certain processing, so that the receiver can be identified from the byte stream and intercept (restore) a message. "Sticky problem" is a pseudo problem.

For short connected TCP services, subcontracting is not an issue, as long as the sender actively closes the connection, it means that a message is sent and the receiver read () returns 0 to know the end of the message. For example, the daytime and time agreements in the previous article.

For long-connected TCP services, there are four ways to subcontract:

1. Message length is fixed, for example, Muduo's roundtrip example uses a fixed 16-byte message;

2. Use a special character or string as the boundary of the message, such as the headers of the HTTP protocol in the field of "RN";

3. Add a length field to the head of each message, which is probably the most common practice, and the chat protocol in this article uses this approach;

4. Use the format of the message itself to subcontract, such as <root>...</root> pairing in XML-formatted messages, or pairing of {...} in JSON format. Parsing this message format usually uses a state machine.

The common pitfalls of subcontracting with length fields are also discussed in the code in the following article.

Chat Service

The Chat Service implemented in this article is very simple and consists of a server-side program and a client program, as follows:

* A port in the server program listens for (listen) a new connection;

* The client initiates a connection to the server;

* After the connection is established, the client is ready to receive the message from the server and display it on the screen;

* The client accepts the keyboard input, takes the carriage return as the boundary, sends the message to the service end;

* The server receives the message and sends it to each client connected to it in turn, and the client process that sent the message also receives the message;

* A server-side process can serve multiple client processes at the same time, when a message arrives at the server, each client process receives the same message, and the order in which the server broadcasts the message is arbitrary, and not necessarily which client receives the message first.

* (optional) If message a arrives at the server before message B, each client receives a and receives B first.

This is actually a simple TCP-based application layer broadcast protocol, where the server is responsible for sending messages to each client connected to it. Participation in "chatting" can be either a person or a program. In a later article, I'll introduce a slightly more complex example hub, which has a "chat room" feature that allows clients to register specific topic (s) and send messages to a topic so that the code is more interesting.