Az adatok^(Data) átvitele a hálózaton és az interneten^(Internet) keresztül történik a TCP/IP Protocol használatával . A TCP/IP nem tökéletes, de könnyebben megvalósítható más adatkommunikációs protokollokhoz képest… mint például az ISO OSI modell. Mint minden technikai dolognak, a TCP/IP -nek is vannak hibái, és a Silly Window Syndrome ezeknek a hibáknak az egyik eredménye. Ahhoz, hogy megértse, mi az a Silly Window Syndrome vagy SWS , először meg kell értenie a ^(SWS)TCP/IP adatkommunikáció mögöttes mechanizmusát .

Buta ablak szindróma

Az ablak és méretének megértése

Ha két pont kommunikál TCP/IP alatt , az egy nyugtázó mechanizmust foglal magában. Ez az elismerő mechanizmus okozza a buta ablak szindrómát^{(Silly Window Syndrome)} , amint azt a továbbiakban kifejtjük. A pontok vonatkozhatnak két számítógépre, kliensre és szerverre stb.

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.

Amikor egy számítógép, mondjuk A, egy adatcsomagot küld egy másik B számítógépnek, az utóbbinak nyugtáznia kell, és válaszolnia kell, hogy megkapta az adatcsomagot. A nyugtával együtt el kell küldenie az adott kommunikációs szálhoz elkülönített puffer méretét is. Általában ez a kommunikációhoz szabaddá tett bájtok száma.

Tehát amikor B azt mondja, hogy a 100B elérhető a következő üzenethez, akkor a 100B a Silly Window Syndrome ablaka^{(Silly Window Syndrome)} . Vagyis ez a puffer mérete. Saját hibája miatt a TCP/IP mechanizmus csökkentheti a puffer méretét minden A-tól érkező kommunikáció/adat esetén. Ez azt jelenti, hogy amikor A üzenetet küld, B feltételezi, hogy a puffer mérete csökken, és kisebb számot küld. Így az ablak mérete tovább csökken, és egy ponton a kommunikáció leáll, mivel B 0B-t küld ablakméretként.

Hogyan működik a buta ablak szindróma

Az A és B fenti példája szerint, ha B 1000B-t küld ablakméretként, A két 500B-re osztja, és két 500B-es csomagot küld. Az első csomag kézhezvételekor B nyugtázást küld arról, hogy az 500B elérhető az ablakhoz, mivel a második csomag még nem érkezik meg. A feltételezi, hogy 500B az ablakméret, és ennek következtében két 250B-os csomagot küld. Míg B-nél 500B-t használnak, és 500-at éppen fogad, addig a 0B-t küldi, ahogyan elérhető. Ezen a ponton A feltételezi, hogy nincs elérhető ablak, bár előfordulhat, hogy a puffer üres, mivel a processzor felhasználta az ott található adatokat. A továbbra is küld egy kisebb csomagot, hogy megnézze, van-e elérhető ablak. Ha a B helyen lévő puffer tartalma még nincs eltávolítva, akkor is 0-t kap válaszként/nyugtázásként.

Így az ablak mérete folyamatosan csökken, mivel B visszaigazolást küld minden alkalommal, amikor csomagot kap A-tól. Ez a méret általában kisebb, mint az előző nyugtázás, mivel B részenként fogadja az adatcsomagokat. Nem lenne probléma, ha A egy akkora csomagot tudna küldeni, hogy egyszerre lefedje a B puffer méretét. De ehhez további mechanizmusokra lenne szükség, és így a Silly Window szindrómára^{(Silly Window Syndrome)} . A kommunikáció leáll, miután A kétszer vagy háromszor 0-t kap.

Hogyan lehet megelőzni a buta ablak szindrómát^{(Silly Window Syndrome)} ( SWS )

Az SWS^(SWS) -től való megszabaduláshoz egy egyszerű algoritmust kell végrehajtani . A kezdeti csomag fogadásakor B a valóban rendelkezésre álló terület felét elküldi ablakként. Ez arra készteti A-t, hogy kisebb csomagokat küldjön. Következésképpen, ha a csomagok túl kicsik lesznek, akkor B elküldi a teljes pufferméretet, hogy A ismét nagyobb adatbájtokat küldhessen.

Más szavakkal, ha 1000B elérhető, B 500B-t küld nyugtázásként. Ennek megfelelően A 250B x ​​2 csomagot küld. Erre A 100B-t kap nyugtázásként. Amikor 50B-es csomagot kap, B 1000B-50B-t küld A-nak. Ettől az egész beszélgetés újra működőképes. Ez némi késést okozhat a feldolgozásban, de megakadályozza a Silly Window^{(Silly Window Syndrome)} -szindróma előfordulását, és leállítja a teljes beszélgetést.

Összefoglalva, az SWS a címzett számára elérhető pufferméreten és a küldő által kiszámított feltételezett méreten alapul. Az SWS^(SWS) megakadályozása érdekében késleltetést vezet be, és szándékosan kisebb ablakméretet hajt végre, amíg a csomag mérete túl kicsi lesz. Ezután a címzett nyilvánosságra hozza a ténylegesen elérhető ablakméretet. Az egész folyamat addig ismétlődik, amíg a kommunikáció be nem fejeződik.

Bár lehet, hogy az ablak és a puffer szavakat felcserélhetően használtam. Nem értek különbséget köztük. Az SWS tanulmányokban a puffer az ablak.

What is Silly Window Syndrome - Explanation and Prevention

Data is transferred over 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

• A Drupal telepítése a WAMP használatával Windows rendszeren

• A legjobb szoftver és hardver Bitcoin pénztárcák Windows, iOS, Android rendszerhez

• Az Internet Radio Station ingyenes beállítása Windows PC-n

• A Fix Partner nem csatlakozott a router hibájához a TeamViewerben Windows 10 rendszeren

• A NASA Eyes segít felfedezni az Univerzumot, mint az űrhajósok

• Különbség az analóg, digitális és hibrid számítógépek között

• A zip fájl túl nagy hiba a fájlok DropBoxból való letöltésekor

• Kilenc nosztalgikus technikai hangzás, amelyeket valószínűleg évek óta nem hallottál

• ngrok: Tedd nyilvánossá helyi szervereidet a Secure Tunnels segítségével

• Hogyan lehet titkosítani és jelszavakat adni a LibreOffice dokumentumokhoz

• Cyber ​​Monday és Black Friday Akciós vásárlási tippek, amelyeket követni szeretne

• A Disqus megjegyzésmezője nem töltődik be vagy nem jelenik meg egy webhelyhez

• SMS-szervező: SMS-alkalmazás, amelyet a Machine Learning üzemeltet

• Ingyenes Feladatkezelő szoftver a csapatmunka kezeléséhez

• A legjobb eszközök ingyenes SMS-küldéshez a számítógépről

• A legjobb ingyenes biztonságos digitális notebook szoftver és online szolgáltatások

• A Windows 95 telepítése Windows 10 rendszeren

• Az OpenGL-alkalmazások nem futnak a Miracast vezeték nélküli kijelzőjén a Windows 11/10 rendszerben

• Konvertálja a Magnet linkeket közvetlen letöltési hivatkozásokká a Seedr segítségével

• Önaláírt SSL-tanúsítványok létrehozása a Windows 11/10 rendszerben