thrift 单向通道服务的局限性

Posted 2020-10-01

thrift作为RPC调用的开源框架介绍，网上已经有不少的介绍，在此不赘述，而是讨论thrift的简单应用下的问题

测试代码

short sThriftPort = 0;

std::string strThriftIP;

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

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();

在上述的服务器端进行客户端请求的监听，存在如下的问题

1 服务器端只有等待客户端的连接，等待客户端的请求发送，然后把应答的消息返回到客户端，如果服务器端想主动发送消息

给客户端，在当前的这种框架下是不可能实现的，必须调整当前的thrift的框架逻辑.

2 当客户端没有正常关闭套接字，服务器端会一直等待客户端的请求，没有机制确保服务器端知道客户端已经丢弃当前的连接。

这种没有客户端发送心跳确保在线的机制，是否能够满足生产的需求，有待商榷

3 客户端一般都是在NAT环境之后，所以客户端无法开启端口对服务器的推送消息进行接收，只有在客户端主动连接服务器，

保持连接的通道，可以进行双向通道的通信

4 服务器端不会主动关闭连接，关闭连接都是由客户端进行的，如果有恶意的连接，耗尽所有的线程，导致拒绝服务的风险