C ++ में gRPC ढांचे के आसपास Qt आवरण

सभी को नमस्कार। आज हम देखेंगे कि आप C ++ और Qt लाइब्रेरी में gRPC फ्रेमवर्क को कैसे लिंक कर सकते हैं। लेख जीआरपीसी में सभी चार इंटरैक्शन मोड के उपयोग को संक्षेप में कोड प्रदान करता है। इसके अलावा, एक कोड प्रदान किया जाता है जो क्यूआर सिग्नल और स्लॉट के माध्यम से जीआरपीसी के उपयोग की अनुमति देता है। आलेख मुख्य रूप से Qt डेवलपर्स के लिए ब्याज की हो सकती है जो gRPC का उपयोग करने में रुचि रखते हैं। फिर भी, जीआरपीसी के चार ऑपरेटिंग मोड का एक सामान्यीकरण क्यूटी का उपयोग किए बिना सी ++ में लिखा गया है, जो उन डेवलपर्स को अनुमति देगा जो कोड को अनुकूलित करने के लिए क्यूटी से संबंधित नहीं हैं। मैं हर किसी से बिल्ली के नीचे दिलचस्पी लेने के लिए कहता हूं।

प्रागितिहास

लगभग छह महीने पहले, दो परियोजनाओं ने मुझ पर लटका दिया, जीआरपीसी के क्लाइंट और सर्वर भागों का उपयोग करके। दोनों परियोजनाएं उत्पादन में गिर गईं। इन परियोजनाओं को डेवलपर्स द्वारा लिखा गया था जो पहले ही छोड़ चुके हैं। केवल अच्छी खबर यह थी कि मैंने जीआरपीसी सर्वर और क्लाइंट कोड लिखने में सक्रिय भाग लिया। लेकिन वो करीब एक साल पहले की बात है। इसलिए, हमेशा की तरह, मुझे खरोंच से सब कुछ से निपटना पड़ा।

जीआरपीसी सर्वर कोड इस अपेक्षा के साथ लिखा गया था कि यह .proto फ़ाइल द्वारा आगे उत्पन्न किया जाएगा। कोड अच्छी तरह से लिखा गया था। हालाँकि, सर्वर में एक बड़ी खामी थी: केवल एक ग्राहक इससे जुड़ सकता था।

GRPC क्लाइंट को बहुत भयानक लिखा गया था।

मुझे कुछ दिनों बाद ही ग्राहक और सर्वर कोड gRPC का पता चला। और मुझे एहसास हुआ कि अगर मैंने कुछ हफ़्ते के लिए एक प्रोजेक्ट लिया, तो मुझे सर्वर और जीआरपीसी क्लाइंट से फिर से निपटना होगा।

यह तब था जब मैंने फैसला किया कि यह लिखने का समय था और जीआरपीसी क्लाइंट और सर्वर को डीबग करना था ताकि:

• आप रात को चैन से सो सकते थे;

• यह याद रखने की कोई आवश्यकता नहीं थी कि यह कैसे काम करता है जब भी आपको क्लाइंट या जीआरपीसी सर्वर लिखने की आवश्यकता होती है;

• आप अन्य प्रोजेक्ट्स में लिखित gRPC क्लाइंट और सर्वर का उपयोग कर सकते हैं।

कोड लिखते समय, मुझे निम्नलिखित आवश्यकताओं द्वारा निर्देशित किया गया था:

• जीआरपीसी क्लाइंट और सर्वर दोनों ही क्यूटी लाइब्रेरी सिग्नल और स्लॉट का उपयोग प्राकृतिक तरीके से कर सकते हैं;

• जीआरपीसी क्लाइंट और सर्वर कोड को .proto फ़ाइल को बदलते समय ठीक करने की आवश्यकता नहीं है;

• जीआरपीसी क्लाइंट को क्लाइंट कोड को सर्वर से कनेक्शन की स्थिति बताने में सक्षम होना चाहिए।

