Connessioni socket client negate dal server su host Windows per numero piccolo (16 <x <24) di tentativi di connessione client simultanei

Question

Si verifica un problema in cui le connessioni socket client in ingresso al nostro server socket vengono negate quando un numero relativamente piccolo il numero di nodi (da 16 a 24, ma dovremo gestirne di più in futuro) stanno cercando di connettersi contemporaneamente.

Alcuni particolari:

• server è in esecuzione su Windows 2008 o 7
• il nostro server principale è scritto in Java utilizzando un ServerSocket
• i clienti sono anche Windows in esecuzione su nodi della griglia nel nostro centro dati

Quando si tenta di eseguire un test sulla griglia, i nodi client tentano di connettersi al server e inviare un pacchetto 40-100K e quindi rilasciare la connessione. Utilizzando tra 16 e 24 nodi, iniziamo a vedere problemi con le connessioni client che non riescono a connettersi al server. Data questa configurazione, stiamo tentando di gestire potenzialmente un massimo di 16-24 connessioni client simultanee e non riuscite, il che non ci sembra affatto corretto.

Il loop del server principale è in ascolto su un normale SocketServer e quando riceve una connessione genera un nuovo Thread per gestire la connessione, ritornando immediatamente ad ascoltare sul socket. Abbiamo anche un server fittizio Python che legge e scarta semplicemente i dati in arrivo e un server C++ che registra i dati prima di scaricarli ed entrambi riscontrano lo stesso problema con i client che non riescono a connettersi con piccole variazioni sul numero di connessioni client riuscite prima i fallimenti iniziano. Questo ci ha portato a credere che qualsiasi server specifico non sia in errore in questo problema e che sia probabilmente ambientale.

I nostri primi pensieri erano di aumentare il backlog TCP sul socket. Questo non ha alleviato il problema anche quando è stato spinto a livelli molto alti. L'impostazione predefinita per Java SocketServer è 50, molto inferiore a quella che siamo in grado di gestire.

Abbiamo eseguito il test tra le macchine sulla stessa sottorete e disabilitato tutti i firewall locali sulle macchine nel caso in cui FW stia eseguendo una velocità di limitazione delle connessioni al server; nessun successo.

abbiamo cercato qualche messa a punto della rete sulla macchina Windows che esegue i server:

• Diminuendo il TimedWaitDelay, ma senza alcun effetto (e nel mio test Python non dovrebbe, perché l'esecuzione di collaudi solo per pochi millisecondi).
• Aumentare MaxUserPort a un valore elevato, intorno a 65000, ma senza alcun effetto (il che è strano dato che il mio test di Python invia sempre solo 240 messaggi, quindi non dovrei nemmeno avvicinarmi a questo tipo di limite).
• Aumento di TcpNumConnection su un valore elevato (impossibile ricordare il numero esatto). Ancora una volta, non dovremmo mai avere più di 24 connessioni alla volta, quindi questo non può essere un limite.
• Avvio della funzione "Dynamic Backlog" che consente di aumentare dinamicamente il backlog dei messaggi. Penso che impostiamo il massimo di 2000 connessioni con un minimo di 1000 connessioni, ma senza alcun effetto. Ancora una volta, Python non dovrebbe mai realizzare più di 240 connessioni, quindi non dovremmo nemmeno attivare il backlog dinamico.
• In aggiunta a quanto sopra disabilitato "autotuning" di Windows per le porte TCP. Di nuovo, senza alcun effetto.

La mia sensazione è che Windows limiti in qualche modo il numero di connessioni in ingresso ma non siamo sicuri di cosa modificare per consentire un numero maggiore di connessioni. Anche i pensieri di un agente sulla rete che limita la velocità di connessione non sembrano essere veri. Dubitiamo fortemente che il numero di connessioni simultanee stia sovraccaricando la rete GB fisica.

Siamo perplessi. Qualcun altro ha avuto un problema come questo e ha trovato una soluzione?

Answer 1

Vorrei verificare quante connessioni sono nello stato TIME_WAIT della connessione TCP. Ho visto questo tipo di problema a causa di molte connessioni aperte/chiuse che causano l'esaurimento del socket a causa di TIME_WAIT. Per verificarlo, eseguire:

netstat -a 

Answer 2

IIS è noto per gestire un gran numero di connessioni simultanee in entrata - molto maggiori rispetto al limite si verificano - rendere l'ambiente una fonte improbabile.

Se, come si indica, l'aumento del backlog TCP non migliora la situazione il problema deve essere nel comportamento accept(). Non si indica se i client ricevono vari tipi di errori o qualcosa di coerente. I timeout lo supportano, mentre i rifiuti indicano che il backlog non viene elaborato abbastanza velocemente.

Sei in grado di provare a prototipare l'applicazione come host ASPX per capire meglio il problema?

Answer 3

Molto probabilmente si è limitati dal sistema operativo; viene visualizzato un messaggio di errore 4226 nei registri di sistema?

Windows limita il numero di concomitante tentativi di connessione a (credo) 10 connessioni/secondo - a seconda della versione del sistema operativo (versioni server hanno un valore fino a 50)

al fine di eliminare questo, avete due possibilità:

• modificare direttamente tcpip.sys in system32/drivers con un editor esadecimale - scherzando :)

• tenta di modificare il [HKEY_LOCAL_MACHINE \ SYSTE M \ CurrentControlSet \ Services \ Lanmanserver \ Parameters \ MaxMpxCt (impostazione predefinita = 10 comandi).

Si può anche provare this hotfix nel caso in cui si sta utilizzando una versione che non consentono di impostare tale parametro.

Puoi anche provare varie cose come il numero massimo di TCB che il sistema operativo utilizza, l'intervallo di porte per l'allocazione dinamica delle porte, ecc. - sebbene questi valori siano abbastanza alti per le tue esigenze.