دانلود فایل پاورپوینت تجزیه تحلیل سیستم عامل پیشرفته

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

--- پاورپوینت شامل تصاویر میباشد ----

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