由于我們現(xiàn)在所搭建的系統(tǒng)是基于分布式的系統(tǒng)，出于性能考慮決定基于RPC技術(shù)進行系統(tǒng)間的互操作與互通信。團隊內(nèi)在使用一個已被封裝的RPC工具包，為什么稱它為工具包呢？因為它要生成兩個頭文件和兩個庫文件，其實它還會生成一些監(jiān)時文件，只不過在它在生成靜態(tài)庫時就會把這些臨時文件刪除。這里逐個介紹它的戰(zhàn)果，頭文件就是接口方法的聲明和編譯控制選項，這里要談的是它的靜態(tài)庫文件，它是由idl生成的代理文件和存根文件并由再加入內(nèi)存的分配和釋放的兩個函數(shù)及必要的入口函數(shù)來生成。為什么這樣說？首先可以通過編譯時出現(xiàn)的提示串。其次反匯編該文件。
于我嘗試用該框架做一個helloworld，其間我經(jīng)歷了幾次沮喪或者近乎冒火。靜下心來，仔細分析。首先查看服務(wù)端已開啟了偵聽，發(fā)現(xiàn)客戶端也已經(jīng)發(fā)送，服務(wù)端也已到達，但就是沒有達到服務(wù)函數(shù)。最后問題定位在權(quán)限問，其實這個問題在我前面的博文中也已經(jīng)詳談了。解決辦法：去除服務(wù)端對RPC的限制，其次反匯編該工具后發(fā)現(xiàn)了是服務(wù)端注冊接口函數(shù)，解決辦法在前面的博文中也已詳述，靜態(tài)hook也成，動態(tài)hook的方法也成。當前就用了第一種方法，最好的辦法還是不用它，而重新寫一個了。
這個工具雖然讓我花了近一天來反匯編它，最后卻發(fā)現(xiàn)都是封裝的。但是其中的封裝的思想?yún)s是值得借鑒的。這樣減輕一般用戶的使用難度，而且也搞得玄了些。哈哈，就怕我不暈。