Как реализовать TcpLister, который будет ожидать запроса?

Question

[Nik Faraday]

Здравствуйте!

Для своего asp.net web api нужно добавить Tcp сервер, который будет работать на заднем фоне как BackgroundService. Проблемы в самом сервисе нет, вопрос заключается в создании Tcp слушателя, который будет работать в режиме ожидания аналогично эндпоинтам контроллеров на web api.

Мне не нравится вот такой вариант:

while (!stoppingToken.IsCancellationRequested)
        {
            Console.WriteLine("Waiting for a connection...");
            TcpClient client = await _listener.AcceptTcpClientAsync();

            if (client != null)
            {
                Console.WriteLine("Connected!");
                _ = HandleClientAsync(client, stoppingToken);
            }
        }

И вот такой вариант:

private async void AcceptClientAsync()
    {
        try
        {
            TcpClient client = await _listener.AcceptTcpClientAsync();
            Console.WriteLine("Connected!");

            _ = HandleClientAsync(client);

            AcceptClientAsync();
        }
        catch (Exception ex)
        {
            Console.WriteLine($"Exception: {ex.Message}");
        }
    }

Есть ли лучшие варианты кроме этих, что бы поставить TcpListener в режим ожидания?

Comments

[VoidVolker]

Nik Faraday, а в чем проблема-то данного кода? И раз не нравится - то, что мешает написать свою реализацию?

[Nik Faraday]

VoidVolker, не нравится конкретно while(true) и рекурсивный вызов метода. Я стремлюсь к реализации аналогичной контроллерам asp.net, который ожидают поступающего запроса. Тут я признаюсь, я не знаю, как это работает под капотом, возможно таким же образом, тут я не уверен.

[Sergey В.]

Сделать фоновый сервер в ASP NET проекте - не очень хорошая идея. Дело в том, что web-сервер может произвольно "прибить" процесс, который длительно выполняется и который он посчитает зависшим. Это делается для высвобождения системных ресурсов.
Не могу понять - в какой задаче может потребоваться такая реализация?

[MVV]

Сделать фоновый сервер в ASP NET проекте - не очень хорошая идея.

Sergey В., это в ASP.NET Core до 3.0, пока приложение использовало Web Host, могло быть не очень хорошей идеей (и то, справлялись, и у MS даже было документировано, как это сделать). После же перехода на Generic Host в 3.0 фоновые процессы стали штатной частью приложения (собственно, само веб-приложение именно так устроено). И автор вопроса эту, совершенно штатную, возможность как раз использует, с помощью ппредназначенного кдля этого класса BackgroundService.
Про какой веб-сервер вы гоорите - непонятно: по умолчанию приложение ASP.NET Core - сам себе веб-сервер (по умолчанию используется Kestrel). А если кто-то вдруг захочет убить ваш процесс (оркестратор?) - настройте этого "кого-то", чтобы не своевольничал. Кстати, оснований считать такой процесс зависшим нет: на всякие пробы здоровья по HTTP ему отвечать ничто не помешает.

[MVV]

не нравится конкретно while(true) и рекурсивный вызов метода.

Nik Faraday, в упор не вижу тут while(true)- вижу (в первом варианте) while (!stoppingToken.IsCancellationRequested). Я куда-то не туда смотрю?

Если вас устраивает, что задача, выполняющая HandleClientAsync будет брошена на произвол судьбы, можно использовать оба варианта. Если вы хотите узнать, чем она закончилась - надо делать по-друому.

Во втором варианте рекурсия в норме не возникает: вложенный вызов AcceptClientAsync() по факту возвращается сразу после начала await, и рекурсивный вызов породить способен, только если AcceptTcpClientAsync срабатывает синхронно, а такое - редкость (правда если ваш сервер начнут DDoSить...). Иначе вложенный вызов прозойдет уже в, скорее всего, в потоке из пула, и будет использоваться его стек, т.к. в ExecutionContext стек не входит. Но вот выхода из этого, неявного, цикла прослушивания, действительно, нет. Стоит добавить.

В TcpListener.AcceptTcpClientAsync в любом случае стоит передать CancellationToken, используемый для завершения приложения (напримере, IHostApplicationLifetime.Stopping), чтобы он тоже завершился без задержек при завершении приложения.

[Nik Faraday]

MVV,

Про какой веб-сервер вы гоорите - непонятно

Возможно не корректно выразился. Имеется ввиду аналогичный asp.net'у сервер, который просто будет работать на TcpListner. Делается для связи с приложением на C++.

Тут больше проблема с этим приложением на C++, т.к. связь между ними должна быть реализована по tcp

[Nik Faraday]

