データは、 (Data)TCP/IP Protocolを使用してネットワークとインターネット(Internet)を介して転送されます。TCP/IPは完全ではありませんが、 ISO OSIモデルなど、データ通信用に理論化された他のプロトコルと比較して実装が簡単です。他の技術的なことと同様に、TCP/IPにもいくつかの欠陥があり、SillyWindowSyndromeはそれらの欠陥の1つです。Silly Window SyndromeまたはSWSとは何かを理解するには、まずTCP/IPでのデータ通信の基本的なメカニズムを理解する必要があります。
愚かなウィンドウ症候群
ウィンドウとそのサイズを理解する
TCP/IPで通信している場合、確認メカニズムが関係します。さらに説明するように、この認識メカニズムが愚かなウィンドウ症候群の原因です。(Silly Window Syndrome)ポイントは、クライアントとサーバーなどの2台のコンピューターを指す場合があります。
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.
コンピュータ、たとえばAがデータパケットを別のコンピュータBに送信する場合、別のコンピュータBは、データパケットを受信したことを確認して応答する必要があります。確認応答とともに、その通信スレッド用に設定されたバッファーのサイズも送信する必要があります。これは通常、通信用に解放されたバイト数です。
したがって、Bが次のメッセージに100Bが使用可能であると言った場合、100BはSillyWindowSyndromeのウィンドウ(Silly Window Syndrome)です。つまり、バッファサイズです。TCP/IPメカニズムには独自の欠陥があるため、Aからの各通信/データのバッファサイズが減少する可能性があります。つまり、Aがメッセージを送信するたびに、Bはバッファサイズが減少したと見なし、送信する数が少なくなります。したがって、ウィンドウサイズは縮小され続け、ある時点で、Bがウィンドウサイズとして0Bを送信すると、通信が停止します。
愚かなウィンドウ症候群はどのように機能しますか
上記のAとBの例によると、Bがウィンドウサイズとして1000Bを送信する場合、Aはそれを2つの500Bに分割し、500Bの2つのパケットを送信します。最初のパケットを受信すると、Bは、2番目のパケットがまだ受信されていないため、ウィンドウに500Bが使用可能であることを示す確認応答を送信します。Aは500Bがウィンドウサイズであると想定し、結果として250Bの2つのパケットを送信します。Bでは、500Bが使用され、500が受信されたばかりですが、使用可能な場合は0Bが送信されます。この時点で、Aは使用可能なウィンドウがないと想定しますが、プロセッサがそこでデータを使い果たしたためにバッファが空になる可能性があります。Aは引き続き小さいパケットを送信して、使用可能なウィンドウがあるかどうかを確認します。Bのバッファの内容がまだ削除されていない場合でも、応答/確認応答として0を受け取ります。
したがって、BがAからパケットを受信するたびに確認応答を送信するため、ウィンドウサイズは縮小し続けます。このサイズは、Bが部分的にデータパケットを受信するため、通常は以前の確認応答よりも小さくなります。Aが一度にBのバッファサイズをカバーするのに十分な大きさのパケットを送信できれば問題はありません。しかし、それは追加のメカニズム、したがって愚かなウィンドウ症候群(Silly Window Syndrome)を必要とするでしょう。Aが0を2、3回受信すると、通信が停止します。
愚かな窓症候群(Silly Window Syndrome)(SWS)を防ぐ方法
SWSを取り除くために実装される簡単なアルゴリズムがあります。最初のパケットを受信すると、Bは実際に使用可能なスペースの半分をウィンドウとして送信します。これにより、Aはより小さなパケットを送信します。その結果、パケットが小さくなりすぎると、Bは合計バッファサイズを送信して、Aがより大きなデータバイトの送信を再開できるようにします。
つまり、1000Bが使用可能な場合、Bは500Bを確認応答として送信します。したがって、Aは250Bx2パケットを送信します。このため、Aは確認応答として100Bを受け取ります。50Bパケットを受信すると、Bは1000B〜50BをAに送信します。これにより、会話全体が再び機能します。これにより、処理が少し遅れる可能性がありますが、愚かなウィンドウ症候群(Silly Window Syndrome)が発生して会話全体が停止するのを防ぐことができます。
要約すると、SWSは、受信者が使用できるバッファサイズと、送信者が計算した想定サイズに基づいています。SWSを防ぐために、遅延が導入され、パケットサイズが小さくなりすぎるまで、意図的に小さいウィンドウサイズが往復します。次に、受信者は実際に利用可能なウィンドウサイズを開示します。通信が完了するまで、プロセス全体が繰り返され続けます。
私はウィンドウとバッファという言葉を同じ意味で使用したかもしれませんが。私はそれらの間に違いを意味するものではありません。SWS研究では、バッファーはウィンドウです。
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.