談談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的哲學。

 本文轉自 dog250 51CTO部落格，原文連結:http://blog.51cto.com/dog250/1274154