Sprat--those protobuf-based RPC (1)

Rai Yonghao (http://laiyonghao.com)

Google Protobuf (HTTP://CODE.GOOGLE.COM/P/PROTOBUF) provided the service keyword to describe the RPC, but did not implement, so everyone has made RPC, just listed on the PROTOBUF official website, There are more than 10 of them (http://code.google.com/p/protobuf/wiki/ThirdPartyAddOns#RPC_Implementations). They use different languages, the framework of the big difference does not have to say, did not think that I saw a few, and found that even the request and response of each call Boggs is very different oh, embodies a lot of different ideas. If you are interested, you may wish to take a look at some of the seven or eight implementations which are more characteristic, then we will draw a table to summarize. Protobuf-rpc

Its self-introduction is RPC based on Google's protocol buffers. Basic Package format See: Http://code.google.com/p/protobuf-rpc/source/browse/trunk/protocol/protobufrpc.proto, Full text as follows:
Message RPC {Repeated request request = 1; repeated Response Response = 2;} message Request {Required String method = 1 ;//Name of a Method_descriptor optional bytes serialized_request = 2;//pb2-encoded message optional UInt32 id = 3; The message Error {required Sint32 code = 1; Optional string text = 2;} message Response {Optional bytes Serialized_respo NSE = 1;//pb2-encoded message Optional Error error = 2; Required UInt32 id = 3; }
I wonder if everyone noticed that the two fields in the message Rpc are repeated. I imagine that this design has the following characteristics: There can be multiple request or response in the same packet, or even return to response and throw some request back to the other end, quite flexible.
Look again at Request.method, the note is name of a method_descriptor, which is actually service_descriptor name plus Method_descriptor's name, but if you don't look at the code Can't know this (see Code: HTTP://CODE.GOOGLE.COM/P/PROTOBUF-RPC/SOURCE/BROWSE/TRUNK/PYTHON/PROTOBUFRPC/SYNCHRONOUS.PY#60) The advantage of this is that you can host several service on the same port. But this doesn't keep up with the changing annotations and cryptic field names, which really make a lot of sense, broken code paradigm.
ID field Incredibly is optional, let me a little puzzled, especially see response.id incredibly is required, the amount ... God, the Request does not come with an ID. What to set Response oh. In fact, from the code point of view, Request.id are set, and read when the field is required to handle.
Error design is not bad, but code is not first wrapped with enum, preset several common mistakes, a bit too liberal.
Finally, because see Request.serialized_request and response.serialized_response are optional, I startled a bit, thought protobuf RPC can have no parameters and return value, But I remember never seeing the document mentioned before. In the end, the pony crossed the river, wrote an RPC without parameters to compile, protoc honest and rude to throw out a "expected type name.", verify that RPC requires both parameters and return values. So this request.serialized_request optional should instead use required, and response.serialized_response can be optional, because when RPC executes the error, The Response instance cannot be returned, only the Error instance is returned, so optional is required to accommodate this flexibility. The author of the goods is really not strict.
To be Continued ...