Thrift's Tprotocol class system principle and source code explanation: Other Agreement class and summary

Section Sixth other Protocol classes

The main protocol class has basically been introduced, of course, if you have a better implementation and ideas can also implement their own protocol classes, as long as I described earlier in the class hierarchy to inherit. In addition to the protocol classes described in the previous sections, thrift also implements some of its own internal protocol classes, such as the Tdebugprotocol class, which uses a developer-readable text protocol to help with debugging, and, for example, the Tprotocoltap class, which can use two protocol classes for two-time protocol conversions. Put a eavesdropping device on the Protocol object, any reading of this class is through a closed protocol object, but also reflected as writing the second Protocol object, and another is used for the exception of the Protocol class.

So far, the protocol classes implemented by thrift are basically complete, from the characteristics of these protocol classes:

(1) is the implementation of the external provision of the unified interface, so each protocol class can be used alone at any time, it is convenient to use a protocol class to replace another protocol class, for the implementation is completely independent of the Protocol class directly without any relationship (except inheritance);

(2) It provides a good design way to extend more protocol classes.

Section Seventh Summary

(1) Some summaries of the definition of IDL, try to avoid the definition of overly complex data structures.

From the above protocol analysis, there is a recursive inclusion relationship in the composite data type. However, thrift in the generation of block/Che Bao code, there is no recursion to block/unpack, but the use of loops nested loops to generate code, this approach avoids frequent recursive call/unpack functions, can improve the efficiency of the seal/Che Bao. The problem at the same time is a sharp expansion of the amount of code generated.

Although there is no recursion to block/unpack, if the definition is too complex, the data structure will also generate multiple loops, see the following example. Suppose you define one of the following data structures:

map< string, list< set<string> > >,thrift will produce loops similar to the following to seal/Che Bao:

foreach (key in map)
    
{
    
foreach (set in Map[key])
    
{
    
foreach (string in Set)
    
encode ()/decode   
    
(); }
    
}

Assuming that the Map,list,set element has 100 each, this will be a serious impact on the performance of the place, should be avoided.

(2) A field using the unsigned long long is recommended for use of the string type, not the U64 type, because the current thrift is not supported (although it seems that the latest version is supported).

(3) A potential bottleneck in the network IO layer

Because the header of the Thrift Binaryprotocol Protocol does not have any bytes to describe the length of the entire network packet information. So thrift's Binaryprotocol protocol in the solution is that each time you can only read a variable from the socket type and then read the value of the variable to explain this way.

Potential problems that can arise from this way of solving a package: When the number of client requests is very large and the amount of data that is interacting is very large (this may be a lot of fields, or too many composite data types are used), the TCP/IP protocol stack buffer may be stuffed with data that has not been processed. Will seriously affect the quality of service. The reason for not providing some bytes to identify the length of the entire packet is because the BINARYPROTOCOL protocol for thrift needs to support complex data types, like Set,list,map, which are difficult to determine size. In order to support the identification of the entire packet length, you need to know the overall size of the set,list,map before the packet, then you need to traverse the size of the Set,list,map, which is quite uneconomical, increases the operational logic, and also causes the protocol to become complex.

(4) How to do compatible with the old interface

When our server updates the interface and also needs to ensure that the old client interacts with the new server, special attention is needed to define IDL. Suppose, we define one of the following structures to interact with user information.

struct user
    
{
    
1:username string,
    
2:password string,
    
3:sex i16, 
    
}

When we need to change, assume the following two scenarios:

(a) New fields are required, age to represent ages

struct user
    
{
    
1:username string,
    
2:password string,
    
3:sex i16, 
    
4:age i32,
    
}

Note that the ordinal ID of the original field must not be changed, 1:username string, and cannot be changed to 5:username string. At this point, if the server is new, the client is old, does not affect the client's work, the client received from the server side of the package contains the age of information, but not decode out.

b Delete Field sex, new field age

struct user
    
{
    
1:username string,
    
2:password string,
    
//3:sex i16, 
    
4:age i32, (note, in order to ensure a) The defined client can interact with the server of B, where the field ordinal must

be defined as 4
    
}

At this point, if the server is new, the client is a) does not affect the server interaction with B, because the package that the client receives from the server does not contain sex information, but the client does not crash, but the sex information is missing. Therefore, when we need to change, try to save the old fields do not delete, do only increase the way to compatible with the old interface. Here the field ordinal is the key to uniquely identify the field.