谈谈RPC与套接字以及信号

谈谈RPC与套接字以及信号

Rpc的linux实现是很简洁的，这是有目共睹的。事实上rpc机制在linux上只是其n分之一而已，windows才是rpc大行其道的舞台。可是为何rpc没有在unix/linux上得到大规模应用呢？这还得从unix的设计哲学上寻找答案。linux就不必说了，因为它继承了unix的优良基因。

一个rpc几乎最少封装了一个事务，具体的数据封装在经过编码的二进制流中，rpc二进制流中包含了太多的东西以至于它是应用相关的，比如包括过程号，程序号，版本等，rpc接口定义的不仅仅是一个用户接口还包括了应用程序的具体数据，而且即使把它纯粹看做一个接口，那么这个接口（确切地说应该是一套接口，而不是一个）也过于复杂，因为你不能说出一个确切的接口函数来表示rpc接口，当你要列举rpc的接口时，你必须说出这次rpc是做什么的。当然越复杂就越容易出错。rpc可以将复杂的网络交易更快更方便的打包，这也许是它的优势，不像套接字那样，首先你要初始化一个套接字，然后你要自己手动的将数据进行组织，因为套接字并不知道除了传输之外的任何行为性质的东西，而rpc却知道约定的不下20种交易行为。

unix的哲学就是简洁，而且引导程序员用小而简单的接口组合从而实现较大的功能，这样的小接口都是最基本的，而且是正交的，对于这一点，我写都快写烦了。这样的好处在于，系统可以提供一个最小集，所有的元素都可以在这个集合里找到，这个集合里面的接口不包含任何策略性的东西，也就是说系统不限制编程者，当然这提高了编程者的技术门槛，毕竟一切都要自己来，但是这真的给了程序员极大的灵活性。可以实现rpc功能的套接字就是这个正交最小集合中的一员，用它来实现一个功能的话可能要自己组织数据结构，要自己发送，实在很麻烦，但是unix却认为这样很好；相反如果用rpc的话，可能仅仅需要一个函数调用就可以了，但是unix却很不推崇这种行为。

在windows中，几乎一切都是用rpc实现的，这并不是说windows不好，而是windows的系统结构决定了它用rpc是不错的选择。在windows中，到处都是c/s模式的应用，windows本身就是C/S模式架构出来的，在双方知根知底的情况下，用rpc是一个不错的选择，比用套接字或者其它的IPC机制要简洁不少，形式也比较统一，当然也有其弊端，比如不够稳定，客户端和服务器程序双向依赖等等，不过客户端和服务器同在一台机器上，依赖又如何呢？不过windows的rpc确实有很多不尽人意的地方，比如出了问题会连累很多无辜者，另外不够稳定。虽然windows想占rpc的便宜，但是天下没有免费的午餐，其对rpc维护的消耗加上出了问题后解决问题的繁杂带来的劣势已经掩盖了其带来的恩惠；unix就不这样，什么也不想，一心坚持自己的哲学--简单！再看看unix的信号，设置好信号处理函数后，信号就是一个通知，没有附带任何数据，数据和代码分来，这也是策略和机制分离的体现，数据就是策略，代码就是机制，这也是unix的哲学。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。