Data overføres over nettverket og Internett ved hjelp av TCP / IP-protokoll. TCP / IP er ikke perfekt, men er lettere å implementere enn andre protokoller som er teoretisert for datakommunikasjon … som ISO OSI-modellen. Som med en hvilken som helst teknisk sak har TCP / IP noen feil også Silly Window Syndrome er en skape av en av disse feilene. For å forstå hva som er Silly Window Syndrome eller SWS, må du først forstå den underliggende mekanismen for datakommunikasjon i TCP / IP.
Silly Window Syndrome
Forstå vinduet og dets størrelse
Når to poeng kommuniserer under TCP / IP, innebærer det en bekreftelsesmekanisme. Denne anerkjennelsesmekanismen er det som forårsaker dumt vinduesyndrom som forklart nærmere. Poeng kan referere til to datamaskiner, klient og server etc.
SWS is caused by the receiver advancing the right window edge whenever it has any new buffer space available to receive data and by the sender using any incremental window, no matter how small, to send more data. The result can be a stable pattern of sending tiny data segments, even though both sender and receiver have a large total buffer space for the connection, says MSDN.
Når en datamaskin, sier A, sender en datapakke til en annen datamaskin B, må sistnevnte anerkjenne og svare på at den mottok datapakken. Sammen med bekreftelsen må den også sende størrelsen på buffer sett fra hverandre for den kommunikasjonstråden. Dette er vanligvis antall byte som er fri for kommunikasjon.
Så når B sier 100B er tilgjengelig for neste melding, er 100B vinduet i Silly Window Syndrome. Det vil si, det er bufferstørrelsen. Med sin egen feil kan TCP / IP-mekanismen redusere bufferstørrelsen for hver kommunikasjon / data som kommer fra A. Det vil si, når A sender en melding, antar B at bufferstørrelsen er redusert og sender et mindre antall. Dermed holder vinduets størrelse på redusert og på et tidspunkt stopper kommunikasjonen bare ettersom B sender 0B som vindusstørrelse.
Hvordan virker dumt vindues syndrom
I henhold til eksempel A og B ovenfor, dersom B sender 1000B som vindustørrelse, vil A dele den i to 500B og sende to pakker på 500B. Ved mottak av første pakke vil B sende et bekreftelsesordtak 500B er tilgjengelig for vinduet da den andre pakken ennå ikke skal mottas. En antar 500B er vinduets størrelse og sender derfor to pakker på 250B. Mens ved B, 500B er brukt og 500 er nettopp mottatt, vil den sende 0B som tilgjengelig. På dette punktet antar A at ingen vindu er tilgjengelig, selv om det kan hende at bufferen er tom ettersom prosessoren har brukt dataene der. En vil fortsatt sende en mindre pakke for å se om et vindu er tilgjengelig. Hvis innholdet av buffer ved B ikke er fjernet, vil det fortsatt motta 0 som respons / bekreftelse.
Dermed fortsetter vinduets størrelse med å redusere når B sender bekreftelse hver gang den mottar en pakke fra A. Denne størrelsen er vanligvis mindre enn tidligere bekreftelse da B mottar datapakker i deler. Det ville ikke være noe problem hvis A kunne sende en pakke stor nok til å dekke bufferstørrelsen på B om gangen. Men det vil kreve ekstra mekanismer og dermed dumme vinduesyndrom. Kommunikasjonen stopper etter at A mottar 0 to eller tre ganger.
Slik hindrer du Silly Window Syndrome (SWS)
Det er en enkel algoritme som skal implementeres for å bli kvitt SWS. Ved mottak av første pakke sender B halvparten av den virkelig tilgjengelige plassen som vinduet. Det vil gjøre A send mindre pakker. Derfor, når pakkene blir for mindre, sender B den totale bufferstørrelsen slik at A kan begynne å sende større data byte igjen.
Med andre ord, hvis 1000B er tilgjengelig, sender B 500B som bekreftelse. Følgelig sender A 250B x 2 pakker. For dette mottar A 100B som bekreftelse. Når den mottar 50B pakke, sender B 1000B - 50B til A. Det gjør hele samtalen operativ igjen. Dette kan forårsake en liten forsinkelse i behandlingen, men vil forhindre at dumt vindussyndrom oppstår og stopper hele samtalen.
For å oppsummere er SWS basert på bufferstørrelsen som er tilgjengelig på mottaker og den antatte størrelsen beregnet av avsenderen. For å forhindre SWS, er det innført en forsinkelse, og bevisst mindre vindustørrelse gjentas frem til pakkestørrelsen blir for liten. Deretter avslører mottakeren faktisk tilgjengelig vinduestørrelse. Hele prosessen fortsetter å gjenta til kommunikasjonen er fullført.
Selv om jeg kanskje har brukt ordvinduet og bufferen utveksling. Jeg mener ikke noen forskjell mellom dem. I SWS-studier er buffer vinduet.
Hvis du trenger mer informasjon, er det en detaljert forklaring tilgjengelig her på tcpipguide.com.
