C〓〓〓巧は信号スレッド間で通信します.

以前はnodejsを使ったことがありますが、最初はNodejsのことに慣れませんでした.IOがブロックされていないので、閉塞状況の符号化に慣れています. ,渋滞がなくて、かえって憂鬱になりました.
nodejs IOでは、ブロックはありませんが、ファイルの原因となります.ネットワーク通信はC〓と同じ実行方式ではなく、nodejsではcall backメソッドのコールバックで一連の呼び出しを行います.慣れてくると、その美しさに気づきます.例えばサイクルの中で、何度も要求を送ります.毎回応答してから、また送ります.C〓〓〓の中で簡単で、ポートの傍受がスレッドをブロックすることができるため、要求を受信するまで.新しい要求を送るコードは受信後に実行すればいいです. 
しかし、同じコードロジックはnodejsではだめです.通信はスレッドをブロックしないので、サイクルは短い時間で走り終わります.実は、一時間ですべての要求を全部送ります.応答を受けて次の要求を送信する目的は達成できません.  しかし、次回のお願いはcalbackに置いてもいいです.これは受け取ってから送ることを保証します.このような事件は思考的にはC〓より分かりやすいようです.
今日はプログラムで面白いところに会いました.

static void Main(string[] args)
        {
            webSocket = new Client();
            // set event hander
            webSocket.ResponseEvent = ResponseHandler;
            webSocket.OpenEvent = OpenHandler;
            webSocket.CloseEvent = CloseHandler;
            webSocket.ErrorEvent = ErrorHandler;
            webSocket.MessageRecvEvent = MessageRecvHandler;

            manualEvent.Reset();
            manualEvent.WaitOne();
            Console.ReadKey();
        }

は上述のように、manaual Eventがないと、メインスレッドはすぐに実行されますが、socketは将来的に実行されます.このような手続きでは全然走れません.しかし、メインスレッドでマンツーマンイベントを通じてメインスレッドをブロックして待ちます.soecketのReponseイベント(非同期的に他のスレッドで実行)では manaual Eventのsetメソッドを呼び出して、メインスレッドを続けて実行させます.
この一連の過程はnodejsの次の普通のsocketに似ています.ただし、そのメインスレッド(Javascriptを実行するスレッド)は、非同期動作が終了する前に、 閉じられないようです.  さもなくばこのように間違いなく完成することを保証しますか?これはまだ検討が必要です.
 Any suggaestions are welcome.