C#使用Thrift作為RPC框架實戰（四）之TSocket

楊凱2020發表於2021-11-30
C#RPC框架

前言

　　在前幾個小節中我們講了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在實戰中會遇到的一些坑，希望對您有幫助。

相關文章