b'\n_START_ARTICLE_\nSilly window syndrome\n_START_PARAGRAPH_\nLa silly window syndrome (sindrome da finestra sciocca, abbreviata con SWS) \xc3\xa8 un problema legato alla cattiva implementazione del controllo di flusso a livello TCP. Un processo di scrittura molto lento da parte del mittente nel buffer di trasmissione (o di lettura da parte del ricevente) porta infatti all\'invio di segmenti di dati molto piccoli, aumentando cos\xc3\xac il rapporto tra header e dati con un conseguente uso inefficiente del canale.\n_START_SECTION_\nSindrome causata dal mittente\n_START_PARAGRAPH_\nNel caso in cui il processo di scrittura dei dati nel buffer TCP del mittente sia molto lento, il protocollo spedir\xc3\xa0 una serie di pacchetti contenenti una quantit\xc3\xa0 di dati molto bassa, con un uso inefficiente del canale (\xc3\xa8 infatti molto meglio spedire un solo pacchetto con  byte di dati, per il quale bisogna pagare il peso di un solo header, che spedire  pacchetti contenenti solo un byte di dati, per ognuno dei quali bisogna pagare il peso di un header, un rapporto di  contro )._NEWLINE_La soluzione a questo problema consiste nel trattenere i dati nel buffer allo scopo di spedirli in un unico segmento. Tuttavia un\'attesa troppo lunga potrebbe causare dei ritardi troppo grandi nella trasmissione._NEWLINE_Un\'ottima soluzione a questo problema \xc3\xa8 fornita dall\'algoritmo di Nagle, secondo il quale i dati devono essere accumulati nel buffer per poi venire spediti in un unico blocco alla ricezione dell\'ACK dell\'ultimo pacchetto trasmesso o quando si raggiunge la massima dimensione fissata per un segmento (MSS). Questo semplicissimo algoritmo riesce a risolvere il problema tenendo anche conto della velocit\xc3\xa0 di trasmissione dei pacchetti: se questa \xc3\xa8 pi\xc3\xb9 lenta della scrittura dei messaggi (il mittente riesce ad accumulare una notevole quantit\xc3\xa0 di dati nel buffer prima dell\'arrivo del riscontro) vengono creati pacchetti con il massimo rapporto dati/header, sfruttando al meglio le risorse del canale. Se invece la rete \xc3\xa8 pi\xc3\xb9 veloce, i pacchetti risulteranno pi\xc3\xb9 piccoli, assicureranno una certa continuit\xc3\xa0 nella trasmissione e verr\xc3\xa0 garantito comunque un utilizzo pi\xc3\xb9 efficiente delle risorse del canale che nel caso in cui l\'algoritmo non venga utilizzato.\n_START_SECTION_\nSindrome causata dal ricevente\n_START_PARAGRAPH_\nNel caso sia invece il ricevente a leggere lentamente i pacchetti ricevuti, il buffer in ingresso tender\xc3\xa0 a riempirsi, costringendo a richiedere al mittente di interrompere la trasmissione. Non appena una trama viene letta il mittente viene informato dal riscontro che si \xc3\xa8 liberato dello spazio nel buffer, e reagisce cos\xc3\xac inviando un nuovo segmento. Si viene cos\xc3\xac a creare una situazione dove viene generato un nuovo pacchetto non appena si libera spazio sufficiente nel buffer, dando nuovamente origine ad una situazione di uso inefficiente del canale dato dal cattivo rapporto lunghezza pacchetto/dati contenuti._NEWLINE_Una soluzione \xc3\xa8 adottare la soluzione di Clark, con la quale si "inganna" il mittente specificando nei messaggi di riscontro che il buffer \xc3\xa8 ancora pieno (costringendolo cos\xc3\xac a bloccare l\'invio) fino a che la coda non si sia svuotata per met\xc3\xa0 o a sufficienza per accogliere un segmento di dimensioni massime (MSS)._NEWLINE_Un\'altra soluzione consiste nel ritardare l\'invio degli ACK (bloccando cos\xc3\xac il mittente) finch\xc3\xa9 non si libera un certo numero di byte nel buffer. Il tempo massimo di ritardo dei riscontri va per\xc3\xb2 calcolato accuratamente, per evitare che il mittente vada in timeout e ritrasmetta il pacchetto.'