مقایسه پروتکل‌های کنترل جریان داده: ایست و انتظار (Stop-and-wait) و پنجره لغزان (Sliding window)

کنترل جریان داده در شبکه چیست؟

کنترل جریان داده به فرستنده می‌گوید که چه مقدار داده باید برای گیرنده ارسال شود که گیرنده بتواند آن را دریافت و پردازش کند و هیچ داده‌ای در شبکه از دست نرود. برای کنترل جریان داده‌ها معمولا یکی از دو پروتکل ذیل به کار می‌رود:

1. پروتکل ایست و انتظار (Stop-and-wait protocol)
2. پروتکل پنجره لغزان (Sliding window protocol)

پروتکل ایست و انتظار (Stop-and-wait protocol) چیست و چگونه کار می‌کند؟

ایست و انتظار، ساده‌ترین روش کنترل جریان داده‌ها در شبکه است. در این روش، فرستنده هر بار یک فریم برای گیرنده می‌فرستد. فرستنده سپس بازمی‌ایستد و منتظر می‌ماند تا گیرنده با مخابره پیغامی تایید کند که فریم را دریافت کرده است. پیغام مذکور را اصطلاحا ACK (مخفف Acknowledgement) می‌‌نامند. پس از آن‌که گیرنده، پیغام تایید را به فرستنده مخابره کرد، فرستنده مجددا به کار می‌افتد و فریم بعدی را می‌فرستد و باز منتظر پیغام تایید می‌ماند و این فرآینده آن‌قدر ادامه می‌یابد تا همه فریم‌های داده به مقصد ارسال شوند.

در پروتکل ایست و انتظار، ارتباط نیمه‌دوطرفه (half-duplex) است، یعنی گره مبدا و مقصد نمی‌توانند هم‌زمان برای یکدیگر داده بفرستند و وقتی یکی از آن‌ها مشغول ارسال داده است، دیگری در حال انتظار به سر می‌برد. فاصله زمانی بین ارسال فریم توسط فرستنده و انتظارش برای دریافت پیغام تایید را زمان انتظار فرستنده می‌نامند. فرستنده طی این مدت کاملا بی‌کار است. تصویر 1 روند کار پروتکل ایست و انتظار در حالت عادی را نشان می‌دهد.

تصویر 1. روند کار پروتکل ایست و انتظار در حالت عادی

اما اگر داده‌ای که فرستنده ارسال کرده است به مقصد نرسد و مفقود شود، یا اگر پیغام تاییدی که گیرنده برای فرستنده ارسال کرده است مفقود شود، پروتکل ایست و انتظار چگونه مشکل را رفع می‌کند؟ راه‌کار پروتکل ایست و انتظار برای رفع هر دو مشکل یادشده در ادامه توضیح داده می‌شود.

موقعیت 1: اگر فریم ارسالی در مقصد دریافت نشود

فرض کنید فریمی که فرستنده می‌فرستد، در مقصد دریافت نشود و گم شود. در این‌صورت گیرنده هیچ پیغام تاییدی مبنی بر دریافت داده‌ها صادر نخواهد کرد. فرستنده نیز که نخست باید پیغام تایید فریم پیشین را دریافت کند، فریم بعدی را نخواهد فرستاد. درنتیجه، تبادل داده به بن‌بست برمی‌خورد. برای پرهیز از بروز این وضعیت، تمهیدی موسوم به زمان‌سنج وقفه (time-out timer) در نظر گرفته شده است که طبق آن، فرستنده برای دریافت پیغام تایید، فقط مدت محدودی درنگ می‌کند و منتظر می‌ماند و اگر پیغام تایید را دریافت نکرد، فریم را دوباره می‌فرستد.

تصویر 2. نحوه عملکرد پروتکل ایست و انتظار وقتی که فریم ارسالی به مقصد نرسد (منظور از فریم صفر، شماره فریم است که از صفر آغاز می‌شود.)

موقعیت 2: اگر پیغام تاییدی که گیرنده ارسال کرده است، توسط فرستنده دریافت نشود

فرض کنید که گیرنده، داده را دریافت کرده و پیغام تایید را نیز برای فرستنده ارسال کرده است، اما پیغام تایید، از دست رفته و فرستنده آن را دریافت نکرده است. این بار نیز اگر زمان‌سنج وقفه نباشد، فرستنده مدت نامحدودی صبر می‌کند و باز تبادل داده به بن‌بست می‌خورد. پس، این‌بار نیز باید از زمان‌سنج وقفه بهره برد تا فرستنده، فقط مدت زمان محدودی درنگ ‌کند و اگر پیغام تایید را دریافت نکرد، فریم را دوباره بفرستد. 

