C#使用Thrift作為RPC框架實戰（四）之TSocket
前言
在前幾個小節中我們講了Thrift框架的基本概念以及重要的名稱空間，接下來的幾個小節，我們將站在實戰的角度來深入講解一些Thrift的重要類型。本小節我先要講一下Thrift框架支援TCP通訊的類，客戶端TSocket，伺服器端TServerSocket。
客戶端TSocket
Tsocket作為Thrift框架實現TCP通訊的底層類型（上面兩層分別為Protocol層和Client層），我們首先來看一下TSocket的構造函數：
public TSocket(TcpClient client); public TSocket(string host, int port); public TSocket(string host, int port, int timeout);
Tsocket有三個構造函數：
- + 第一個構造需要我們自己維護一個TcpClient，對於熟悉.net Socket通訊的同學來說，這個很簡單，就不在此贅述了
- + 第二個和第三個構造函數相似，唯一的不同是在是否有設置超時時間TimeOut這個參數上
構造函數 有無timeout參數的問題
我們重點來講一些後兩個構造函數上，其實後兩個構造函數在內部實現上並無差別，看一下源碼我們就清晰了：
public TSocket(string host, int port) : this(host, port, 0)
{
}
public TSocket(string host, int port, int timeout)
{
this.host = host;
this.port = port;
this.timeout = timeout;
this.InitSocket();
}
在內部實現上如果我們不設置timeout參數，它會被設置為0，然後還是調用三個參數的構造構造函數的。是不是我們調用這個兩個構造函數去實例化這個類沒有一點差別呢？答案是 否定的。他們在調用**Open**方法時走了不同的程式碼分支：
if (this.timeout == 0)
{
this.client.Connect(this.host, this.port);
}
else
{
TSocket.ConnectHelper connectHelper = new TSocket.ConnectHelper(this.client);
IAsyncResult asyncResult =
this.client.BeginConnect(this.host, this.port,
new AsyncCallback(TSocket.ConnectCallback), connectHelper);
if (!asyncResult.AsyncWaitHandle.WaitOne(this.timeout) || !this.client.Connected)
{
......
這裡先說明一點Timeout參數被賦值給TcpLient類型的SendTimeout和ReceiveTimeout參數上：
public int Timeout
{
set
{
TcpClient arg_1E_0 = this.client;
TcpClient arg_18_0 = this.client;
this.timeout = value;
arg_18_0.SendTimeout = value;
arg_1E_0.ReceiveTimeout = value;
}
}
如果你沒有設置timeout參數，需要記住一點，host參數你要傳IPv6對應的字元串，如果你傳了ipv4對應的字元串，你將收到莫名其妙的三種類型的錯誤：
- 調用sendto方法前沒有設置遠程終結點
- 遠程主機關閉了現有鏈接
- 內部錯誤
thrift框架在錯誤提示上有點不友好，給出的錯誤提示沒有一點用處。這個錯誤解決的方法我們可以從源碼上找到問題所在，請看一下程式碼：
internal static TcpClient CreateTcpClient()
{
return new TcpClient(AddressFamily.InterNetworkV6)
{
Client =
{
DualMode = true
}
};
}
上面程式碼我們在**InitSocket**方法中找到創建TcpClient類型的方法，我們一下程式碼已經知道了原因，因為將TcpClient類型定位到了InterNetworkV6的類型，如果我們創建時傳了ipv4的地址，就會出上述問題。如果，我們設置了timeout參數，既是我們傳了ipv4的地址也不會有問題，這個可能和connect,beginconnect兩種鏈接方式的內部實現有關吧。
服務端
伺服器端就是一個監聽連接，處理請求的過程，上文我們已經講過伺服器端的處理大致處理過程，這裡不再贅述。
TMultiplexedProtocol和TMultiplexedProcessor
接下來我們將一下合併監聽埠的主要的處理類，TMultiplexedProtocol為客戶端使用類，TMultiplexedProcessor為伺服器端使用類。前面的文章，我們提到過這兩個類怎麼用，也對兩個類的調用方法進行的簡單的封裝處理，這裡我想講一下它們的內部時怎麼處理請求的。
想要說明一個類的實現原理，最好的方法時帶著大家去看下它的源程式碼，首先，我們看一下TMultiplexedProtocol的部分源碼：
public override void WriteMessageBegin(TMessage tMessage)
{
TMessageType type = tMessage.Type;
if (type == TMessageType.Call || type == TMessageType.Oneway)
{
base.WriteMessageBegin(new TMessage(this.ServiceName
+ TMultiplexedProtocol.SEPARATOR + tMessage.Name, tMessage.Type,
tMessage.SeqID));
return;
}
base.WriteMessageBegin(tMessage);
}
看過源碼後，我們一目了然，是的，它把ServiceName寫到了請求中，那麼在伺服器端時怎麼處理的呢？同樣，我們看下伺服器端的處理方法：
public bool Process(TProtocol iprot, TProtocol oprot)
{
bool result;
try
{
TMessage message = iprot.ReadMessageBegin();
if (message.Type != TMessageType.Call &&
message.Type != TMessageType.Oneway)
{
this.Fail(oprot, message,
TApplicationException.ExceptionType.InvalidMessageType,
"Message type CALL or ONEWAY expected");
result = false;
}
else
{
int num =
message.Name.IndexOf(TMultiplexedProtocol.SEPARATOR);
if (num < 0)
{
this.Fail(oprot, message,
TApplicationException.ExceptionType.InvalidProtocol,
"Service name not found in message name: " + message.Name
+ ". Did you forget to use a TMultiplexProtocol in your client?");
result = false;
}
else
{
string text = message.Name.Substring(0,
num);
TProcessor tProcessor;
if (!this.ServiceProcessorMap.TryGetValue(text, out tProcessor))
{
this.Fail(oprot, message,
TApplicationException.ExceptionType.InternalError,
"Service name not found: " + text
+ ". Did you forget to call RegisterProcessor()?");
result = false;
}
else
{
TMessage messageBegin = new
TMessage(message.Name.Substring(text.Length +
TMultiplexedProtocol.SEPARATOR.Length), message.Type, message.SeqID);
result = tProcessor.Process(new
TMultiplexedProcessor.StoredMessageProtocol(iprot, messageBegin), oprot);
}
}
}
}
看到源碼中的第一個else分支，它解析出serviceName，然後在中ServiceProcessorMap集合中獲取我們之前註冊過的對應的請求處理器。
其他一些問題
-
+ 伺服器端被調用的方法不能返回Null類型，否則調用方法會拋出異常
-
+ thrift框架進行RPC調用是不是執行緒安全的，因此，執行緒安全部分需要自己去處理
結尾
本小節我們講述了Tsocket在實戰中會遇到的一些坑，希望對您有幫助。
