بخشی از پاورپوینت
اسلاید 1 :
فصل دوم: ارتباطات در سيستمهاي توزيع شده (ادامه)
- پيادهسازي مدل Client-Server
- خلاصه حالات در جدول شكل 14-2 ص 65 81 تركيب كه همه آنها به دردبخور هستند.
- هر شبكه يك Packet Size مشخصي (حداكثر چند هزار بيت) دارد و پيامهاي بزرگتر بايد شكسته شوند.
- با توجه به امكان گم شدن يا ناقص شدن پاكتها يا رسيدن بدون ترتيب آنها شمارهگذاري ميشوند يعني در هر پاكت علاوه بر شماره پيام يك شماره پاكت هم وجود دارد.
- براي تأييد ميتوان هر پاكت را ack كرد كه تعداد Packet زياد ميشود ولي Recovery ساده است.
- يا ميتوان كل پيام را ack كرد كه تعدا Packetها كم ميشود ولي با يك پاكت خراب كل پيام بايد تكرار شود.
- انتخاب بسته به ضريب اطمينان شبكه دارد.
- موضوع جالب ديگر پروتكل ارتباطي است در شكل 15-2 ص 66 يك نمونه ارائه شده است. شكل 16-2 چند نمونه پروتكل
- براي حالت بدون بافر سيستم ميتواند با درخواست Server پروسسها را ثبت نام كند تا پيغامهاي رسيده قبل از Receive را با TA برگرداند نه با AU
اسلاید 2 :
.4Remote Prcedure Call – احضار روال از راه دور
- I/O به عنوان بحث مهم در سيستمهاي توزيع شده و ماندن عدهاي به غلط در حل آن
- احضار برنامهاي روي ماشين B توسط برنامهاي روي ماشين A (پس از احضار برنامه روي A معلق ميشود تا خاتمه كار)
- پارامترها ميتوانند ردوبدل شوند. هيچ I/O اي از ديد برنامهنويس موجود نيست.
- مسئله نظير وجود دو فضاي آدرس متفاوت، مبادله پارامترها بين دو ماشين متفاوت، توقف ماشينها مطرح است.
- با وجود اينها RPC زمينهساز خيلي از سيستمهاي عامل توزيع شده است.
- عمليات ابتدايي RPC
- توجه به يك احضار معمولي شكل 17-2 ص 69، دو نوع انتقال پارامتر
( Value، Reference و Copy/Restor) - اينكه چه نوع ارسال پارامتر داشته باشيم به زبان بستگي دارد (C) و گاهي هم انتخابي است (Pascal) و گاهي انواع (Ada)
- هدف از RPC اين است كه آنرا از ديد كاربر درست شبيه Call عادي انجام دهيم يعني جزئيات مخفي باشد.
اسلاید 3 :
- مثال احضار Read ، افزودن روتين Read توسط Linker، گذاشتن پارامترها در Reg هاي مربوطه انجام System Call
- پس Read يك واسط بين كاربر و سيستم عامل است كه از طريق Kernel انجام ميپذيرد اجضار عادي نيست.
- جزئيات Read از كاربر مخفي است و مثل يك Call عادي به كار گرفته ميشود.
- نحوه كار RPC هم مشابه Read است.
- اگر يك RPC Read داشته باشيم برنامه كاربر به شكل عادي (شكل 17-2) Client Stub را احضار ميكند.
- Cilent Stub پارامترها را در قالب يك پيام در ميآورد و از Kerel ميخواهد كه آنرا بفرستد به مقصد
- Cilent Stub بعد از احضار Send و ارسال پيام Receive را احضار كرده و بلوكه ميشود تا جواب بيايد.
- شكل 18-2 ص 71 Server Stub هر بيضي يك پروسس است و Stub زير روالي است كه احضار ميشود.
- در Serverاي كه بايد پيغام را بگيرد Server Stub در Loop اصلي خود Receive را احضار كرده و منتظر است
اسلاید 4 :
- Server با دريافت پيام آنرا به Server Stub مي فرستد تا آنرا باز كرده پارامترها را جدا كند.
- Server Stub به طور معمول (ش 17-2 ) روتين موجود در Server را احضار ميكند.
- اين روتين پس از انجام عمل، نتيجه را در پارامترها قرار ميدهد و به Stub برميگرداند
- Server Stub پارامترها را در قالب پيام بستهبندي كرده و از طريق Send به Client ميفرستد. با احضار Receiver منتظر پيام بعدي ميشود.
- Kernel مربوط به Client پيغام را ميگيرد و ميفهمد به كدام پروسس بدهد (آنرا به Process Stub ميدهد) ولي Client چيزي از اين نميداند.
- Client Stub پيغام را باز ميكند و نتايج را به برنامه احضار كننده ميفرستد و اين برنامه فكر ميكند كه احضار عادي انجام داده بود.
- پس آنچه براي Client جذاب است انجام احضار عادي به جاي Send و Receiver است
- جزئيات مراحل در ص 72 ولي Client و Server از آنها بيخبرند.
اسلاید 5 :
- مبادله پارامترها
- گرچه مبادلة پارامترها با استفاده از Stubها به ظاهر ساده است ولي نكاتي در عمل دارد .
(Parameter Marshalling)
- جزئيات يك احضار در شكل 19-2 ص 73 آمده است.
- در صورتي كه دو ماشين Clinet و Server يكسان باشند اين روند درست كار ميكند.
- اگر دو كامپيوتر متفاوت داشته باشيم در بستن و باز كردن پيامها اشكال پيش ميآيد.
- مثال مبادله بين Intel 486 كه Little Endian است و SPARK كه Big Endian است شكل 20-2 ص 75
- راه حل ساده است بايد يك قرارداد بين Client و Server در مورد نوعهاي اولية داده گذاشته شود. شكل 21-2 ص 75
- راه اول تعريف يك استاندارد انتقال مثلاً ones comp + ASCII و Litt Endian و الزام به رعايت در مبدأ و مقصد
- بسيار خوب با تنها عيب كه ماشينهاي مشابه ممكن است دو تبديل بيخودي انجام دهند.
- راه دوم ارسال اطلاعات مربوط به نوعها همراه پيام با اين شرط كه هر دو بتوانند تبديلات انجام دهند.
اسلاید 6 :
- روالهاي Stub از كجا ميآيند؟ با داشتن اطلاعات Server كامپايلر ميتواند دستورات لازم را اتوماتيك توليد كند. (بدون خط)
- يك روال بستهبندي پيغام و يك روال باز كردن پيغام با توجه به نوعهاي داده و نوع ماشين، توليد ميشود.
- نحوة ارسال Pointerها ؟ راه اول منع آن به طور كامل و ارسال همه پارامترها به صورت مقدار يا C/R
- اين راه حل قبول نيست
- راه دوم اينكه Client Stub محتويات را كپي كند بفرستد، Server Stub روي آن كار كند برگرداند و Cilent Stub دوباره محتويات پيام را در محل اصل كپي كند (شبيهسازي C/R)
- دوباره كپي كردن وقتگير است ولي چارهاي نيست
- با دانستن Input، Output يا هر دو (نوع پارامتر) ميتوان كپيها غير لازم را انجام نداد.
- براي اينكه در تعريف RPC بايد نوع پارامترها و حداكثر طول آنها گفته شود.
- براي ساختمان دادههاي پيچيده (درختها و گرافهاي ديناميك) اين روش عملي نيست
- راه حل پيشنهادي ارسال Pointer و سپس انجام عمليات روي اطلاعات در قالب مبادله پيام است كه گرچه كارآيي خوبي ندارد ولي از هيچ بهتر است.
اسلاید 7 :
- چگونه Client موفق ميشود Server را پيدا كند (پيدا كردن Client Server, را)
- راه حل ساده گذاشتن اطلاعات داخل برنامه Client به صورت Hardwiered كه اصلاً انعطاف ندارد. (نياز به ترجمه دوباره همه برنامهها در صورت كوچكترين تغيير)
- راه حل بهتر Dynamic binding يا وابسته كردن به طور پويا
- اول نياز به تعريف فرمان براي Server داريم ش 22-2 ص 78 براي Server ش 9-2 ص 55
- يك Stateless server است يعني نيازي به دانستن وضعيت قبلي (Open بودن فايلها مثلاً) ندارد.
- Stub generator در كامپايلر ازاين تعاريف فرمان براي توليد Stubها در زمان كامپايل استفاده ميكند و نتيجه براي Link شدن در كد باينري در زمان Link در يك Library قرار ميگيرد. (براي Client ، Server)
- با شروع كار Server دستور Initialize ش 9-2 باعث ارسال يك پيغام به برنامه Binder براي ثبت نام (register) كردن Server ميشود يعني من هستم! (به اين كار export كردن server گويند)
- براي ثبت نام نياز به اسم، handle, id, version و مجوزهاي دسترسي ميباشد.
اسلاید 8 :
- Handle وسيله شناسايي فيزيكي است مثل شماره IP يا SPI يا ....
- حذف نام هم در زمان توقف Server انجام ميشود. خلاصه در ش 23-2 ص 79 رابط Binder
- حال وقتي يك RPC انجام ميشود مثلاً يك Read توسط Client
- Client Stub عدم اتصال به Server مورد نياز را متوجه ميشود.
- پيامي به Binder ميفرستد براي Import كردن Version خاصي از واسط Server مربوطه
- اگر چنين واسطي از هيچ Servery تا حالا export نشده با شماره version ها تطبيق ندارد Fail ميكند.
- اگر نه، Handle و شماره شناسايي را برميگرداند تا توسط Client در جوف پيام گذاشته شود.
- بعد از ارسال پيام، Server ها آن را چك كرده فقط Server مورد نظر پيام را برميدارد با در نظر گرفتن Version
- انعطافپذيري زيادي در اين روش وجود دارد.
- داشتن چند Server ارائه دهنده خدمات مشابه
- امكان تقسيم بار كاري به طور اتوماتيك روي Serverها
- Poll كردن Serverها و حذف نام آنها كه خوابيدهاند به طور اتوماتيك
- رعايت كردن مجوزهاي دسترسي به Serverهاي خاص
اسلاید 9 :
- اشكالاتي هم دارد از جمله هزينه سر بار براي عمليات بالا و كند بودن در سيستمهاي بزرگ
- در سيستمهاي توزيعي وسيع ميتوان چند Binder داشت كه با هر تغيير كليه آنها بايد آگاه شوند كه خود يك بار زيادي است.
- عملكرد RPC هنگام بروز شكست (Failure)
- با توجه به آنچه ذكر شد در صورت درست كار كردن هر دو ماشين عملكرد مورد نظر توسط RPC تامين ميشود.
- حال اگر اتفاقي افتاد چه ميشود؟
- پنج نوع شكست:
- عدم امكان يافتن Server توسط Client (نيافتن Client، Server را)
- گم شدن پيغام ارسالي از Client به Server
- گم شدن پيغام ارسالي از Server به Client
- سقوط Server پس از وصول پيام
- سقوط Client پس از ارسال پيام
- عدم يافتن Server به دليل down بودن يا عدم تطبيق version هاست. Server جديد، Client قديمي راه حل:؟
اسلاید 10 :
- مشابه ش 9-2 برگردان 1- توسط توابع در زمان خطا
- در Unix متغير error حاوي كد نوع خطاست كه يكي هم ميتواند "Can’t locate server" باشد.
- اگر برنامهاي مثل SUM باشد 1- ميتواند يك جواب واقعي باشد (7+(-8)
- راه حل ديگر چيزي شبيه ON ERROR است كه در بعضي زبانها هست و با شرط Transparency مغايرت دارد در بعضي زبانها هم نيست.
- گم شدن پيام درخواست، استفاده از Timeout و تكرار پيام
- اگر پيغام وقعاً گم شده، با تكرار آن مسئله حل ميشود.
- اگر با چند بار تكرار حل نشد باز ميشود Can’t locate server
- گم شدن پيام پاسخ، يك راه همان Timeout و تكرار پيام درخواست است.
- بعضي درخواستها تكرارشان بدون اشكال است مثل خواندن يك بلوك (Idempotent)
- بعضي نيستند مثل انتقال پول بين دو حساب، زير ممكن است كار انجام شود ولي پاسخ گم شود.
- يك راه دادن شماره رديف به پيغامهاست تا Server مواظب باشد هميشه آخرين پيام هر Client چه شمارهاي بوده
- راه دوم گذاشتن يك Flag و 1 كردن آن براي پيغامهاي تكراري