因為最近要用到RPC，考察了一下thrift（facebook用的一套rpc框架）和google protocol buffer。

thrift支持的語言非常多，不光支持c++，java，python，ruby等非常流行的語言外還支持ocaml，Squeak等很少見的語言，比google protocol buffer好多了，而且已經內置RPC，不像google protocol buffer的RPC還藏著掖著。比較google protocol buffer和thrift的文章比較多，其中google到的比較靠前的一篇blog指出thift的c++版本對windows支持不好，我一開始也是覺得如此，主要是thrift只提供了autoconf，automake作為構建工具，在windows上只能用cygwin或者msys才能比較方便的編譯，而google protocol buffer提供了vc的工程文件。另外在代碼的規范性方面，的確是google protocol buffer更好。

此次移植的目的是在windows上運行的client和compiler，因為server肯定是用linux的，移植沒太大必要。根據我從前移植代碼的經驗，發現妨礙移植的關鍵在于系統api的差異，或者是某些依賴庫的差異，如果差異太大，則移植比較麻煩。另外，在移植時我比較傾向于先移植一個最小的功能集合，并逐步完善。

在泛讀了thrift的代碼和文檔后發現thrift中并沒有用到非常難于移植的api，我先用thrift compiler開始，thrift compiler很簡單，基本不用修改就可以在vc2008上編譯，主要依賴的是flex和bison，在windows下也都不難找到，也可以在linux生成后，再把生成的thriftl.cc，thrifty.cc和thrifty.h直接copy過來使用。編譯完成后發現在處理include和externs的時候有問題，主要是linux和windows的路徑分隔符（"/"和"\\"）的差異，修改main.cc里面的program_name和directory_name就可以解決了，這個問題在msys下面也存在。

接下來就是client和server了，我打算主要使用Framed Transport＋Binary protocol＋nonblocking server，因為使用的是libevent（在windows上已經有移植，直接拿過來用就可以了，在linux上面用的是epoll，性能也不錯），也沒有其他的依賴庫，移植起來還是比較方便的。

先從client開始，在TSocket中因為使用了poll來進行超時處理，先改成阻塞方式，將所有的非阻塞和poll相關代碼注釋掉，基本可以編譯成功，然后還有就是ctime_t的地方可以用vc的ctime_s代替，但是dbgtime的長度要改成26。運行tutorial沒什么問題。然后就是加入超時處理了，雖然ms在windows server 2008里面引入了WSAPoll，我用的是xp，只有用select來模擬一個poll了，反正功能差不多，只是接口不太一樣。完成后就可以生成基本的client runtime庫了。

至于server，大致看了一下，里面主要的問題是使用了socketpair和poll，主要是用來做libevent的通知。不過socketpair就自己建兩個socket然后連接起來就可以了，poll用之前client的select模擬實現，移植起來問題應該不大。

client的代碼因為移植時間比較緊，只有半天時間，還沒清理，就不放上來丟人了。

只發一個tutorial的client的exe（需要vc9的runtime才能運行），修改后的Framed Transport＋Binary protocol＋nonblocking server的linux server代碼和compiler的vc9工程代碼。下載