تصویر 3. نحوه عملکرد پروتکل ایست و انتظار وقتی که پیغام تایید دریافت داده، مفقود شده باشد (منظور از فریم صفر، شماره فریم است که از صفر آغاز می‌شود. منظور از تایید صفر نیز پیغام تایید دریافت فریم صفر است که گیرنده، آن را برای فرستنده می‌فرستد.)

تاخیر انتقال و تاخیر انتشار چیست؟

هنگام ارسال فریم‌ها دو نوع تاخیر رخ می‌دهد که یکی تاخیر انتقال و دیگری تاخیر انتشار است. 

• تاخیر انتقال (Transmission Delay): زمانی را که لازم است تا فرستنده همه بیت‌های فریم را به شبکه بفرستد، تاخیر انتقال می‌نامند. تاخیر انتقال از تقسیم اندازه داده‌ ارسالی (D) بر پهنای باند (B) به دست می‌آید، یعنی: Td = D / B

• تاخیر انتشار (Propagation Delay): زمانی را که لازم است تا آخرین بیت فریم از مبدا به مقصد برسد، تاخیر انتشار می‌نامند. تاخیر انتشار از تقسیم فاصله گره فرستنده تا گیرنده (d) بر سرعت انتشار موج (s) به دست می‌آید، یعنی: Tp = d / s

تصویر 4. تاخیر انتقال و تاخیر انتشار در فرآیند کنترل جریان داده

مدت تاخیر انتشار (Tp) برای ارسال فریم داده و ارسال پیغام تایید، یکسان است، زیرا فاصله و سرعت برای هر دو فریم یکی است. زمان کل مورد نیاز برای ارسال یک فریم چنین محاسبه می‌شود:

زمان کل = مدت تاخیر انتقال + مدت تاخیر انتشار فریم داده + مدت تاخیر انتشار پیغام تایید

یعنی:  Total time = Td + Tp + Tp

Total time = Td + 2Tp

در پروتکل ایست و انتظار، فرستنده فقط در زمان Td مشغول کار است و باقی زمان یعنی 2Tp را منتظر دریافت پیغام تایید است.

نحوه محاسبه بازده 

بازده از تقسیم زمان مفید بر زمان کل به دست می‌آید، یعنی:

Ƞ = Td / (Td + 2Tp)

Ƞ = 1 / (1 + 2a) -> (1) معادله 

a =Tp / Td

نحوه محاسبه توان عملیاتی

توان عملیاتی یعنی تعداد بیت‌هایی که گیرنده در زمان کل می‌تواند دریافت کند. اندازه هر فریم را بر حسب تعداد بیت‌ها می‌سنجند و با D نشان می‌دهند. لذا توان عملیاتی چنین محاسبه می‌شود:

Throughput = D / (Td + 2Tp)

Throughput = D / Td (1 + 2a) -> (2) معادله

a =Tp / Td  و گفته شد که 

طبق تعریف، معادله تاخیر انتقال داده، Td=D/B است که از ضرب متقابل آن‌ها نتیجه می‌شود:

B = D / Td -> (3) معادله

با جاسازی مقادیر معادله 3 در معادله 2، معادله زیر حاصل می‌شود:

Throughput= B / (1 + 2a) -> (4)

و اکنون با جاسازی مقدار معادله 1 در معادله 4 فرمول محاسبه توان عملیاتی حاصل می‌شود:

Throughput= Ƞ * B

مزایای پروتکل ایست و انتظار

• پیاده‌سازی آن بسیار ساده است.
• دقت خوبی دارد. زیرا فریم بعدی فقط زمانی ارسال می‌شود که دریافت فریم اخیر از سوی گیرنده تایید شود. لذا هیچ فریمی در شبکه مفقود نمی‌شود.

ضعف‌های پروتکل صبر و انتظار

• هر بار فقط یک فریم ارسال می‌شود.
• اگر فاصله بین فرستنده و گیرنده زیاد باشد، مدت تاخیر انتشار بیش از تاخیر انتقال خواهدبود. درنتیجه، بازده بسیار کم خواهدشد.
• پس از ارسال هر فریم، فرستنده باید منتظر بماند تا گیرنده دریافت فریم را با مخابره پیغامی تایید کند. این، زمان کل را افزایش می‌دهد و فرآیند انتقال داده را کند می‌کند.

پروتکل پنجره لغزان (Sliding window) چیست و چگونه کار می‌کند؟

