پروتکل پنجره لغزان چیه ؟ و یه سری سوال ...

[ellisa]

با سلام
من یه سری اطلاعات راجع به پروتکل پنجره لغزان میخوام ... هر چی سرچ کردن مطلب مفید و قابل توجهی که بشه بعنوان تحقیق ارائه داد پیدا نکردم ... من میخوام بدونم کنترل جریان در این پروتکل چه جوری انجام میشه؟ و کنترل خطا در کنترل جریان در این پروتکل چه جوریه؟ و اندازه و طول پنجره در پروتکل پنجره لغزان به چه صورت است ؟ ممنون میشم راهنمایی جامع و کاملی در این زمینه به من کنید ...

با سپاس

[hess]

پاسخ : پروتکل پنجره لغزان چیه ؟ و یه سری سوال ...

سلام ..............

من میتونم در مورد پروتکل پنجره ی لغزان اطلاعاتی رو در اختیارتون بذارم منتهی میفته آخر هفته .. اشکال که نداره .. شرمنده ..

[hess]

پاسخ : پروتکل پنجره لغزان چیه ؟ و یه سری سوال ...

سلام .......................

اولا ببخشید که یک مقدار دیر شد .... ببینید برای اینکه به معرفی این پروتکل بپردازیم باید یک مقدار به عقب بر گردیم و ببینیم که این پروتکل در مقابل چه پروتکلی معرفی شده و اصلا بحث این پروتکل ها سر چیه؟

پروتکل پنجره ی لغزان (Sliding Window ) در مقابل پروتکل توقف و انتظار (Stop & Wait) تعریف شده و برای کنترل جریان در لینک دیتا به کار میره . پس نکته ی اول اینکه این پروتکل ها مربوط میشه به لایه ی دیتا لینک . نکته ی دوم اینکه این پروتکل ها برای کنترل جریان به کار میرن . اما معنی کنترل جریان چیه؟

کنترل جریان به این منظور در لینک های ارتباطی انجام میشه که از سرریز شدن اطلاعات در گیرنده جلوگیری بشه . یعنی چی در گیرنده؟ منظور همون بافر هایی هستن که در گیرنده قرار دارن (و البته در فرستنده..) و برای دریافت دیتا به کار میرن . حالا اصلا کنترل جریان دیتا در لایه ی لینک چه لزومی داره؟ یه مثال بزنم .. ببینید فرض کنید فرستنده (ایستگاه فرستنده ..) یه سری دیتا (فریم یا پاکت ..) به گیرنده ارسال میکنه و گیرنده هم باید اطلاعات دریافت شده رو پردازش کنه و اونها رو به لایه ی بالاتر خودش تحویل بده . خب اینجا اگه فرستنده دیتایی بیش از ظرفیت ماکزیمم بافر گیرنده برای اون ارسال کنه ، زودتر از زمانی که گیرنده بتونه اونهارو پردازش بکنه و به لایه ی بالاتر تحویل بده و بافر خودش رو برای دریافت اطلاعات جدید آماده کنه ، دیتاهای دریافتی در بافر گیرنده Over Write میشن و اطلاعات دریافتی دچار اختلال شده و طبیعتا صحتشون از دست میره . برای این منظور باید از سرریز شدن بافر گیرنده قبل از زمانی که کار اون لایه (دیتالینک ..) با دیتاهای دریافتی تموم میشه ، جلوگیری بشه یعنی جریان در لینک دیتا کنترل بشه . اهمیت این لایه در شبکه های LAN بیشتر به چشم میاد .

تا اینجا منظور از کنترل جریان رو متوجه شدیم . اما بریم سراغ پروتکل S & W ببینیم این طرز کارش چجوریه؟ اگه بخوایم به صورت خیلی کامل و البته با شرح به اسم این پروتکل نگاه کنیم میتونیم بگیم که کامل این این پروتکل رو میشه اینطوری تعبیر کرد .. Send—Stop—Wait—Send یعنی چی ؟ یعنی ایده ی بسیار ساده ی ارسال فریم، توقف ارسال مجدد همون فریم، انتظار برای دریافت ACK و ارسال فریم بعدی .. ببینید اساس این پروتکل بر این اصله که شما در یه شبکه فرضی فریمی که از طرف فرستنده ارسال میکنید ، رو با دریافت یه ACK از طرف گیرنده تصدیق شده میبینید و میرید سراغ ارسال فریم بعدی . حالا اگه گیرنده این ACK رو برای فرستنده ارسال نکنه جریان ارسال متوقف میشه و این اتفاق به این معناست که به هر دلیلی فریم ارسالی به گیرنده نرسیده و دوباره این عمل (ارسال مجدد همون فریم ..) باید از نو انجام بشه ..

