Chi sta impostando le dimensioni della finestra TCP su 0, Indy o Windows?

Question

Abbiamo un server delle applicazioni che ha osservato l'invio di intestazioni con la dimensione della finestra TCP 0 nei momenti in cui la rete presentava congestione (sul sito di un cliente).

Vorremmo sapere se è Indy o il livello sottostante di Windows che è responsabile della regolazione della dimensione della finestra TCP in giù rispetto al 64K nominale in adattamento alla velocità effettiva disponibile.
E saremo in grado di agire su di esso diventando 0 (niente viene inviato, gli utenti attendono => non va bene).

Quindi, qualsiasi informazione, collegamento, puntatore al codice di Indy sono i benvenuti ...

Disclaimer: io non sono uno specialista di rete. Si prega di mantenere la risposta comprensibile per la media me ;-)
Nota: è Indy9/D2007 su Windows Server 2003 SP2.

Altri dettagli cruenti:
I casi di finestra zero TCP si verificano sul livello intermedio parlando al server DB.
Si verifica negli stessi momenti in cui gli utenti finali lamentano rallentamenti nell'applicazione client (questo è ciò che ha attivato l'indagine di rete).
2 principali problemi di rete che causano colli di bottiglia sono stati identificati.
La finestra TCP zero si è verificata in caso di congestione della rete, ma potrebbe essere causata o meno.
Vogliamo sapere quando succede e avere un modo per fare qualcosa (logging almeno) nel nostro codice.

Quindi la domanda principale è chi imposta la dimensione della finestra su 0 e dove?
Dove agganciare (in Indy?) Per sapere quando si verifica questa condizione?

Answer 1

La dimensione della finestra nell'intestazione TCP è noramlly impostata dal software stack TCP per riflettere la dimensione dello spazio buffer disponibile. Se il tuo server invia pacchetti con una finestra impostata a zero, probabilmente perché il client sta inviando dati più velocemente di quanto l'applicazione in esecuzione sul server la stia leggendo, e i buffer associati alla connessione TCP sono ora pieni.

Questo è un'operazione perfettamente normale per il protocollo TCP se il client invia i dati più rapidamente di quanto il server possa leggerlo. Il client dovrebbe astenersi dall'inviare i dati fino a quando il server non invierà una dimensione della finestra diversa da zero (non c'è alcun punto, in quanto verrebbe comunque scartata).

Questo può o potrebbe non riflettere un problema serio tra client e server, ma se la condizione persiste probabilmente significa che l'applicazione in esecuzione sul server ha smesso di leggere i dati ricevuti (una volta iniziata la lettura, questo libera spazio per il buffer per TCP e lo stack TCP invierà una nuova dimensione della finestra diversa da zero).

Answer 2

Un'intestazione TCP con una dimensione della finestra pari a zero indica che i buffer del ricevitore sono pieni. Questa è una condizione normale per uno scrittore più veloce del lettore.

Nella lettura della descrizione, non è chiaro se questo è inaspettato. Cosa ti ha causato l'apertura di un analizzatore di protocollo?

Answer 3

Dal momento che potrebbe essere interessato a una soluzione al tuo problema, troppo:

Se si dispone di un certo controllo su ciò che è in esecuzione sul lato server (quello che invia i messaggi di dimensione 0 finestra): Ha fatto si considera utilizzando setsockopt() con SO_RCVBUF per aumentare significativamente la dimensione del buffer di ricezione del socket?

In Indy, setsockopt() è un metodo della TIdSocketHandle. Dovresti applicarlo a tutti gli oggetti TIdSocketHandle associati al tuo socket. E in Indy 9, quelli si trovano attraverso Associazioni di proprietà nel vostro TIdTCPServer.

Suggerisco ad usare getsockopt() con SO_RCVBUF per vedere ciò che il sistema operativo che si dà come dimensione del buffer di default. Quindi aumentare in modo significativo questo, può essere da prove successive, raddoppiando le dimensioni ogni volta. Si potrebbe anche voler ri-eseguire un getsockopt() chiamata dopo tua setsockopt() per assicurare che il vostro setsockopt è stata effettivamente eseguita: Di solito c'è un limite superiore che la presa di set di implementazione per le dimensioni del buffer. E in questo caso, di solito c'è un modo OS-dipendente per spostare il valore del soffitto verso l'alto. Ma quelli sono casi piuttosto estremi, e non è molto probabile che tu ne abbia bisogno.

Se non si ha il controllo sul codice sorgente sul lato che viene overflow, è sufficiente verificare se il software in esecuzione espone alcuni parametri per modificare la dimensione del buffer.

Buona fortuna!