MVV, очень прошу прощения, переплутал фрагменты кода. Вот этот while(true):

public async Task StartAsync()
    {
        _listener.Start();

        while (true)
        {
            Console.WriteLine("Waiting for a connection...");
            TcpClient client = await _listener.AcceptTcpClientAsync();

            _ = HandleClientAsync(client);
        }
    }

Да и тот же фрагмент кода c while (!stoppingToken.IsCancellationRequested), что в вопросе, так же не нравится. Почему? Чисто из-за цикла. Повторюсь, ищу способ сделать какое-то ожидание, а не циклическую проверку

[MVV]

Nik Faraday, у васт там для ожидания есть await. Какое ещё ожидание вам нужно?

PS А мой ответ, которым вы отвечали предыдущим комментарием, вообще был не вам.

Answer 1

[Петр]

А зачем вообще использовать TcpLister
Используйте класс Socket

void Init()
{
   listener = new Socket(loopback.AddressFamily, SocketType.Stream, ProtocolType.Tcp);
   listener.Bind(localEndPoint);
   listener.Listen(10);
   listener.BeginAccept(OnBeginAsyncCallback, this);
}
private void OnBeginAsyncCallback(IAsyncResult asyncResult)
{
   var clientSocket = listener.EndAccept(asyncResult);
   listener.BeginAccept(OnBeginAsyncCallback, this);
   // ...
}

Будет реально асинхронно и еще на портах ввода-вывода

Comments

[Nik Faraday]

Нравится ваш вариант. Можете, пожалуйста, показать, как на нём сделать ожидание запроса без циклов?

[Петр]

Nik Faraday,
В OnBeginAsyncCallback вы уже в отдельном потоке, поэтому
Для акцепнутого клиента (тут это socket) сразу вызывается

void ReceiveAsync(byte[] buffer, EventHandler<SocketAsyncEventArgs> releaseEvent)
{
      var asyncEventArgs = AsyncEventArgsPool.Get();

      asyncEventArgs.SetBuffer(buffer, 0, buffer.Length);
      asyncEventArgs.Completed += releaseEvent;

      bool isAsync;
      try
      {
                asyncEventArgs.RemoteEndPoint = socket.RemoteEndPoint;
                isAsync = socket.ReceiveAsync(asyncEventArgs); // если данные уже есть в принимаемом буфере
      }
       catch (Exception ex)
      {
             AsyncEventArgsPool.Release(asyncEventArgs, releaseEvent);
             CloseConnect(ex);
             return;
       }
       if (!isAsync)
       {
           // Данные были в буффере, обрабатываем сразу. (Тут мы еще в отдельном потоке)
            releaseEvent(this, asyncEventArgs);
       }
}

и пример асунхронного обработчика
void OnRecieveDataSizeComplete(object sender, SocketAsyncEventArgs asyncEventArgs)
{
     if (asyncEventArgs.SocketError != SocketError.Success)
     {
           var socketError = asyncEventArgs.SocketError;
           AsyncEventArgsPool.Release(asyncEventArgs, OnRecieveDataSizeComplete);
           CloseConnectOnException(nameof(OnRecieveDataSizeComplete), socketError.ToString());
           return;
      }

      var buffer = asyncEventArgs.Buffer;   // Пришел буфер с данными
      var bytesRead = asyncEventArgs.BytesTransferred; // Сколько было в него записано

       AsyncEventArgsPool.Release(asyncEventArgs, OnRecieveDataSizeComplete); 
       if (bytesRead == 0)
       {
              CloseConnectOnEmpty();
             return;
        }
        var messageSize = BitConverter.ToUInt32(buffer, 0); // Тут я просто получаю сообщение в виде размера остальной части сообщения
        ReceiveData(messageSize); // Тут запуск на получение новой порции данных. У меня это само тело сообщения
}

[Петр]

AsyncEventArgsPool - это мой класс для переиспользования обьектов типа SocketAsyncEventArgs, так как за ними нужно внимательно следить, чтобы не было утечек памяти.
Видел системы где на чистку забивали и память текла просто невероятно быстро.

[Петр]

isAsync = socket.ReceiveAsync(asyncEventArgs);
Этот вызов не будет асинхронным, если данные уже в буффер пришли и поэтому их требуется обработать прям в текущем потоке. Это происходит в созданном самим Socket потоке

Answer 2

[MVV]

Зависит от того, чего вы хотите.
Если вас устраивает, что задача, выполняющая HandleClientAsync для подключившегося клиента будет брошена на произвол судьбы, можно использовать оба варианта (но первый мне нравится больше). Если вы хотите узнать, чем она закончилась - надо делать по-друому.
PS См. также комментарии к вопросу.