Overflow dello stack quando si utilizza System.Net.Sockets.Socket.AcceptAsync model

Question

Per quanto riguarda il metodo C# e .NET System.Net.Sockets.Socket.AcceptAsync, sarebbe necessario gestire un valore restituito di "false" per gestire lo stato immediatamente disponibile SocketAsyncEventArgs dalla connessione elaborata in modo sincrono. Microsoft fornisce degli esempi (che si trovano sulla pagina della classe System.Net.Sockets.SocketAsyncEventArgs) che causerà un sovraccarico dello stack in presenza di una grande quantità di connessioni in sospeso, che possono essere sfruttate su qualsiasi sistema che implementa il loro modello di gestione.

Altre idee per aggirare questo problema sono creare un ciclo che richiami il metodo del gestore, con la condizione che il valore Socket.AcceptAsync restituisca uguale a false e interrompa il ciclo (per consentire l'elaborazione posticipata) se il valore indica che l'operazione è in corso in modo asincrono (true). Tuttavia, questa soluzione causa anche una vulnerabilità di overflow dello stack a causa del fatto che il callback associato a SocketAsyncEventArgs passato a Socket.AcceptAsync ha alla fine del metodo una chiamata a Socket.AcceptAsync, che ha anche un ciclo per le connessioni immediatamente disponibili, accettate in modo sincrono, .

Come potete vedere, questo è un problema piuttosto solido, e devo ancora trovare una buona soluzione che non coinvolge System.Threading.ThreadPool e la creazione di tonnellate di altri metodi e l'elaborazione di pianificazione. Per quanto posso vedere, il modello di socket asincrono relativo a Socket.AcceptAsync richiede più di quello dimostrato negli esempi su MSDN.

Qualcuno ha una soluzione pulita ed efficiente per gestire immediatamente le connessioni in attesa accettate in modo sincrono da Socket.AcceptAsync senza dover creare thread separati per gestire le connessioni e senza ricorrere alla ricorsione?

Answer 1

Non userei AcceptAsync, ma piuttosto BeginAccept/EndAccept e implementare correttamente il modello asincrono comune, ovvero il controllo di CompletedSynchronously per evitare le richiamate nel thread di richiamata sulle operazioni completate.

Vedi anche AsyncCallBack CompletedSynchronously

---

Modifica per quanto riguarda l'obbligo di utilizzare AcceptAsync:

Il MSDN documentation dice esplicitamente che il callback non verrà richiamato per le operazioni che hanno completato in modo sincrono. Questo è diverso dal comune schema asincrono in cui la richiamata è sempre invocata.

Restituisce vero se l'operazione di I/O è in sospeso. L'evento SocketAsyncEventArgs.Completed sul parametro e verrà generato al termine dell'operazione . Restituisce false se l'operazione di I/O ha completato in modo sincrono. Il SocketAsyncEventArgs.Completed evento sul parametro e non verrà sollevata e l'oggetto e passato come parametro può essere esaminata immediatamente dopo la chiamata al metodo ritorna per recuperare il risultato dell'operazione.

Attualmente non vedo come un ciclo non risolva il problema di overflow dello stack. Forse puoi essere più specifico sul codice che causa il problema?

---

Edit 2: Sto pensando di codice come questo (solo per quanto riguarda AcceptAsync, il resto è stato solo per ottenere un'applicazione di lavoro per provarlo con):

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

non ho guardato con attenzione, ma odora questo potrebbe essere utile (si veda la sezione chiamata "stack dive"):

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

Answer 3

ho risolto questo problema semplicemente cambiando il posizionamento del ciclo. Invece di chiamare in modo ricorsivo il gestore accept da se stesso, avvolgere il codice in un ciclo do-while con la condizione "! Socket.AcceptAsync (args)" impedisce un overflow dello stack.

Il ragionamento alla base di questo è che si utilizza il thread di richiamata per elaborare le connessioni che sono immediatamente disponibili, prima di preoccuparsi di attendere in modo asincrono altre connessioni. Sta riutilizzando un thread in pool, in modo efficace.

Apprezzo le risposte ma per qualche motivo nessuno di loro ha cliccato con me e non ha risolto il problema. Tuttavia, sembra che qualcosa lì dentro abbia spinto la mia mente a venire con questa idea. Evita di lavorare manualmente con la classe ThreadPool e non usa la ricorsione.

Ovviamente, se qualcuno ha una soluzione migliore o anche un'alternativa, sarei felice di sentirlo.

Answer 4

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

Il problema con questo frammento di codice sopra è che questo bloccherà la tua prossima operazione di accettazione.

Un modo migliore è come questo:

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