Implementation of PROTOBUF codec and message distributor in Muduo

This article is "a kind of automatic reflection message type of the Google PROTOBUF network transmission scheme," the continuation of how to introduce the packaging scheme described above with Muduo::net::buffer to achieve PROTOBUF codec and dispatcher.

Muduo's download Address: http://muduo.googlecode.com/files/muduo-0.1.9-alpha.tar.gz, SHA1 DC0BB5F7BECDFC0277FB35F6DFAAFEE8209213BC, the complete code for this article can be read online http://code.google.com/p/muduo/source/browse/trunk/ examples/protobuf/codec/.

Considering that not everyone installs the PROTOBUF related example in Google Protobuf,muduo, the default is no build, and if you have protobuf 2.3.0 or 2.4.0a installed on your machine, then you can use./build.sh prot Obuf_all to build protobuf-related examples.

Before introducing codec and dispatcher, let's start with an unresolved issue before the text.

Why does the default serialization format for Protobuf not contain the length and type of the message?

Protobuf is a thoughtful package of messages, and its default serialization format does not contain the length and type of messages, and naturally makes sense. In which cases do you not need to include the length and/or type of the message in a byte stream resulting from PROTOBUF serialization? The answers I can think of are:

If you write a message to a file and a file saves a message, the serialization results do not need to include the length and type, because you can tell the type and length of the message from the file name and file length.

If you write a message to a file and a file has more than one message, the serialization result does not need to include the type, because the file name represents the type of message.

If a message is stored in a database (or NoSQL) and saved as a VARBINARY field, the serialization result does not need to include the length and type, because the type and length of the message can be learned from the field name and field length.

If the message is sent to each other as UDP and a UDP port receives only one type of message, the serialization result does not need to contain the length and type, because the type and length of the message can be learned from the port and UDP packet lengths.

If a message is sent to each other in a TCP short connection and a TCP port receives only one type of message, the serialization result does not need to include the length and type, because the type and length of the message can be learned from the port and TCP byte throttle lengths.

If the message is sent as a TCP long connection, but one TCP port receives only one message type, then the serialization result does not need to include the type because port represents the type of message.

If you use RPC to communicate, you only need to tell the other party method name, the other side can naturally infer the Request and Response message types, these can be generated by Protoc RPC stubs automatically.

For the last point, let's say Sudoku.proto is defined as:

Service Sudokuservice {
  rpc Solve (sudokurequest) returns (Sudokuresponse);
}

Then RPC method sudoku.solve the corresponding request and response are sudokurequest and Sudokuresponse respectively. When you send an RPC request, you do not need to include the type of sudokurequest, you only need to send the method name Sudoku.solve, and the other person knows that you should parse (parse) The request according to Sudokurequest. This example comes from my semi-finished project Evproto, see http://blog.csdn.net/Solstice/archive/2010/04/17/5497699.aspx.

For these cases, if protobuf unconditionally puts the length and type into the serialized byte string, it will only waste network bandwidth and storage. Visible PROTOBUF The default does not send the length and type is the correct decision. Protobuf is a good example of the design of the message format, which should be handled by itself and which is left to the external system to be considered very clearly.

Only if you are using a TCP long connection and you pass more than one message on a connection (for example, Heartbeat and request/response at the same time), you need the package I mentioned earlier. (Why do you send Heartbeat and business messages at the same time on a connection?) See Chen Yu "The engineering development method of Distributed System" p.51 Heartbeat protocol design. This is one of the topics of this article, when we need a distributor dispatcher to distribute different types of messages to each message handler function.