开局篇我们说了,RPC框架的四个核心内容
RPC数据的传输。RPC消息 协议RPC服务注冊RPC消息处理
接下来处理传输数据。实际应用场景一般都是基于socket。socket代码比較多,使用起来也比較麻烦。并且详细的传输通道使用socket或者其它的方式,如更上层的http,或者android里的binder,都是可替换的。仅仅是详细的一种实现而已。所以,这里我就偷个懒,仅仅是引入一个非常easy的Connection类。用来描写叙述一下怎样将传输数据
这一层给独立出来。
首先简单列出Connection类的实现,非常easy,就是两个list。一个管发送。一个管接收。(实现没有考虑多线程安全。实际是必须考虑的)。
须要说明的是,这里的recv的实现约定是堵塞式的,也就是假设没有收到不论什么数据。recv调用会一直堵塞。
class Connection(object):
'''
@RPC 连接。一般说来。都是socket连接。这里简化起见,直接本地变量实现。
'''
def __init__(self, sending_msg_list, recving_msg_list):
'''
Constructor
'''
self.sending_msg_list = sending_msg_list
self.recving_msg_list = recving_msg_list
def send(self, message):
self.sending_msg_list.append(message)
def recv(self):
while len(self.recving_msg_list) == 0: time.sleep(0.01)
return self.recving_msg_list.pop(0)
def isClosed(self):
return False
有了这个connection,剩下的就仅仅要将rpc消息统统通过这个connection去发送。通过这个Connection去接收。
接着改动client的request请求,不再直接调用server端的procRequest方法,而是将请求交给connection,去发送。 然后等待connection收到server端的回复,将回复消息从connection中取出来。
def request(self, req):
# 所有简化处理。不考虑线程安全问题,不考虑异步
# 先是将RPC消息发送到服务端,然后服务端就会处理,并将结果发回到client,client这边接收处理结果。
# self.remote.procRequest(req) // 删除
self.conn.send(req)
rsp = self.conn.recv()
return rsp.result
相同的,改动服务端收到request请求后的处理。首先重复调用connection.recv()方法读取客户端发过来的请求。当请求处理完毕后,不再直接以函数返回的方式return。而是将rsp交给connection。由connection负责传输给client
# def procRequest(self, req): 调整參数列表,不再须要req
def procRequest(self):
# 循环读取并处理收到的客户端请求
while True:
req = self.conn.recv()
rsp = Response()
rsp.id = req.id
if req.command == 'sayHello':
rsp.result = self.sayHello()
elif req.command == 'whoAreYou':
rsp.result = self.whoAreYou()
else:
raise Exception("unknown command")
# return rsp # rsp也是通过connection终于传给client。而不是直接函数返回
self.conn.send(rsp)
最后。列一下connection的初始化
slist = []
rlist = []
client = Client(Connection(slist, rlist))
server = Server(Connection(rlist, slist))
server.start()
总结,引入传输层的意义在于
1. 实现client与server端的解耦,client端不再须要持有server端的对象了。 这也是实现“远程调用 ”所必须的。
2. 传输层的实现有非常大的自由度,一般说来,他无需关心详细的RPC消息的格式。仅仅须要完毕数据的可靠传输就能够了。
3. 传输层详细基于socket。binder, 是採用http,udp。tcp这些都是自由的。依据须要选择就能够了。也就是相当于一个能够自由拼接的组件。
4. 上面的模型实在过于简单,没有考虑多线程保护,没有考虑异常。实际比較理想的情况。应该起码有个类,Connector,以及Channel。当中channel仅仅负责数据的传输,Connector负责管理channel。
兴许假设有时间,会再进行完好
发表评论