یکی از معایب پروتکل ایست و انتظار این بود که چون فرستنده پیش از ارسال فریم بعدی منتظر دریافت پیغام تایید فریم اخیر می‌ماند، تمام مدت انتظارش بی‌کار بود. اما در پروتکل پنجره لغزان، از زمان انتظار نیز برای ارسال داده استفاده می‌شود. در پروتکل پنجره لغزان منظور از «پنجره»، حافظه بافر (buffer) است که برای ذخیره فریم‌ها به کار می‌رود. در این پروتکل، دو پنجره یا دو حافظه بافر تعریف می‌شود: یکی پنجره فرستنده و دیگری پنجره گیرنده. شماره فریم‌هایی که فرستنده باید ارسال کند، در پنجره فرستنده ذخیره می‌شود. اگر اندازه پنجره فرستنده n فرض شود، فریم‌ها از 0 تا n-1 شماره‌گذاری می‌شوند و فرستنده هر بار به‌جای یک فریم، n فریم می‌فرستد. پنجره گیرنده نیز حاوی شماره فریم‌هایی است که باید دریافت شوند. 

برخلاف پروتکل ایست و انتظار که شیوه ارتباطی آن نیمه‌د‌وطرفه (half-duplex) بود، در پروتکل پنجره لغزان ارتباط فرستنده و گیرنده کاملا دوطرفه (full-duplex) است، یعنی هم‌زمان می‌توانند برای هم داده بفرستند. این یکی از ویژگی‌های مهم پروتکل پنجره لغزان است.

در پروتکل پنجره لغزان، فرستنده بسته به اندازه حافظه بافر یا اصطلاحا پنجره خود، تعداد مشخصی فریم‌ ذخیره می‌کند. فریم‌های درون حافظه بافر، پیاپی ارسال می‌شوند. یعنی فرستنده، اولین فریم را می‌فرستد، اما منتظر پیغام تایید از سمت گیرنده نمی‌ماند، بلکه فریم‌های بعدی را نیز ارسال می‌کند. هرگاه که پیغام تایید فریم اول از سمت گیرنده به‌دست فرستنده ‌رسید، فرستنده که از به مقصد رسیدن آن مطمئن شده است، آن فریم را از حافظه بافر (پنجره) خود پاک می‌کند. لذا برای ذخیره یک فریم جدید جا باز می‌شود و فرستنده، فریم جدیدی را در حافظه بافرش ذخیره می‌کند. در این حالت اصطلاحا می‌گویند، پنجره فرستنده (حافظه بافر فرستنده) به جلو می‌لغزد تا فریم جدید را درون چارچوب خود بگیرد. به همین ترتیب، وقتی پیغام تایید فریم دوم به فرستنده می‌رسد، فرستنده فریم دوم را نیز از حافظه خود پاک می‌کند و پنجره یک گام دیگر به جلو می‌لغزد تا فریم جدیدی ذخیره کند. فرستنده، هم‌زمان مشغول ارسال فریم‌های دیگری به سمت گیرنده است. این روند آن‌قدر ادامه می‌یابد تا تمام فریم‌ها به مقصد ارسال شوند. 

بدین‌ترتیب در پروتکل پنجره لغزان، فرستنده و گیرنده هیچ زمانی را به انتظار و توقف نمی‌گذرانند و تمام مدت به تبادل داده می‌پردازند. مثال زیر این موضوع را آشکارتر توضیح می‌دهد:

مثال برای توضیح نحوه کنترل جریان داده توسط پروتکل پنجره لغزان 

1. فرض کنید اندازه پنجره یا حافظه بافر فرستنده 4 است. پس فریم‌ها متناوبا از 0 تا 3 شماره می‌خورند، یعنی: ...,0,1,2,3,0,1,2,3,0 
2. ابتدا چهار فریم 0,1,2,3 درون پنجره جای می‌گیرند. فرستنده، انتقال فریم‌ها را آغاز می‌کند. نخست فریم 0 و بعد فریم 1 و سپس دیگر فریم‌های درون پنجره ارسال می‌شوند.
3. همین‌که گیرنده، اولین فریم یعنی فریم 0 را دریافت کرد، پیغام تایید آن را برای فرستنده ارسال می‌کند.
4. فرستنده با دیدن پیغام تایید متوجه می‌شود که فریم 0 در مقصد دریافت شده است. پس آن را از حافظه بافر یا پنجره خود پاک می‌کند و چون جای خالی ایجاد شده است، فریم جدیدی در حافظه ذخیره می‌شود و اصطلاحا پنجره یک گام به جلو می‌لغزد. (به پاک شدن فریم از حافظه بافر و ذخیره شدن فریم بعدی در  حافظه اصطلاحا لغزش پنجره می‌گویند.)
5. پنجره اکنون حاوی فریم‌های 1,2,3,0 است (فریم 0 جدید با رنگ نارنجی تایپ شده است). این روند تا زمانی که همه فریم‌ها ارسال شوند، ادامه می‌یابد. تصویر 5 و تصویر 6 به‌ترتیب موقعیت پنجره فرستنده و پنجره گیرنده را حین و پس از ارسال اولین فریم یعنی فریم 0 نشان می‌دهند. 

