項目上遇到使用WebSocket超時問題，具體情況是這樣的，OTA升級過程中，解壓zip文件會有解壓進度事件，將解壓進度通過進程通信傳給另一進程，通信提示超時異常

小伙伴堂園發(fā)現大文件使用Zip解壓，解壓進度事件間隔竟然是1ms，簡直超大頻率啊

但是，解壓事件超頻也不應該通信異常啊，于是我通過1ms定時發(fā)送通信事件，測試了下進程間通信流程。

WebSocketSharp

當前進程間通信組件是基于kaistseo/UnitySocketIO-WebSocketSharp實現，主機內設置一服務端，多個客戶端連接服務端，客戶端通信由服務端轉發(fā)數據?？蛻舳薃發(fā)送給B后，客戶端B會將執(zhí)行結果反饋給客戶A。

那在定位中發(fā)現，各個鏈路發(fā)送延時都是正常的，包括服務端發(fā)送反饋數據給到客戶端A，但客戶端A接收數據延時很大，下面是部分返回數據：

并且通信時間久了之后，延時會越來越大

這里是WebSocketSharp.WebSocket對外事件OnMessage： 

private void WebSocketOnMessage(object sender, MessageEventArgs e)
    {
        if (!e.IsText)
        {
            //暫時不支持
            return;
        }
        Debug.WriteLine($"{DateTime.Now.ToString("HH:mm:ss fff")},{e.Data}");


        var receivedMessage = JsonConvertSlim.Decode<ChannelServerMessage>(e.Data);
        xxxxx
    }

我們繼續(xù)往下看，OnMessage是由WebSocket.message()觸發(fā)，從_messageEventQueue隊列中獲取數據： 

private void message ()
    {
      MessageEventArgs e = null;
      lock (_forMessageEventQueue) {
        if (_inMessage || _messageEventQueue.Count == 0 || _readyState != WebSocketState.Open)
          return;


        _inMessage = true;
        e = _messageEventQueue.Dequeue ();
      }


      _message (e);
    }

循環(huán)接收數據是這樣拿的： 

private void startReceiving ()
    {
      xxxx
      _receivingExited = new ManualResetEvent (false);
      Action receive = () => WebSocketFrame.ReadFrameAsync (_stream, false,
            frame => {
              if (!processReceivedFrame (frame) || _readyState == WebSocketState.Closed) {
                var exited = _receivingExited;
                if (exited != null)
                  exited.Set ();
                return;
              }
              // Receive next asap because the Ping or Close needs a response to it.
              receive ();
              xxxx
              message ();
            },
            xxxx
          );
      receive ();
    }

這里我看到了ManualResetEvent。。。數據量那么大，這里搞個同步信號鎖，肯定會堵住咯

為何設置線程同步鎖呢？我們往下看

WebSocketSharp數據發(fā)送是基于TCPClient實現的：

     _tcpClient = new TcpClient (_proxyUri.DnsSafeHost, _proxyUri.Port);

    _stream = _tcpClient.GetStream ();

初始化后通過_stream.Write (bytes, 0, bytes.Length);發(fā)送數據

接收數據，也是通過_stream讀取，可以看上方的startReceiving()方法里，WebSocketFrame.ReadFrameAsync (_stream, false,...)

我們知道，TCP是面向連接，提供可靠、順序的數據流傳輸。用于一對一的通信，即一個TCP連接只能有一個發(fā)送方和一個接收方。具體的可以看我之前寫的文章：.NET TCP、UDP、Socket、WebSocket

但接收時在高并發(fā)場景下，適當的同步措施依然是必需的。我們可以使用lock也可以用SemaphoreSlim來實現復雜的同步需求，這里使用的是信號鎖ManualResetEvent

我們再看看發(fā)送端代碼，也是用了lock一個object來限制并發(fā)操作：

private bool send (Opcode opcode, Stream stream)
    {
      lock (_forSend) {
        var src = stream;
        var compressed = false;
        var sent = false;
        xxxxx
        sent = send (opcode, stream, compressed);
        xxxxx
        return sent;
      }
    }

所以WebSocketSharp在高并發(fā)場景下是存在通信阻塞問題的。當然，WebSocketSharp已經實現的很好了，正常的話幾ms都不會遇到阻塞問題，如下設置3ms定時超頻發(fā)送、發(fā)送一段時間后：

客戶端A發(fā)送消息，由服務端轉發(fā)至客戶B，再將客戶端B的反饋結果由服務端轉發(fā)回客戶端A，真正延時才0-2ms！

所以上方項目中遇到的ZIP文件解壓進度超快1ms，只能要ZIP解壓處優(yōu)化下，設置并發(fā)操作10ms內保留最后一個操作，可以參考 .NET異步并發(fā)操作，只保留最后一次操作，即10ms最多觸發(fā)一次解壓進度事件。確實也應該這么優(yōu)化，通信即使撐住這種高并發(fā)，UI刷新這么高幀率也有點浪費CPU/GPU資源。

WebSocket

我們再看看原生的WebSocket，寫個WebSocket通信Demo kybs00/WebSocketDemo (github.com)

服務端定時1ms使勁往客戶端發(fā)送Message消息，結果竟然是：

System.InvalidOperationException:“There is already one outstanding 'SendAsync' call for this WebSocket instance. ReceiveAsync and SendAsync can be called simultaneously, but at most one outstanding operation for each of them is allowed at the same time.”

看來發(fā)送事件外部也要處理好高并發(fā)的場景，1ms真的是太猛了

private SemaphoreSlim _sendLock = new SemaphoreSlim(1);
    private async void Timer_Elapsed(object sender, ElapsedEventArgs e)
    {
        var message = $"{DateTime.Now.ToString("HH:mm:ss fff")},hello from server";


        await _sendLock.WaitAsync();
        await BroadcastAsync("test", message);
        _sendLock.Release();
        Console.WriteLine(message);
    }

加完信號量同步，服務端就能正常發(fā)送了。下面是10分鐘后客戶端接收數據打印，傳輸幾乎無延時：

另外，也嘗試了單獨在客戶端接收添加信號量同步，依然是提示服務端發(fā)送不支持并行的異常。

所以原生WebSocket在發(fā)送端加個需要串行處理比如上面的SemaphoreSlim信號量，保證完整的寫入完數據、執(zhí)行_stream.FlushAsync()。

作者：唐宋元明清2188

出處：http://www.cnblogs.com/kybs0/

本文版權歸作者和博客園共有，歡迎轉載，但未經作者同意必須在文章頁面給出原文連接，否則保留追究法律責任的權利。