लेख की संरचना इस प्रकार है। सबसे पहले, क्लाइंट कोड के साथ काम करने के परिणामों और इसके कुछ स्पष्टीकरणों का संक्षिप्त अवलोकन होगा। समीक्षा के अंत में, रिपॉजिटरी का एक लिंक। आगे वास्तुकला पर सामान्य चीजें होंगी। फिर सर्वर और क्लाइंट कोड (हुड के नीचे क्या है) और एक निष्कर्ष का वर्णन।

संक्षिप्त समीक्षा

सरलतम pingproto.proto फ़ाइल को .proto फ़ाइल के रूप में उपयोग किया जाता था, जिसमें सभी प्रकार के इंटरैक्शन के RPC को परिभाषित किया गया था:

syntax = "proto3"; package pingpong; service ping { rpc SayHello (PingRequest) returns (PingReply) {} rpc GladToSeeMe(PingRequest) returns (stream PingReply){} rpc GladToSeeYou(stream PingRequest) returns (PingReply){} rpc BothGladToSee(stream PingRequest) returns (stream PingReply){} } message PingRequest { string name = 1; string message = 2; } message PingReply { string message = 1; } 

Pingpong.proto फ़ाइल नरक से सी ++ में एसिंक्रोनस gRPC मोड पर लेख से helloworld.proto फ़ाइल दोहराती है।

