Uno stack TCP / IP può essere ucciso a livello di codice?

Question

La nostra applicazione server è in ascolto su una porta e dopo un certo periodo di tempo non accetta più connessioni in entrata. (E mentre mi piacerebbe risolvere questo problema, non è quello che sto chiedendo qui;)

Lo strano è che quando la nostra app smette di accettare connessioni sulla porta 44044, anche IIS (sulla porta 8080). Uccidere la nostra app risolve tutto: IIS inizia a rispondere di nuovo.

Quindi la domanda è: un'applicazione può incasinare l'intero stack TCP / IP? O forse, come può un'applicazione farlo?

Dettagli senza senso: la nostra app è scritta in C #, sotto .Net 2.0, su XP / SP2.

Chiarimento: IIS non " rifiuta " i tentativi di connessione. Non li vede mai. I clienti stanno ottenendo un server "non ha risposto in modo tempestivo" messaggio (utilizzando il client .Net TCP.)

Answer 1

Potresti star morendo di fame. È abbastanza facile drenare in un ambiente aperto / chiuso al secondo ambiente ad es. server web che serve molte richieste non raggruppate.

Questo è esaurito dal ritardo TIME-WAIT predefinito: la quantità di tempo in cui un socket deve essere chiuso prima di essere riciclato è impostato su 90s (se ricordo bene)

Ci sono un sacco di chiavi di registro che possono essere modificate - suggerisci che almeno le seguenti chiavi sono create / modificate

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

TcpTimedWaitDelay = 30
MaxUserPort = 65534 
MaxHashTableSize = 65536 
MaxFreeTcbs = 16000 

Un sacco di documenti su MSDN e amp; Technet sulla funzione di questi tasti.

Answer 2

Non hai raggiunto il limite massimo degli handle di porta disponibili?
     netstat -a

Ho visto qualcosa di simile quando un'app apriva e chiudeva le porte (ma in realtà non le chiudeva correttamente).

Answer 3

Usa netstat -a per vedere le connessioni attive quando ciò accade. Forse, l'app del server non sta chiudendo / eliminando connessioni "chiuse".

Answer 4

Buoni suggerimenti da parte di tutti, grazie per il vostro aiuto.

Quindi, ecco cosa stava succedendo: Si scopre che avevamo diversi servizi in competizione per lo stesso porto e il più delle volte il "corretto" il servizio otterrebbe il porto. Di tanto in tanto un secondo servizio prenderebbe via il porto e il primo servizio proverebbe ad aprire un altro porto. Da quel momento in poi, i servizi continuerebbero ad afferrare nuove porte ogni volta che soddisfacessero una richiesta (poiché non stavano usando le loro porte preferite) e alla fine esauriremmo tutte le porte disponibili.

Ovviamente, la vera domanda era: "Un'applicazione può rovinare l'intero stack TCP / IP?" e la risposta a questa domanda è: Sì. Un modo per farlo è ascoltare un sacco di porte.

Answer 5

Suppongo che il commento sul numero di porta di RichS sia corretto.

Oltre a ciò, lo stack TCP / IP è solo un modulo nel sistema operativo e, come tale, può contenere bug che potrebbero consentire a un'applicazione di ucciderlo. Non sarebbe il primo pilota ad essere ucciso da un programma.

(Un suggerimento per Andrew Tanenbaum per aver insistito sul fatto che i sistemi operativi dovrebbero essere modulari anziché monolitici.)

Answer 6

Sono stato anche io in un paio di situazioni simili. Un buon passaggio per la risoluzione dei problemi è tentare una connessione dalla macchina interessata a una destinazione ben nota che in quel momento non presenta problemi di connettività. Se il tentativo di connessione fallisce, è molto probabile che tu ottenga dettagli più interessanti nel messaggio / codice di errore. Ad esempio, si potrebbe dire che non ci sono abbastanza handle o memoria.

Answer 7

Dal punto di vista dell'amministratore di supporto e di sistema, l'ho visto solo nelle occasioni più rare (più di una volta), ma certamente può succedere.

Quando si diagnostica il problema, è necessario eliminare attentamente le possibili cause, anziché riavviare ciecamente il sistema al primo segnale di guasto. Lo dico solo perché molti clienti con cui lavoro sono tentati di farlo.