Today, when my colleagues tried oneway, they found that the number of messages sent by the client was inconsistent with that received by the server. I did the experiment myself. The results are also inconsistent.
The data structure is defined as follows: book. thrift
Namespace cpp codelab
Struct Book {
1: i32 book_id
2: string name
}
The definition of hello. thrift on the server side is as follows:
Include "book. thrift"
Namespace cpp codelab_proto
Service HelloBook {
Oneway void ping (1: book. Book book)
}
The server code is roughly as follows:
Class HelloBookHandler: virtual public HelloBookIf {
Public:
HelloBookHandler (){
// Your initialization goes here
}
Void ping (const codelab: Book & book ){
// Your implementation goes here
++ Count;
Printf ("book name: % s, % d \ n", book. name. c_str (), count );
}
Private:
Static volatile int count;
};
Volatile int HelloBookHandler: count = 0;
Int main (int argc, char ** argv ){
// Create the server in a new thread
Thritnonblockingserverthread <HelloBookHandler, HelloBookProcessor>
Threads (false, 9090, NULL );
Thread. Start ();
Bool flag = true;
// Wait forever or do anything you need to do
While (true ){
Sleep (1 );
If (flag ){
LOG (INFO) <"server port:" <thread. ServerPort ();
Flag = false;
}
}
Return 0;
}
The client code is roughly as follows:
Int main (int argc, char ** argv ){
Base: ParseCommandLineFlags (& argc, & argv, true );
Boost: shared_ptr <TSocket> socket (new TSocket ("localhost", 9090 ));
Boost: shared_ptr <TTransport> transport (new TFramedTransport (socket ));
Boost: shared_ptr <TProtocol> protocol (new TBinaryProtocol (transport ));
HelloBookClient client (protocol );
Transport-> open ();
Book;
Book. name = "This is a hello thrift test ";
For (size_t I = 0; I <10000; ++ I ){
Try {
Client. ping (book );
Sleep (0); // here is
} Catch (TException & tx ){
LOG (ERROR) <"exception:" <tx. what ();
Transport-> open ();
}
}
Sleep (60); // here is the second place B
Transport-> close ();
Return 0;
}
Note: Due to personal code compiling environment problems, the above Code is only for understanding the logic and may not be directly used.
Implementation:
When the thrift interface defines a non-oneway, the number of messages received by the server is the same as that of the client.
However, when defined as oneway, there are several situations as follows:
Note that there are two items A and B above. When A is set to greater than 0 and there is no code at B, the server receives the same number of messages as the client.
When A is set to 0, but there is no code at B. The number of messages received by the server is inconsistent. The number of received messages is related to the Message Size.
When A is set to 0, the code output from B is also set to sleep. The number of messages received by the server is the same as that of the client.
Personal analysis:
The oneway method is that the client writes messages to the local network buffer and returns them directly. Whether the data is successfully sent to the server is guaranteed by the network. If the sending speed is slow. The client exits directly. The subsequent messages will be lost.
Instead of one-way, messages are sent to the other party. After receiving the message, the server sends a response to the client. This is the synchronous stop and other sending methods.
Therefore, oneway should be used with low reliability requirements and an understanding of the transmission speed. This ensures that the probability of failure is low.
From @ and listen to the wind @