Phenquestions
Gegevens worden overgedragen via het netwerk en internet met behulp van de TCP/IP-protocol. De TCP/IP is niet perfect, maar is gemakkelijker te implementeren in vergelijking met andere protocollen die zijn getheoretiseerd voor datacommunicatie... zoals het ISO OSI-model. Zoals met elk technisch ding, heeft TCP/IP ook enkele gebreken en Silly Window Syndroom is een creatie van een van die gebreken. Om te begrijpen wat Silly Window Syndrome of SWS is, moet u eerst het onderliggende mechanisme van datacommunicatie in TCP/IP begrijpen.
Silly Window Syndroom
Het raam en de grootte ervan begrijpen
Wanneer twee punten communiceren onder TCP/IP, is er een bevestigingsmechanisme nodig. Dit erkenningsmechanisme is de oorzaak van het Silly Window Syndrome, zoals verder uitgelegd. Punten kunnen verwijzen naar twee computers, client en server enz.
SWS wordt veroorzaakt doordat de ontvanger de rechterrand van het venster naar voren schuift wanneer er nieuwe bufferruimte beschikbaar is om gegevens te ontvangen en doordat de afzender een willekeurig incrementeel venster gebruikt, hoe klein ook, om meer gegevens te verzenden. Het resultaat kan een stabiel patroon zijn van het verzenden van kleine gegevenssegmenten, ook al hebben zowel de afzender als de ontvanger een grote totale bufferruimte voor de verbinding, zegt MSDN.
Wanneer een computer, zeg A, een datapakket naar een andere computer B stuurt, moet deze laatste bevestigen en antwoorden dat het het datapakket heeft ontvangen. Samen met de bevestiging moet het ook de grootte van de buffer verzenden die is apart gezet voor die communicatiethread. Dit is over het algemeen het aantal bytes dat is vrijgemaakt voor communicatie.
Dus als B zegt dat 100B beschikbaar is voor het volgende bericht, is de 100B het venster in Silly Window Syndrome. Dat wil zeggen, het is de buffergrootte. Met zijn eigen fout kan het TCP/IP-mechanisme de buffergrootte verkleinen voor elke communicatie/data afkomstig van A. Dat wil zeggen, telkens wanneer A een bericht verzendt, neemt B aan dat de buffer kleiner is en stuurt een kleiner aantal smaller. Dus de venstergrootte blijft kleiner en op een gegeven moment stopt de communicatie als B 0B als venstergrootte verzendt.
Hoe werkt het Silly Window-syndroom?
Volgens het bovenstaande voorbeeld van A en B, als B 1000B als venstergrootte verzendt, splitst A het in twee 500B en verzendt twee pakketten van 500B. Na ontvangst van het eerste pakket stuurt B een bevestiging dat 500B beschikbaar is voor het venster omdat het tweede pakket nog moet worden ontvangen. A gaat ervan uit dat 500B de venstergrootte is en verzendt bijgevolg twee pakketten van 250B. Terwijl bij B 500B wordt gebruikt en 500 zojuist is ontvangen, wordt 0B verzonden als beschikbaar. Op dit punt gaat A ervan uit dat er geen venster beschikbaar is, hoewel het kan gebeuren dat de buffer leeg is omdat de processor de gegevens daar heeft opgebruikt. A zal nog steeds een kleiner pakket sturen om te zien of er een venster beschikbaar is. Als de inhoud van buffer bij B nog niet is verwijderd, ontvangt deze nog steeds 0 als antwoord/bevestiging.
De grootte van het venster blijft dus kleiner worden omdat B een bevestiging verzendt telkens wanneer het een pakket van A ontvangt. Deze grootte is meestal kleiner dan de vorige bevestiging, omdat B datapakketten in delen ontvangt. Er zou geen probleem zijn als A een pakket zou kunnen verzenden dat groot genoeg is om de buffergrootte op B tegelijk te dekken. Maar daarvoor zijn aanvullende mechanismen nodig en dus Silly Window Syndrome. De communicatie stopt nadat A twee of drie keer 0 heeft ontvangen.
Hoe het Silly Window Syndrome (SWS) te voorkomen
Er is een eenvoudig algoritme dat moet worden geïmplementeerd om van SWS af te komen. Bij ontvangst van het eerste pakket stuurt B de helft van de werkelijk beschikbare ruimte als het venster. Dat zorgt ervoor dat A kleinere pakketten verzendt. Bijgevolg, wanneer de pakketten te kleiner worden, verzendt B de totale buffergrootte zodat A opnieuw grotere databytes kan verzenden.
Met andere woorden, als 1000B beschikbaar is, stuurt B 500B als bevestiging. Dienovereenkomstig verzendt A 250B x 2 pakketten. Hiervoor krijgt A 100B als erkenning. Wanneer het een pakket van 50B ontvangt, stuurt B 1000B - 50B naar A. Dat maakt het hele gesprek weer operationeel. Dit kan een kleine vertraging in de verwerking veroorzaken, maar zal voorkomen dat Silly Window Syndrome optreedt en het hele gesprek stopt.
Samenvattend, SWS is gebaseerd op de buffergrootte die beschikbaar is op de ontvanger en de veronderstelde grootte berekend door de afzender. Om SWS te voorkomen, wordt een vertraging geïntroduceerd en wordt opzettelijk een kleinere venstergrootte beantwoord totdat de pakketgrootte te klein wordt. Vervolgens onthult de ontvanger de daadwerkelijk beschikbare venstergrootte. Het hele proces blijft zich herhalen totdat de communicatie is voltooid.
Hoewel ik de woorden venster en buffer misschien door elkaar heb gebruikt. Ik bedoel geen enkel verschil tussen hen. In SWS-onderzoeken is buffer het venster.
Als je meer informatie nodig hebt, is er een gedetailleerde uitleg beschikbaar hier op tcpipguide.com.
