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的哲學。
談談RPC與套接字以及訊號
rpc的linux實現是很簡潔的，這是有目共睹的。事實上rpc機制在linux上只是其n分之一而已，windows才是rpc大行其道的舞台。可是為何rpc沒有在unix linux上得到大規模應用呢？這還得從unix的設計哲學上尋找答案。linux就不必說了，因為它繼承了unix的優良基因。乙個rp...
Dart的套接字與web套接字
首先在專案中建三個dart檔案，如下圖 main.dart中的 如下 import dart io import dart convert main listarguments socket 1.dart中的 如下 import dart io main listarguments socket 2...
套接字與FIFO
套接字與fifo 全雙工 套接字 特點 sv 0 與sv 1 可讀可寫 案列 客戶端伺服器模型 操作 建立 int socketpair int domain,int type,int protocl,int sv 2 domain 套介面的域 af local af unix type 套介面型別...