تصویر 5. پنجره فرستنده: ابتدا چهار فریم 0,1,2,3 در پنجره ذخیره شده‌اند (خانه‌های فیروزه‌ای). فرستنده، اولین فریم یعنی فریم 0 و سپس فریم‌های 1 و 2 و 3 را برای گیرنده ارسال می‌کند و منتظر دریافت پیغام تایید آن‌ها نمی‌ماند. در ‌سوی دیگر، گیرنده فریم 0 را دریافت می‌کند و برای فرستنده، پیغام تایید می‌فرستد. همین‌که فرستنده، پیغام تایید را دریافت کرد، فریم 0 را پاک می‌کند (خانه خاکستری) و چون یک جای خالی در حافظه ایجاد شده است، پنجره یک گام به جلو می‌لغزد و فریم بعدی که در این مثال، باز شماره آن 0 است، وارد چارچوب پنجره می‌شود؛ یعنی در حافظه ذخیره می‌شود. تبادل داده تا پایان با همین روند ادامه می‌یابد. 

تصویر 6. پنجره گیرنده: گیرنده پیوسته بررسی می‌کند که آیا ترتیب فریمی که دریافت می‌کند صحیح است یا نه. اگر فریم صحیح بود، گیرنده برای فرستنده پیغام تایید می‌فرستد. گیرنده سپس شماره آن فریم را از حافظه بافر (پنجره) خود پاک و شماره فریم بعدی را در آن ذخیره می‌کند. با دریافت فریم جدید، گیرنده مجددا آن را با شماره فریم ذخیره شده در حافظه خود مقایسه می‌کند و روند فوق تا پایان ادامه می‌یابد.

تصویر 7، عملکرد پنجره فرستنده و پنجره گیرنده را یک‌جا نشان می‌دهد. (در تصویر 7 برخلاف دو تصویر فوق، جهت حرکت پنجره فرستنده و پنجره گیرنده از راست به چپ است که البته در اصل موضوع تفاوتی ایجاد نمی‌کند.)

تصویر 7. نحوه کنترل جریان داده با پروتکل پنجره لغزان

پروتکل TCP که یکی از پروتکل‌های بنیادی اینترنت و شبکه‌های آی‌پی است نیز به‌شیوه پنجره لغزان عمل می‌کند و از حافظه بافری بهره می‌برد که در هسته سیستم‌عامل جای دارد. پروتکل TCP سبب می‌شود بسته‌های داده حتما به مقصد برسند و با همان ترتیبی که از مبدا ارسال شده‌اند، در مقصد دریافت شوند و به هم بپیوندند.

پنجره لغزان در مقایسه با ایست و انتظار، بازده بیشتری دارد، زیرا در این پروتکل، از زمان انتظار نیز برای ارسال داده استفاده می‌شود. برای این منظور، فرستنده باید تمام مدت یعنی در زمان کل (Td+2Tp) فریم‌ بفرستد. 

برای دست‌یابی به حداکثر بازده در پروتکل پنجره لغزان، هر بار باید چه تعداد بسته ارسال شود؟ پاسخ چنین است: اگر در Td واحد زمانی، یک بسته ارسال شود، پس در یک واحد زمانی، I 1/Tdبسته ارسال می‌شود و نتیجتاً در زمان کل یعنی در زمان Td+2Tp می‌شود l (Td+2Tp)/Tdبسته ارسال کرد. و پیش‌تر گفته شد که a=Tp/Td است، پس اگر l 1+2aبسته ارسال شود، بازده 1 خواهدبود.

تفاوت‌های اصلی پروتکل ایست و انتظار با پروتکل پنجره لغزان

• در پروتکل ایست و انتظار هر بار فقط یک فریم به مقصد ارسال می‌شود. اما در پروتکل پنجره لغزان بیش از یک فریم ارسال می‌شود.
• پروتکل پنجره لغزان پربازده‌تر است زیرا تاخیر انتشار کمتری دارد.
• شیوه ارسال داده‌ها در پروتکل ایست و انتظار نیمه‌دوطرفه، اما در پروتکل پنجره لغزان کاملا دوطرفه است.
• پروتکل پنجره لغزان در مقایسه با پروتکل ایست و انتظار، بازده بیشتری دارد و بهره‌گیری آن از منابع شبکه، بهینه‌تر است. 

سخن پایانی

هر دو پروتکل ایست و انتظار و پنجره لغزان راه‌کاری برای کنترل جریان داده‌ها هستند. اما پروتکل پنجره لغزان پربازده‌تر و بهره‌گیری آن از پهنای باند شبکه، بهینه‌تر است. اما پروتکل ایست و انتظار هرچند ساده است، منابع شبکه را هدر می‌دهد.