परिणामस्वरूप, एक लिखित सर्वर का उपयोग इस तरह किया जा सकता है:

 class A: public QObject { Q_OBJECT; QpingServerService pingservice; public: A() { bool is_ok; is_ok = connect(&pingservice, SIGNAL(SayHelloRequest(SayHelloCallData*)), this, SLOT(onSayHello(SayHelloCallData*))); assert(is_ok); is_ok = connect(&pingservice, SIGNAL(GladToSeeMeRequest(GladToSeeMeCallData*)), this, SLOT(onGladToSeeMe(GladToSeeMeCallData*))); assert(is_ok); is_ok = connect(&pingservice, SIGNAL(GladToSeeYouRequest(GladToSeeYouCallData*)), this, SLOT(onGladToSeeYou(GladToSeeYouCallData*))); assert(is_ok); is_ok = connect(&pingservice, SIGNAL(BothGladToSeeRequest(BothGladToSeeCallData*)), this, SLOT(onBothGladToSee(BothGladToSeeCallData*))); assert(is_ok); } public slots: void onSayHello(SayHelloCallData* cd) { std::cout << "[" << cd->peer() << "][11]: request: " << cd->request.name() << std::endl; cd->reply.set_message("hello " + cd->request.name()); cd->Finish(); } //etc. }; 

जब कोई क्लाइंट RPC को कॉल करता है, तो gRPC सर्वर क्लाइंट कोड (इस मामले में, क्लास ए) को उचित सिग्नल के साथ सूचित करता है।

GRPC क्लाइंट का उपयोग इस तरह किया जा सकता है:

 class B : public QObject { Q_OBJECT QpingClientService pingPongSrv; public: B() { bool c = false; c = connect(&pingPongSrv, SIGNAL(SayHelloResponse(SayHelloCallData*)), this, SLOT(onSayHelloResponse(SayHelloCallData*))); assert(c); c = connect(&pingPongSrv, SIGNAL(GladToSeeMeResponse(GladToSeeMeCallData*)), this, SLOT(onGladToSeeMeResponse(GladToSeeMeCallData*))); assert(c); c = connect(&pingPongSrv, SIGNAL(GladToSeeYouResponse(GladToSeeYouCallData*)), this, SLOT(onGladToSeeYouResponse(GladToSeeYouCallData*))); assert(c); c = connect(&pingPongSrv, SIGNAL(BothGladToSeeResponse(BothGladToSeeCallData*)), this, SLOT(onBothGladToSeeResponse(BothGladToSeeCallData*))); assert(c); c = connect(&pingPongSrv, SIGNAL(channelStateChanged(int, int)), this, SLOT(onPingPongStateChanged(int, int))); assert(c); } void usage() { //Unary PingRequest request; request.set_name("user"); request.set_message("user"); pingPongSrv.SayHello(request); //Server streaming PingRequest request2; request2.set_name("user"); pingPongSrv.GladToSeeMe(request2); //etc. } public slots: void SayHelloResponse(SayHelloCallData* response) { std::cout << "[11]: reply: " << response->reply.message() << std::endl; if (response->CouldBeDeleted()) delete response; } //etc. }; 

जीआरपीसी ग्राहक आपको सीधे आरपीसी को कॉल करने और उचित संकेतों का उपयोग करके सर्वर की प्रतिक्रिया की सदस्यता लेने की अनुमति देता है।

GRPC क्लाइंट का भी एक संकेत है:

 channelStateChanged(int, int); 

जो पिछले और वर्तमान सर्वर कनेक्शन स्थितियों पर रिपोर्ट करता है। सभी नमूना कोड qgrpc रिपॉजिटरी में है ।

यह कैसे काम करता है

प्रोजेक्ट में क्लाइंट और gRPC सर्वर को शामिल करने का सिद्धांत चित्र में दिखाया गया है।

.Pro प्रोजेक्ट फ़ाइल में, .proto फ़ाइल निर्दिष्ट की जाती हैं, जिसके आधार पर gRPC काम करेगी। Grpc.pri फ़ाइल में gRPC और QgRPC फ़ाइलों को बनाने के लिए आदेश हैं। प्रोटोक कंपाइलर gRPC फाइल्स [protofile] .grpc.pb.h और [protofile] .grpc.pb.cc उत्पन्न करता है। [प्रोटोफाइल] .proto फाइल का नाम है जो कंपाइलर इनपुट में जाती है।

QgRPC फ़ाइलों की पीढ़ी [प्रोटॉफ़ाइल] .qgrpc। [विन्यास] .h को स्क्रिप्ट genQGrpc.py द्वारा नियंत्रित किया जाता है। [विन्यास] या तो "सर्वर" या "क्लाइंट" है।

जेनरेट की गई QgRPC फाइलों में gRPC क्लासेस के आसपास Qt आवरण होता है और इसी सिग्नल के साथ कॉल होते हैं। पिछले उदाहरणों में, QpingServerService और QpingClientService कक्षाएं क्रमशः उत्पन्न फ़ाइलों pingpong.qgrpc.server.h और pingpong.qgrpc.client.h में घोषित की जाती हैं। उत्पन्न QgRPC फ़ाइलों को moc प्रसंस्करण में जोड़ा जाता है।

उत्पन्न QgRPC फ़ाइलों में, QGrpc [config] .h फाइलें शामिल हैं, जिसमें सभी मुख्य कार्य होते हैं। इसके बारे में नीचे पढ़ें।

इस सभी निर्माण को प्रोजेक्ट से कनेक्ट करने के लिए, आपको प्रोजेक्ट में .pri फ़ाइल को .pro फ़ाइल में शामिल करने और तीन चर निर्दिष्ट करने की आवश्यकता है। GRPC वैरिएबल .proto फ़ाइलों को परिभाषित करता है, जो प्रोटोक कंपाइलर और genQGrpc.py स्क्रिप्ट के इनपुट पर स्थानांतरित हो जाएंगे। QGRPC_CONFIG चर उत्पन्न QgRPC फ़ाइलों के कॉन्फ़िगरेशन मान को परिभाषित करता है और इसमें "सर्वर" या "क्लाइंट" मान हो सकते हैं। आप जीआरपीसी के संस्करण को इंगित करने के लिए वैकल्पिक GRPC_VERSION चर को भी परिभाषित कर सकते हैं।

सब कुछ के बारे में अधिक जानकारी के लिए, grpc.pri फ़ाइल और .pro उदाहरण फ़ाइलों को पढ़ें।

सर्वर आर्किटेक्चर

सर्वर वर्ग आरेख चित्र में दिखाया गया है।

मोटे तीर वर्ग वंशानुक्रम के पदानुक्रम को दिखाते हैं, और पतले तीर कक्षाओं में सदस्यों और विधियों की सदस्यता दिखाते हैं। सामान्य तौर पर, Q [servicename] ServerService वर्ग सेवा के लिए उत्पन्न होता है, जहाँ servicename .proto फ़ाइल में घोषित सेवा का नाम है। RPCCallData सेवा में प्रत्येक RPC के लिए उत्पन्न नियंत्रण संरचनाएँ हैं। QpingServerService वर्ग के निर्माता में, बेस क्लास QGrpcServerService को gRPC pingpong :: ping :: AsyncService अतुल्यकालिक सेवा के साथ आरंभीकृत किया जाता है। सेवा शुरू करने के लिए, आपको पता और पोर्ट के साथ स्टार्ट () विधि को कॉल करना होगा, जिस पर सेवा चलेगी। प्रारंभ () फ़ंक्शन सेवा शुरू करने के लिए मानक प्रक्रिया को लागू करता है।

प्रारंभ () फ़ंक्शन के अंत में, शुद्ध वर्चुअल फ़ंक्शन मेकएरेपिस्ट्स () कहा जाता है, जो कि जेनरेटिंग QpingServerService वर्ग में लागू किया जाता है:

 void makeRequests() { needAnotherCallData< SayHello_RPCtypes, SayHelloCallData >(); needAnotherCallData< GladToSeeMe_RPCtypes, GladToSeeMeCallData >(); needAnotherCallData< GladToSeeYou_RPCtypes, GladToSeeYouCallData >(); needAnotherCallData< BothGladToSee_RPCtypes, BothGladToSeeCallData >(); } 

NeedAnotherCallData फ़ंक्शन का दूसरा टेम्पलेट पैरामीटर उत्पन्न RPCCallData संरचना है। समान संरचनाएं सेवा के उत्पन्न क्यूटी वर्ग में संकेतों के पैरामीटर हैं।

उत्पन्न RPCCallData संरचना ServerCallData वर्ग से विरासत में मिली। बदले में, ServerCallData वर्ग सर्वरResponder उत्तरदाता से विरासत में मिला है। इस प्रकार, सुसंगत संरचनाओं की एक वस्तु का निर्माण एक प्रत्युत्तर वस्तु के निर्माण की ओर जाता है।

ServerCallData वर्ग के लिए निर्माता दो पैरामीटर लेता है: signal_func और request_func। signal_func एक उत्पन्न संकेत है जिसे कतार से टैग प्राप्त करने के बाद कहा जाता है। request_func एक ऐसा फंक्शन है जिसे एक नया रेस्पोंडर बनाते समय कहा जाना चाहिए। उदाहरण के लिए, इस मामले में यह RequestSayHello () फ़ंक्शन हो सकता है। Request_func कॉल की जरूरत हैअनोथेरिकडालडाटा () फ़ंक्शन में। ऐसा इसलिए किया जाता है ताकि सेवा में उत्तरदाताओं (निर्माण और विलोपन) का प्रबंधन हो सके।

NeedAnotherCallData () फ़ंक्शन के कोड में एक रेस्पोंडर ऑब्जेक्ट बनाने और एक फ़ंक्शन को कॉल करने के लिए होता है जो रेस्पॉन्डर को एक आरपीसी कॉल से जोड़ता है:

 template<class RPCCallData, class RPCTypes> void needAnotherCallData() { RPCCallData* cd = new RPCCallData(); //... RequestRPC<RPCTypes::kind, ...> (service_, cd->request_func_, cd->responder, ..., (void*)cd); } 

RequestRPC () फ़ंक्शन चार प्रकार के इंटरैक्शन के लिए टेम्पलेट फ़ंक्शंस हैं। परिणामस्वरूप, कॉल करने के लिए RequestRPC () उबलता है:

 service_->(cd->request_func_)(...,cd->responder, (void*)cd); 

जहाँ सेवा_ gRPC सेवा है। इस स्थिति में, यह pingpong :: ping :: AsyncService है।

सिंक्रोनाइज़ या एसिंक्रोनसली ईवेंट कतार की जाँच करने के लिए, आपको क्रमशः CheckCQ () या AsyncCheckCQ () फ़ंक्शन को कॉल करना होगा। CheckCQ () फ़ंक्शन का कोड कतार से तुल्यकालिक टैग और इस टैग के प्रसंस्करण के लिए कॉल करने के लिए नीचे आता है:

 virtual void CheckCQ() override { void* tag; bool ok; server_cq_->Next(&tag, &ok); //tagActions_ call if (!tag) return; AbstractCallData* cd = (AbstractCallData*)tag; if (!started_.load()) { destroyCallData(cd); return; } cd->cqReaction(this, ok); } 

कतार से टैग प्राप्त करने के बाद, टैग और सर्वर प्रारंभ की वैधता की जाँच की जाती है। यदि सर्वर बंद है, तो टैग की अब आवश्यकता नहीं है - इसे हटाया जा सकता है। उसके बाद, ServerCallData वर्ग में परिभाषित cqReaction () फ़ंक्शन को कहा जाता है:

 void cqReaction(const QGrpcServerService* service_, bool ok) { if (!first_time_reaction_) { first_time_reaction_ = true; service_->needAnotherCallData<RPC, RPCCallData>(); } auto genRpcCallData = dynamic_cast<RPCCallData*>(this); void* tag = static_cast<void*>(genRpcCallData); if (this->CouldBeDeleted()) { service_->destroyCallData(this); return; } if (!this->processEvent(tag, ok)) return; //call generated service signal with generated call data argument service_->(*signal_func_)(genRpcCallData); } 

First_time_reaction_ ध्वज इंगित करता है कि आपको RPC के लिए एक नया प्रत्युत्तर बनाने की आवश्यकता है। फ़ंक्शंस सकते हैंबेडलेट () और ProcessEvent () संबंधित ServerResponder उत्तरदाता वर्ग से विरासत में मिले हैं। CanBeDeleted () फ़ंक्शन एक संकेत देता है कि प्रत्युत्तर ऑब्जेक्ट हटा दिया जा सकता है। ProcessEvent () फ़ंक्शन टैग और ओके फ्लैग को प्रोसेस करता है। इसलिए, उदाहरण के लिए, क्लाइंट स्ट्रीमिंग प्रकार के उत्तरदाता के लिए, फ़ंक्शन इस तरह दिखता है:

 bool processEvent(void* tag, bool ok) { this->tag_ = tag; read_mode_ = ok; return true; } 

ProcessEvent () फ़ंक्शन, प्रत्युत्तर के प्रकार की परवाह किए बिना, हमेशा सच होता है। इस फ़ंक्शन का रिटर्न मान कार्यक्षमता के संभावित विस्तार के लिए और सैद्धांतिक रूप से त्रुटियों को खत्म करने के लिए छोड़ दिया जाता है।

घटना को संसाधित करने के बाद, कॉल इस प्रकार है:

 service_->(*signal_func_)(genRpcCallData); 

वेरिएबल सर्विस_ हमारे मामले में क्यूपिंगसर्वर सर्विस के द्वारा उत्पन्न सर्विस का एक उदाहरण है। वैरिएबल सिग्नल_फुनक_ एक विशिष्ट आरपीसी के अनुरूप सेवा सिग्नल है। उदाहरण के लिए, SayHelloRequest ()। चर genRpcCallData इसी प्रकार का एक उत्तरदाता वस्तु है। कॉलिंग कोड के दृष्टिकोण से, चर genRpcCallData उत्पन्न RPCCallataata संरचनाओं में से एक का एक उद्देश्य है।

ग्राहक वास्तुकला

जब भी संभव हो, क्लाइंट के वर्गों और कार्यों के नाम सर्वर के वर्गों और कार्यों के नाम से मेल खाते हैं। क्लाइंट क्लास आरेख चित्र में दिखाया गया है।

मोटे तीर वर्ग वंशानुक्रम के पदानुक्रम को दिखाते हैं, और पतले तीर कक्षाओं में सदस्यों और विधियों की सदस्यता दिखाते हैं। सामान्य तौर पर, सेवा के लिए, क्यू [सर्विसिकनाम] क्लायंटसेवा उत्पन्न होता है, जहाँ सर्विस नाम .pro फ़ाइल में घोषित सेवा का नाम है। RPCCallData सेवा में प्रत्येक RPC के लिए उत्पन्न नियंत्रण संरचनाएँ हैं। RPC को कॉल करने के लिए, उत्पन्न वर्ग फ़ंक्शंस प्रदान करता है जिनके नाम .pro फ़ाइल में घोषित RPC से बिल्कुल मेल खाते हैं। हमारे उदाहरण में, .pro RPC फ़ाइल में SayHello () के रूप में घोषित किया गया है:

 rpc SayHello (PingRequest) returns (PingReply) {} 

उत्पन्न QpingClientService वर्ग में, इसी RPC फ़ंक्शन इस तरह दिखता है:

 void SayHello(PingRequest request) { if(!connected()) return; SayHelloCallData* call = new SayHelloCallData; call->request = request; call->responder = stub_->AsyncSayHello(&call->context, request, &cq_); call->responder->Finish(&call->reply, &call->status, (void*)call); } 

उत्पन्न RPCCallData संरचनाएं, जैसा कि सर्वर के मामले में होता है, अंततः ClientResponder वर्ग से विरासत में मिली हैं। इसलिए, उत्पन्न संरचना की एक वस्तु का निर्माण एक प्रत्युत्तर के निर्माण की ओर जाता है। रेस्पोंडर बनाने के बाद, RPC को कॉल किया जाता है और रिस्पोंडर को सर्वर से प्रतिक्रिया प्राप्त करने की घटना के साथ जोड़ा जाता है। क्लाइंट कोड के संदर्भ में, एक RPC कॉल इस तरह दिखता है:

 void ToSayHello() { PingRequest request; request.set_name("user"); request.set_message("user"); pingPongSrv.SayHello(request); } 

जेनरेटिंग QpingServerService सर्वर वर्ग के विपरीत, QpingClientService वर्ग दो टेम्प्लेट वर्गों से इनहेरिट करता है: कनेक्टिविटीफ्रीचर और मॉनिटरफ्रीचर।

ConnectivityFeatures वर्ग क्लाइंट-सर्वर कनेक्शन की स्थिति के लिए जिम्मेदार है और उपयोग के लिए तीन फ़ंक्शन प्रदान करता है: grpc_connect (), grpc_disconnect (), grpc_reconnect ()। Grpc_disconnect () फ़ंक्शन केवल सर्वर के साथ बातचीत के लिए जिम्मेदार सभी डेटा संरचनाओं को हटा देता है। Grpc_connect के कॉल को grpc_connect_ () फ़ंक्शन पर कॉल करने के लिए कम किया जाता है, जो नियंत्रण डेटा संरचनाओं को बनाता है:

 void grpc_connect_() { channel_ = grpc::CreateChannel(target_, creds_); stub_ = GRPCService::NewStub(channel_); channelFeatures_ = std::make_unique<ChannelFeatures>(channel_); channelFeatures_->checkChannelState(); } 

ChannelFeatures वर्ग सर्वर के साथ Channel_ चैनल संचार की स्थिति पर नज़र रखता है। कनेक्टिविटीफाइट्स वर्ग ChannelFeatures वर्ग की एक वस्तु को एनकैप्सुलेट करता है और इस ऑब्जेक्ट का उपयोग करके एब्स्ट्रैक्ट फ़ंक्शंस ChannelState (), checkChannelState (), और कनेक्टेड () को लागू करता है। ChannelState () फ़ंक्शन सर्वर के साथ संचार चैनल के अंतिम देखे गए राज्य को वापस करता है। CheckChannelState () फ़ंक्शन, वास्तव में, चैनल की वर्तमान स्थिति को लौटाता है। कनेक्टेड () फ़ंक्शन क्लाइंट के सर्वर से कनेक्ट होने के संकेत देता है।

मॉनिटरफ्रीचर वर्ग सर्वर से घटनाओं को प्राप्त करने और संसाधित करने के लिए जिम्मेदार है और उपयोग के लिए चेकसीक्यू () फ़ंक्शन प्रदान करता है:

 bool CheckCQ() { auto service_ = dynamic_cast< SERVICE* >(this); //connection state auto old_state = conn_->channelState(); auto new_state = conn_->checkChannelState(); if (old_state != new_state) service->*channelStateChangedSignal_(old_state, new_state); //end of connection state void* tag; bool ok = false; grpc::CompletionQueue::NextStatus st; st = cq_.AsyncNext(&tag, &ok, deadlineFromMSec(100)); if ((st == grpc::CompletionQueue::SHUTDOWN) || (st == grpc::CompletionQueue::TIMEOUT)) return false; (AbstractCallData< SERVICE >*)(tag)->cqActions(service_, ok); return true; } 

कोड संरचना सर्वर के मामले में समान है। सर्वर के विपरीत, वर्तमान स्थिति को संसाधित करने के लिए जिम्मेदार एक कोड ब्लॉक क्लाइंट में जोड़ा जाता है। यदि संचार चैनल की स्थिति बदल गई है, तो सिग्नल चैनलस्टेटनेटेडसिग्नल_ () कहा जाता है। सभी उत्पन्न सेवाओं में, यह एक संकेत है:

 void channelStateChanged(int, int); 

इसके अलावा, सर्वर के विपरीत, AsyncNext () फ़ंक्शन का उपयोग Next () के बजाय यहां किया जाता है। ऐसा कई कारणों से किया गया है। सबसे पहले, AsyncNext () का उपयोग करते समय, क्लाइंट कोड में संचार चैनल की स्थिति में परिवर्तन के बारे में जानने की क्षमता होती है। दूसरे, AsyncNext () का उपयोग करते समय, ग्राहक कोड में विभिन्न RPC को किसी भी समय कॉल करना संभव है। इस मामले में नेक्स्ट () फ़ंक्शन का उपयोग करके थ्रेड को तब तक ब्लॉक किया जाएगा जब तक कि एक घटना कतार से प्राप्त न हो जाए और, परिणामस्वरूप, दो वर्णित विशेषताओं को खो देगा।

कतार से घटना प्राप्त करने के बाद, जैसा कि सर्वर के मामले में, क्लाइंटकॉलडेटा क्लास में परिभाषित cRReaction () फ़ंक्शन को कहा जाता है:

 void cqActions(RPC::Service* service, bool ok) { auto response = dynamic_cast<RPCCallData*>(this); void* tag = static_cast<void*>(response); if (!this->processEvent(tag, ok)) return; service->*func_( response ); } 

सर्वर के साथ के रूप में, processEvent () फ़ंक्शन टैग और ओके फ्लैग को प्रोसेस करता है और हमेशा सच होता है। जैसा कि सर्वर के मामले में, घटना को संसाधित करने के बाद, उत्पन्न सेवा का संकेत कहा जाना चाहिए। हालाँकि, एक ही नाम के सर्वर फ़ंक्शन से दो महत्वपूर्ण अंतर हैं। पहला अंतर यह है कि इस फ़ंक्शन में उत्तरदाता नहीं बनाए गए हैं। उत्तरदाताओं का निर्माण, जैसा कि ऊपर दिखाया गया है, तब होता है जब आरपीसी कहा जाता है। दूसरा अंतर यह है कि इस फ़ंक्शन में उत्तरदाताओं को हटाया नहीं जाता है। उत्तरदाताओं को हटाने का अभाव दो कारणों से किया जाता है। सबसे पहले, क्लाइंट कोड अपने स्वयं के प्रयोजनों के लिए उत्पन्न RPCCallData संरचनाओं के लिए पॉइंटर्स का उपयोग कर सकता है। क्लाइंट कोड से छिपे इस पॉइंटर द्वारा सामग्री को हटाने से अप्रिय परिणाम हो सकते हैं। दूसरे, प्रत्युत्तर को हटाने से तथ्य यह होगा कि डेटा के साथ एक संकेत उत्पन्न नहीं होगा। इसलिए, क्लाइंट कोड को अंतिम सर्वर संदेश प्राप्त नहीं होगा। संकेतित समस्याओं को हल करने के लिए कई विकल्पों में से, ग्राहक कोड के लिए उत्तरदाता (उत्पन्न संरचनाओं) को हटाने के लिए निर्णय लिया गया था। इस प्रकार, सिग्नल हैंडलर फ़ंक्शन (स्लॉट) में निम्न कोड होना चाहिए:

 void ResponseHandler(RPCCallData* response) { if (response->CouldBeDeleted()) delete response; //process response } 

ग्राहक कोड में उत्तरदाता के निष्कासन की अनुपस्थिति न केवल एक स्मृति रिसाव की ओर ले जाएगी, बल्कि संचार चैनल के साथ संभावित समस्याओं को भी हल करेगी। नमूना कोड में सभी प्रकार के आरपीसी इंटरैक्शन के सिग्नल हैंडलर लागू किए जाते हैं।

निष्कर्ष

अंत में, हम दो बिंदुओं पर ध्यान आकर्षित करते हैं। पहला बिंदु क्लाइंट और सर्वर के चेकक्यू () फ़ंक्शन को कॉल करने से संबंधित है। वे काम करते हैं, जैसा कि ऊपर दिखाया गया है, एक सिद्धांत के अनुसार: यदि कतार में कोई घटना होती है, तो संबंधित उत्पन्न RPCCallData संरचना के साथ एक संकेत "उत्सर्जित" होता है। आप इस फ़ंक्शन को मैन्युअल रूप से कॉल कर सकते हैं और किसी ईवेंट के लिए (क्लाइंट के मामले में) चेक कर सकते हैं। लेकिन शुरू में जीआरपीसी से जुड़े पूरे नेटवर्क हिस्से को दूसरे धागे में स्थानांतरित करने का विचार था। इन उद्देश्यों के लिए, gRPC सर्वर के लिए सहायक वर्ग QGrpcSrvMonitor और GRPC क्लाइंट के लिए QGrpcCliServer लिखे गए थे। दोनों वर्ग एक ही सिद्धांत पर काम करते हैं: वे एक अलग स्ट्रीम बनाते हैं, इस स्ट्रीम में जेनरेट की गई सर्विस को लगाते हैं और समय-समय पर इस सर्विस के चेकसीक्यू () फंक्शन को कॉल करते हैं। इस प्रकार, दोनों सहायक कक्षाओं का उपयोग करते समय, क्लाइंट कोड में CheckCQ () फ़ंक्शन को कॉल करने की आवश्यकता नहीं है। उत्पन्न सेवा के संकेत, इस मामले में, एक अन्य धारा से "आते हैं"। क्लाइंट और सर्वर के उदाहरण इन सहायक वर्गों का उपयोग करके कार्यान्वित किए जाते हैं।

दूसरा बिंदु उन अधिकांश डेवलपर्स की चिंता करता है जो अपने काम में क्यूटी लाइब्रेरी का उपयोग नहीं करते हैं। QgRPC में Qt वर्ग और मैक्रोज़ केवल दो स्थानों पर उपयोग किए जाते हैं: जनरेट की गई सेवा फ़ाइलों में, और सहायक कक्षाओं वाली फ़ाइलों में: QGrpcServerMonitor.h और QGrpcClientMonitor.h। Qt लाइब्रेरी वाली शेष फाइलें किसी भी तरह से जुड़ी नहीं हैं। यह सीमेक का उपयोग करके विधानसभा को जोड़ने और कुछ क्यूटी निर्देशों को स्टब करने की योजना बनाई गई थी। विशेष रूप से, QObject वर्ग और Q_OBJECT मैक्रो। लेकिन हाथों को यह नहीं मिला। इसलिए, किसी भी सुझाव का स्वागत है।

वह सब है। आप सभी को धन्यवाद!

संदर्भ

• QgRPC कोड के साथ भंडार

• C ++ में एसिंक्रोनस gRPC