لطفا به نکات زیر در هنگام خرید دانلود پاورپوینت سيستم‌عامل پيشرفته توجه فرمایید.

1-در این مطلب، متن اسلاید های اولیه دانلود پاورپوینت سيستم‌عامل پيشرفته قرار داده شده است 2-به علت اینکه امکان درج تصاویر استفاده شده در پاورپوینت وجود ندارد،در صورتی که مایل به دریافت  تصاویری از ان قبل از خرید هستید، می توانید با پشتیبانی تماس حاصل فرمایید 3-پس از پرداخت هزینه ، حداکثر طی 12 ساعت پاورپوینت خرید شده ، به ادرس ایمیل شما ارسال خواهد شد 4-در صورت  مشاهده  بهم ریختگی احتمالی در متون زیر ،دلیل ان کپی کردن این مطالب از داخل اسلاید ها میباشد ودر فایل اصلی این پاورپوینت،به هیچ وجه بهم ریختگی وجود ندارد 5-در صورتی که اسلاید ها داری جدول و یا عکس باشند در متون زیر قرار نخواهند گرفت

اسلاید ۱ :

فصل دوم: ارتباطات در سيستم‌هاي توزيع شده (ادامه)

  • پياده‌سازي مدل Client-Server
  • خلاصه حالات در جدول شكل ۱۴-۲ ص ۶۵ ۸۱ تركيب كه همه آنها به دردبخور هستند.
  • هر شبكه يك Packet Size مشخصي (حداكثر چند هزار بيت) دارد و پيام‌هاي بزرگتر بايد شكسته شوند.
  • با توجه به امكان گم شدن يا ناقص شدن پاكت‌ها يا رسيدن بدون ترتيب آنها شماره‌گذاري مي‌شوند يعني در هر پاكت علاوه بر شماره پيام يك شماره پاكت هم وجود دارد.
  • براي تأييد مي‌توان هر پاكت را ack كرد كه تعداد Packet زياد مي‌شود ولي Recovery ساده است.
  • يا مي‌توان كل پيام را ack كرد كه تعدا Packetها كم مي‌شود ولي با يك پاكت خراب كل پيام بايد تكرار شود.
  • انتخاب بسته به ضريب اطمينان شبكه دارد.
  • موضوع جالب ديگر پروتكل ارتباطي است در شكل ۱۵-۲ ص ۶۶ يك نمونه ارائه شده است. شكل ۱۶-۲ چند نمونه پروتكل
  • براي حالت بدون بافر سيستم مي‌تواند با درخواست Server پروسس‌ها را ثبت نام كند تا پيغام‌هاي رسيده قبل از Receive را با TA برگرداند نه با AU

اسلاید ۲ :

.۴Remote Prcedure Call – احضار روال از راه دور

  • I/O به عنوان بحث مهم در سيستم‌هاي توزيع شده و ماندن عده‌اي به غلط در حل آن
  • احضار برنامه‌اي روي ماشين B توسط برنامه‌اي روي ماشين A (پس از احضار برنامه روي A معلق مي‌شود تا خاتمه كار)
  • پارامتر‌ها مي‌توانند ردوبدل شوند. هيچ I/O ‌اي از ديد برنامه‌نويس موجود نيست.
  • مسئله نظير وجود دو فضاي آدرس متفاوت، مبادله پارامتر‌ها بين دو ماشين متفاوت، توقف ماشين‌ها مطرح است.
  • با وجود اينها RPC زمينه‌ساز خيلي از سيستم‌هاي عامل توزيع شده است.
  • عمليات ابتدايي RPC
  • توجه به يك احضار معمولي شكل ۱۷-۲ ص ۶۹، دو نوع انتقال پارامتر
    ( Value، Reference و Copy/Restor)
  • اينكه چه نوع ارسال پارامتر داشته باشيم به زبان بستگي دارد (C) و گاهي هم انتخابي است (Pascal) و گاهي انواع (Ada)
  • هدف از RPC اين است كه آنرا از ديد كاربر درست شبيه Call عادي انجام دهيم يعني جزئيات مخفي باشد.

