摘要：在研究遠程過程調用的原理和嵌入式系統特點的基礎上，提出一種遠程過程調用的設計以及在VxWorks操作系統上服務器端和在Win-dows探作系統上客戶端的實現。經在項目中的應用，本設計與實現體現了良好的實用性、移植性和擴展性。
關鍵詞：遠程過程調用；嵌入式系統；網絡；狀態機
遠程過程調用(Renmte Procedure call，RPC)最早是在B．J．Nelson的博士論文中論述的。這里的過程等價于例程，函數的意思。RPC的思想源于大多數的程序都以過程作為最小設計單位。RPC擴展了過程調用機制，允許客戶端的過程通過網絡調用服務器端的過程。
從RPC的思想出發，不同的組織和公司開發了不同的RPC協議。有SUN公司的ONC RPC，開放軟件基金會的DCE RPC，微軟公司的MSRPC等。這些RPC都依賴與特定操作系統，并且定義了自己的接口描述語言(IDL)，對于嵌入式開發過于復雜。
1 RPC的機制
1．1 過程調用
典型的過程調用就是過程A將參數和控制權交給過程B，過程B經過一系列運算或者下一級過程，最后把結果和控制權返回給過程A。
1．2 RPC流程
RPC分為同步RPC和異步RPC。在同步RPC中客戶端發出RPC調用的線程將被阻塞，直到從服務器端完成。異步RPC中客戶端發出調用的線程不會被阻塞而是繼續執行。本文以同步RPC為研究對象。
RPC的思想就是使遠程過程調用看上去就像在本地的過程調用一樣。從程序運行角度來看，其流程如圖1所示。客戶端(MACHINE A)的進程通過網絡發送遠程過程調用請求給服務器(MACHINE B)。服務器收到請求后處理，調用相應的過程執行，執行完畢后服務器返回結果給客戶進程。客戶進程在發出遠程過程調用后被阻塞，直到服務器返回結果給客戶進程。
1．3 RPC的結構模型
從描述的角度出發，產生不同的RPC模型如Andrew S．Tanenhum在其著作分布式操作系統中論述的模型以及B.J．Nelson論文中的RPC模型等。但這些模型的主要組件都是相同的。圖2是B.J．Nelson博士的RPC結構模型。客戶進程、客戶存根和RPC運行庫實例在客戶端執行。服務進程、服務器存根和RPC運行庫實例在服務器端執行。客戶過程調用相應的客戶存根。客戶存根打包參數。客戶端的RPC運行庫將打包好的參數通過網絡發送給服務器RPC運行庫。服務器存根拆包參數，然后調用服務器過程。完成后返回結果給服務器存根。服務器存根打包結果給服務器RPC運行庫。服務器RPC運行庫發送打包好的參數給客戶RPC運行庫。客戶存根拆包并將結果取出返回給客戶。
盡管RPC的思想比較簡單，但有很多問題需要考慮。由于有很多不同的CPU，如X86、ARM、SPARC等以及各種DSP、單片機，產生了參數傳遞問題。如X86采用最低有效字節優先，而SPARC是最高字節優先。有些大型機采用EBCDIC碼，而其他處理器采用ASCII碼。存根就是用來解決這些問題。還有指針問題，涉及物理地址、虛擬地址、地址空間等很多考慮。我們知道不同計算機之間無法直接訪問彼此的地址。還有過程的參數如果為數據結構，這就引出數據對齊的問題。由此可以推斷所有的RPC實現都在一定的范圍適用。本文的RPC設計假定客戶端和服務器端有相同的大小端和并且都是32位處理器。
1．4 SunRPC
Sun RPC有時也稱為ONC(Open Network Computing)RPC。Sun RPC提供了一個接口語言IDL和rpcgen用于C語言支持。這門語言可以定義constants，typedef，structure，union。rpcgen可以產生server code，client stub和頭文件。server code主要是建立socket，注冊端口和監聽，接受連接，拆參數，調用實際的過程，打包返回值。client stub則是打包參數，發送給server，將返回值解包。Sun RPC缺點就是對Windows沒有很好的支持。
2 設計
本設計與傳統的模型不同，服務器端分為：網絡通訊，接收狀態機和過程處理。客戶端分為網絡通訊，發送狀態機和過程調用。
圖3是服務器端的狀態機。服務器進程從初始狀態進入GetHeader狀態。GetHeader是讀取遠程過程調用的頭信息。如果一次得到了所有數據，也就是nCurLen>=dwTotalSize，則進入GetComplatePacket狀態，反之進入GetData狀態。GetData是讀取參數數據，讀取數據直到得到所有的數據進入GetComplatePacket狀態。期間如果超時，則回到GetHeader狀態。超時的起始時間從GetHeader韻第一個字節算起，如果在定義的時間無法讀取dwTotalSize個字節，則Timeout從而回到GetHeader狀態。在GetHeader和GetData時，如果讀取數據有錯誤(如客戶端斷開連接，recv函數返回錯誤)則狀態機退出。GetComplatePacket是得到了完整的包。CheckCall判斷當前的調用是否是有效的過程調用。如果無效則進入狀態，并回復無效命令給客戶端，最后進入GetHeader狀態。如果有效，則處理此調用，最后發送結果給客戶端。
圖4為客戶端狀態機。首先是打包參數，發送到服務器端，等待服務器端的回復，進入GetHeader狀態。GetHeader，GetData和Get Com-plate Packet與服務器相應的狀態意義相同。如果timeout則返回timeout錯誤。如果得到了整個packet則拆分最后返回。
DCE—RPC和ONC—RPC允許選擇UDP或TCP協議。TCP協議傳輸控制協議，提供的是面向連接、可靠的字節流服務。UDP協議不提供可靠性，它只是把應用程序傳給IP層的數據報發送出去，但是并不能保證它們能到達目的地。基于TCP協議的可靠性，選擇TCP作為通訊協議。
3 實現
3．1 數據結構
服務器和客戶用共用包頭信息和每個過程的參數結構。頭信息定義如下。dwCallID是過程的標識號。每個過程都有一個唯一的號碼。bCallType是調用的類型。dwTotalSize是整包的字節數。dwReturn是返回結果。
過程調用的類型定義如下。RPC_TYPE_SIMPLE_WRITEREAD是簡單的讀寫，輸入參數和輸出參數都在頭信息和過程的參數數據結構中。RPC_TYPE_READ指返回結果保存在單獨的內存。RPC_TYPE_WRITE指寫信息保存在單獨的內存。RPC_TYPE_WRITE_READ調用是需要內存保存輸入數據，返回時需要保存輸出的結果。
每個過程定義自己的輸入輸出參數結構。例如對獲取串口狀態GetCommState過程，建立RPC_GETCOMMSTATE結構。
由于各個編譯器對struct數據結構的成員的對齊實現不同。這樣同樣的struct在客戶端和服務器端的大小可能不同，同樣的成員在結構中的位置不同。為了確保客戶端和服務器端有相同的對齊，我們采用字節對齊用#pragma pack(1)。
3．2 Packet內存布局
開始依次是頭信息和參數，其余部分根據特定的過程而不同。以RPC_TYPE_WRITE_READ類型的布局為例：頭信息，參數，輸入內存塊[1…N]，輸出內存塊[1…N]。其他的過程類型布局類似。
3．3 服務器端實現
3．3．1 網絡模塊實現
RPC在單獨的任務中執行。圖5為RPC任務流程圖。調用VxWorks的系統函數taskSpawn建立RPC任務。調用socket( )建立面向連接的SOCK_ STREAM套接字，bind將套接字與本地網絡地址和端口號捆綁，listen申明要在該端口偵聽客戶連接請求，accept阻塞等待請求的到來。
3．3．2 狀態機實現
當accept后，進入服務器端狀態機。設置accept返回的socket為非阻塞狀態。在阻塞的socket上調用send時，如果沒有足夠的輸出緩沖區，該調用將被阻塞。Recv也是一樣，要讀的數據沒有就緒時，調用者阻塞。服務器不知道每次要讀取的字節數，所以阻塞的socket無法工作。
分配2塊內存：A和B。內存A用來保存recv的內容，內存B用來保存客戶端發送的Packet內容。因為服務器不知道客戶會發送多大的內容過來，每次從內存A拷貝到內存B之前檢查內存B的大小，如果內存B剩余大小不夠則重新分配。
在得到了整個Packet后，即GetComplatePacket后，根據dwCallID調用服務器的本地過程，待返回后將返回值和內存打包發送給客戶端。
3．4 客戶端實現
客戶端的流程如圖6所示。在Windows下運行，首先調用WSAStartup，Windows根據請求的Socket版本來搜索相應的Socket庫，然后綁定找到的Socket庫到該應用程序中。然后初始化socket，連接到服務器，接著過程調用。比如過程調用1會進入圖4狀態機。狀態機和服務器端類似，只是首先參數打包，發送給服務器，返回后拆包并拷貝返回信息到內存中。
4 結束語
本文設計和實現的RPC可應用于白盒測試、跨平臺開發環境和開發客戶端軟件等。商用的嵌入式IDE軟件都很昂貴，通過本RPC，測試人員就可用開源的環境如cygwin等開發白盒測試代碼。另外對于有大量操作界面的嵌入式開發，需要頻繁下載到開發板上驗證，本文RPC可應用于構建跨平臺的開發環境，直接在Windows上開發界面部分，最后下載到開發板上，從而大大提高開發效率。大多數的嵌入式軟件都有相應的PC客戶端軟件，本文的實現也適用于開發PC客戶端軟件。