1 簡單應(yīng)答模式

讓客戶滿意是我們工作的目標(biāo)，不斷超越客戶的期望值來自于我們對這個行業(yè)的熱愛。我們立志把好的技術(shù)通過有效、簡單的方式提供給客戶，將通過不懈努力成為客戶在信息化領(lǐng)域值得信任、有價值的長期合作伙伴，公司提供的服務(wù)項目有：空間域名、虛擬主機、營銷軟件、網(wǎng)站建設(shè)、索縣網(wǎng)站維護、網(wǎng)站推廣。

結(jié)構(gòu)模型

1）調(diào)用RPC接口的過程中，參數(shù)是請求的結(jié)構(gòu)信息，返回值是服務(wù)器的反饋信息

2）對于服務(wù)器的告警信息和系統(tǒng)公告信息，客戶端需要定時發(fā)送查詢的RPC接口，然后在RPC的接口返值

中攜帶反饋信息

局限性

測試代碼

short sThriftPort = 0;

std::string strThriftIP;

CSystemConfig::GetInstance().GetThriftServiceInfo(strThriftIP, sThriftPort);

boost::shared_ptr handler(new UploadMessageServiceHandler());

boost::shared_ptr processor(new UploadMessageServiceProcessor(handler));

boost::shared_ptr serverTransport(new TServerSocket(sThriftPort));

boost::shared_ptr transportFactory(new TBufferedTransportFactory());

boost::shared_ptr protocolFactory(new TBinaryProtocolFactory());

boost::shared_ptr threadManager = ThreadManager::newSimpleThreadManager(10);

boost::shared_ptr threadFactory(new BoostThreadFactory());

threadManager->threadFactory(threadFactory);

threadManager->start();

TThreadPoolServer server(processor, serverTransport, transportFactory, protocolFactory, threadManager);

server.serve();

Windows下將PosixThreadFactory換成PlatformThreadFactory
Linux下將BoostThreadFactory換成PosixThreadFactory

在上述的服務(wù)器端進行客戶端請求的監(jiān)聽，存在如下的問題

1 服務(wù)器端只有等待客戶端的連接，等待客戶端的請求發(fā)送，然后把應(yīng)答的消息返回到客戶端，如果服務(wù)器端想主動發(fā)送消息

給客戶端，在當(dāng)前的這種框架下是不可能實現(xiàn)的，必須調(diào)整當(dāng)前的thrift的框架邏輯.

2 當(dāng)客戶端沒有正常關(guān)閉套接字，服務(wù)器端會一直等待客戶端的請求，沒有機制確保服務(wù)器端知道客戶端已經(jīng)丟棄當(dāng)前的連接。

這種沒有客戶端發(fā)送心跳確保在線的機制，是否能夠滿足生產(chǎn)的需求，有待商榷

3 客戶端一般都是在NAT環(huán)境之后，所以客戶端無法開啟端口對服務(wù)器的推送消息進行接收，只有在客戶端主動連接服務(wù)器，

保持連接的通道，可以進行雙向通道的通信

4 服務(wù)器端不會主動關(guān)閉連接，關(guān)閉連接都是由客戶端進行的，如果有惡意的連接，耗盡所有的線程，導(dǎo)致拒絕服務(wù)的風(fēng)險

2 服務(wù)器模式

客戶端也是服務(wù)器，需要啟動端口進行監(jiān)聽服務(wù)器端消息的推送

局限性

客戶端需要開放端口進行監(jiān)聽，如果客戶端部署在私有的網(wǎng)絡(luò)，通過NAT連接到公網(wǎng)的服務(wù)器，這一點目前單純依賴thrift框架無法實現(xiàn)

3 雙向通道模式

結(jié)構(gòu)模型

雙向通道確實可以讓服務(wù)器端直接推送告警和系統(tǒng)公告信息給客戶端，但是thrift在這種應(yīng)用結(jié)構(gòu)中，不允許調(diào)用的RPC接口有任何的返回值，就類似于UDP的郵件的投遞，服務(wù)器端的反饋信息需要通過用RPC

發(fā)送給客戶端客戶端以一種類似回調(diào)的方式來獲取到反饋的信息

局限性

發(fā)送的請求，需要在回調(diào)函數(shù)中得到反饋信息，對于是否執(zhí)行成功，客戶端需要等待

C#客戶端異常剖析

1）未將對象引用設(shè)置到對象的實例 原因：無法連接Thrift服務(wù)器

2）無法將數(shù)據(jù)寫入傳輸連接（遠程主機強迫關(guān)閉了一個現(xiàn)有的連接） 原因：Thrift服務(wù)器崩潰或者重啟，連接中斷

3）應(yīng)用服務(wù)跟客戶端的代碼不一致：調(diào)用的目標(biāo)發(fā)生了異常（無法將數(shù)據(jù)寫入傳輸連接: 你的主機中的軟件中止了一個已建立的連接）?

C++接收代碼

類：class TDispatchProcessor : public TProcessor

函數(shù)：

? virtual bool process(boost::shared_ptr in,

? ? ? ? ? ? ? ? ? ? ? ?boost::shared_ptr out,

? ? ? ? ? ? ? ? ? ? ? ?void* connectionContext) {

? ? std::string fname;

? ? protocol::TMessageType mtype;

? ? int32_t seqid;

? ? in->readMessageBegin(fname, mtype, seqid);

? ? if (mtype != protocol::T_CALL && mtype != protocol::T_ONEWAY) {

? ? ? GlobalOutput.printf("received invalid message type %d from client",

? ? ? ? ? ? ? ? ? ? ? ? ? mtype);

? ? ? return false;

? ? }

? ? return dispatchCall(in.get(), out.get(), fname, seqid, connectionContext);

? }

WireShark抓包可以看到發(fā)送的服務(wù)接口，在服務(wù)器端可以看到接收到的RPC接口，但是發(fā)送出去的接口在限制詞thrift中無法看到，只能通過限制端口來看到所有的報文信息，可以通過報文的長度來知道是哪個接口

https://www.cnblogs.com/xiaosuiba/p/4122459.html

https://blog.csdn.net/qq_27989757/article/details/50761051

文章描述了Thrift雙向通信的基本機制

https://blog.csdn.net/lwwl12/article/details/77449550

oneway修飾符意味著客戶端發(fā)送一個請求，但是沒有監(jiān)聽任何的返回信息，所以oneway方法必須是void類型。沒有oneway修飾的函數(shù)，在調(diào)用函數(shù)的時候，會一直阻塞在函數(shù)的調(diào)用中，等待另一方的返回結(jié)果，這種是同步情況，會導(dǎo)致客戶端阻塞，切記??！