اسلاید ۳ :

  • مثال احضار Read ، افزودن روتين Read توسط Linker، گذاشتن پارامتر‌ها در Reg هاي مربوطه انجام System Call
  • پس Read يك واسط بين كاربر و سيستم عامل است كه از طريق Kernel انجام مي‌پذيرد اجضار عادي نيست.
  • جزئيات Read از كاربر مخفي است و مثل يك Call عادي به كار گرفته مي‌شود.
  • نحوه كار RPC هم مشابه Read است.
  • اگر يك RPC Read داشته باشيم برنامه كاربر به شكل عادي (شكل ۱۷-۲) Client Stub را احضار مي‌كند.
  • Cilent Stub پارامتر‌ها را در قالب يك پيام در مي‌آورد و از Kerel مي‌خواهد كه آنرا بفرستد به مقصد
  • Cilent Stub بعد از احضار Send و ارسال پيام Receive را احضار كرده و بلوكه مي‌شود تا جواب بيايد.
  • شكل ۱۸-۲ ص ۷۱ Server Stub هر بيضي يك پروسس است و Stub زير روالي است كه احضار مي‌شود.
  • در Server‌اي كه بايد پيغام را بگيرد Server Stub در Loop اصلي خود Receive را احضار كرده و منتظر است

اسلاید ۴ :

  • Server با دريافت پيام آنرا به Server Stub مي فرستد تا آنرا باز كرده پارامترها را جدا كند.
  • Server Stub به طور معمول (ش ۱۷-۲ ) روتين موجود در Server را احضار مي‌كند.
  • اين روتين پس از انجام عمل، نتيجه را در پارامتر‌ها قرار مي‌دهد و به Stub برميگرداند
  • Server Stub پارامتر‌ها را در قالب پيام بسته‌بندي كرده و از طريق Send به Client مي‌فرستد. با احضار Receiver منتظر پيام بعدي مي‌شود.
  • Kernel مربوط به Client پيغام را مي‌گيرد و مي‌فهمد به كدام پروسس بدهد (آنرا به Process Stub مي‌دهد) ولي Client چيزي از اين نمي‌داند.
  • Client Stub پيغام را باز مي‌كند و نتايج را به برنامه احضار كننده مي‌فرستد و اين برنامه فكر مي‌كند كه احضار عادي انجام داده بود.
  • پس آنچه براي Client جذاب است انجام احضار عادي به جاي Send و Receiver است
  • جزئيات مراحل در ص ۷۲ ولي Client و Server از آنها بي‌خبرند.

اسلاید ۵ :

  • مبادله پارامتر‌ها
  • گرچه مبادلة پارامتر‌ها با استفاده از Stubها به ظاهر ساده است ولي نكاتي در عمل دارد .

(Parameter Marshalling)

  • جزئيات يك احضار در شكل ۱۹-۲ ص ۷۳ آمده است.
  • در صورتي كه دو ماشين Clinet و Server يكسان باشند اين روند درست كار مي‌كند.
  • اگر دو كامپيوتر متفاوت داشته باشيم در بستن و باز كردن پيام‌ها اشكال پيش مي‌آيد.
  • مثال مبادله بين Intel 486 كه Little Endian است و SPARK كه Big Endian است شكل ۲۰-۲ ص ۷۵
  • راه حل ساده است بايد يك قرارداد بين Client و Server در مورد نوع‌هاي اولية داده گذاشته شود. شكل ۲۱-۲ ص ۷۵
  • راه اول تعريف يك استاندارد انتقال مثلاً ones comp + ASCII  و Litt Endian  و الزام به رعايت در مبدأ و مقصد
  • بسيار خوب با تنها عيب كه ماشين‌هاي مشابه ممكن است دو تبديل بيخودي انجام دهند.
  • راه دوم ارسال اطلاعات مربوط به نوع‌ها همراه پيام با اين شرط كه هر دو بتوانند تبديلات انجام دهند.

اسلاید ۶ :

  • روال‌هاي Stub از كجا مي‌آيند؟ با داشتن اطلاعات Server كامپايلر مي‌تواند دستورات لازم را اتوماتيك توليد كند. (بدون خط)
  • يك روال بسته‌بندي پيغام و يك روال باز كردن پيغام با توجه به نوع‌هاي داده و نوع ماشين، توليد مي‌شود.
  • نحوة ارسال Pointerها ؟ راه اول منع آن به طور كامل و ارسال همه پارامتر‌ها به صورت مقدار يا C/R
  • اين راه حل قبول نيست
  • راه دوم اينكه Client Stub محتويات را كپي كند بفرستد، Server Stub روي آن كار كند برگرداند و Cilent Stub دوباره محتويات پيام را در محل اصل كپي كند (شبيه‌سازي C/R)
  • دوباره كپي كردن وقت‌گير است ولي چاره‌اي نيست
  • با دانستن Input، Output يا هر دو (نوع پارامتر) مي‌توان كپي‌ها غير لازم را انجام نداد.
  • براي اينكه در تعريف RPC بايد نوع پارامتر‌ها و حداكثر طول آنها گفته شود.
  • براي ساختمان داده‌هاي پيچيده (درخت‌ها و گراف‌هاي ديناميك) اين روش عملي نيست
  • راه حل پيشنهادي ارسال Pointer و سپس انجام عمليات روي اطلاعات در قالب مبادله پيام است كه گرچه كارآيي خوبي ندارد ولي از هيچ بهتر است.

