C# SocketSynceventaRgs interrompe l'evento completato

Question

Ho notato un problema in cui l'evento. Completato di un socketSynceventargs sembra smettere di sparare. Lo stesso SAEA può sparare correttamente ed essere sostituiti nella piscina più volte, ma alla fine tutti i casi smetteranno di sparare e poiché il codice per sostituirli nella piscina è nel gestore degli eventi, la piscina svuota.

Il seguenti circostanze sono anche anche veri:

1) Sembra che si verifichi solo quando un socket lato server invia dati a uno dei client connessi. Quando la stessa classe si collega come client, non sembra malfunzionamento.

2) Sembra che si verifichi sotto un carico elevato. Il conteggio dei thread sembra insinuarsi fino a quando alla fine si verifica l'errore.

3) Un impianto di prova sotto stress simile sembra mai malfunzionamento. (Sono solo 20 messaggi al secondo e il rig di test è stato dimostrato a 20k)

Non sarò in grado di incollare il codice piuttosto complicato, ma ecco un Descrizione del mio codice:

1) L'ispirazione principale è questa: http://vadmyst.blogspot.ch/2008/05/sample-code-for-tcp-server-using.html. Mostra come collegare una porta di completamento usando un evento, come ottenere messaggi di dimensioni diverse tramite la connessione TCP e così via.

2) Ho un tampone di byte in cui tutti i saeas hanno un pezzo, che non si sovrappone.

3) Ho un pool di oggetti di SAEAS, basato su un bloccante. Questo lancia se la piscina è vuota per troppo tempo.

4) Come server, mantengo una raccolta di prese restituite dalla funzione AccettaSync, indicizzata dall'endpoint del client. Un singolo processo può utilizzare un'istanza come server e più istanze come client (formando un Web). Condividono il buffer di dati e il pool di SAEAS.

Mi rendo conto che è difficile spiegarlo; L'ho debug per un'intera giornata e notte. Sperando solo che qualcuno ne abbia sentito parlare o abbia domande o suggerimenti utili.

Al momento, sospetto una sorta di stanchezza del filo, portando al SAEAS non riuscire a chiamare il completamento. In alternativa, una sorta di problema con buffer sul buffer in uscita.

Answer 1

Quindi, un altro giorno di debug e infine ho una spiegazione.

1) I SAEA non stavano sparando l'evento completato perché non erano in grado di inviare di più. Ciò è rivelato da Wireshark a causa dello svuotamento della finestra TCP. (TCP Zerowindow)

2) La finestra TCP si stava svuotando perché il livello di networking stava passando un evento sullo stack che impiegava troppo tempo per essere completato, cioè non esiste un produttore/consumatore tra il livello di rete e l'interfaccia utente. Pertanto, l'OP di rete dovrebbe attendere il sorteggio dello schermo prima di inviare l'ACK.

3) L'evento che ha richiesto troppo tempo è stato un sorteggio sullo schermo in un gestore di eventi sulla GUI. L'impianto di prova era una finestra di console (una che ha riassunto i messaggi in arrivo), quindi è per questo che non ha causato un problema a carico molto più elevato. È normale non ridisegnare lo schermo su ogni messaggio, ma ciò stava accadendo perché il progetto non è ancora del tutto fatto. Il tasso di ridisemo sarebbe stato risolto in seguito.

4) La soluzione a breve termine è semplicemente quella di assicurarsi che non ci siano GUI che reggono lo spettacolo. Una soluzione più solida potrebbe essere quella di creare un produttore/consumatore nel livello di rete.