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

پاورپوینت سیستم‌عامل پیشرفته دارای 20 اسلاید می باشد که بخشی از متن و فهرست آن را در ادامه برای مشاهده قرار داده ایم و در صورت نیاز به داشتن کل این پاورپوینت می توانید آن را دریافت نموده و از آن استفاده نمایید

اسلاید ۱ :

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

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

مطالب فوق فقط متون اسلاید های ابتدایی پاورپوینت بوده اند . جهت دریافت کل ان ، لطفا ان را خریداری نمایید .

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

فرمت:پاورپوینت

صفحات:20 اسلاید