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

توجه : این فایل به صورت فایل power point (پاور پوینت) ارائه میگردد

 پاورپوینت سیستم‌ عامل پیشرفته دارای ۲۰ اسلاید می باشد و دارای تنظیمات کامل در Power Point می باشد و آماده پرینت یا چاپ است

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

این پروژه توسط مرکز پاورپوینت سیستم‌ عامل پیشرفته۲ ارائه میگردد

توجه : در صورت  مشاهده  بهم ریختگی احتمالی در متون زیر ،دلیل ان کپی کردن این مطالب از داخل فایل می باشد و در فایل اصلی پاورپوینت سیستم‌ عامل پیشرفته،به هیچ وجه بهم ریختگی وجود ندارد

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

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

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

اسلاید :

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

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

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

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

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

صفحات:۲۰ اسلاید