1 簡單應答模式html
結構模型服務器
1)調用RPC接口的過程當中,參數是請求的結構信息,返回值是服務器的反饋信息網絡
2)對於服務器的告警信息和系統公告信息,客戶端須要定時發送查詢的RPC接口,而後在RPC的接口返值框架
中攜帶反饋信息ide
侷限性函數
測試代碼測試
short sThriftPort = 0;ui
std::string strThriftIP;spa
CSystemConfig::GetInstance().GetThriftServiceInfo(strThriftIP, sThriftPort);.net
boost::shared_ptr<UploadMessageServiceHandler> handler(new UploadMessageServiceHandler());
boost::shared_ptr<TProcessor> processor(new UploadMessageServiceProcessor(handler));
boost::shared_ptr<TServerTransport> serverTransport(new TServerSocket(sThriftPort));
boost::shared_ptr<TTransportFactory> transportFactory(new TBufferedTransportFactory());
boost::shared_ptr<TProtocolFactory> protocolFactory(new TBinaryProtocolFactory());
boost::shared_ptr<ThreadManager> threadManager = ThreadManager::newSimpleThreadManager(10);
boost::shared_ptr<BoostThreadFactory> threadFactory(new BoostThreadFactory());
threadManager->threadFactory(threadFactory);
threadManager->start();
TThreadPoolServer server(processor, serverTransport, transportFactory, protocolFactory, threadManager);
server.serve();
Windows下將PosixThreadFactory換成PlatformThreadFactory
Linux下將BoostThreadFactory換成PosixThreadFactory
在上述的服務器端進行客戶端請求的監聽,存在以下的問題
1 服務器端只有等待客戶端的鏈接,等待客戶端的請求發送,而後把應答的消息返回到客戶端,若是服務器端想主動發送消息
給客戶端,在當前的這種框架下是不可能實現的,必須調整當前的thrift的框架邏輯.
2 當客戶端沒有正常關閉套接字,服務器端會一直等待客戶端的請求,沒有機制確保服務器端知道客戶端已經丟棄當前的鏈接。
這種沒有客戶端發送心跳確保在線的機制,是否可以知足生產的需求,有待商榷
3 客戶端通常都是在NAT環境以後,因此客戶端沒法開啓端口對服務器的推送消息進行接收,只有在客戶端主動鏈接服務器,
保持鏈接的通道,能夠進行雙向通道的通訊
4 服務器端不會主動關閉鏈接,關閉鏈接都是由客戶端進行的,若是有惡意的鏈接,耗盡全部的線程,致使拒絕服務的風險
2 服務器模式
客戶端也是服務器,須要啓動端口進行監聽服務器端消息的推送
侷限性
客戶端須要開放端口進行監聽,若是客戶端部署在私有的網絡,經過NAT鏈接到公網的服務器,這一點目前單純依賴thrift框架沒法實現
3 雙向通道模式
結構模型
雙向通道確實可讓服務器端直接推送告警和系統公告信息給客戶端,可是thrift在這種應用結構中,不容許調用的RPC接口有任何的返回值,就相似於UDP的郵件的投遞,服務器端的反饋信息須要經過用RPC
發送給客戶端客戶端以一種相似回調的方式來獲取到反饋的信息
侷限性
發送的請求,須要在回調函數中獲得反饋信息,對因而否執行成功,客戶端須要等待
C#客戶端異常剖析
1)未將對象引用設置到對象的實例 緣由:沒法鏈接Thrift服務器
2)沒法將數據寫入傳輸鏈接(遠程主機強迫關閉了一個現有的鏈接) 緣由:Thrift服務器崩潰或者重啓,鏈接中斷
3)應用服務跟客戶端的代碼不一致:調用的目標發生了異常(沒法將數據寫入傳輸鏈接: 你的主機中的軟件停止了一個已創建的鏈接)
C++接收代碼
類:class TDispatchProcessor : public TProcessor
函數:
virtual bool process(boost::shared_ptr<protocol::TProtocol> in,
boost::shared_ptr<protocol::TProtocol> 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抓包能夠看到發送的服務接口,在服務器端能夠看到接收到的RPC接口,可是發送出去的接口在限制詞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修飾符意味着客戶端發送一個請求,可是沒有監放任何的返回信息,因此oneway方法必須是void類型。沒有oneway修飾的函數,在調用函數的時候,會一直阻塞在函數的調用中,等待另外一方的返回結果,這種是同步狀況,會致使客戶端阻塞,切記!!