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

PowerPoint قابل ویرایش
21 صفحه
8900 تومان

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

1-در این مطلب، متن اسلاید های اولیه دانلود فایل پاورپوینت تجزیه تحلیل سیستم عامل پیشرفته قرار داده شده است

2-به علت اینکه امکان درج تصاویر استفاده شده در پاورپوینت وجود ندارد،در صورتی که مایل به دریافت تصاویری از ان قبل از خرید هستید، می توانید با پشتیبانی تماس حاصل فرمایید

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

مطالب فوق فقط متون اسلاید های ابتدایی پاورپوینت بوده اند . جهت دریافت کل ان ، لطفا خریداری نمایید .
PowerPointقابل ویرایش - قیمت 8900 تومان در 21 صفحه
سایر مقالات موجود در این موضوع
دیدگاه خود را مطرح فرمایید . وظیفه ماست که به سوالات شما پاسخ دهیم

پاسخ دیدگاه شما ایمیل خواهد شد