Phenquestions
Data overføres over nettverket og Internett ved hjelp av TCP / IP-protokoll. TCP / IP er ikke perfekt, men er enklere å implementere sammenlignet med andre protokoller som er teoretisert for datakommunikasjon ... som ISO OSI-modellen. Som med alle tekniske ting, har TCP / IP også noen feil og Silly Window Syndrome er en opprettelse 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 størrelsen
Når to punkter kommuniserer under TCP / IP, innebærer det en bekreftelsesmekanisme. Denne anerkjennelsesmekanismen er det som forårsaker Silly Window Syndrome som forklart nærmere. Poeng kan referere til to datamaskiner, klient og server osv.
SWS er forårsaket av at mottakeren går frem til høyre vinduskant når den har noen ny bufferplass tilgjengelig for å motta data og av avsenderen ved hjelp av et hvilket som helst trinnvis vindu, uansett hvor lite, for å sende mer data. Resultatet kan være et stabilt mønster for sending av små datasegmenter, selv om både avsender og mottaker har en stor total bufferplass for tilkoblingen, sier MSDN.
Når en datamaskin, si A, sender en datapakke til en annen datamaskin B, må sistnevnte erkjenne og svare at den mottok datapakken. I tillegg til bekreftelsen, må den også sende størrelsen på bufferen som er satt fra hverandre for den kommunikasjonstråden. Dette er vanligvis antall byte som er ledig for kommunikasjon.
Så når B sier at 100B er tilgjengelig for neste melding, er 100B vinduet i Silly Window Syndrome. Det vil si at det er bufferstørrelsen. Med sin egen feil kan TCP / IP-mekanismen redusere bufferstørrelsen for hver kommunikasjon / data som kommer fra A. Når A sender en melding, antar B at bufferstørrelsen reduseres og sender et mindre tall. Dermed fortsetter vindusstørrelsen å bli redusert, og på et tidspunkt stopper kommunikasjonen bare når B sender 0B som vindusstørrelse.
Hvordan fungerer Silly Window Syndrome
I følge ovenstående eksempel på A og B, hvis B sender 1000B som vindusstørrelse, vil A dele den i to 500B og sende to pakker på 500B. Ved mottak av første pakke vil B sende en bekreftelse som sier 500B er tilgjengelig for vinduet ettersom den andre pakken ennå ikke skal mottas. A antar at 500B er vindusstørrelsen og sender to pakker på 250B følgelig. Mens B er 500B brukt og 500 nettopp mottatt, vil den sende 0B som tilgjengelig. På dette tidspunktet vil A anta at ingen vinduer er tilgjengelige, selv om det kan skje at bufferen er tom da prosessoren brukte dataene der. A vil fortsatt sende en mindre pakke for å se om noe vindu er tilgjengelig. Hvis innholdet i buffer på B ennå ikke er fjernet, vil det fortsatt motta 0 som svar / bekreftelse.
Dermed fortsetter vindusstørrelsen å reduseres ettersom B sender bekreftelse hver gang den mottar en pakke fra A. Denne størrelsen er vanligvis mindre enn tidligere bekreftelse, ettersom B mottar datapakker i deler. Det ville ikke være noe problem hvis A kunne sende en pakke som var stor nok til å dekke bufferstørrelsen på B om gangen. Men det vil kreve flere mekanismer og dermed Silly Window Syndrome. Kommunikasjonen stopper etter at A mottar 0 to eller tre ganger.
Slik forhindrer du Silly Window Syndrome (SWS)
Det er en enkel algoritme som skal implementeres for å kvitte seg med SWS. Ved mottak av første pakke sender B halvparten av den tilgjengelige plassen som vinduet. Det får A til å sende mindre pakker. Følgelig, når pakkene blir for mindre, sender B den totale bufferstørrelsen slik at A kan begynne å sende større databytes 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. Dette kan føre til litt forsinkelse i behandlingen, men forhindrer at Silly Window Syndrome oppstår og stopper hele samtalen.
For å oppsummere er SWS basert på bufferstørrelsen som er tilgjengelig på mottakeren og antatt størrelse beregnet av avsenderen. For å forhindre SWS introduseres en forsinkelse og bevisst mindre vindusstørrelse blir gjengjeldt til pakkestørrelsen blir for liten. Deretter avslører mottakeren faktisk tilgjengelig vindusstørrelse. Hele prosessen gjentas til kommunikasjonen er fullført.
Selv om jeg kanskje har brukt ordene vindu og buffer om hverandre. 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.
