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

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

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

WebSocketSharp

當(dāng)前進(jìn)程間通信組件是基于kaistseo/UnitySocketIO-WebSocketSharp實現(xiàn)，主機(jī)內(nèi)設(shè)置一服務(wù)端，多個客戶端連接服務(wù)端，客戶端通信由服務(wù)端轉(zhuǎn)發(fā)數(shù)據(jù)。客戶端A發(fā)送給B后，客戶端B會將執(zhí)行結(jié)果反饋給客戶A。

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

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

這里是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隊列中獲取數(shù)據(jù)： 

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)接收數(shù)據(jù)是這樣拿的： 

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。。。數(shù)據(jù)量那么大，這里搞個同步信號鎖，肯定會堵住咯

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

WebSocketSharp數(shù)據(jù)發(fā)送是基于TCPClient實現(xiàn)的：

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

    _stream = _tcpClient.GetStream ();

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

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

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

但接收時在高并發(fā)場景下，適當(dāng)?shù)耐酱胧┮廊皇潜匦璧摹Ｎ覀兛梢允褂胠ock也可以用SemaphoreSlim來實現(xiàn)復(fù)雜的同步需求，這里使用的是信號鎖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ā)場景下是存在通信阻塞問題的。當(dāng)然，WebSocketSharp已經(jīng)實現(xiàn)的很好了，正常的話幾ms都不會遇到阻塞問題，如下設(shè)置3ms定時超頻發(fā)送、發(fā)送一段時間后：

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

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

WebSocket

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

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

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);
    }

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

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

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

作者：唐宋元明清2188

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

本文版權(quán)歸作者和博客園共有，歡迎轉(zhuǎn)載，但未經(jīng)作者同意必須在文章頁面給出原文連接，否則保留追究法律責(zé)任的權(quán)利。