يتم نقل البيانات^(Data) عبر الشبكة والإنترنت^(Internet) باستخدام TCP/IP Protocol . بروتوكول TCP/IP ليس مثاليًا ولكنه أسهل في التنفيذ مقارنة بالبروتوكولات الأخرى النظرية لاتصالات البيانات ... مثل نموذج ISO OSI . كما هو الحال مع أي شيء تقني ، فإن TCP/IP به بعض العيوب أيضًا ومتلازمة Silly Window^{(Silly Window Syndrome)} هي إنشاء أحد تلك العيوب. لفهم ما هو Silly Window Syndrome أو SWS ، ستحتاج أولاً إلى فهم الآلية الأساسية لاتصال البيانات في TCP/IP .

متلازمة النافذة السخيفة

فهم النافذة وحجمها

عندما تتواصل نقطتان تحت TCP/IP ، فإنها تنطوي على آلية إقرار. آلية الاعتراف هذه هي التي تسبب متلازمة النافذة السخيفة^{(Silly Window Syndrome)} كما هو موضح بمزيد من التفصيل. قد تشير النقاط إلى جهازي كمبيوتر ، العميل والخادم ، إلخ.

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 أن 100B متاح للرسالة التالية ، فإن 100B هي النافذة في Silly Window Syndrome . هذا هو حجم المخزن المؤقت. مع وجود عيب خاص بها ، قد تقلل آلية TCP/IP من حجم المخزن المؤقت لكل اتصال / بيانات قادمة من A. أي عندما يرسل A رسالة ، يفترض B أن حجم المخزن المؤقت قد تم تقليله ويرسل عددًا أصغر. وهكذا يستمر حجم النافذة في التقلص وعند نقطة ما ، يتوقف الاتصال فقط عندما يرسل B 0B كحجم النافذة.

كيف تعمل متلازمة النوافذ السخيفة

وفقًا لمثال A و B أعلاه ، إذا أرسل B 1000B كحجم نافذة ، فسيقسمه A إلى مجموعتين 500B ويرسل حزمتين من 500B. عند استلام الحزمة الأولى ، سيرسل B إقرارًا يفيد بأن 500B متاح للنافذة لأن الحزمة الثانية لم يتم استلامها بعد. يفترض A أن 500B هو حجم النافذة ويرسل حزمتين من 250B بناءً على ذلك. بينما في B ، يتم استخدام 500B ويتم استلام 500 للتو ، سيرسل 0B كما هو متاح. في هذه المرحلة ، سيفترض A أنه لا توجد نافذة متاحة على الرغم من أنه قد يحدث أن يكون المخزن المؤقت فارغًا لأن المعالج يستخدم البيانات هناك. سيظل A يرسل حزمة أصغر لمعرفة ما إذا كانت هناك أي نافذة متاحة. إذا لم تتم إزالة محتويات المخزن المؤقت في B بعد ، فسيظل يتلقى 0 كاستجابة / إقرار.

وبالتالي ، يستمر حجم النافذة في الانخفاض حيث يرسل B إقرارًا في كل مرة يتلقى فيها حزمة من A. وعادة ما يكون هذا الحجم أصغر من الإقرار السابق حيث يتلقى B حزم بيانات في أجزاء. لن تكون هناك مشكلة إذا كان بإمكان A إرسال حزمة كبيرة بما يكفي لتغطية حجم المخزن المؤقت على B في كل مرة. لكن هذا سيتطلب آليات إضافية وبالتالي متلازمة النافذة السخيفة^{(Silly Window Syndrome)} . يتوقف الاتصال بعد أن يتلقى A صفرًا مرتين أو ثلاث مرات.

كيفية منع متلازمة النوافذ السخيفة^{(Silly Window Syndrome)} ( SWS )

هناك خوارزمية بسيطة ليتم تنفيذها للتخلص من SWS . عند استلام الحزمة الأولية ، يرسل B نصف المساحة المتوفرة بالفعل مثل النافذة. سيؤدي ذلك إلى إرسال حزم أصغر. وبالتالي ، عندما تصبح الحزم أصغر جدًا ، يرسل B حجم المخزن المؤقت الإجمالي بحيث يمكن لـ A البدء في إرسال وحدات بايت أكبر من البيانات مرة أخرى.

بمعنى آخر ، إذا كان 1000B متاحًا ، يرسل B 500B كتأكيد. وفقًا لذلك ، يرسل A حزمًا بحجم 250B × 2. لهذا ، يتلقى A 100B كاعتراف. عندما يتلقى حزمة 50B ، يرسل B 1000B - 50B إلى A. وهذا يجعل المحادثة بأكملها جاهزة للعمل مرة أخرى. قد يؤدي هذا إلى تأخير بسيط في المعالجة ولكنه سيمنع حدوث متلازمة النوافذ السخيفة^{(Silly Window Syndrome)} ويوقف المحادثة بأكملها.

باختصار ، تستند SWS إلى حجم المخزن المؤقت المتاح للمستلم والحجم المفترض الذي يحسبه المرسل. لمنع SWS ، يتم تقديم تأخير ويتم تبادل حجم إطار أصغر متعمدًا حتى يصبح حجم الحزمة صغيرًا جدًا. ثم يكشف المستلم عن حجم النافذة المتاح بالفعل. تستمر العملية برمتها في التكرار حتى يكتمل الاتصال.

على الرغم من أنني قد استخدمت نافذة الكلمات والمخزن المؤقت بالتبادل. لا أقصد أي فرق بينهما. في دراسات SWS ، يكون المخزن المؤقت هو النافذة.

What is Silly Window Syndrome - Explanation and Prevention

Dаta 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

• كيفية تثبيت Drupal باستخدام WAMP على Windows

• Best Software & Hardware Bitcoin Wallets ل Windows، IOS، Android

• Setup Internet Radio Station مجانا على Windows PC

• لم يتصل Fix Partner بخطأ جهاز التوجيه في TeamViewer على Windows 10

• NASA's Eyes يساعدك على استكشاف Universe مثل Astronauts

• Zip file خطأ كبير جدا عند تنزيل الملفات من DropBox

• Convert Magnet روابط إلى روابط Download مباشرة باستخدام Seedr

• Best Laptop Tables لشراء عبر الإنترنت

• Hubstaff Tasks عبارة عن Project Management Tool مجانية مع ميزات Agile

• كيفية إغلاق Payoneer Account الخاص بك؟

• Disqus comment مربع لا تحميل أو عرض لموقع ويب

• SMS Organizer: SMS Application مدعوم من Machine Learning

• لا تعمل OpenGL تطبيقات على Miracast wireless عرض في Windows 10

• Task Management Software مجانا لإدارة العمل الجماعي

• كيفية جعل Invitation Card في Windows PC

• ما هي Virtual Credit Cards وكيف وأين تحصل عليها؟

• أفضل الميزات في LibreOffice Calc

• Ngrok: اجعل خوادمك المحلية العامة مع Secure Tunnels

• كيفية استخدام Template لإنشاء مستند مع LibreOffice

• كيفية حماية كلمة المرور وثائق PDf آمنة مع LibreOffice