一種嵌入式RPC的設計與實現
加入技術交流群
過程調用的類型定義如下。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阻塞等待請求的到來。本文引用地址：http://www.j9360.com/article/150615.htm
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客戶端軟件。
評論