عملا پروتکل بی نقصیه مخصوصا این که خیلی برای Implement کردن اون نمیخواد وقت صرف کنیم و پروتکل های پیچیده تعریف کنیم . از طرفی به نظر میرسه که برای فریم های بزرگ واقعا جواب میده . اما اگه یه مقدار دقیق تر نگاه کنیم متوجه میشیم که خیلی هم برای کار ما مفید نیست . اجازه بدید یه مثال بزنم . فرض کنید در یه شبکه بخواین فریم هایی با اندازه های بزرگ رو از طریق این پروتکل ارسال کنید . خب عملا ارسال فریم های بزرگ امکان پذیر نیست . به چند دلیل .. اول اینکه ممکنه اندازه ی بافر گیرنده محدود باشه و با سایز فریم شما نخونه . دوم اینکه اگه خطایی (حالا به هر دلیل ..) در ارسال صورت بگیره و فریم به دست گیرنده نرسه باید کل فریم دوباره ارسال بشه و این یعنی اطلاف وقت بسیار زیاد و صرف هزینه ی فراوان . سوم اینکه اگه شبکتون LAN باشه دیگه نمیشه یه خط برای مدت طولانی در وضعیت Busy بمونه و این عمل باعث انتظار بیش از حد ایستگاه های گیرنده (یا فرستنده ی ..) دیگه میشه که اصلا به صلاح شبکه نیست و در حقیقت بار ترافیکی شبکه میره بالا . پس نمیتونیم از فریم های بزرگ استفاده کنیم . خب مساله ای نیست فریم هارو کوچیک میکنیم . اما مشکل پروتکل اینجا مشخص میشه . ببینید فاصله ی بین فرستنده و گیرنده معمولا خیلی بیشتر از طول فریمه و این یعنی کاهش کارایی پروتکل S & W . چرا؟ چون در هر زمان مشخص تنها یک فریم میتونه روی خط باشه ß فرستنده بعد از ارسال فریم باید منتظر بمونه تا فریم به گیرنده برسه، بعدگیرنده ACK برای اون ارسال کنه، بعد فرستنده این ACK رو دریافت کنه و بعد شروع کنه به ارسال فریم بعدی . خب به نظر شما از زمان ارسال آخرین فیلد فریم توسط فرستنده تا زمانی که ACK گیرنده رو دریافت کنه ؛ خط چه وضعیتی داره؟ کاملا خالیه و نمیتونه برای ارسال فریم مفید باشه . پس این پروتکل مورد استقبال قرار نمیگیره ..

اما پروتکل پنجره ی لغزان چجوری کار میکنه؟ چه فرقی با S & W داره؟ اصلی ترین مشکلی که برای S & W مطرح میشد این بود که در هر زمان تنها یک فرم میتونست روی خط در حال ارسال باشه . خب این مشکل در پروتکل Sliding Window حل شد . یعنی برای فرستنده این امکان وجود داشت که چندین فریم رو به صورت متوالی ارسال کنه و در مجموع ACK ترتیبی خاص رو برای اطلاع از صحت دریافت به فرستنده ارسال کنه . (ACK تجمعی ..) اگه به شکل زیر توجه گنید مطلب براتون کامل مشخص میشه که طرز کار این پروتکل به چه ترتیبه . اجازه بدید این طرز کار رو از روی شکل توضیح بدم ..

در قسمت اول شکل دو ایستگاه مشخص شده یکی دست راست که فرستنده ی شبکه هست و دست چپی هم گیرنده . خب ببینید مربع های خاکستری که در این قسمت مشخص شدن در واقع همون پنجره های ما هستم که از اندازه ی هفت هستن . (یعنی میتونن هفت فریم رو یکجا ارسال کنن ..) اما معنای دو پنجره در فرستنده و گیرنده چیه؟ در فرستنده منظور از اون پنجره با اندازه ی هفت مجموعه ی فریم هایی هستن که آماده ی ارسال هستن و در گیرنده هم منظور فریم هایی هستن که گیرنده انتظار دریافتشون رو داره .

قسمت دوم لحظه ایه که ارسال داره انجام میشه و فریم های 0 و 1 و 2 و 3 دارن ارسال میشن و به همین ترتیب طول پنجره (هم در فرستنده و هم در گیرنده ..) کاهش پیدا کرده . اما گیرنده در این لحظه ACK4 رو به فرستنده میفرسته یعنی تائید میکنه که فریم های ماقبل اون همگی به درستی دریافت شدن . منظور از ACK تجمعی هم دقیقا همینه . یعنی هر ACK معرف فریم های ماقبل اونه . مثلا ACK4 میشه تائید دریافت فریم های 0 و 1 و 2 و 3 توسط گیرنده . در این لحظه پنجره در فرستنده به اندازه ی اولیه ای که بوده لغزانده میشه به این معنا که حیطه ی پوشش خودش برای ارسال فریم هارو به هفت فریم بعدی تعمیم میده . (پایان قسمت سه .. )

قسمت چهارم هم حالت دیگه ای از این پروتکل رو نشون میده . توضیحش هم مثل بالا هست . پس از دریافت فریم 4 توسط گیرنده ، ACK5 توسط اون ارسال میشه و اینجای کار یعنی لغزانده شدن پنجره ی ارسال . اما در این زمان فریم های 5 و 6 و 7 در حال ارسال هستن پس پنجره ی فرستنده و به طبع اون گیرنده به اندازه ی (هفت منهای سه) برای فریم های منتظر برای ارسال و دریافت لغزونده میشه که در شکل کاملا مشخص شدن .

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

این لینک تصویره پایینه . برای این گذاشتم که شاید مرورگرتون نتونه همه ی تصویر رو نمایش بده .. امیدوارم توضیحات تونسته باشه براتون مفید باشه .. موفق باشید .

http://i34.tinypic.com/2rmvaiw.png

[abedjoon]

پاسخ : پروتکل پنجره لغزان چیه ؟ و یه سری سوال ...

سلام
http://en.wikipedia.org/wiki/Sliding_window