Gegevens^(Data) worden overgedragen via het netwerk en internet met behulp van het 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 ook TCP/IP enkele gebreken en Silly Window Syndrome 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 erkennende mechanisme is de oorzaak van het Silly Window Syndrome , zoals verder uitgelegd. Punten kunnen verwijzen naar twee computers, client en server, enz.

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.

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 vrijkomt 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 die van A komt. Dat wil zeggen dat wanneer A een bericht verzendt, B ervan uitgaat dat de buffergrootte kleiner is en een kleiner aantal verzendt. Dus de venstergrootte blijft kleiner en op een gegeven moment stopt de communicatie gewoon als B 0B verzendt als de venstergrootte.

Hoe werkt Silly Window Syndrome?

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 neemt aan 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 de buffer bij B nog niet is verwijderd, krijgt deze alsnog 0 als antwoord/bevestiging.

De grootte van het venster blijft dus kleiner worden als B een bevestiging verzendt telkens wanneer het een pakket van A ontvangt. Deze grootte is gewoonlijk 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 dat het aanvullende mechanismen en dus Silly Window Syndrome zou vereisen . De communicatie stopt nadat A twee of drie keer 0 heeft ontvangen.

Hoe Silly Window Syndrome ( SWS ) te voorkomen

Er moet een eenvoudig algoritme worden geïmplementeerd om van SWS af te komen . Bij ontvangst van het initiële pakket stuurt B de helft van de werkelijk beschikbare ruimte als 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 ontvangstbewijs. Wanneer het 50B-pakket 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.

Kortom, SWS is gebaseerd op de buffergrootte die beschikbaar is voor de ontvanger en de veronderstelde grootte die door de afzender wordt berekend. Om SWS te voorkomen , wordt een vertraging geïntroduceerd en wordt een opzettelijk 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 de buffer het venster.

What is Silly Window Syndrome - Explanation and Prevention

Data is transferred ovеr the network and Internet using the TCP/IP Protocol. The TCP/IP is not perfect but is easier to implement compared to other protocols theorized for data communication… such as the ISO OSI model. As with any technical thing, TCP/IP has some flaws too and Silly Window Syndrome is a creation of one of those flaws. To understand what is Silly Window Syndrome or SWS, you will first need to understand the underlying mechanism of data communication in TCP/IP.

Silly Window Syndrome

Understanding the window and its size

When two points are communicating under TCP/IP, it involves an acknowledging mechanism. This acknowledging mechanism is what causes Silly Window Syndrome as explained further. Points may refer to two computers, client and 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.

When a computer, say A, sends a data packet to another computer B, the latter has to acknowledge and reply that it received the data packet. Along with the acknowledgment, it also has to send the size of buffer set apart for that communication thread. This is generally the number of bytes set free for communication.

So when B says 100B is available for the next message, the 100B is the window in Silly Window Syndrome. That is, it is the buffer size. With its own flaw, the TCP/IP mechanism may reduce the buffer size for each communication/data coming from A. That is, whenever A sends a message, B assumes the buffer size is reduced and sends a smaller number. Thus the window size keeps on reduced and at a point, the communication just stops as B sends 0B as the window size.

How Does Silly Window Syndrome Work

According to the above example of A and B, if B sends 1000B as window size, A will split it into two 500B and send two packets of 500B. Upon receipt of the first packet, B will send an acknowledgment saying 500B is available for the window as the second packet is yet to be received. A assumes 500B is the window size and sends two packets of 250B consequently. While at B, 500B is used and 500 is just received, it will send 0B as available. At this point, A will assume no window is available though it might happen that buffer is empty as the processor used up the data there. A will still send a smaller packet to see if any window is available. If the contents of the buffer at B are not yet removed, it will still receive 0 as response/acknowledgment.

Thus, the window size keeps on reducing as B sends acknowledgment every time it receives a packet from A. This size is usually smaller than the previous acknowledgment as B is receiving data packets in parts. There would be no problem if A could send a packet big enough to cover the buffer size on B at a time. But that it would require additional mechanisms and hence Silly Window Syndrome. The communication stops after A receives 0 two or three times.

How to prevent Silly Window Syndrome (SWS)

There is a simple algorithm to be implemented to get rid of SWS. Upon receiving the initial packet, B sends half the really available space as the window. That will make A send smaller packets. Consequently, when the packets become too smaller, then B sends the total buffer size so that A can start sending bigger data bytes again.

In other words, if 1000B is available, B sends 500B as acknowledgment. Accordingly, A sends 250B x 2 packets. For this, A receives 100B as acknowledgment. When it receives 50B packet, B sends 1000B – 50B to A. That makes the entire conversation operational again. This might induce a little delay in processing but will prevent Silly Window Syndrome from occurring and stopping the entire conversation.

To sum up, SWS is based on the buffer size available to the recipient and the assumed size calculated by the sender. To prevent SWS, a delay is introduced and a deliberate smaller window size is reciprocated until packet size becomes too small. Then the recipient discloses actually available window size. The entire process keeps on repeating until the communication is complete.

Although I may have used the words window and buffer interchangeably. I do not mean any difference between them. In SWS studies, the buffer is the window.

Related posts

• Drupal installeren met WAMP op Windows

• Beste software en hardware Bitcoin-portefeuilles voor Windows, iOS, Android

• Gratis internetradiostation instellen op Windows-pc

• Fix Partner heeft geen verbinding gemaakt met routerfout in TeamViewer op Windows 10

• NASA's Eyes helpt je het heelal te verkennen zoals astronauten

• OpenGL-apps werken niet op Miracast draadloze weergave in Windows 11/10

• 10 beste USB LED-lampen voor laptops

• Beste laptoprugzakken voor heren en dames

• Beste gratis veilige digitale notebooksoftware en online services

• Session messaging-app biedt sterke beveiliging; Geen telefoonnummer nodig!

• SMS Organizer: SMS-applicatie mogelijk gemaakt door Machine Learning

• Hoe u uw LastPass-account kunt verwijderen

• Gratis taakbeheersoftware om Teamwork te beheren

• Hoe sluit u uw Payoneer-account?

• Disqus-commentaarvak wordt niet geladen of weergegeven voor een website

• Zip-bestand is te groot fout bij het downloaden van bestanden van DropBox

• Tips, tools en services voor online reputatiebeheer

• Verschil tussen analoge, digitale en hybride computers

• Beste laptoptafels om online te kopen

• Automate.io is een gratis automatiseringstool en IFTTT-alternatief