Переполнение стека при использовании System.Net.Sockets.Socket.AcceptAsync модели

Question

Что касается метода C# и .NET System.Net.Sockets.Socket.AcceptAsync, то потребуется обработать возвращаемое значение «false», чтобы обрабатывать сразу доступное состояние SocketAsyncEventArgs от синхронно обработанного соединения. Microsoft предоставляет примеры (найденные на странице класса System.Net.Sockets.SocketAsyncEventArgs), что приведет к переполнению стека, если существует большое количество ожидающих подключения соединений, которые могут быть использованы в любой системе, которая реализует свою модель обработки.

Другие идеи для решения этой проблемы состоят в том, чтобы создать цикл, который вызывает метод обработчика, при условии, что значение Socket.AcceptAsync возвращает значение false и разбить цикл (чтобы разрешить отложенную обработку), если значение указывает, что операция выполняется асинхронно (true). Однако это решение также вызывает уязвимость переполнения стека из-за того, что обратный вызов, связанный с SocketAsyncEventArgs, переданный в Socket.AcceptAsync, имеет в конце метода вызов Socket.AcceptAsync, который также имеет цикл для сразу доступных, синхронно принятых соединений ,

Как вы можете видеть, это довольно солидная проблема, и мне еще предстоит найти хорошее решение, которое не связано с System.Threading.ThreadPool и созданием множества других методов и обработки планирования. Насколько я вижу, асинхронная модель сокета, относящаяся к Socket.AcceptAsync, требует больше, чем показано в примерах в MSDN.

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

Answer 1

я бы не использовать AcceptAsync, а BeginAccept/EndAccept и правильно реализовать обычный шаблон асинхронизации, то есть проверять на наличие CompletedSynchronously, чтобы избежать обратных вызовов в потоке обратного вызова при завершенных операциях.

Смотрите также AsyncCallBack CompletedSynchronously

---

Edit относительно требований использовать AcceptAsync:

MSDN documentation явно говорит о том, что обратный вызов не будет вызываться для операций, выполненных синхронно. Это отличается от обычного асинхронного шаблона, где обратный вызов всегда вызывается.

Возвращает true, если операция ввода-вывода не ожидается. Событие SocketAsyncEventArgs.Completed по параметру e будет поднято после завершения операции . Возвращает false, если операция ввода-вывода завершена синхронно. SocketAsyncEventArgs.Completed событие от параметра е не будет поднято и й объект, переданный в качестве параметра может быть рассмотрен сразу же после того, как вызов метода возвращает для получения результата операции.

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

---

Edit 2: Я имею в виду код, как это (только в отношении AcceptAsync, остальное было просто получить рабочее приложение, чтобы попробовать его с):

static void Main(string[] args) { 
    Socket listenSocket = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp); 
    listenSocket.Bind(new IPEndPoint(IPAddress.Loopback, 4444)); 
    listenSocket.Listen(100); 
    SocketAsyncEventArgs e = new SocketAsyncEventArgs(); 
    e.Completed += AcceptCallback; 
    if (!listenSocket.AcceptAsync(e)) { 
     AcceptCallback(listenSocket, e); 
    } 
    Console.ReadKey(true); 
} 

private static void AcceptCallback(object sender, SocketAsyncEventArgs e) { 
    Socket listenSocket = (Socket)sender; 
    do { 
     try { 
      Socket newSocket = e.AcceptSocket; 
      Debug.Assert(newSocket != null); 
      // do your magic here with the new socket 
      newSocket.Send(Encoding.ASCII.GetBytes("Hello socket!")); 
      newSocket.Disconnect(false); 
      newSocket.Close(); 
     } catch { 
      // handle any exceptions here; 
     } finally { 
      e.AcceptSocket = null; // to enable reuse 
     } 
    } while (!listenSocket.AcceptAsync(e)); 
} 

Answer 2

Я не смотрел внимательно, но он пахнет, как это могло бы быть полезным (смотрите раздел под названием «стек погружение»):

http://blogs.msdn.com/b/mjm/archive/2005/05/04/414793.aspx

Answer 3

У меня есть разрешили эту проблему, просто изменив размещение петли. Вместо того, чтобы рекурсивно вызывать обработчик accept изнутри, обертывание кода в цикле do-while с условием «! Socket.AcceptAsync (args)» предотвращает переполнение стека.

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

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

Конечно, если у кого-то есть лучшее решение или даже альтернатива, я был бы рад это услышать.

Answer 4

newSocket.Send(Encoding.ASCII.GetBytes("Hello socket!")); 
newSocket.Disconnect(false); 
newSocket.Close(); 

Проблема с этим фрагментом выше заключается в том, что это заблокирует вашу следующую операцию приема.

Лучший способ, как это:

while (true) 
{ 
    if (e.SocketError == SocketError.Success) 
    { 
     //ReadEventArg object user token 
     SocketAsyncEventArgs readEventArgs = m_readWritePool.Pop(); 
     Socket socket = ((AsyncUserToken)readEventArgs.UserToken).Socket = e.AcceptSocket; 

     if (!socket.ReceiveAsync(readEventArgs)) 
     ThreadPool.QueueUserWorkItem(new WaitCallback(ProcessReceiveEx), readEventArgs); . 
    } 
    else 
    { 
     HadleBadAccept(e); 
    } 

    e.AcceptSocket = null; 

    m_maxNumberAcceptedClients.WaitOne(); 
    if (listenSocket.AcceptAsync(e)) 
     break; 
}