دانلود پاورپوینت سیستم‌عامل پیشرفته

بخشی از پاورپوینت

اسلاید 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 كردن آن براي پيغام‌هاي تكراري