前言

　　在前幾個小節中我們講了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對應的字串，你將收到莫名其妙的三種型別的錯誤：

1. 呼叫sendto方法前沒有設定遠程終結點
2. 遠程主機關閉了現有鏈接
3. 內部錯誤

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在實戰中會遇到的一些坑，希望對您有幫助，

標籤：C#

上一篇：C# 將Excel轉為PDF時自定義表格紙張大小

下一篇：瓦片切圖演算法以及并發切圖實踐(上篇)