اسلاید ۷ :

  • چگونه Client موفق مي‌شود Server را پيدا كند (پيدا كردن Client Server, را)
  • راه حل ساده گذاشتن اطلاعات داخل برنامه Client به صورت Hardwiered كه اصلاً انعطاف ندارد. (نياز به ترجمه دوباره همه برنامه‌ها در صورت كوچكترين تغيير)
  • راه حل بهتر Dynamic binding يا وابسته كردن به طور پويا
  • اول نياز به تعريف فرمان براي Server داريم ش ۲۲-۲ ص ۷۸ براي Server ش ۹-۲ ص ۵۵
  • يك Stateless server است يعني نيازي به دانستن وضعيت قبلي (Open بودن فايل‌ها مثلاً) ندارد.
  • Stub generator در كامپايلر ازاين تعاريف فرمان براي توليد Stubها در زمان كامپايل استفاده مي‌كند و نتيجه براي Link شدن در كد باينري در زمان Link در يك Library قرار مي‌گيرد. (براي Client ، Server)
  • با شروع كار Server دستور Initialize ش ۹-۲ باعث ارسال يك پيغام به برنامه Binder براي ثبت نام (register) كردن Server مي‌شود يعني من هستم! (به اين كار export كردن server گويند)
  • براي ثبت نام نياز به اسم، handle, id, version و مجوزهاي دسترسي مي‌باشد.

اسلاید ۸ :

  • Handle وسيله شناسايي فيزيكي است مثل شماره IP يا SPI يا ….
  • حذف نام هم در زمان توقف Server انجام مي‌شود. خلاصه در ش ۲۳-۲ ص ۷۹ رابط 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هاي خاص

اسلاید ۹ :

  • اشكالاتي هم دارد از جمله هزينه سر بار براي عمليات بالا و كند بودن در سيستم‌هاي بزرگ
  • در سيستم‌هاي توزيعي وسيع مي‌توان چند Binder داشت كه با هر تغيير كليه آنها بايد آگاه شوند كه خود يك بار زيادي است.
  • عملكرد RPC هنگام بروز شكست (Failure)
  • با توجه به آنچه ذكر شد در صورت درست كار كردن هر دو ماشين عملكرد مورد نظر توسط RPC تامين مي‌شود.
  • حال اگر اتفاقي افتاد چه مي‌شود؟
  • پنج نوع شكست:
  • عدم امكان يافتن Server توسط Client (نيافتن Client، Server را)
  • گم شدن پيغام ارسالي از Client به Server
  • گم شدن پيغام ارسالي از Server به Client
  • سقوط Server پس از وصول پيام
  • سقوط Client پس از ارسال پيام
  • عدم يافتن Server به دليل down بودن يا عدم تطبيق version هاست. Server جديد، Client قديمي راه حل:؟

اسلاید ۱۰ :

  • مشابه ش ۹-۲ برگردان ۱- توسط توابع در زمان خطا
  • در Unix متغير error حاوي كد نوع خطاست كه يكي هم مي‌تواند “Can’t locate server” باشد.
  • اگر برنامه‌اي مثل SUM باشد ۱- مي‌تواند يك جواب واقعي باشد (۷+(-۸)
  • راه حل ديگر چيزي شبيه ON ERROR است كه در بعضي زبان‌ها هست و با شرط Transparency مغايرت دارد در بعضي زبان‌ها هم نيست.
  • گم شدن پيام درخواست، استفاده از Timeout و تكرار پيام
  • اگر پيغام وقعاً گم شده، با تكرار آن مسئله حل مي‌شود.
  • اگر با چند بار تكرار حل نشد باز مي‌شود Can’t locate server
  • گم شدن پيام پاسخ، يك راه همان Timeout و تكرار پيام درخواست است.
  • بعضي درخواست‌ها تكرارشان بدون اشكال است مثل خواندن يك بلوك (Idempotent)
  • بعضي نيستند مثل انتقال پول بين دو حساب، زير ممكن است كار انجام شود ولي پاسخ گم شود.
  • يك راه دادن شماره رديف به پيغام‌هاست تا Server مواظب باشد هميشه آخرين پيام هر Client چه شماره‌اي بوده
  • راه دوم گذاشتن يك Flag و ۱ كردن آن براي پيغام‌هاي تكراري