Блог

У нас есть несколько клиентов, подключающихся к серверу по именованным каналам. Иногда мы видим pipe/file not found ошибку, когда клиент пытается подключиться к именованному каналу. Наш исходный код

     while (!cancelToken.IsCancellationRequested)
    {
        // This creates a new NamedPipeServerStream
        var stream = PipeHelper.NewCurrentUserServerStream(PipeNames.Server, PipeTransmissionMode.Byte);
        await stream.WaitForConnectionAsync(cancelToken);

        Task.Run(() => HandleStreamAsync(stream).WithExceptionTrapper(LogNamedPipeException));
  

Из того, что я могу сказать, NamedPipeServerStream должен быть создан, а затем WaitForConnection должен быть вызван, затем сервер должен обработать запрос.

Однако, если этот запрос выполняется почти мгновенно или клиент отключает канал, представляется возможным, что серверный поток будет закрыт и весь именованный канал исчезнет, прежде чем цикл кода завершится и будет создан новый серверный поток.

Итак, как мы можем гарантировать, что именованный канал существует в течение всего срока службы сервера, независимо от времени и количества подключающихся клиентов?

Код здесь https://learn.microsoft.com/en-us/dotnet/standard/io/how-to-use-named-pipes-for-network-interprocess-communication предполагает, что простое использование нескольких потоков является вариантом (в этом примере 4). Однако это, по-видимому, только снижает вероятность ошибки, и возможно, что клиент попытается подключиться в редком промежутке, когда все 4 потока только что закрыли серверный поток, и именованный канал исчезает. Кроме того, это ограничивает параллельное выполнение 4 потоками.

Существует ли механизм, позволяющий нам открывать именованный канал-сервер, который допускает произвольное количество подключений, создает новый серверный поток для каждого соединения и никогда не рискует закрыть именованный канал?

Прямо сейчас мы думаем о том, чтобы сделать это:

     var nextStream = PipeHelper.NewCurrentUserServerStream(PipeNames.Server, PipeTransmissionMode.Byte);
    while (!cancelToken.IsCancellationRequested)
    {
        try
        {
            await nextStream.WaitForConnectionAsync(cancelToken);
            var currentStream = nextStream;
            // Always have another stream ready so if the task is handled and finished 
            // really quickly theres no chance of the named pipe being removed altogether.
            nextStream = PipeHelper.NewCurrentUserServerStream(PipeNames.Server, PipeTransmissionMode.Byte);

            Task.Run(() => HandleStreamAsync(currentStream).WithExceptionTrapper(LogNamedPipeException));
        }
  

Это в основном гарантирует, что мы создадим 2-й серверный поток до того, как начнем обрабатывать подключение к 1-му серверному потоку, поэтому мы гарантируем, что всегда есть один активный, и мы запускаем обработчик для отдельной задачи, поэтому мы должны запустить другое WaitForConnection как можно скорее.

Существует ли шаблон фреймворка, который позволяет нам выполнять вышеуказанное, поддерживая любое количество параллельных клиентов и гарантируя, что именованный канал никогда не будет удален при условии, что сервер все еще активен?

Итак, как мы можем гарантировать, что именованный канал всегда существует независимо от времени и количества подключающихся клиентов?

Это невозможно для любого сетевого сервера. Даже TCP / IP (на котором построены именованные каналы) имеет ограниченное «отставание». Даже если вы измените количество невыполненных работ до смешного, вы все равно будете ограничены серверным оборудованием.

Что вы можете сделать, так это всегда сохранять определенное количество прослушивающих вызовов (т. Е. WaitForConnectionAsync ), чтобы у вас всегда было достаточное количество слушателей, постоянно подключающихся, начиная новое прослушивание, как только каждый из них завершается, точно так же, как в вашем последнем примере кода. Вы захотите запустить этот код несколько раз, например, 20 или около того, чтобы у вас было много слушателей. Все, что вы можете сделать, это свести к минимуму вероятность пропуска соединения; вы не можете предотвратить это полностью.