那些很差的Socket服務器設計

基礎Socket 

自強的程序猿們都喜歡搞Socket，並且以爲最好本身來封裝個組件出來，若是再往上，加入某種數據協議，讓上層服務器開發照着此協議走，就是一個小小的框架了。因而，從頭開始，最開始的服務器的雛形與下圖有一些類似。

如今服務器能夠經過socket1到n，分別發送二進制數據到達對應的client1到n了，若是服務器的設計到此打住，本文也就到此打住了，但這個的服務器，畢竟離實際能夠拿來做某種服務太遙遠了，就於就有了更深層次的封裝和擴展。

兩種封裝和擴展

第一種：保留Socket1到n不變，擴展ListenerServer

例如，如今有一個需求，要服務器發到客戶端的數據內容爲某些對象序列化後的JSON文本UTF8轉碼後的二進制，經過繼承ListenerServer，咱們能夠封裝一個SendJson的方法

    public class JsonServer : ListenerServer
    {
        public void SendJson(Socket socket, object model)
        {
            var javaScriptSerializer = new System.Web.Script.Serialization.JavaScriptSerializer();
            var json = javaScriptSerializer.Serialize(model);
            this.SendJson(socket, json);
        }

        public void SendJson(Socket socket, string json)
        {
            var buffer = Encoding.UTF8.GetBytes(json);
            socket.Send(buffer);
        }
    }

到此，這種設計感受依然」完美「，若是往上抽象一層，加入某種協議，基礎的ListenerServer的就設計爲ListenerServerBase<T> where T:IProtocol，IProtocol造成協議約束。

讓我說，我以爲這種設計基本能解決問題，但職責不單一，會形成上層通信相關代碼和業務服務API代碼會偶合在一塊兒，沒法分離，由於全部返回數據流，都深深依賴於ListenerServer這個對象。假設ListenerServer爲IIS，socket1到n爲HttpContext，那麼咱們的業務API代碼就依賴於IIS而不是依賴於HttpContext了，但寫了這麼多年Asp.net程序，沒有人能引用IIS程序集，調用IIS.Instance.Response.Write("這是服務器回覆的內容「）如此的代碼吧！

第二種

ListenerServer只做監聽，而socket1到n做相似HttpContext同樣封裝，在此且命名爲Session會話，以下圖 

如今解決剛纔的JSON需求的SendJson的方法以下：

    public class JsonSession : Session
    {
        public void SendJson(object model)
        {
            var javaScriptSerializer = new System.Web.Script.Serialization.JavaScriptSerializer();
            var json = javaScriptSerializer.Serialize(model);
            this.SendJson(json);
        }

        public void SendJson(string json)
        {
            var buffer = Encoding.UTF8.GetBytes(json);
            base.Send(buffer);
        }
    }

到這裏，感受邏輯通順多了，獲得一個session會話實例，就能夠調用session.SendJson（json)了，不依賴於ListenerServer。而基礎ListenerServer能夠設計爲ListenerServer<T> where T:Session，加入的協議在Session的派生類完成。

本文只代碼做者觀點，若是你想繼續深刻第二種擴展方法，能夠參考個人一個socket組件：NetworkSocket