تحقیق سیستم های توزیع شده



پایان نامه جهت اخذ درجه کارشناسی
رشته فناوری اطلاعات

موضوع:
سیستم های توزیع شده

استاد راهنما:

دانشجو:

بهار93

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

در تاریخ…………. توسط استاد راهنما، پروژه دانشجو ………………….. به شماره دانشجویی …………….بررسی و با نمره به عدد……… به حروف………………………. به تصویب نهایی رسید.
نام استاد راهنمای پروژه امضاء و تاریخ

امضاء مدیر گروه

سپاس و تقدیر
حمد وسپاس ارزانی بارگاه حضرات احدیت که این حقیر را توفیق خوشه چینی از خرمن دانش و معرفت عطا فرمود و در پرتو الطاف خداوندیش استقامت و امیدمان بخشید. بدان امید که مورد قبول صاحب نظران واستاد محترم قرار گیرد. که اگر ارشاد و راهنمایی آن بزرگوار نبود به انجام رساندن این کار در امکان این حقیر نمی گنجید.
در اینجا لازم است از استاد گرامی مهندس ……………. که با صبر و بردباری مرا در ارائه این تحقیق با سعه صدر راهنمایی و ارشاد نموده اند تشکر و قدردانی نمایم و نهایت سپاسگزاری را از ایشان به عمل آورم.

تقدیم به:
همسر و پدر و مادر عزیزم

چکیده
سیستم های توزیع شده
سیستم های توزیع شده از کامپیوتر های خود مختار تشکیل شده اند که ضمن همکاری با هم، نمایی از یک سیستم منسجم و منفرد ارائه می دهند. یکی از مهمترین مزایای این گونه سیستم ها آن است که تلفیق برنامه های کاربردی مختلف را، که روی کامپیوتر های مختلفی در حال اجرا هستند، در یک سیستم واحد تسهیل می کنند. مزیت دیگر سیستم های توزیع شده این است که در صورت طراحی مناسب، به خوبی با ابعاد شبکه زیر بنایی مقیاس پذیر می شوند. اما هزینه ای که در قبال این مزایا بپردازیم، افزایش پیچیدگی نرم افزار، افت کارایی و کاهش سطح امنیتی است وجود تمام این اشکالات، هنوز هم علاقه زیادی به ساخت و نصب سیستم های توزیع شده در سرتاسر جهان وجود دارد. هدف غالب سیستم های توزیع شده مخفی سازی بسیاری از پیچیدگی های مربوط به توزیع فرآیندها، داده ها وکنترل آنهاست. اما کسب این شفافیت توزیع شده نه تنها باعث افت عملکرد می شود، بلکه در موقعیت های علمی هم هرگز به طور کامل محقق نمی شود. در طراحی سیستم های توزیع شده بایستی مساله ایجاد توازن در کسب اشکال مختلف شفافیت توزیع شده لحاظ شده و همین امر درک آنها را پیچیده می کند. پیچیدگی بیشتر ناشی از این واقعیت است که بسیاری از سازندگان در ابتدای کار فرضیات اساساً نادرستی راجع به شبکه زیر بنایی در نظر دارند. بعدها که این فرضیات با شکست مواجه می شود، ممکن است سرپوش گذاشتن بر رفتار ناخواسته ناشی از آنها مشکل ساز شود. بعنوان مثال، این فرض که تاخیرهای شبکه ناچیز هستند، را درنظر بگیرید. بعداً، حین انتقال سیستم موجود به یک شبکه گسترده، مخفی سازی تاخیرها ممکن است تاثیر شدیدی بر طرح اولیه سیستم داشته باشد. از نمونه فرض های نابجای دیگر می توان به فرض قابل اطمینان بودن، ثبات، ایمنی و همگن بودن شبکه اشاره کرد. انواع مختلف سیستم های توزیع شده را می توان در سه گروه سیستم های پشتیبان محاسبات، پردازش اطلاعات و شرکتی دسته بندی کرد. سیستم های محاسبه توزیع شده نوعاً برای برنامه های کاربردی با کارایی بالا، که از حوزه محاسبه موازی سرچشمه می گیرند، ایجاد شده اند. گروه دیگری از سیستم های توزیع شده را می توان در دفاتر کار سنتی مشاهده کرد که پایگاه های داده در آنها نقش مهمی ایفا می کنند. معمولا در این محیط ها از سیستم های پردازش تراکنش استفاده می شود. در آخرین گروه سیستم های توزیع شده نوظهور، مولفه ها کوچک بوده و سیستم به صورت موردی ساخته می شود، اما مدیریت آنها دیگر بر عهده سرپرست سیستم نمی باشد. از محیط های محاسبه همه جا حاضر می توان بعنوان نمونه بارز این گروه نام برد.
کلمات کلیدی:
سیستم های توزیع شده، کامپیوتر، سیستم، برنامه های کاربردی

فهرست مطالب
عنوان شماره صفحه

فصل اول- سیستم های توزیع شده 1
1-1 تعریف سیستم های توزیع شده 1
1-2 اهداف 3
1-2-1دسترس پذیر کردن منابع 4
1-2-2 شفافیت توزیع 5
1-2-3 باز بودن 7
1-2-4 مقیاس پذیری 9
1-2-5 طرح اشکال 12
1-3 انواع سیستم های توزیع شده 12
1-3-1 سیستم های محاسبات توزیع شده 13
1-3-2 سیستم های اطلاعات توزیع شده 16
1-3-3 سیستم های فراگیر توزیع شده 19
فصل دوم- معماری 22
2-1 شیوه های معماری 22
2-2معماری های سیستم 25
2-2-1 معماری های متمرکز 25
2-2-2 معماری های غیر متمرکز 26
2-2-3 معماری های هیبریدی (دورگه) 29
2-3 معماری یا میان افزار؟ 30
2-3-1 رهگیرها 31
2-3-2 رویکردهای عمومی به نرم افزار تطبیقی 32
2-4 خود مدیریتی در سیستم های توزیع شده 33
فصل سوم- ارتباطات 34
3-1 ارتباطات 34
3-1-1 پروتکل های لایه ای 35
3-1-2 انواع ارتباطات 39
3-2 فراخوانی روال راه دور 40
3-2-1 عملیات اصلی RPC 41
2-2-3 پاس کردن پارامتر 44
2-3-2 RPC ناهمگام 45
3-3 ارتباطات پیام گرا 48
3-3-1 ارتباطات پیام گرای ناپایدار 49
3-3-2 ارتباطات پیام گرای پایدار 50
3-4 ارتباطات چند پخشی 53
3-4-1 چندبخشی سطح کاربرد 53
3-4-2 همگام سازی جویبار 55
فصل چهارم- تحمل خرابی 57
4-1 مقدمه ای بر خرابی پذیری 57
4-1-1 مفاهیم اساسی 58
4-1-2 مدل های خرابی 59
4-1-3 پوشش خرابی با افزونگی 62
4-2 مسائل طراحی 62
4-2-1پوشش خرابی و تکثیر 64
4-2-2تشخیص خرابی 64
4-3 ارتباط بین مشتری و خدمتگزار 65
4-3-1 ارتباط نقطه به نقطه 66
4-3-2 فراخوانی روال راه دور در حضور خرابی 66
4-4 ارتباط قابل اطمینان بین اعضای گروه 69
4-4-1 روش های ساده چند پخشی قابل اطمینان 69
4-4-2 گسترش پذیری در چند پخشی قابل اطمینان 70
4-4-3 چند پخشی تقسیم ناپذیر 70
4-5 تعهد اجرایی توزیع شده 72
4-5-1 تعهد اجرایی دو مرحله ای 72
4-5-2 تعهد اجرایی سه مرحله ای 73
4-6 ترمیم خرابی و برگشت سیستم 74
4-6-2 نقطه بازرسی 75
4-6-3 ثبت پیام 76
4-6-4 محاسبات ترمیم گرا 77
فصل پنجم- امنیت 78
5-1 مقدمه ای بر امنیت 78
5-1-1 تهدیدهای امنیتی: سیاست ها و مکانیزم ها 78
5-1-2 مسائل طراحی 81
5-1-3 رمز نگاری 83
5-2 کانال های امن 86
5-2-1 احراز هویت 86
5-2-2 یکپارچگی پیام و محرمانگی 87
5-2-3 ارتباطات گروهی امن 88
5-3 کنترل دسترسی 88
5-3-1 دیوار آتش 90
5-3-2 عدم پذیرش سرویس 92
5-4 مدیریت امنیت 93
فصل ششم- سیستم های توزیع شده شئ محور 94
6-1 نام گذاری 94
6-1-1 مرجع شئ در CORBA 94
6-2 سازگاری و تکثیر 100
6-2-1 سازگاری مدخل 100
6-3 تحمل خرابی 101
6-3-1 خرابی پذیری در CORBA 101
منابع و ماخذ: 104

فهرست شکل ها
عنوان شماره صفحه
شکل 1-1 چهار کامپیوتر شبکه شده و سه برنامه کاربردی را نمایش می دهد 3
شکل1-2 نمونه ای از سیستم های محاسبه خوشه 14
شکل1-3 معماری لایه ای سیستم های محاسبه توری. 15
شکل1-4 تراکنش تو در تو 18
شکل 2-1 جریان پاسخ 24
شکل 2-2 ارتباط پروتکل ها 28
شکل2-3 سازمان سلسله مراتبی گره ها در یک شبکه ابر نظیر 29
شکل3-1. لایه ها، واسط ها و پروتکل های مدل OSI 36
شکل3-2 اصول کلی RPC بین برنامه مشتری و خدمتگزار 42
شکل3-3 الف) برهم کنش بین مشتری و خدمتگزار در یک RPC متعارف 46
شکل 3-3 ب) برهم کنش بین مشتری و خدمتگزار با استفاده از RPCناهمگام 46
شکل3-4 چهار ترکیب ارتباط سست پیوند با استفاده از صف 51
شکل5-1 سازماندهی منطقی یک سیستم توزیع شده به چند لایه 82
شکل5-2 روش متداول پیاده سازی دیوار آتش 90
شکل 6-1 ساختار یک IOR همراه با اطلاعات ویژه برای IIOP 96

فهرست جداول
عنوان شماره صفحه
جدول 1-1 اشکال مختلف شفافیت در سیستم های توزیع شده 5
جدول 1-2 لیست دقیق عمل های پایه بستگی به نوع اشیاء مورد استفاده در تراکنش 17
جدول 4-1 نوع خرابی با توضیحات 60
جدول 6-1 انواع فیلد و کارهای آنها 98

فصل اول- سیستم های توزیع شده

1-1 تعریف سیستم های توزیع شده
سیستم های توزیع شده در واقع مجموعه ای از کامپیوترهای مستقل (independent computers) است که برای کاربرد خود مانند یک سیستم منسجم (coherent) ومنفرد (singel) به نظر می رسد.
این تعریف نکته های مختلفی و مهمی در خود دارد. اول آن که، یک سیستم توزیع شده از مولفه ها (یعنی، کامپیوترهای) خود مختار تشکیل می شود. نکته دوم اینکه، کاربران (چه افراد و چه برنامه ها) تصور می کنند که با یک سیستم منفرد کار می کنند. به این معنا که مولفه های خود مختار
(autonomous components) بایستی به روشی با هم همکاری کنند. نحوه ایجاد این تشریک مساعی هسته سیستم های توزیع شده را تشکیل می دهد. توجه داشته باشید که هیچ فرضی راجع به نوع کامپیوتر ها صورت نمی گیرد. اما در مجموع، حتی در داخل یک سیستم منفرد هم انواع کامپیوترها، از کامپیوتر های بزرگ کارآمد گرفته تا گره های کوچک در شبکه های حسگر، به چشم می خورند. به همین ترتیب، هیچ فرضی راجع به نحوه اتصال کامپیوترها صورت نمی گیرد.

ویژگیهای مهم سیستم های توزیع شده
یکی از این ویژگی ها این است که تفاوت های بین کامپیوتر های مختلف و نحوه ارتباط آنها تا حد زیادی از دید کاربران مخفی می باشد. همین امر در مورد سازمان های داخلی (internal organization) سیستم های توزیع شده صدق می کند. ویژگی مهم دیگر اینکه کاربران و برنامه های کاربردی می توانند به صورتی منسجم و متحد با سیستم توزیع شده ارتباط برقرار کنند، مستقل از این که این تعامل در کجا و کی صورت پذیرد.
در مجموع، توسعه یا به مقیاس در آوردن (scale) سیستم های توزیع شده باید نسبتاً به راحتی انجام شود. این ویژگی، هرچند پیامد مستقیم استقلال کامپیوترهاست، در عین حال باعث مخفی سازی کلی نقش واقعی این کامپیوترها در سیستم می شود. حتی در صورت خرابی موقت برخی بخش های سیستم توزیع شده ، این سیستم ها معمولاً همواره در دسترس هستند. با این وجود، کاربران و برنامه های کاربردی نبایستی متوجه تعمیر یا تعویض بخش های معیوب و یا افزودن یا عدم افزودن بخش های جدید برای خدمت رسانی به کاربران یا برنامه های کاربردی بشوند.
مطابق شکل1-1، سیستم های توزیع شده بمنظور پشتیبانی از کامپیوترها و شبکه های ناهمگن (heterogeneous) و در عین حال ارئه نمایی تک سیستمی، غالباً بوسیله لایه ای از نرم افزار سازماندهی می شوند یعنی، بصورت منطقی بین یک لایه سطح بالاتر، شامل کاربران و برنامه های کاربردی و یک لایه زیرین، حاوی سیستم های عامل و امکانات ارتباطی قرار داده می شوند. به همین دلیل، این نوع سیستم توزیع شده گاهی اوقات میان افزار (middleware) نامیده می شود.

شکل 1-1 چهار کامپیوتر شبکه شده و سه برنامه کاربردی را نمایش می دهد

برنامه کاربردی B در بین ماشین های 2 و 3 توزیع شده است. برای هریک از برنامه های کاربردی یک واسط واحد ارائه می شود. سیستم توزیع شده امکانی را برای ارتباط مولفه های یک برنامه کاربردی منفرد با یکدیگر و همچنین برای ارتباط برنامه های کاربردی مختلف با یکدیگر فراهم می کند. در عین حال، به بهترین و منطقی ترین روش ممکنه، تفاوت های بین سخت افزار و سیستم های عامل را از برنامه های کاربردی مخفی می کند.

1-2 اهداف
امکان ساخت سیستم های توزیع شده لزوماً به معنای خوب بودن این ایده نیست. مثلاً، هر چند فن آوری نوین امکان قرار دادن چهار فلاپی دیسک درایو روی کامپیوترهای شخصی را فراهم آورده، ولی به دلیل بی مورد بودن کسی حتی به فکر انجام آن هم نمی افتد.
1- دسترس پذیر کردن منابع
2- شفافیت توزیع
3- باز بودن
4- مقیاس پذیری

1-2-1 دسترس پذیر کردن منابع
هدف اصلی سیستم های توزیع شده آن است که کاربران و برنامه های کاربردی بتوانند به راحتی به منابع از راه دور دسترسی پیدا کرده و بصورتی کنترل شده و موثر در آنها شریک (share) شوند. این منابع ممکن است از هر نوعی باشند، اما به عنوان برخی نمونه ها می توان به چاپگرها، کامپیوترها، تجهیزات ذخیره سازی، داده ها، فایل ها، صفحات وب و شبکه ها اشاره کرد.
اتصال کاربران و منابع باعث تسهیل همکاری و تبادل اطلاعات می شود که از نمونه های آن می توان به موفقیت اینترنت در سایه پروتکل های ساده آن جهت تبادل فایل ها، کارهای پستی، اسناد، صوت و تصویر اشاره کرد. امروزه، اتصال به اینترنت باعث ایجاد سازمان های مجازی (virtual organizations) متعددی شده که در آنها گروه های انسانی که گاهی اوقات حتی چند صد هزار کیلومتر از هم فاصله دارند، با استفاده از گروه افزار (groupware) یعنی نرم افزاری برای ویرایش اشتراکی، کنفرانس های تلفنی و غیرهبا هم کار می کنند. به همین ترتیب، ارتباطات اینترنتی با فراهم کردن امکان تجارت الکترونیک، موجب شده اند تا بتوان بدون مراجعه به فروشگاه یا حتی خروج از خانه انواع کالاها را خرید و فروش کرد.
اما همین افزایش امکان ارتباط و شراکت، نیاز روز افزون به امنیت را هم مطرح می کند. در حال حاضر سیستم ها از محافظت کمی در برابر استراق سمع و نفوذگری در ارتباط برخوردار هستند. مشکل امنیتی دیگر مربوط به ردیابی ارتباطات برای ساخت نمودار ترجیحی از کاربر مورد نظر است. این دست ردیابی ها، خصوصاً اگر بدون اطلاع کاربر انجام شود، آشکارا باعث نقض حریم خصوصی افراد خواهد شد. مشکل دیگر این است که افزایش قابلیت ارتباط می تواند باعث ارتباط ناخواسته و از جمله پست های الکترونیکی بیهوده ای شود که غالباً مزاحم (spam) نامیده می شوند. در این موارد لازم است به کمک فیلترهای اطلاعاتی خاص که بر اساس محتوای پیام های ورودی اقدام به انتخاب آنها می کنند، از خود مراقبت کنیم.
1-2-2 شفافیت توزیع
یکی از اهداف مهم سیستم های توزیع شده مخفی سازی این واقعیت است که فرآیندها و منابع آن به صورت فیزیکی در بین ماشن های متعدد توزیع شده اند. یک سیستم توزیع شده که در نظر کاربران و برنامه های کاربردی خود بصورت یک سیستم کامپیوتری منفرد جلوه کند، اصطلاحاً شفاف (transparent) نامیده می شود.

انواع شفافیت
گرچه مفهوم شفافیت را می توان در مورد جنبه های مختلف یک سیستم توزیع شده بکار برد، مهمترین آنها در جدول 1-1 ارائه شده است.
جدول 1-1 اشکال مختلف شفافیت در سیستم های توزیع شده
شفافیت
توضیح
دسترسی
مخفی سازی تفاوت ها در ارائه داده و نحوه دسترسی به منابع
مکان
مخفی سازی محل استقرار منبع
مهاجرت
مخفی سازی احتمال جابجایی منبع به محل دیگر
مکان یابی مجدد
مخفی سازی جابجایی منبع به محل دیگر در حین استفاده از آن
تکثیر
مخفی سازی وجود چند کپی از منبع
هم روندی
مخفی سازی اشتراک منبع در بین کاربران رقیب
خرابی
مخفی سازی خرابی و ترمیم خرابی منبع

شفافیت دسترسی (access transparency) به بحث در مورد مخفی سازی تفاوت های ارائه داده و نحوه دسترسی به منابع بوسیله کاربران می پردازد. در پایین ترین سطح، هدف مخفی سازی تفاوت بین معماری ماشین هاست، اما مهمتر از آن رسیدن به توافق در زمینه نحوه ارائه داده توسط ماشین ها و سیستم های مختلف است.
گروه مهم دیگری از انواع شفافیت مربوط به محل منبع است. هدف از شفافیت مکان (location transparency) آن است که کاربران نتوانند محل استقرار فیزیکی منبغ در سیستم راشناسایی کنند. نام گذاری نقش مهمی در کسب شفافیت توزیع شده دارد. شفافیت مکان بخصوص از طریق نسبت دادن اسامی منطقی به منابع، یعنی اسامی که در آنها نام محل بصورت مخفیانه کدگذاری نشده باشد، امکان پذیر است. بعنوان نمونه، در نام گذاری http: //www. prenhall. com/index. html url هیچ نشانه ای در مورد محل خدمتگزار اصلی وب شرکت prenticce hall به چشم نمی خورد. بعلاوه، از url نمی توان دریافت که آیاindex. html همیشه در موقعیت فعلی خود بوده یا اخیراً به آن منتقل شده است. سیستم های توزیع شده که بتوان منابع آنها را بدون تاثیرگذاری بر نحوه دسترسی به آنها انتقال داد، اصطلاحاً دارای شفافیت مهاجرت (migration transparency) هستند. حالت دیگر هنگامی است که بتوان منابع را در حین دسترسی به آنها و بدون کوچکترین اطلاعی به کاربر یا برنامه کاربردی مجدداً مکان یابی کرد. در این موارد، سیستم ها اصطلاحاً از شفافیت مکان یابی مجدد (relocation transparency) می توان به امکان ادامه استفاده کاربران متحرک از لپ تاپ های خود در حین جابجایی از یک نقطه به نقطه دیگر و بدون قطع ارتباط (حتی موقت هم) اشاره کرد.
تکثیر نقش مهمی در سیستم های توزیع شده ، برقراری امکان اشتراک منابع است. هر چند در بسیاری از موارد، از جمله ارتباطات، اشتراک منابع با همکاری انجام می شود، نمونه های زیادی هم می توان از اشتراک رقابتی منابع ذکر کرد. بعنوان مثال، ممکن است دو کاربر مستقل فایل های خود را روی یک خدمتگذار فایل واحد ذخیره کرد و یا به جداول واحدی در یک پایگاه داده مشترک دسترسی داشته باشند. در این موارد، هیچیک از کاربران نباید کوچکترین اطلاعی از واقعیت استفاده کاربر دیگر از آن منبع داشته باشند. این پدیده به نام شفافیت هم روندی (concurrency transparency) خوانده می شود. اما مهم این است که دسترسی همزمان به یک منبع مشترک، منبع را در حالت سازگار نگهدارد. سازگاری (consistency) از طریق مکانیزم های قفل کردن قابل ایجاد بوده و به کمک آن کاربران دسترسیانحصاری به منبع مورد نظر را خواهند داشت. مکانیزم اصلاح شده دیگر، استفاده از تراکنش (transaction) است، اما پیاده سازی تراکنش ها در سیستم های توزیع شده بسیار مشکل است.
یکی دیگر از مسائل مهم در طراحی سیستم های توزیع شده ایجاد شفافیت خرابی (failure transparency) در سیستم های به این معناست که کاربر متوجه خرابی و عملکرد نادرست یک منبع نشده (حتی شاید کوچکترین گزارشی هم از آن دریافت نکند) و سپس سیستم اقدام به ترمیم آن خرابی کند. مشکل اصلی در مخفی سازی خرابی ها ناشی از عدم توانایی در تمایز بین منبع مرده از منبع کُند است.

1-2-3 باز بودن
یکی دیگر از اهداف مهم سیستم های توزیع شده ، باز بودن است. سیستم توزیع شده باز (open distributed system) سیستمی است که بر اساس قوانین استاندارد تشریح کننده معنا ونحوه خدمات، اقدام به ارائه آنها می کند. بعنوان مثال، در شبکه های کامپیوتری، قوانین استانداردی بر قالب، محتوا و معنای پیام های ارسالی و دریافتی حاکم است. این دست قوانین در قالب پروتکل (protocol) مدون می شوند. در سیستم های توزیع شده ، سرویس ها غالباً از طریق واسط ها تخصیص یافته، و غالباً توسط زبان تعریف واسط تشریح می شوند. تعاریف واسط نوشته شده درidl، تقریبا همیشه فقط در مورد نحوه خدمات صحبت می کنند. به بیان دیگر، صرفاً اسامی توابعی را در تعیین می کنند که به همراه انواع پارامترها، مقادیر برگشتی استثنائات احتمالی و غیره موجود هستند. بخش مشکل کار تخصیص وظیفه دقیق این سرویس ها، یعنی معنای واسط ها است. در عمل، این دست ویژگی ها همیشه به صورتی غیر متعارف، یعنی بوسیله زبان طبیعی ارائه می شوند.
در صورتی که واحد به نحو مناسبی تعریف شود، اجازه می دهد یک فرآیند دلخواه که این واسط را دارد با فرآیند دیگری که این واسط را ارائه می دهد، صحبت نماید. همچنین باعث می شود تا دو طرف مستقل، پیاده سازی های کاملاً متفاوتی را از آن واسط ایجاد کرده، در نتیجه دو سیستم توزیع شده جداگانه، اما با عملکرد یکسان بوجود می آید. اما این ویژگی ها باید کامل وخنثی باشند. کامل بودن یعنی، تمام آنچه برای پیاده سازی لازم است واقعاً تعریف شده باشد. با این وجود، بسیاری از تعاریف واسط به هیچ وجه کامل نبوده و سازنده آنها باید جزئیات مربوط به پیاده سازی را به آنها اضافه کند. به همین اندازه خنثی بودن اهمیت دارد به این معنی نحوه وشکل پیاده سازی ویژگی ها تجویز نشود. کامل بودن وخنثی بودن باعث کسب قابلیت کار با هم و قابلیت جابجایی می شود.
یکی دیگر از اهداف مهم سیستم های توزیع شده باز آن است که پیکربندی سیستم توسط مولفه های مختلف براحتی امکان پذیر باشدوهمچنین، افزودن، مولفه های جدید یا تعویض مولف های فعلی نباید هیچ تاًثیری بر دیگر مولفه ها داشته باشد. به بیان دیگر، یک سیستم توزیع شده باز باید قابل گسترش هم باشد.

تفکیک سیاست از مکانیزم
برای کسب انعطاف پذیری در سیستم های توزیع شده باز، سیستم بایستی لزوماً بصورت مجموعه ای از مولفه های براحتی قابل انطباق یا قابل تعویض و نسبتاً کوچک سازماندهی شود. به این معنا که بایستی تعاریفی را هم برای واسط های بالاترین سطح- یعنی واسط هایی که بوسیله کاربران و برنامه های کاربردی قابل رویت هستند و هم برای واسط های بخش داخلی سیستم ایجاد و نحوه ارتباط این بخش ها را توصیف کرد. لزوم تغییر سیستم های توزیع شده غالباً ناشی از مولفه ای است که سیاست بهینه ای را برای یک کاربر یا برنامه کاربردی ایجاد نمی کند. به عنوان مثال، حافظه پنهان (caching) در شبکه جهانی وب را در نظر بگیرید. جستجوگرها معمولاً به کاربر امکان می دهند تا با تعیین ابعاد حافظه پنهان و لزوم یا عدم لزوم چک کردن دائمی سند حافظه پنهان خود را منطبق کنند. با این وجود، کاربر نمی تواند تغییری در دیگر پارامترهای حافظه پنهان، از قبیل مدت زمان ماندگاری سند در حافظه پنهان یا تعیین سندی که باید با پرشدن حافظه پنهان حذف شود، ایجاد کند. همچنین، نمی توان بر اساس محتوای سند راجع به مخفی سازی آن تصمیم گیری کرد.
1-2-4 مقیاس پذیری
مقیاس پذیری یکی از مهمترین اهداف طراحی برای سازندگان سیستم های توزیع شده محسوب می شود. مقیاس پذیری سیستم را می توان حداقل در سه بعد مختلف اندازه گیری نمود. اولاً یک سیستم می تواند با توجه به اندازه خود مقیاس پذیر باشد، به این معنا که بتوان به راحتی کاربران و منبع دیگری را به سیستم اضافه نمود. ثانیاً، یک سیستم مقیاس پذیر جغرافیایی سیستمی است که ممکن است کاربران ومنابع آن در فاصله های دوری از همک قرار گرفته باشند. ثالثاً، یک سیستم ممکن است از نظر مدیریت اجرایی مقیاس پذیر باشد، به این معنا که حتی اگر سازمانهایی با مدیریت اجرایی مستقل را هم به هم پیوند دهد، ابز به راحتی قابل مدیریت باشد. متاسفانه، اغلب سیستم هایی که از یک یا چند مقیاس پذیر هستند، با افزایش مقیاس پذیری سیستم تا حدودی با افت عملکرد مواجه می شوند.

مشکلات مقیاس پذیری
یکی از مهمترین دلایل بروز اشکال در مقیاس پذیری سیستم های توزیع شده موجود که برای شبکه های محلی طراحی شده اند، این است که بر اساس ارتباطات همگام استوارهستند. در این شکل از ارتباط، طرف درخواست کننده سرویس که معمولاً به نام مشتری خوانده می شود، تا زمان بازگشت پاسخ مسدود باقی می ماند. این روش معمولاً برای lan هایی مناسب است که در آنها ارتباطات بین دو ماشین بطور معمول حداکثر چند صد میلی ثانیه طول می کشد. اما در سیستم های گسترده، ارتباطات میان فرآیندی ممکن است صدها میلی ثانیه یعنی هزار برابر بیشتر طول بکشد. ساخت برنامه های کاربردی تعاملی با استفاده از ارتباط همگام در سیستم های گسترده مستلزم صرف دقت زیادی است.
مشکل دیگر در کسب مقیاس پذیری جغرافیایی این است که ارتباطات در شبکه های گسترده ذاتاً نامطمئن تقریباً همیشه نقطه به نقطه است. بالعکس، شبکه های محلی معمولاً امکانات ارتباطی بسیار مطمئن بر اساس بس پخشی ایجاد می کنند، و همین امر باعث سادگی زیاد در ایجاد سیستم های توزیع شده می شود. چنانچه یک سیستم توزیع شده به دامنه دیگر گسترش یابد، بایستی دو نوع اقدام امنیتی صورت بپذیرد. در درجه اول، سیستم توزیع شده باید از خود در برابر حملات ناخواسته از دامنه جدید محافظت کند. بعنوان مثال، کاربران دامنه جدید ممکن است به سیستم فایل در دامنه اصلی فقط در دسترسی خواندن داشته باشند. به همین ترتیب، امکاناتی از قبیل شکل نگارهای گران قیمت یا کامپیوترهای پُر بازده ممکن است برای کاربران خارج از دامنه قابل دستیابی نباشد. ثانیاً، دامنه جدید بایستی از خود در برابر حملات ناخواسته از جانب سیستم توزیع شده محافظت کند. بعنوان یک نمونه می توان به دانلود کردن برنامه هایی از قبیل اپلت ها در جستجگرهای وب اشاره کرد. اساساً، دامنه جدید نم پی داند که باید چه نوع رفتاری را از این کُدهای بگیرد.

تکنیک های مقیاس پذیری
مشکلات مقیاس پذیری در سیستم های توزیع شده به صورت مشکلات کارآیی ناشی از محدودیت ظرفیت خدمتگزارها و شبکه ها جلوه می کند. در حال حاضر، اساساً فقط سه تکنیک در زمینه مقیاس پذیری وجود دارد: مخفی سازی تاخیر های ارتباطات، توزیع و تکثیر.
مخفی سازی تاخیرهای ارتباطی تاثیر مهمی در رسیدن به مقیاس پذیر جغرافیای دارد. ایده اصلی اجتناب حداکثری از انتظار برای دریافت پاسخ به درخواست های سرویس از راه دور (و احتمالا در فاصله دور) است. بعنوان مثال وقتی سرویسی واقع در یک ماشین را دور درخواست می شود، می توان بجای انتظار برای دریافت پاسخ از جانب خدمتگزار، کار مفید دیگری در طرف درخواست کننده انجام داد. اساسا، این به معنای ساخت برنامه کاربردی درخواست کننده به صورتی است که فقط از ارتباطات ناهمگام استفاده کند. با ورود پاسخ، برنامه کاربردی متوقف شده و برای تکمیل درخواست قبلی، عمل کننده خاصی فراخوانی می شود. از ارتباطات ناهمگام غالبا می توان در سیستم های پردازش دسته ای و برنامه های کاربردیموازی استفاده کرد، که در آنها وظیفه های کمابیش مستقل را می توان در حالی برای اجرا زمانبندی کرد که کار دیگری منتظر تکمیل ارتباط است. روش دیگر، آغاز یک ریسمان کنترلی جدید جهت انجام درخواست است. هرچند این ریسمان انتظار برای پاسخ را مسدود می کند، ریسمان های دیگر فرآیند قادر به ادامه کار هستند.
یکی دیگر از تکنیک های مهم مقیاس پذیری، توزیع است. توزیع به معنای انتخاب یک مولفه، تجزیه آن به قطعات کوچکتر و سپس پخش این قطعات در بین سیستم هاست. یکی از بهترین نمونه های توزیع، سیستم نام دامنه (dns) است. فضای نام dns بصورت سلسله مراتبی به سه دامنه سازمان داده شده، و هر دامنه به مناطق ناهمپوش تقسیم می شود. اسامی در هریک از مناطق بوسیله یک خدمتگزار نام واحد اداره می شود. با این فرض که مشکلات مقیاس پذیری غالبا به شکل افت کارایی ظاهر می شود، معمولا بهتر است که مولفه ها را واقعاً در داخل سیستم توزیع شده تکثیر کنیم. این تکثیر غلاوه بر افزایش قابلیت دسترسی، به تعادل بار در بین مولفه ها کمک کرده و در نتیجه باعث افزایش کارآیی هم خواهد شد. بعلاوه، در سیستم های دارای پراکندگی جغرافیایی زیاد، در اختیار داشتن یک کپی دم دستی باعث مخفی سازی بخش عمده ای از مشکلات تاخیر در ارتباطات می شود.
با بررسی تکنیک های مقیاس پذیری، به راحتی می توان ادعا کرد که از نظر فنی مقیاس پذیری اندازه کمترین مشکل را دارد. در بسیاری از موارد، صرفاً با افزایش ظرفیت ماشین می توان حداقل بطور موقت و احتمالاً با صرف هزینه های زیاد مشکل را حل کرد. در مقایسه، مقیاس پذیری جغرافیایی مشکل بزرگتری است، چون می خواهیم طبیعت را رام خود کنیم. در عمل ترکیب تکنیک های توزیع، تکثیر و به کارگیری حافظه پنهان با انواعمختلف سازگاری، عملکرد مناسبی ارئه می دهند. نهایتاً اینکه مقیاس پذیری سرپرستی تا حدی به دلیل نیاز ما به حل مشکلات غیرتکنیکی از قبیل سیاست های سازمانی و همکاری های انسانی، مشکل ترین نوع مقیاس پذیری به نظر می رسد. با این وجود، صرفاً با نادیده گرفتن دامنه های سرپرستی، شاهد پیشرفت هایی در این زمینه بوده ایم. ایجاد و کاربرد گسترده فن آوری نظیر به نظیر در دنیای امروز بیانگر چیزی است که با قرارگیری کنترل در اختیار کاربران نهایی قابل دستیابی می باشد. با این وجود لازم به ذکر است که فناوری نظیر به نظیر در بهترین حالت می تواند فقط یک راه حل نسبی برای حل مشکلات مقیاس پذیری سرپرستی محسوب شود.

1-2-5 طرح اشکال
وجه تمایز سیستم های توزیع شده با نرم افزارهای متداول، پراکندگی مولفه های آنها در سرتاسر شبکه است. لحاظ نکردن این پراکندگی در طراحی ها باعث پیچیدگی بیهوده بسیاری از سیستم ها و نهایتاً منجر به اشنباهاتی می شود که باید بعدها به دنبال راه چاره ای برای رفع آنها باشیم. پیتر دویچ این اشتباهات را در قالب مفروضاتی اشتباه مدون وارائه کرد، که مبتدی ها را در اولین تلاش ها برای ایجاد برنامه های کاربردی توزیع شده گرفتار خود می کند:
1- شبکه قابل اطمینان است.
2- شبکه ایمن است.
3- شبکه همگن است.
4- ساختار شبکه تغییر نمی کند.
5- تاخیر انتشار صفر است.
6- پهنای باند نامحدود است.
7- هزینه انتقال صفر است.
8- فقط یک سرپرست وجود دارد.
به رابطه بین این مفروضات با ویژگی های خاص سیستم های توزیع شده یهنی قابلیت اطمینان، ایمنی، همگن بودن، توپولوژی شبکه، تاخیر، پهنای باند، هزینه های انتقال و نهایتاً دامنه های مدیریتی توجه کنید. در هنگام ایجاد برنامه های کاربردی غیر توزیع شده بسیاری از این مشکلات اصلاً مطرح نمی شوند

1-3 انواع سیستم های توزیع شده
1- سیستم های محاسبات توزیع شده
2- سیستم های اطلاعات توزیع شده
3- سیستم های فراگیر توزیع شده

1-3-1 سیستم های محاسبات توزیع شده
یکی از مهم ترین گروه های سیستم های توزیع شده در محاسبات بسیار کارا استفاده دارد. در این رابطه دو زیرگروه می توان شناسایی کرد. در محاسبه خوشه، سخت افزار زیربنایی متشکل از مجموعه ای از ایستگاه های کاری یا رایانه های شخصی (pc) مشابه است که از طریق یک شبکه محلی پرسرعت ارتباط نزدیکی باهم پیدا کرده اند. بعلاوه، تمامی گره ها سیستم عامل واحی را اجرا می کند. اما در مورد محاسبه توری، وضعیت تا حدودی متفاوت است. این زیرگروه متشکل از سیستم های توزیع شده است که غالباً به شکل فدراسیونی از سیستم های کامپیوتری سازماندهی می شوند. هر یک از این سیستم ها ممکن است در دامنه سرپرستی متفاوتی قرار گرفته و حتی سخت افزار، نرم افزار و فن آوری شبکه بکار رفته در آنها بسیار با یکدیگر متفاوت باشد.

سیستم های محاسبه خوشه
سیستم های محاسبه خوشه محصول بهبود نسبت قیمت به کارآیی کامپیوترهای شخصی و ایستگاه های کاری محسوب می شود. از محاسبه خوشه برای برنامه نویسی های موازی استفاده می شود که در آنها یک برنامه با محاسبات فراوان به صورت موازی روی چندین ماشین اجرا شود. یکی از نمونه های معروف کامپیوترهای خوشه ای می توان به خوشه های بیوولف بر اساس لینوکس اشاره کرد که پیکربندی کلی آن در شکل 1-2 ارائه شده است. هریک از خوشه ها متشکل از مجموعه ای از گره های محاسبه است که بوسیله یک گره اصلی قابل کنترل و دسترسی هستند. به این ترتیب گره اصلی واقعاً میان افزار لازم برای اجرای برنامه ها و مدیریتخوشه را اجرا می کند، در حالیکه گره های محاسبه غالباً فقط به یک سیستم عامل استاندارد نیاز دارند.

شکل1-2 نمونه ای از سیستم های محاسبه خوشه

سیستم های محاسبه توری
همگن بودن، یکی از ویژگی های بارز محاسبه خوشه است. در اغلب موارد کامپیوترهای داخل خوشه تا حد زیادی یکسان هستند، دارای سیستم عامل واحدی بوده و همگی از طریق یک شبکه واحد متصل می شوند. در حالیکه، سیستم های محاسبه توری تا حد زیادی ناهمگن هستند، یعنی هیچ فرضی در مورد سخت افزار، سیستم های عامل، شبکه ها، دامنه های سرپرستی، سیاست های امنیتی و غیره وجود ندارد. یکی از مهمترین مسائل در سیستم های محاسبه توری آن است که منابعی از سازمان های مختلف در کنار هم قرار داده می شوند تا امکان تشریک مساعی گروه هایی از افراد یا موسسات فراهم شود. این نوع تشریک مساعی در قالب سازمان مجازی محقق می شود. افراد متعلق به یک سازمان مجازی حق دسترسی به منابع تامین شده برای همان سازمان دارند.
به دلیل ماهیت این سیستم ها، قسمت اعظم نرم افزار مربوط به عملی کردن محاسبات توری، جهت ایجاد دسترسی به منابع مربوط به دامنه های سرپرستی مختلف و فقط برای کاربران و برنامه های کاربردی متعلق به سازمان مجازی تکامل یافته اند. به همین دلیل، عمدتاً روی مسائل معماری تمرکز می شود. نمونه ای از معماری های پیشنهادی در شکل 1-3ارئه شده است.

شکل1-3 معماری لایه ای سیستم های محاسبه توری.

این معماری از چهار لایه تشکیل شده است. پایین ترین لایه، یعنی لایه فابریک، واسط هایی را برای منابع محلی در محلی خاص بوجود می آورد. توجه داشته باشید که این واسط ها به گونه ای ساخته می شوند تا امکان اشتراک منابع در داخل یک سازمان مجازی فراهم شود. این واسط ها توابعی را برای پرس و جوی وضعیت و توانایی های منابع و همچنین توابعی برای مدیریت واقعی منابع از قبیل قفل کردن منابع ایجاد می کنند.
لایه اتصال متشکل از پروتکل های ارتباطی جهت پشتیبانی از تراکنش توری است که از چندین منبع استفاده می کنند. بعنوان مثال، برای انتقال داده ها در بین منابع یا صرفاً دسترسی به منابع از راه دور نیازمند پروتکل هایی هستیم. بعلاوه، این لایه حاوی پروتکل های امنیتی برای تایید هویت کاربران و منابع است.
لایه منبع مسئول مدیریت در شبکه های منفرد است. این لایه با استفاده از توابع فراهم شده بوسیله لایه اتصال، واسط های فراهم شده بوسیله لایه فابریک را مستقیماً فراخوانی می کند. بعنوان مثال، این لایه کارکردهای مربوط به کسب اطلاعات پیکربندی روی یک منبع خاص یا، در کل، برای انجام عملیات خاصی از قبیل ایجاد فرآیند یا خواندن داده را ارائه می دهد. بنابر این لایه منبع مسئول کنترل دسترسی بوده و از اینرو روی احراز هویت صورت گرفته بعنوان بخشی از لایه اتصال تکیه می کند.
لایه بعد در سلسله مراتب بالا، لایه جمعی است. این لایه مسئول هدایت دسترسی به منابع متعدد بوده و نوعاً متشکل از سرویس هایی جهت کشف منبع، تخصیص و زمانبندی امور روی منابع متعدد، تکثیر داده و غیره است. برخلاف لایه های اتصال و منبع که از مجموعه استاندارد و نسبتاً کوچکی از پروتکل ها تشکیل می شوند، لایه جمعی ممکن است متشکل از پروتکل های بسیار متفاوت برای اهداف بسیار متفاوت بوده و این خود بیانگر طیف وسیع سرویس هایی است که لایه مذکور می تواند به یک سازمان مجازی ارائه دهد.
لایه برنامه کاربردی متشکل از برنامه های کاربردی است که در داخل یک سازمان مجازی عمل کرده، و از محیط محاسبه توری استفاده می کنند.
لایه های جمعی، اتصال و منبع روی هم رفته هسته چیزی به نام لایه میان افزارتوری را تشکیل می دهند. این لایه ها در مجموع امکان دسترسی و مدیریت منابعی را فراهم می کنند که بالقوه در سرتاسر سایت های متعدد پراکنده شده اند. یکی از مهمترین مشاهدات از نقطه نظر میان افزاری این است که در محاسبه توری، همیشه ایده سایت (یا یک واحد سرپرستی) به چشم می خورد. این جهت گیری مشترک با تغییر موضع تدریجی به سمت معماری سرویس گرا که امکان دسترسی به لایه های مختلف را از طریق مجموعه ای از سرویس های وب فراهم می کند، تشدید شد. این معماری منجر به تعریف معماری دیگری به نام معماری سرویس های توری باز شده است. در این معماری، تنوع لایه ها و تعداد مولفه ها باعث ایجاد پیچیدگی می شود.

1-3-2 سیستم های اطلاعات توزیع شده
یکی دیگر از گروه های مهم سیستم های توزیع شده در سازمان هایی مشاهده می شود که گرچه با مجموعه ای از برنامه های کاربردی شبکه شده سر و کار دارند، اما قابلیت کار باهم برای آنها تجربه ای بسیار سخت است. بسیاری از راه حل های میان افزاری موجود نتیجه کار با زیر ساخت هایی است که در آنها ادغام برنامه های کاربردی در یک سیستم اطلاعاتی شرکتی آسان تر بوده است.
یکپارچگی در سطوح مختلفی قابل تشخیص است. در بسیاری از موارد، یک برنامه کاربردی شبکه شده فقط متشکل از خدمتگزار اجراکننده آن برنامه کاربردی در اغلب موارد مجهز به یک پایگاه داده بود که در اختیار برنامه های از راه دوری موسوم به مشتری قرار می گرفت. این مشتریان قادر به ارسال درخواست اجرای یک عملیات خاص برای خدمتگزار و متعاقب آن دیافت پاسخ بودند. ادغام در پایین ترین لایه به کاربران اجازه می داد تا تعدادی از درخواست ها را، که گاهی برای خدکمتگزار های مختلف بودند، در قالب یک درخواست بزرگ بسته بندی کرده و تحت عنوان تراکنش توزیع شده اجرا کند.

سیستم های پردازش تراکنش
در عمل، عملیات روی پایگاه داده معمولاً در قالب تراکنش انجام می شود. برنامه نویسی با استفاده از تراکنش ها مستلزم آشنایی با عمل های پایه خاصی سات که یا باید بوسیله سیستم توزیع شده زیر بنایی تامین شود، و یا از طریق سیستم زمان اجرای برنامه نویسی. برخی ازنمونه های عمل های پایه تراکنش در
جدول 1-2 ارائه شده است. لیست دقیق عمل های پایه بستگی به نوع اشیاء مورد استفاده در تراکنش دارد.
جدول 1-2 لیست دقیق عمل های پایه بستگی به نوع اشیاء مورد استفاده در تراکنش
عمل پایه
توضیح
begin-transaction
آغاز تراکنش را علامتگذاری می کند
end-transaction
پایان تراکنش را علامتگذاری می کند.
abort-transaction
تراکنش را قطع کرده و مقادیر قبلی را برمی گرداند
Read
داده ها را از یک فایل، جدول و امثال آنها می خوان
Write
داده ها را در یک فایل، جدول و امثال آنها می نویسد

از begin-transaction و end-transaction برای مشخص کردن محدوده تراکنش ها استفاده شده و عملیات بین آنها بدنه تراکنش را تشکیل می دهند. ویژگی بارز تراکنش آن است که یا تمام این عمل ها اجرا می شوند و یا هیچیک از آنها. این ویژگی همه یا هیچ تراکنش ها یکی از چهار ویژگی عمده تمام تراکنش ها است. به بیان دقیقتر، تراکنش ها دارای ویژگی های زیر هستند:
1- تقسیم ناپذیری: از دید دنیای خارج، تراکنش به صورت یک کل تفکیک ناپذیر اجرا می شود.
2- سازگار بودن: تراکنش اصول بنیادی سیستم را مخدوش نمی کند.
3- ایزوله بودن: تراکنش های همزمان با یکدیگر تداخل ندارند.
4- دوام: تغییرات ناشی از تراکنش ها دائمی هستند.
تا به اینجا تراکنش ها روی یک پایگاه داده منفرد تعریف شده است. مطابق شکل 1-4 تراکنش تو در تو از تعدادی زیر تراکنش تشکیل می شود. ممکن است در بالاترین سطح تراکنش با منشعب کردن فرزندانی که به صورت موازی باهم، اما روی ماشین های مختلف اجرا می شوند، باعث افزایش عملکرد یا تسهیل برنامه نویسی شود. هر یک از این فرزندان هم ممکن است یک یا چند زیر تراکنش اجرا کرده و یا فرزندان خود را منشعب کنند.

شکل1-4 تراکنش تو در تو

تراکنش تو در تو
تراکنش ها تو در تو، از آنجاییکه یک روش طبیعی برای توزیع تراکنش ها بین ماشین های مختلف بوجود می آورند، در سیستم های توزیع شده دارای اهمیت هستند. این تراکنش ها از تقسیم بندی منطقی عملیات تراکنش اصلی تبعیت می کنند.

1-3-3 سیستم های فراگیر توزیع شده
سیستم های فراگیر توزیع شده ، همانطور که از نام آنها بر می آید، بخشی از محیط اطراف ما می باشد (و از همین رو، در اغلب موارد ذاتاً توزیع شده هستند). یکی از مهمترین ویژگی این سیستم ها، فقدان عمومی کنترل سرپرستی انسانی در آنهاست. در بهترین حالت، این دستگاه ها بوسیله مالکانشان قابل پیکربندی هستند، ولی گذشته از این باید بصورتی خودکار محیط خود را کشف کرده و به بهترین نحو ممکن در آن جایگذاری شوند. این جایگذاری بوسیله گریم و همکاران با تعیین سه شرط زیر برای برنامه های کاربردی فراگیر فرموله شده است:
1- شمول تغییرات بافتی
2- تشویق ترکیب موردی
3- شناسایی اشتراک بعنوان پیش فرض
شمول تغییرات بافتی به این معناست که یک دستگاه بایستی دائماً از این حقیقت آگاه باشند که محیط آن هر لحظه دستخوش تغییر است. یکی از ساده ترین تغییرات آن است که چون کاربرد در بین ایستگاه های پایه در حال جابجایی است، شبکه دیگر در دسترس نباشد.
ویژگی تشویق ترکیب موردی اشاره به این واقعیت دارد که در سیستم های فراگیر بسیاری از دستگاه ها به روش های بسیار متفاوت توسط کاربران متفاوت مورد استفاده قرار می گیرند. در نتیجه پیکربندی مجموعه برنامه های کاربردی که روی یک دستگاه اجرا می شوند، چه بوسیله کاربر و چه از طریق موقعیت های میانی خودکار (اما تحت کنترل) باید ساده باشد.
یکی از جنبه های بسیار مهم سیستم های فراگیر آن است که دستگاه ها غالباً با هدف دسترسی اطلاعات به سیستم ملحق می شوند. این امر لزوم اییجاد ابزاری جهت تسهیل خواند، ذخیره سازی، مدیریت و اشتراک اطلاعات را مطرح می کند. به دلیل تناوب و تغییر اتصال دستگاه ها، فضایی که اطلاعات قابل دسترسی در آن وجود دارد، به احتمال قوی دائماً تغییر خواهد کرد. در مجموع می توان نتیجه گرفت که شفافیت توزیع شده در سیستم های فراگیر دیده نمی شود. در واقع، توزیع داده ها فرآیندها وکنترل ذاتی این سیستم ها بوده، و به همین دلیل شاید بهتر باشد که به جای تلاش برای مخفی سازی، این ویژگی را حتی در معرض دید قرار دهیم.

انواع سیستم های فراگیر:
1- سیستم های خانگی
2- سیستم های الکترونیکی مراقبت از سلامت
3- شبکه های حسگر

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

سیستم های الکترونیکی مراقبت از سلامت:
یکی از دیگر از مهمترین و رو به افزایش ترین انواع سیستم های فراگیر، سیستم های الکترونیکی مراقبت از سلامت (فردی) است. سیستم های مراقبت از سلامت فردی غالباً مجهز به حسگرهای مختلفی هستند که به صورت یک شبکه بدنی (که ترجیحاً بی سیم است) سازماندهی شده اند. مهم این است که این شبکه ها در بدترین حالت حداقل سختی را برای شخص داشته باشند. بنابراین شبکه باید بتواند در حین حرکت فرد و اتصال هیچگونه رشته سیمی به دستگاه های ثابت، باز هم عمل کند.
شبکه های حسگر: یک شبکه حسگر نوعاً از چند تا چند ده هزار گره نسبتاً کوچک دارد، که هر یک مجهز به یک دستگاه حس کننده می باشد. اغلب شبکه های حسگر از ارتباط بی سیم (wireless) استفاده کرد و انرژی گره ها غالباً از طریق باتری تامین می شود. محدودیت منابع، امکانات ارتباطی محدود و مصرف توان محدود باعث می شود تا در طراحی این شبکه ها موضوع بهره وری جایگاه ویژه ای داشته باشد. برای سازماندهی شبکه های حسگر به صورت پایگاه های داده توزیع شده دو راه وجود دارد. در روش اول، حسگرها تشریک مساعی نمی کنند، بلکه صرفاً داده های خود را به یک پایگاه داده متمرکز واقع در سایت اپراتور ارسال می کنند. در روش دوم، پرس جوها به حسگرهای مربوطه ارسال شده و هر حسگر پاسخی را محاسبه می کند؛ البته اپراتور هم باید پاسخ های عودت داده شده را بصورتی منطقی متمرکز کند.

فصل دوم- معماری

چگونگی سازمان سیستم های توزیع شده تا حد زیادی در رابطه با مولفه های نرم افزاری تشکیل دهنده سیستم است. این معماری نرم افزار بیانگر نحوه سازماندهی مولفه های مختلف نرم افزاری و تقابل آنهاست. تحقق یک سیستم توزیع شده مستلزم آن است که موًلفه های نرم افزاری ایجاد و روی ماشین های واقعی قرارداده شوند. برای انجام اینکار روش های مختلفی وجود دارد. نحوهٔ استقرار نهایی معماری نرم افزاری غالباً معماری سیستم خوانده می شود.
یکی از اهداف مهم سیستم های توزیع شده تفکیک برنامه های کاربردی از بسترهای زیربنایی از طریق ایجاد یک لایه میان افزاری است. استفاده از چنین لایه ای یکی از مهمترین تصمیمات معماری محسوب شده و هدف اصلی آن ایجاد شفافیت توزیع شده است.

2-1 شیوه های معماری
مفهوم شیوه معماری اهمیت به سزا دارد. چنین شیوه ای شامل مولفه ها، نحوه اتصال مولفه ها به یکدیگر، تبادل داده در بین مولفه ها، و در نهایت نحوه پیکربندی این عوامل برای تشکیل یک سیستم واحد است. منظور از مولفه واحد پیمانه ای با واسط های کاملاً تعریف شده لازم و موجود است، که در داخل محیط خود قابل تعویض هستند. نکته مهم در مورد یک مولفه برای سیستم های توزیع شده آن است که مشروط به لحاظ کردن واسط آن، مولفه قابل تعویض است. یکی از مفاهیمی که در آن تا حدودی مشکل است اتصال گر (component) است که غالبا به صورت مکانیزمی برای میانجی گری بین ارتباطات، هماهنگ سازی، یا همکاری در بین مولفه ها تعریف می شود. با استفاده از مولفه ها و اتصال گرها می توان پیکربندی های مختلفی ایجاد نمودکه نهایتاً در قالب شیوه های معماری دسته بندی می شوند. شیوه های مختلفی شناسایی شده اند که مهمترین آنها در سیستم های توزیع شده می توان به موارد زیر اشاره کرد:
1* معماری های لایه ای
2* معماری های شئ محمور
3* معماری های داده مرکز
4* معماری های رویداد محور
ایده اساسی در شیوه لایه ای بسیار ساده است: مولفه ها به صورت لایه ای سازماندهی می شوند. همانطور که در شکل 2-1 الف مشاهده می کنید، مولفه واقع در لایه Li می تواند موله های واقع در لایه زیرین آن Li-1 را فراخوانی نمایداین مدل به طور گسترده در دنیای شبکه به کاربرده شده است. یکی از مشاهدات کلیدی این است که کنترل غالباً از یک لایه به لایه دیگر جریان می یابد. به بیان دیگر درخواست ها بصورت سلسله مراتبی از بالا به پایین و نتایج از پایین به بالا جریان پیدا می کنند.
در حالیکه در معماری شئ محور از ساختار بسیار آزاده تر شکل 2-1 تبعیت می شود. بطور خلاصه، هر شئ متناظر با چیزی است که ما آنرا مولفه می نامیم و این مولفه ها از طریق یک مکانیزم فراخوانی روال از راه دور به متصل می شوند.

شکل 2-1 جریان پاسخ

جریان پاسخ
معماری داده مرکز بر اساس ایده برقراری تماس بین فرآیندها از طریق یک منبع مشترک فعال یا غیر فعال شکل گرفته است. می توان استدلال کرد که اهمیت این معماری ها در سیستم های توزیع شده به همان اندازه معماری های لایه ای و شئ محور است. بعنوان مثال مجموعه بزرگی از برنامه های کاربردی تحت شبکه بر اساس سیستم فایل توزیع شده اشتراکی بوجود آمه اند که در آنها، تقریباً تمام ارتباطات از طریق فایل ها انجام می شود.
در معماری رویداد محور فرآیندها اساساً از طریق انتشار رویدادها ارتباط برقرار کرده و بصورت اختیاری داده حمل می کنند. در سیستم های توزیع شده ، پخش رویداد غالباً با آنچه به نام سیستم های انتشار/اشتراک خوانده می شود ایده اساسی این است که فرآیندها در صورتی اقدام به پخش رویدادها خواهند کرد که میان افزار اطمینان دهد که فقط فرآیندهای قبلاً مشترک شده در آن رویداد آن را دریافت می کنند. مزیت عمده سیستم های رویدادمحور آن است که فرآیندها دارای اتصال سست هستند، و در مجموع لزومی ندارد که آشکارا به یکدیگر ارجاع دهند. این حالت به نام باز شدن اتصال در فضا یا به بیان دیگر، بازشدن اتصال مرجعی هم خوانده می شود. معماری های رویداد محور را می توان با معماری های داده مرکز تلفیق کرد و چیزی به نام فضای داده اشتراکی ایجاد نمود. بطور خلاصه، معنای فضای داده اشتراکی آن است که فرآیندها اکنون از نظر زمانی هم به یکدیگر اتصال ندارند و دیگر لازم نیست که هر دو در حین انجام ارتباط فعال باشند. وجه اهمیت این معماری های نرم افزاری در سیستم های توزیع شده آن است که هدف همه آنها دستیابی به شفافیت توزیع شده (در حد معقول و منطقی) است.

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

2-2-1 معماری های متمرکز
در مدل اصلی مشتری خدمتگزار، فرآیندها درسیستم توزیع شده به دو گروه تقسیم می شوند: خدمتگزار (server)، فرآیند اجراکننده یک سرویس خاص از قبیل سرویس سیستم فایل یا سرویس پایگاه داده است. در حالیکه مشتری (client) فرآیند درخواست کننده یک سرویس خاص ازخدمتگزار از طریق ارسال درخواست برای خدمتگزار وسپس انتظار برای دریافت پاسخ از جانب آن است. تقابل مشتری خدمتگزار که رفتار درخواست پاسخ هم نامیده می شود. ارتباط بین مشتری و خدمتگزار را می توان در صورت مطمئن بودن شبکه زیربنایی که در مورد بسیاری از شبکه های محلی صدق می کند با استفاده از یک پروتکل بدون اتصال ساده پیاده نمود. مزیت آشکار استفاده از پروتکل بدون اتصال کارآمدی است. مادامی که پیام ها مفقود یا معیوب نشوند، پروتکل درخواست/پاسخ فوق به خوبی عمل خواهد کرد. متاسفانه، مقاوم سازی پروتکل ها در برابر خرابی های موردی سیستم ارسال چندان کار ساده ای هم نیست. تنهاراه حل ممکنه شاید این باشد که به مشتری اجازه دهیم تا در صورت عدم دریافت پیام پاسخ درخواست خود را مجدداً ارسال نماید. در معماری متمرکز از لایه بندی برنامه کاربردی و معماری های چند طبقه نیز استفاده می شود. ایده تقسیم بندی لایه بندی برنامه کاربردی به 3 سطح منطقی که شامل 1- سطح واسط کاربر 2- سطح پردازش 3- سطح داده تقسیم می شود. و در معماری های چند طبقه فقط با دو ماشین سروکار داریم.
1*ماشین مشتری که فقط شامل (بخشی از) برنامه های اجراکننده لایه واسط کاربر است
2*ماشین خدمتگزار که شامل مابقی برنامه ها یعنی برنامه های اجراکننده لایه داده و پردازش است.

2-2-2 معماری های غیر متمرکز
معماری های مشتری خدمتگزار چند طبقه یکی از پیامدهای مستقیم تقسیم برنامه های کاربردی به واسط کاربر، مولفه های پردازشی و لایه داده هستند. طبقات مختلف مستقیماً با سازمان منطقی برنامه های کاربردی مربوط هستند. در بسیاری از محیط های کسب وکار پردازش توزیع شده به معنای سازماندهی یک برنامه کاربردی مشتری خدمتگزار بصورت معماری چند طبقه است. ما از این توزیع به نام توزیع عمودی یاد می کنیم. ویژگی بارز توزیع عمودیآن است که با قرار گیری موفه های منطقاً متفاوت روی ماشین های مختلف بوجود می آید. این اصطلاح با مفهوم تکه کردن عمودی ارتباط دارد که در پایگاه های داده رابطه ای توزیع شده به کار برده شده، و به این معناست که جداول به صورت ستونی تفکیک و سپس، در میان ماشین های مختلف توزیع می شوند. با این وجود توزیع عمودی فقط یکی از روش های سازماندهی برنامه های کاربردی مشتری خدمتگزار است. در معماری های مدرن غالباًتکیه بر روی توزیع مشتری ها و خدمتگزارها قرار می گیرد، که از آن با نام توزیع افقی یاد می شود. در این توزیع یک مشتری یا خدمتگزار بایستی به بخش های منطقاً برابر تقسیم شود؛ هر بخش روی سهم و مجموعه کامل داده های خود عمل می کند، و به این ترتیب بار متعادل خواهد شد. یکی دیگر از معماری های نوین به نام سیستم های نظیر به نظیر که از توزیع افقی پشتیبانی می کنند. فرآیندهای تشکیل دهنده سیستم های نظیر به نظیر همگی برابر هستند. به این معنا که کارکردهایی که باید اجرا شود، بوسیله هر یک از فرآیندهای تشکیل دهنده سیستم های توزیع شده ارائه می شوند. در نتیجه قسمت اعظم تبادل بین فرآیندها متقارن بوده و هر فرآیند بطور همزمان هم بعنوان مشتری و هم خدمتگزار عمل خواهد کرد و بنابراین اصطلاحاً به نام پیشخدمت هم نامیده می شود. مساله مهم درمعماری های نظیر به نظیر نحوه سازماندهی فرآیندها در یک شبکه روی هم گذاری است. شبکه روی هم گذاری شبکه ای است که در آن گره ها بوسیله فرآیندها شکل گرفته وپیوندها بیانگر کانال های ارتباطی ممکن هستند.
معماری های نظیر به نظیر به دو دسته ساخت یافتهو بدون ساختار تقسیم می شود.
درمعماری های نظیر به نظیر ساخت یافته شبکه روی هم گذاری با استفاده از یک روال مشخص ایجاد می شوند. پرکاربردترین روال تا به امروز سازماندهی فرآیندها با استفاده از جدول درهم توزیع شده بوده است.
در سیستم های نظیر به نظیر بدون ساختار ساخت شبکه روی هم گذاری تا حد زیادی روی الگوریتم های تصادفی تکیه می شود. ایده اصلی این است که هرگره لیستی از همسایگانش را در اختیار داشته باشد؛ اما این لیست باید به صورت کمابیش تصادفی ایجاد شود.

مدیریت توپولوژی شبکه های روی هم گذاری
هر چند ممکن است به نظر برسد که سیستم های نظیر به نظیر ساختیافته و ساخت نیافته کاملاً از یکدیگر مستقل هستند، در عمل ضرورتاً اینطور نیست. یکی از مهمترین مشاهدات این است که با تبادل و انتخاب آگاهانه ورودی ها از نماهای جزیی، امکان ساخت و نگهداری توپولوژی های مشخص شبکه های روی هم گذاری فراهم می آید. مدیریت این توپولوژی با اتخاذ رهیافت دو لایه مطابق شکل 2-2 امکان پذیر می شود.

شکل 2-2 ارتباط پروتکل ها

پایین ترین لایه سیستم نظیر به نظیر ساخت یافته را تشکیل می دهد که گره های موجود در آن به منظور کسب یک گراف تصادفی دقیق، به طور منظم مدخل های نماهای جزیی خود را مبادله می کنند. دقت در ایم مورد به این مطلب اشاره دارد که نماهای جزیی خود را مبادله می کنند. دقت در این مورد به این مطلب اشاره دارد که نمای جزیی باید با مدخل های رجوع کننده به گره های زنده تصادفاً انتخاب شده پرشود. پایین ترین لایه نمای جزیی خود را به لایه منتقل کرده، که در آنجا انتخاب دیگری روی مدخل ها انجام می شود. اینکار منجربه تهیه لیست ثانویه ای از همسایگان متناظر با توپولوژی مورد نظر خواهد شد.

ابرنظیرها
گره هایی از قبیل آنها که اندیس را نگه می دارند یا بعنوان واسطه عمل می کنند، غالباً به نام ابر نظیر خوانده می شوند. همانطور که از نام آنها بر می آید، ابر نظیرها هم غالباً در شبکه های نظیر به نظیر سازماندهی شده و منجر به تولید سازمان سلسله مراتبی مشابه چیزی می شوند که در یانگ و گارسیا مولینا (2003) تشریح شده است. یکی از انواع ساده این سازمان ها در شکل 2-3 نمایش داده شده است. در این سازمان، هر یک از نظیرهای عادی بعنوان مشتری به یک ابر نظیر متصل شده است. تمامی ارتباطات از/ به نظیر عادی از طریق ابر نظیر مربوط به همان نظیر خواهد شد.

شکل2-3 سازمان سلسله مراتبی گره ها در یک شبکه ابر نظیر

در بسیاری از موارد رابطه مشتری ابر نظیر ثابت است؛ یعنی هروقت که یک نظیر عادی به شبکه ملحق می شود، به یکی از ابر نظیرها متصل شده و تا زمان خروج از شبکه این اتصال را حفظ خواهد کرد. قاعدتاً انتظار می رود که ابر نظیر ها فرآیندهایی با عمر طولانی و دسترس پذیری بالا باشند. برای جبران رفتار بعضاً ناپایدار یک ابرنظیر می توان از طرح های پشتیبان از قبیل جفت کردن هر ابر نظیر با ابر نظیر دیگر و الزام مشتریان برای اتصال همزمان به هر دو ابر نظیر استفاده نمود.

2-2-3 معماری های هیبریدی (دورگه)
تا اینجا روی معماری های مشتری- خدمتگزار و تعدادی از معماری های نظیر به نظیر تمرکزکردیم. در بسیاری از سیستم های توزیع شده ویژگی های معماری با هم ترکیب می شوند، همچنان که در شبکه های ابرنظیر دیدیم. در این قسمت نگاهی خواهیم داشت به برخی از انواع خاص سیستم های توزیع شده که در آنها راه حل های مشتری خدمتگزار با معماری های غیر متمرکز ترکیب شده اند.

سیستم های خدمتگزار لبه ای
یکی از مهمترین انواع سیستم های توزیع شده که براساس معماری هیبریدی سازماندهی شده، سیستم خدمتگزار لبه ای است. این سیستم ها روی اینترنت در جاهایی پیاده شده اند که خدمتگزارها در لبه شبکه قرار می گیرند. این لبه بر اساس مرز بین شبکه های شرکتی و اینترنت واقعی که بوسیله فراهم کنندگان سرویس اینترنت ارائه می شود. تشکیل می شود. به همین ترتیب هنگامیکه کاربران نهایی خانگی از طریق isp خود به اینترنت متصل می شوند، می توان تصور کرد که isp در لبه اینترنت واقع شده است. کاربران نهایی یا بطور کلی مشتریان، بوسیله خدمتگزار لبه ای به اینترنت متصل می شوند. وظیفه اصلی خدمتگزار لبه ای فراهم کردن محتوا، احتمالاً پس از اعمال کارکردهای فیلترینگ و تبدیل کد است. جالب تر از اینکه از مجموعه ای از خدمتگزار های لبه ای می توان برای بهینه سازی محتوا و توزیع برنامه های کاربردی استفاده کرد. ایده اصلی این است که برای یک سازمان خاص یک خدمتگزار لبه ای می تواند به عنوان خدمتگزار مبدا عمل کند، بطوریکه گویی تمام محتوا از آن نشات می گیرد. این خدمتگزار هم می تواند از دیگر خدمتگزارهای لبه ای برای تکثیر صفحات وب و نظایر آن استفاده کند.

سیستم های توزیع شده با تشریک مساعی
ساختارهای هیبریدی به ویژه در سیستم های توزیی با تشریک مساعی پیاده سازی شده اند. مسئله اصلی بسیاری از این سیستم ها اولین راه اندازی است، که بدین منظور غالباً یک طرح مشتری-خدمتگزار متعارف به کار گرفته می شود. پس از الحاق یک گره مفروض به سیستم، این گره می تواند برای تشریک مساعی از طرحی کاملاً غیر متمرکز استفاده کند.

2-3 معماری یا میان افزار؟
میان افزار لایه ای را بین برنامه های کاربردی و سکوهای توزیع شده ایجاد می کند. یکی از مهم ترین اهداف این کار یاجاد درجه ای از شفافیت توزیع شده است که بتوان به کمک آن توزیع داده، توزیع پردازش و توزیع کنترل را ازبرنامه های کاربردی مخفی کرد.
اما غالباً در عمل مشاهده می شود که سیستم های میان افزاری از شیوه معماری خاصی تبعیت می کنند. بعنوان مثال، بسیاری از راه حل های میان افزاری از قبیلCORBA از شیوه معماری شئ محمور استفاده می کنند. برخی دیگر، از جمله TIB/Rendezvous برای ایجاد میان افزار از شیوه معماری رویداد محور بهره می گیرند. مزیت میان افزارهایی که بر اساس شیوه معماری خاصی مدل شده اند، این است که بعضاً باعث تسهیل طراحی برنامه های کاربردی می شوند. اما یکی از نقاط ضعف آشکار آنها این است که میان افزار مذکور ممکن است برای آنچه طراح یک برنامه کاربردی در ذهن دارد، بهینه نباشد. بعنوان مثال، CORBA در ابتدا فقط اشیایی را ارائه می داد که توسط مشتری های راه دور قابل فراخوانی بودند. بعدها احساس شد که استفاده صرف از این نوع برهم کنش بسیار محدود کننده خواهد بود، و به همین دلیل الگوهای دیگر بر هم کنش از قبیل پیام دهی نیز به آن افزوده شد. افزودن ویژگی های جدید می تواند باعث افزایش راه حل های میان افزاری شود.

2-3-1 رهگیرها
از نظر مفهومی رهگیر در واقع یک ساختار نرم افزاری است که جریان عادی کنترل را شکسته و به کد (خاص برنامه کاربردی) دیگر اجازه اجرا می دهد. عمومی کردن رهگیرها مستلزم تلاش اجرایی زیادی است که توسط اشمیت و همکاران (2000) مورد بررسی قرار گرفته است. بطور قطع نمی توان گفت که در چنین مواردی ارجحیت با عمومیت است یا قابلیت اجرای محدود و ساده بودن. همچنین در بسیاری از موارد داشتن امکانات رهگیری محدود باعث بهبود مدیریت نرم افزار و سیستم توزیع شده خواهد شد.
برای وضوح بحث، موضوع رهگیری را به صورتی در نظر بگیرید که در بسیاری از سیستم های توزیع شده شئ محور مورد پشتیبانی قرار می گیرد. ایده اصلی ساده است: شئ A می تواند متعلق به شئB را که روی ماشینی دیگر قرار دارد، فراخوانی کند. این فراخوانی شئ از راه دور طی رهیافت سه مرحله ای زیر انجام خواهد شد:
1* یک واسط محلی، دقیقاً مانند آنچه توسط به شئ B ارائه شده، به شئA ارائه می شود. A به سادگی متد موجود در این وسط را فراخوانی می کند.
2*فراخوانی انجام شده توسط A به یک فراخوانی شئ عمومی تبدیل می شود، که از طریق واسط فراخوانی شئ عمومی ارائه شده توسط میان افزار موجود در ماشین A امکان پذیر می شود.
3* در انتها، فراخوانی شئ عمومی تبدیل به پیامی می شود که توسط واسط شبکه سطح انتقال ارئه شده بوسیله سیستم عامل محلیA ارسال می شود.

2-3-2 رویکردهای عمومی به نرم افزار تطبیقی
در واقع می توان گفت که رهگیرها ابزاری جهت تطبیق میان افزار ارائه می کنند. لزوم تطبیق ریشه در این واقعیت دارد که محیط اجرای برنامه های کاربردی توزیع شده دائماً دستخوش تغییر می شود. از جمله این تغییرات می توان به جابجایی، تفاوت زیاد کیفیت خدمات شبکه ها، خرابی سخت افزار، تخلیه باتری و بسیاری موارد دیگر اشاره کرد. وظیف واکنش در برابر این تغییرات به جای برنامه های کاربردی، بر عهده میان افزار قرار داده شده است. این دست تاثیرات شدید بسیاری از طراحان نرم افزار را به فکر ساخت نرم افزار تطبیقی انداخت. اما موفقیت نرم افزار تطبیقی هیچگاه به اندازه ای نبود که از آن انتظار می رفت. از آنجایی که بسیاری از محققان و سازندگان نرم افزار آن را یکی از مهم ترین جنبه های سیستم های توزیع شده امروزی می دانند. مک کینلی و همکاران سه تکنیک اساسی در مورد تطبیق نرم افزار مطرح کرده اند:
1* تفکیک موارد
2* انعکاس محاسباتی
3* طراحی مولفه محور
تفکیک موارد با روش متعارف پیمانه ای ساختن سیستم ها مرتبط می باشد، یعنی تفکیک بخش هایی که کارکردها را پیاده سازی می کنند از سایر بخش های مسئول انجام امور دیگر که به نام کارکرد اضافی خوانده می شود، مانند قابلیت اطمینان، کارایی، امنیت و غیره. می توان استدلال کرد که ایجاد میان افزار برای برنامه های کاربردی توزیع شده تا حدود زیادی با کار با موضوع کارکردهای اضافی، آن هم بصورتی مستقل از برنامه های کاربردی، مرتبط است. مشکل اصلی این است که نمی توان از طریق پیمانه ای کردن، این کارکردهای اضافی را از هم تفکیک کرد. بعنوان مثال، قرار دادن امنیت در یک پیمانه جداگانه عملی نیست. به همین ترتیب، نمی توان تصور کرد که تحمل خرابی را در یک جعبه جداگانه قرار داده و بعنوان یک سرویس مستقل ارائه نماییم.
انعکاس محاسباتی اشاره دارد به توانایی یک برنامه مفروض در نظارت بر خود، ودر صورت لزوم انطباق رفتار خود. موضوع انعکاس در برخی از زبان های برنامه نویسی از جمله جاوا لحاظ شده، و امکانات گسترده ای را برای اصلاحات زمان اجرا در اختیار قرار می دهد. بعلاوه، برخی از سیستم های میان افزاری امکان اتخاذ روش های انعکاسی را فراهم می آورند. با این وجود، درست مانند حالت جنبه گرایی، میان افزار انعکاسی باید بتواند خود را بعنوان یک ابزار قوی در مدیریت پیچیدگی سیستم های توزیع شده پر دامنه اثبات کند.
نهایتاً طراحی مولفه محور از تطبیق به طریق ترکیب پشتیبانی می کند. هر سیستم مفروض را می توان یا به صورت ایستا در زمان طراحی پیکربندی کرد، و یا به صورت پویا در زمان اجرا. پیکربندی پویا نیازمند پشتیبانی برای پیوند دیر هنگام می باشد. این روش به صورت موفقیت آمیزی هم در محیط های زبان برنامه نویسی اعمال شده و هم در سیستم های عاملی که بتوان در آنها پیمانه ها را به دلخواه بار کرد و تخلیه نمود.

2-4 خود مدیریتی در سیستم های توزیع شده
به عنوان جایگزین، سیستم های توزیع شده خود مدیریتی پیاده سازی شده اند. در این سیستم ها تا حدودی ایده هایی از معماری های نرم افزار و سیستم با هم ترکیب می شود. سیستم های توزیع شده خود مدیریتی را می توان بصورت حلقه های کنترل باز خورد سازماندهی کرد. این قبیل حلقه ها دارای یک مولفه نظارتی جهت اندازه گیری رفتار سیستم توزیع شده ، یک مولفه آنالیز جهت بررسی لزوم یا عدم لزوم تنظیمات، و همچنین مجموعه ای از ابزارهای مختلف جهت تغییر رفتار سیستم می باشند. حلقه های کنترل باز خورد را می توان در محل های مختلف در سیستم های توزیع شده تلفیق نمود. تا رسیدن به درکی مشترک از نحوه ایجاد این حلقه ها، و همچنین اجرای آنها، به پژوهش بسیاری نیاز داریم.

فصل سوم- ارتباطات

3-1 ارتباطات
ارتباطات میان فرآیندی قلب تپنده تمامی سیستم های توزیع شده محسوب می شود. در واقع، مطالعه سیستم های توزیع شده بدون بررسی دقیق روش های تبادل اطلاعات بین فرآیندها در ماشین های مختلف امری بیهوده است. درسیستم های توزیع شده ، ارتباطات همواره بر اساس تبادل پیام سطح پایین، آن طور که توسط شبکه زیربنایی ارائه می شود، استوار است. ارتباطات سریع از طریق تبادل پیام مشکل تر از به کار گیری عملیات پایه حافظه اشتراکی که ویژگی بسترهای غیرتوزیع شده محسوب می شود است.
ابتدا راجع به قوانین ارتباط فرآیندها که به آن پروتکل می گویند صحبت کرده و سپس روی لایه ای کردن این پروتکل ها تمرکز خواهیم کرد. پس از آن نگاهی به سه مدل ارتباطی پرکاربرد خواهیم داشت: فراخوانی روال راه دور، میان افزار پیام گرا. جویباری کردن داده ها همچنین در مورد مشکل عمومی ارسال همزمان داده برای چندین گیرنده موسوم به چند بخشی بحث خواهیم کرد.
اولین مدل ارتباطات در سیستم های توزیع شده فراخوانی روال راه دور (RPC) است. هدف از RPC مخفی سازی بخش عظیمی از ظرافت های تبادل پیام است و به همین دلیل برای برنامه های کاربردی مشتری خدمتگزار ایده آل می باشد. در بسیاری از برنامه های کاربردی توزیع شده ، ارتباطات از الگوی بسیار خشک برهم کنش مشتری خدمتگزار تبعیت نمی کند. در این قبیل موارد در نظر گرفتن ارتباط به صورت جریانی از پیام های دو طرفه مفیدتر خواهد بود. با این وجود امکانات ارتباطی سطح پایین شبکه های کامپیوتری به دلیل عدم شفافیت توزیع شده از بسیاری جهات نامناسب است. یک راه غلبه بر این مشکل استفاده از مدل صف بندی پیام سطح بالا است. این روش تا حد زیادی شبیه سیستم های الکترونیک عمل می کند. با ظهور سیستم های توزیع شده چند رسانه ای مشخص شد که اغلب سیستم ها از ارتباطات رسانه های جویباری (از قبیل رسانه های صوتی و تصویری) پشتیبانی نمی کنند. در واقع لازم بود پیام ها به صورت جویباری از داده های پیوسته که از قیدهای زمان بندی مختلف پشتیبانی کنند، سازماندهی شوند.

3-1-1 پروتکل های لایه ای
در سیستم های توزیع شده ، به دلیل عدم وجود حافظه اشتراکی، تمامی ارتباطات بر اساس ارسال و دریافت پیام های سطح پایین استوار است. وقتی فرآیندA می خواهد با فرآیند B ارتباط برقرار کند، ابتدا در فضای آدرس خود یک پیام ایجاد می کند. سپس با اجرای یک فراخوان سیستمی سیستم عامل را وادار می کند تا این پیام را از طریق شبکه بهB ارسال کند. هر چند این ایده بسیار ساده می نماید، برای جلوگیری از هرج و مرج B,A بایستی قبلاً در مورد معنای بیت های ارسال شده به توافق رسیده باشند.
به منظور تسهیل کار در مورد سطوح و مسائل متعدد مربوط به ارتباطات، موسسه بین المللی استاندارد (ISO) با توسعه یک مدل مرجع، اقدام به معرفی دقیق سطوح مختلف، نام گذاری و تعریف وظایف هر یک از آنها کرد. این مدل، مدل مرجع اتصال متقابل سیستم های باز نام دارد که به آن مدل ISO گفته می شود.
مدل OSI برای ایجاد ارتباط بین سیستم های باز طراحی شده است. سیستم باز سیستمی است که آمادگی دارد تا بر اساس قوانین استاندارد مربوط به قالب، محتوا و معنای پیام های ارسالی و دریافتی، با هر سیستم باز دیگری ارتباط برقرار کند. این قوانین تحت عنوان پروتکل صورت بندی می شوند. برای آنکه یک گروه کامپیوتر بتوانند در شبکه با یکدیگر ارتباط برقرار نمایند، بایستی همگی از پروتکل های مشترکی استفاده کنند. در کل دو نوع پروتکل وجود دارد که باید بین آنها تفاوت قائل شویم در پروتکل های اتصال گرا فرستنده و گیرنده پیش از تبادل داده ها، ابتدا به صراحت یک اتصال ایجاد کرده و احتمالاً در مورد پروتکل هایی که بکار خواهند برد، مذاکره می کنند. در پایان اتصال بایستی آزاد شود. دستگاه تلفن نمونه ای از سیستم های اتصال گرا است. اما در پروتکل های بدون اتصال نیازی به ایجاد هیچ تنظیم قبلی نیست. اولین پیام به محض آماده شدن توسط فرستنده ارسال می شود. انداختن نامه در صندوق پست نمونه ای از ارتباط بدون اتصال است. در کامپیوترها، هردونوع ارتباطات اتصال گرا و بدوناتصال کاربرد دارد.
همانطور که در شکل3-1 نشان داده شده، در مدل OSI ارتباط به هفت سطح یا لایه تقسیم می شود، و هر لایه مسئول جنبه خاصی از ارتباط است. هر لایه واسطی برای لایه فوقانی خود ایجاد می کند. این واسط مجموعه ای از عملیاتی است که روی هم رفته معرف سرویس قابل ارئه توسط این لایه به کاربران خواهد بود.

شکل3-1. لایه ها، واسط ها و پروتکل های مدل OSI

هنگامی که فرآیند A روی مشاین 1 قصد برقراری ارتباط با فرآیند B روی ماشین 2 را داشته باشد، پس از ساخت پیام، آن را به لایه کاربرد ماشین خود انتقال می دهد. این لایه ممکن است یک روال کتابخانه ای باشد، ولی به روش های دیگر نیز قابل پیاده سازی است مثلاً، داخل سیستم عامل روی یک پردازشگر شبکه خارجی و غیره. نرم افزار لایه کاربرد یک سرآیند به ابتدای پیام اضافه کرده، و از طریق واسط لایه7/6 آن را به لایه ارائه منتقل می کند. لایه ارائه هم بنوبه خود سرآیند خاص خود را به پیام اضافه کرده، و آن را به لایه جلسه ارسال می کند، و الی آخر. برخی لایه ها، علاوه بر افزودن سرآیند، یک پی آیند هم به انتهای پیام ها اضافه می کنند. وقتی پیام به انتهای سفر خود می رسد، لایه فیزیکی با قراردادنآن روی رسانه ارسال فیزیکی ماند سیم مسی فیبر نوری یا امواج رادیویی پیام را ارسال می کند.
لایه فیزیکی مسئول ارسال 0ها و 1هاست. ولتاژ بکار رفته برای سطوح 0 و1، تعداد بیت های قابل ارسال در هر ثانیه، و امکان ارسال همزمان در هردو جهت از جمله مسائل کلیدی در لایه فیزیکی هستند. پروتکل لایه فیزیکی به استاندارد سازی واسط های الکتریکی، مکانیکی و سیگنال دهی می پردازد، تا هر زمان که یک ماشین بیت 0 ارسال می کند، ماشین مقابل واقعاً یک بیت 0دریافتکند نه بیت1. لایه فیزیکی صرفاً مسئول ارسال بیت هاست. مادامیکه هیچ خطایی رخ ندهد، همه چیز روال عادی خود را طی خواهد کرد. اما شبکه های ارتباطی واقعی در معرض خطا قرار دارند. به همین دلیل به مکانیزه هایی برای ردیابی واصلاح این نوع خطاها نیاز داریم. این مکانیزم ها وظیفه اصلی لایه لینک داده است. این لایه بیت ها را به چندین واحد، که گاهی به آنها قاب گفته می شود. دسته بندی کرده و سپس بر دریافت صحیح هر قاب نظارت می کند.
وظیفه لایه لینک داده قراردادن یک الگوی بیت خاص در ابتدا و انتهای هر ژفریم برای نشانه گذاری آنهاست. همچنین با جمع کردن تمامی بیت های قاب به روشی خاص، اقدام به محاسبه حاصلجمع آزمایشی کرده و آن را به قاب ضمیمه می کند. گیرنده پس از دریافت قاب، خودش حاصلجمع آزمایشی را بر حسب داده دریافت شده محاسبه کرده، و نتیجه را با حاصلجمع آزمایشی مربوط به قاب مقایسه می کند. در صورت تطابق این دو عدد، آن قاب صحیح بوده و پذیرفته می شود. در غیر اینصورت، گیرنده از فرستنده درخواست ارسال مجدد آن را می کند. به هر قاب یک عدد ترتیبی اختصاص می آید تا بتوان آنها را از یکدیگر تفکیک کرد.
پرکاربردترین پروتکل شبکه، پروتکل بدون اتصال IP (INTERNET PROTOCOL پروتکل اینترنت) است که بخشی از بسته پروتکل اینترنت محسوب می شود. یک بسته IP اصطلاح فنی مورد استفاده برای پیام در لایه شبکه را می توان بدون هیچ تنظیم و تغییری ارسال نمود. هر بسته IP مستقل از بسته های دیگر به سمت مقصد مسیردهی می شود. علاوه بر آن، هیچ مسیری از پیش تعیین و به خاطر سپرده نمی شود.
لایه انتقال آخرین بخش از پشته اصلی پروتکل شبکه است. دلیل این نام گذاری آن است که لایه مذکور قادر به انجام کلیه سرویس هایی است که اگر چه منطقاً لازمه ساخت برنامه های کاربردی شبکه می باشند، اما در واسط لایه شبکه ارئه نمی شوند. لایه انتقال به محض دریافت پیام از لایه کاربرد آن را به قطعات کوچک تقسیم می کند. اندازه این قطعات باید به حدی باشد که ارسال آنها امکانپذیر باشد. سپس به هر قطعه یک شماره ترتیبی الصاق و ارسال می شود. محتویات سرآیند لایه انتقال روی موضوعاتی از این قبیل تمرکز می کند: کدام بسته ها ارسال شده اند، کدام بسته ها دریافت شده اندگیرنده چه مقدار فضا برای دریافت پیام در اختیار دارد، کدام پیام باید مجدداً ارسال شود. پروتکل انتقال اینترنت به نامTCP خوانده شده و امروزه ترکیب TCP/IP استاندارد مسلم ارتباطات شبکه محسوب می شود.
لایه نشست در اصل نسخه تقویت شده لایه انتقال است. این لایه گفتگو ها را کنترل می کند تا بدین وسیله امکان پی گیری طرف گفتگو کننده فراهم آید و علاوه بر آن امکانات همگام سازی را ایجاد می کند. این امکانات به کاربر اجازه می دهند تا در لابه لای انتقال های طولانی نقاط بازرسی درج کند، تا در صورت بروز خرابی به جای تکرار مجدد کل فرآیند، فقط آخرین نقطه بازرسی بررسی شود.
لایه ارائه بر خلاف لایه های زیرین خود که مسئول دریافت بیت ها و ارسال موثق و موثر آنها به گیرنده هستند، به مفهوم بیت ها علاقه دارد. اغلب پیام ها صرفاً زنجیره ای از بیت های تصادفی نیستند، بلکه اطلاعات سازماندهی شده (از قبیل اسامی افراد، آدرس و موجودی حساب بانکی آنها و غیره) در آنها وجود دارد. در لایه ارئه می توان رکوردهایی با فیلدهی مشخص تعریف کرده و سپس پیام های دریافتی را برای اطمینان از وجود چنین فیلدهایی بررسی کرد این روش باعث تسهیل ارتباط میان ماشین های مختلف یا اجزای داخلی یک برنامه می شود.
هدف اولیه طراحی لایه کاربرد در مدلOSI مجموعه ای از برنامه های کاربردی استاندارد شبکه از قبیل پست الکترونیک، انتقال فایل و شبیه سازی ترمینال بود. اما امروزه تبدیل به ظرفی برای گنجاندن تمامی برنامه های کاربردی و پروتکل هایی شده که در لایه زیرین نمی گنجند. از نقطه نظر مدل OSI تمامی سیستم های توزیع شده ذاتاً و صرفاً برنامه های کاربردی هستند.

پروتکل های میان افزار
میان افزار یک برنامه کاربردی است که منطقاً در لایه کاربرد قرار می گیرد اما حاوی تعداد زیادی از پروتکل های همه منظوره ای است که لایه ای مخصوص به خود و مستقل از کاربردهای مشخص را طلب می کنند. قابل ذکر استکه بین پروتکل های ارتباطی سطح بالا وپروتکل های مربوط به ایجاد سرویس های مختلف میان افزاری تفاوت وجود دارد. استفاده از این رهیافت در لایه بندی منجر به تولید مدل مرجع نسبتاً سازگاری برای ارتباطات می شود. درقیاس بامدل OSI به جای لایه ارائه و نشست از یک لایه میان افزاری جداگانه استفاده شده که حاوی پروتکل های مستقل از برنامه کاربردی است. سرویس های اصلی لایه انتقال ممکن است بدون هیچ اصلاح و تغییری بعنوان یک سرویس میان افزاری هم ارائه شوند. این روش تاحدودی مشابه ارائه UDP در لایه انتقال است. سرویس های ارتباطات میان افزاری ممکن است حاوی سرویس های تبادل پیام قابل مقایسه با سرویس های لایه انتقال باشند.

3-1-2 انواع ارتباطات
سیستم پست الکترونیک نمونه بارزی از ارتباطات پایدار است. در ارتباطات پایدار پیام تحویل شده برای ارسال بوسیله میان افزار ارتباطی ذخیره شده، و مادامیکه میان افزار اقدام به انتقال آن به گیرنده نکرده باشد، در همانجا باقی خواهد ماند. در این حالت پیام توسط میان افزار در یک یا چند وسیله ذخیره سازی ذخیره می شود.
در ارتباطات ناپایدار پیام فقط تا زمانی توسط سیستم ارتباطی ذخیره می شود که برنامه کاربردی گیرنده و فرستنده در حال اجرا باشند. در صورت وقفه در روند ارسال یا غیر فعال شدن گیرنده،، میان افزار دیگر قادر به تحویل پیام نبوده و پیام حذف خواهد شد. غالباً تمامی سرویس های ارتباطی در لایه انتقال فقط ارتباطات ناپایدار را ارائه می دهند. در این حالت سیستم ارتباطی شامل مسیریاب های ذخیره و ارسال متداول است. چنانچه یک مسیریاب نتواند پیام را به مسیریاب دیگر یا به میزان مقصد تحویل دهد، به سادگی پیام را حذف خواهد کرد.
علاوه بر دو حالت پایدار وناپایدار، ارتباطات می تواند ناهمگام یا همگام هم باشد. ویژگی بارز ارتباطات ناهمگام آن است که فرستنده بلافاصله پس از تحویل پیام به سیستم ارتباطی به کار قبلی خود باز می گردد. این بدان معناست که پیام به محض تحویل فوراً و به طور موقت توسط میان افزار ذخیره می شود. در ارتباطات همگام مادامی که درخواست فرستنده پذیرفته نشود، فرستنده مسدود باقی خواهد ماند. به طور مشخص همگام سازی در سه نقطه می تواند اتفاق بیفتد. در حالت اول، فرستنده فقط تا زمانی مسدود می ماند که میان افزار اطلاع دهد که انتقال این درخواست را بر عهده خواهد گرفت. در حالت دوم فرستنده ممکن است همگامی خود را تا زمان تحویل درخواست به گیرنده مورد نظر ادامه دهد. در حالت سوم، همگام سازی با انتظار فرستنده برای پردازش کامل درخواست یعنی تا زمانی که گیرنده پاسخ خود را باز گرداند ادامه خواهد یافت.

3-2 فراخوانی روال راه دور
بسیاری از سیستم های توزیع شده بر اساس تبادل آشکار پیام بین فرآیندها استوار هستند. با این وجود، روال های send و receive نمی توانند ارتباط را بههیچ وجه پنهان سازند، و این ویژگی تاثیر مهمی در رسیدن به شفافیت دسترسی در سیستم های توزیع شده محسوب می شود. اطلاعات را می توان به صورت پارامتر از فراخوانی کننده به فراخوانیشونده انتقال داد، و به شکل مقدار برگشتی روال بازگرداند. بغلاوه برنامه نویس هیچ اثری از تبادل پیام ها مشاهده نخواهند کرد. این روش به نام فراخوانی روال راه دور یا به اختصار RPC خوانده می شود. هر چند ایده اساسی این روش بسیار ساده و بی نقص به نظر می رسد، مشکلات ظریفی دراین میان وجود دارد. به عنوان پیش زمینه به خاطر داشته باشید که از آنجایی که روال های فراخوانی کننده و فراخوانی شونده روی ماشین های مختلف اجرا می شوند، فضاهای آدرس مختلفی دارند که باعث پیچیدگی کارمی شود. پارامترها و مقادیر برگشتی نیز بایستی رد و بدل شوند که این هم، در صورت تفاوت ماشین ها باعث افزایش پیچیدگی خواهد شدونهایتاً هر یک از دو ماشین می توانند دچار خرابی شوند و حالت های مختلف خرابی مسائل مختلفی را ایجاد خواهند کرد. اما اغلب این مسائل قابل حل هستند، و به همین دلیلRPC روشی متداول برای پیاده سازی سیستم های توزیع محسوب می شود.

3-2-1 عملیات اصلی RPC
مشتری و خدمتگزار مجازی
ایده زیربنایی RPC این است که فراخوانی روال راه دورحتی الامکان به صورت فراخوانی روال محلی به نظر برسد. به بیان دیگرRPC باید شفاف باشد و روال فراخوانی کننده نباید از اجرای روال فراخوانی شونده روی ماشین دیگر اطلاع داشته باشد و بر عکس فرض کنید یک برنامه می خواهد داده هایی را از یک فایل بخواند. برای گرفتن داده مورد نظر، برنامه نویس فراخوانیread را در کد خود می گنجاند. در سیستم های متعارف (تک پردازنده) روالread توسط پیوند دهنده از کتابخانه استخراج و داخل برنامه مورد نظر درج می شود. این روال کوتاه غالباً از طریق فراخوانی یک فراخوانی سیستمی معادل read پیاده سازی می شود. به بیان دیگر، روال read نوعی واسط بین کد کاربر و سیستم عامل محلی است.
اگرچه read اقدام به فراخوانی سیستمی می کند، ولی به همان صورت عادی یعنی با قرار دادن پارامترها در پشته فراخوانی خواهد شد. به این ترتیب، برنامه نویس کوچکترین اطلاعی از عمل زیرکانه read پیدا نخواهد کرد.
RPC شفافیت خود را به روشی مشابه کسب می کند. در صورتیکهread واقعا روال راه دور باشد، نسخه متفاوتی از read به نام مشتری مجازی در کتابخانه قرار داده خواهد شد. روند فراخوانی این نسخه هم مشابه read اصلی مشابه زنجیره فراخوانی است و منجر به یک فراخوانی read در سیستم عامل محلی می شود. تنها تفاوت این است که بر خلاف read اصلی خودش از سیستم عامل تقاضای گرفتن داده را نخواهد کرد، بلکه در عوض پارامترها را به شکل یک پیام دسته بندی کرده و درخواست می کند که این پیام به خدمتگزار ارسال شود؛ بلکه در عوض پارامترها را به شکل یک پیام دسته بندی کرده و درخواست می کند که این پیام به خدمتگزار ارسال شود. پس از فراخوانیsend مشتری مجازی روال receive را فراخوانی کرده و تا زمان بازگشت پاسخ مسدود می شود. همانند شکل3-2

شکل3-2 اصول کلی RPC بین برنامه مشتری و خدمتگزار
با رسیدن پیام به خدمتگزار، سیستم عامل خدمتگزار آن را به خدمتگزار مجازی پاس می کند. خدمتگزار مجازی معادل مشتری در سمت خدمتگزار است. به بیان دیگر، قطعه ای از یک کد است که درخواست های ورودی از سرتاسر شبکه را به فراخوانی های روال محلی تبدیل می کند. معمولاً خدمتگزار مجازی مجبور است یک روال receive را فراخوانی کرده و تا رسیدن پیام های ورودی مسدود باقی بماند. خدمتگزار مجازی پارامترهای پیام را بازگشایی کرده و سپس مطابق معمول روال خدمتگزار را فراخوانی می کند. از نقطه نظر خدمتگزار، این وضعیت مشابه فراخوانی شدن بوسیله مشتری است پارامترها و آدرس بازگشت همگی روی پشته ای قرار دارند که به آن متعلق بوده و همه چیز عادی به نظر می رسد. خدمتگزار کار خود را انجام داده و سپس نتیجه را به صورت معمول به فراخوانی کننده باز می گرداند. پس از تکمیل فراخوانی هنگامیکه خدمتگزار مجازی کنترل را مجدداً در دست می گیرد، نتیجه (بافر) را در قالب یک پیام بسته بندی کرده، و روال send را فراخوانی می کند تا آن را به مشتری بازگرداند. معمولاً، پس از آن خدمتگزار مجازی مجدداًreceive را فراخوانی می کند تا منتظر درخواست ورودی بعدی بماند.
پس از آنکه پیام به مشتری بازگردانده شد سیستم عامل مشتری مشاهده می کند که به فرآیند مشتری آدرس دهی شده است. پیام به بافر در حال انتظار کپی شده و فرآیند مشتری آزاد می شود. مشتری مجازی پیام را بازبینی کرده نتیجه را بازگشایی کرده، آن را به روال فراخوانی کننده اش کپی کرده و به همان صورت معمول باز می گردد. پس از فراخوانیread هنگامی که روال فراخوانی کننده کنترل را مجدداً به دست گرفت، تنها چیزی که می داند این است که داده ها را در اختیار دارد، و دیگر کوچکترین اطلاعی ندارد که این کار نه توسط سیستم عامل محلی، بلکه از راه دور انجام شده است. این نا آگاهی مشتری در واقع راز ظرافت و جذابیت کلی رهیافتRPC است. تا آنجاییکه به مشتری مربوط می شود این سرویس ها از طریق فراخوانی های معمولی یعنی محلی قابل دسترسی هستند، نه با فراخوانی های راه دور send ,receive.

یک فراخوانی روال راه دور به صورت زیر انجام می شود:
1- روال مشتری، مشتری مجازی را به طور معمول فراخوانی می کند.
2-مشتری مجازی پس از ساختن پیام، سیستم عامل محلی را فراخوانی می کند.
3- سیستم عامل مشتری پیام را به سیستم عامل ماشین راه دور ارسال می کند.
4- سیستم عامل ماشین راه دور پیام را به خدمتگزار مجازی می دهد.
5- خدمتگزار مجازی پارامترها را بازگشایی کرده و خدمتگزار را فراخوانی می کند.
6-خدمتگزار کار خود را انجام داده و نتیجه را به خدمتگزار مجازی باز می گرداند.
7- خدمتگزار مجازی نتیجه را دیک بسته پیام بسته بندی کرده و سیستم عامل محلی خود را فراخوانی می کند.
8-سیستم عامل خدمتگزار پیام را به سیستم عامل مشتری ارسال می کند.
9- سیستم عامل مشتری پیام را به مشتری مجاز می دهد.
10- مشتری مجازی پیام را باز گشایی کرده و نتیجه را به مشتری باز می گرداند.

2-2-3 پاس کردن پارامتر
وظیفه مشتری مجازی گرفتن پارامترهای فراخوانی، بسته بندی آن به شکل یک پیام، و ارسال پیام به خدمتگزار مجازی است. این کار بر خلاف ظاهر ساده آن دارای پیچیدگی های خاصی است.
پاس کردن پارامترهای مقداری بسته بندی پارامترها به شکل پیام، به صف سازی پارامتر نامیده می شود. برای نمونه یک روال راه دور ساده مثل (i,j) add را در نظر بگیرید، که دو پارامتر صحیح i ,j گرفته و حاصل جمع آنها را بعنوان نتیجه بازگردانده می شود. مشتری مجازی ان دو پارامتر را گرفته و آهنا را به ترتیب گفته شده به یک پیام تبدیل می کند. سپس نام یا شماره روالی را که قرار است فراخوانی شود، در این پیام قرار می دهد. وقتی این پیام به خدمتگزار می رسد، خدمتگزار مجازی بعد ازبررسی محتویات پیام روال لازم را شناسایی کرده و فراخوانی مناسب را انجام می دهد. چنانچه خدمتگزار روال های راه دور دیگری را هم پشتیبانی کند، ممکن است خدمتگزار مجازی از یک دستورswitchبرای انتخاب روال فراخوانی شونده استفاده کند. فراخوانی واقعی از خدمتگزار مجازی به خدمتگزار مشابه فراخوانی اولیه مشتری است، با این تفاوت که پارامترهای آن مقدار خود را از پیام دریافتی می گیرند. بعد از اتمام کار خدمتگزار، کنترل مجدداً به خدمتگزار مجازی داده می شود. این خدمتگزار نتیجه بازگردانده شده توسط خدمتگزار اصلی را گرفته و آن را در یک پیام دسته بندی می کند و به ماشین مشتری ارسال می فرستد. مشتری مجازی پیام را گرفته و بعد از بازگشایی آن نتیجه را استخراج کرده و به روال مشتری باز می گرداند.

مشخصات پارامتر و تولید مشتری و خدمتگزار مجازی
مخفی سازی فراخوانی روال راه دور مستلزم توافق فراخوانی کننده و فراخوانی شونده در مورد قالب پیام مبادله شده است. علاوه بر آن، در مواردی از قبیل پاس کردن ساختمان های داده پیچیده مشتری وخدمتگزار باید از مراحل یکسانی تبعیت کنند. به بیان دیگر، طرفینRPC بایستی از یک پروتکل واحد تبعیت کنند، در غیر اینصورتRPC عملکرد صحیحی نخواهد داشت.
بعد از آن که قوانین کدگذاری با جزئیات کامل مشخص شدند، تنها چیزی که باقی می ماند این است که فراخوانی کننده و فراخوانی شونده در مورد تبادل واقعی پیام ها به توافق برسند. بعنوان مثال ممکن است توافق شود که از یک سرویس انتقال اتصال گر، مانند tcp/ip استفاده شود. روش دیگر استفاده از یک سرویس دیتاگرام نامطمئن و به کارگیری طرح های کنترل خطا (به عنوان بخشی از پروتکل RPC) در عمل از راهکارهای متفاوتی استفاده می شود.
پس از تعریف کامل و دقیق پروتکلRPC، بایستی مشتری و خدمتگزار مجازی پیاده سازی شوند. روال های مختلف که پروتکل واحد غالباً فقط از نظر واسط بزنامه های کاربردی با یکدیگر تفاوت دارند. یک واسط مجموع های از روال ها تشکیل شده که بوسیله مشتری فراخوانی شده و توسط خدمتگزار اجرا می شوند. معمولاً با همان زبان برنامه نویسی که خدمتگزار و مشتری به آن نوشته شده اند، نوشته می شود. برای ساده ترکردن اوضاع، واسط ها غالباً بوسیله زبان تعریف واسط تعریف می شوند. این واسط به همراه واسط های مناسب زمان کامپایل یا زمان اجرا به صورت مشتری مجازی یا خدمتگزار مجازی کامپایل می شود. استفاده از زبان تعریف واسط به نحو چشمگیری باعث تسهیل در پیاده سازی برنامه کاربردی مشتری خدمتگزار بر اساس RPC می شود.

2-3-2 RPC ناهمگام
هنگامی که مشتری یک روال راه دور را فرا می خواند، تا زمان بازگشت پاسخ مسدود باقی خواهد ماند. این رفتار انعطاف ناپذیر درخواست/ پاسخ هنگامی بیشتر غیر ضروری می نماید که هیچ نتیجه ای بازگشت داده نشده و فقط منجر به مسدود کردن مشتری شود، در حالیکه می توانست به کار ادامه داده و پس از درخواست فراخوانی روال راه دور کار مفیدی انجام دهد.
سیستم های RPC امکانی به نام RPC ناهمگام ارائه می دهند، بدین ترتیب که مشتری بعد از صدور درخواستRPC فوراً فعال می شود. درRPC های ناهمگام خدمتگزار به محض دریافت درخواستRPC پاسخی برای مشتری ارسال کرده و سپس روال درخواست شده را فرامی خواند. این پاسخ به مشتری می گوید که خدمتگزار درخواستRPC وی را پذیرفته است. مشتریبه محض دریافت تصدیق خدمتگزار، مسدود شدن را پایان داده و شروع به کار خواهد کرد شکل 3-3 ب نحوه برهم کنش مشتری خدمتگزار را در RPCهای ناهمگام نشان می دهد. برای سهولت مقایسه در شکل 3-3 الف رفتار عادی درخواست/پاسخ نمایش داده شده است.

شکل3-3 الف) برهم کنش بین مشتری و خدمتگزار در یک RPC متعارف
شکل 3-3 ب) برهم کنش بین مشتری و خدمتگزار با استفاده از RPCناهمگام

RPCهای ناهمگام درحالتی که پاسخ بازگردانده خواهد شد، اما مشتری آمادگی برای انتظار کشیدن و غیر فعال ماندن در این فاصله زمانی را ندارد، نیز می توانند مفید باشند. گاهی به ترکیب دو RPC ناهمگامRPC معوق نیز گفته می شود. در برخی از انواع RPC های ناهمگام، مشتری فوراً پس از ارسال درخواست به خدمتگزار همچنانبه اجرا شدن ادامه می دهد. به بیان دیگر مشتری دیگر منتظر دریافت پیام پذیرش درخواست خود از طرف خدمتگزار باقی نمی ماند به چنین RPC هایی RPC یکطرفه می گویند.

مقدمه ای بر DCE
از آنجاییکهDCE برای اجرای بعنوان یک لایه منتزع کننده بین سیستم های عامل موجود و برنامه های کاربردی توزیع شده طراحی شده، می توان آن را یک سیستم میان افزاریواقعی تلقی کرد. امروزه در بسیاری از سیستم عامل های مهم از جمله نسخه های مختلف ویندوز، VMSوهمچنین سیستم های عامل کامپیوترهای شخصی به کار گرفته شده است. بعضی از سرویس ها از اجزاء تشکیل دهنده DCE هستند. سرویس فایل توزیع شده یک سیستم فایل جهانی است که روش شفاف و واحدی را برایدسترسی به تمام فایل های درون سیستم ایجاد می کند. سرویس دایرکتوری برای مکان یابی و پیگیری تمامی منابع موجود در سیستم بکار برده می شود. رویس امنیتی امکان محافظت از تمامی انواع منابع را فراهم می آورد، تا فقط افراد تایید شده و مجاز امکان دسترسی به آن را داشته باشند. سرویس های زمان توزیع شده سرویسی است که سعی می کند تمامی ساعت های ماشین های مختلف را همگام و همزمان نگه دارد.

اهداف DCE RPC
اهداف سیستم DCE RPC همان هدف های متعارف است. اول و مهمتر از همه اینکه، این سیستم RPC به مشتری امکان می دهد تا صرفاً با فراخوانی یک روال محلی به سرویس راه دور مورد نظر دسترسی پیدا کند. این واسط باعث می شود تا برنامه های مشتری به روشی ساده و آشنا برای برنامه نویسان نوشته شوند. همچنین، این سیستم موجب تسهیل در اجرای قسمت اعظم کدهای (غیر توزیع شده ) موجود در یک محیط توزیع شده می شود.
سیستم DCE RPC وظیفه دارد تا تمامی جزئیات را از مشتریان و همچنین تا حدودی از خدمتگزارها مخفی نگه دارد. بدین منظور، این سیستم RPC می تواند به طور خودکار خدمتگزار مناب را مکان یابی کرده و سپس ارتباط بین نرم افزار مشتری و خدمتگزار را که به آن پیوند گفته می شود برقرار کند. می تواند کار تبادل پیام را به صورت دو طرفه انجام دهد. می تواند به طور خودکار تبدیل انواع داده بین مشتری و خدمتگزار راحتی در مواردی که فرآیند ها روی معماری های مختلف اجرا می شوند انجام دهد.
اجرای RPC
RPC واقعی به صورت شفاف و به طور معمول انجام می شود. مشتری مجازی به کمک پروتکل انتخابی در زمان اتصال پارامترها را برای کتابخانه زمان اجرا به صف کرده و برای انتقال آماده می کند. هنگامی که پیام به ماشین خدمتگزار می رساند بر حسب نقطه پایانی تعیین شده در پیام ورودی به سمت خدمتگزار صحیح مسیردهی می شود. کتابخانه زمان اجرا پیام را به خدمتگزار مجازی پاس کرده، و آن هم پارامترها را از حالت صف خارج کرده و خدمتگزار را فراخوانی می کند. پاسخ نیز در همان مسیر ازگردانده می شود. موجود در یک محیط توزیع شده می شود. DCE در حالت پیش فرض یعنی معنای حداکثر یک مرتبه هیچ فراخوانی حتی در صورت خرابی سیستم بیش از یک مرتبه انجام نمی شود. این ویژگی در عمل باعث می شود تا چنانچه خدمتگزار در حینRPC خراب و سپس به سرعت ترمیم شود، مشتری مجدداً عملیات را تکرار نخواهد کرد.
در روش دیگر می توان روال مورد نظر را تحت عنوان تکرارشونده نشانه گذاری کرد. در این صورت می توان آن را بدون هیچ اشکالی چندین مرتبه تکرار کرد. در صورتی که یک RPC تکرارشونده به دلیل خرابی خدمتگزار با شکست مواجه شود، مشتری بایستی تا زمان راه اندازی مجدد خدمتگزار صبر کرده و سپس مجدداً تلاش کند.

3-3 ارتباطات پیام گرا
فراخوانی روال راه دور و احضار شئ راه دور در مخفی سازی ارتباطات در سیستم های توزیع شده نقش دارند؛ به این معنی که باعث ارتقاء شفافیت دسترسی می شوند. متاسفانه هیچ سیستمی برای همه موارد مناسب نیست. در برخی موارد که نمی توان اطمینان داشت که طرف دریافت کننده در زمان صدور درخواست در حالاجرا باشد، لزوم وجود سرویس های جایگزین بیش از پیش آشکار می شود.
ارتباطات پیام گرا را می توان به دو دسته: 1* ارتباطات پیام گرای ناپایدار 2*ارتباطات پیام گرای پایدار تقسیم می شود.

3-3-1 ارتباطات پیام گرای ناپایدار
بساری از سیستم های توزیع شده و برنامه های کاربردی مستقیماً بر روی مدل ساده پیامگرای ارائه شده توسط لایه انتقال ساخته شده اند. مساله استانداردسازی واسط لایه انتقال بسیار موردتوجه قرار گرفته تا برنامه نویسان بتوانند به کمک مجموعه ای از عملکردهای پایه ساده از کل مجموعه پروتکل های پیام دهی استفاده نمایند. استفاده از واسط های استاندارد موجب تسهیل انتقال برنامه کاربردی مورد نظر به ماشین دیگر می شود. واسط سوکت. یکی دیگر از واسط های مهم XTI است که قبلاً به نام واسط لایه انتقال شناخته می شد و توسطAT&T ابداع شده است. سوکت ها و XTI از نظر مدل برنامه نویسی شبکه بسیار شبیه یکدیگر هستند، ولی از عملکردهای پایه متفاوتی بهره می برند. از نظر مفهومی سوکت در واقع نقطه پایانی ارتباط بوده و برنامه کاربردی می تواند داده هایی را که باید به شبکه زیربنایی ارسال شوند، در آن بنویسد و داده های ورودی را از آن بخواند و سوکت انتزاعی از ارتباط واقعی بر روی نقطه پایانی است که توسط سیستم عامل محلی برای یک پروتکل انتقال خاص مورد استفاده قرار می گیرد.

واسط تبادل پیام
عملکردهای پایه باید برای تسهیل ایجاد برنامه کاربردی در سطح انتزاعی قابل قبول بوده و پیاده سازی آنها کمترین سرباره را ایجاد کند. سوکت ها به دو دلیل چنان قابلیتی نهداشتندواولاً به دلیل پشتیبانی از عملکردهای پایه ادهsend و receive از نظر سطح انتزاع در موقعیت مناسبی قرار نداشتند. ثانیاًه هدف از طراحی سوکت ها ایجاد ارتباط در سرتاسر شبکه با استفاده از پروتکل های همه منظوره از قبیلtcp/ip بود. به همین دلیل در شبکه هایی که از پروتکل های ارتباطی اختصاصی استفاده می کردند، از قبیل آنهایی که در خوشه های خدمتگزار با کارآیی بالا مورد استفاده قرار می گیرند، مناسب نیستند. این نوع پروتکل ها به واسطی نیاز دارند که بتواند ویژگی های پیشرفته تری از قبیل اشکال مختلف بافر و همگام سازی را مدیریت کند.

3-3-2 ارتباطات پیام گرای پایدار
گروه مهمی از سرویس های میان افزار پیام گرا به نام، سیستم های صف بندی پیام یا میان افزار پیام گرا می باشد.
سیستم های صف بندی پیام پشتیبانی قوی از ارتباطات ناهمگام پایدار را ارائه می دهد. این سیستم ها یک ظرفیت ذخیره سازی میان مدت برای پیام ها را ایجاد می کنند، بدون آن که حتی لازم باشد فرستنده یا گیرنده حین تبادل پیام فعال باقی بمانند. یکی از موارد مهم تفاوت این نوع سیستم ها با سوکت های برکلی و mpi آن است که سیستم های صف بندی پیام نوعاً برای پشتیبانی از تبادلات پیامی مورد استفاده قرار می گیرند که به جای چند میلی ثانیه یا ثانیه، ممکن است چندین دقیقه طول بکشند.
ایده اصلی سیستم های صفبندی پیام آن است که برنامه های کاربردی با درج کردن پیام در صف های خاص باهم ارتباط برقرار کنند. حتی اگر خدمتگزار مقصد در لحظه ارسال پیام فعال نباشد، بازهم این پیام ها به یک سری از خدمتگزارهای ارتباطی ارسال شده، و نهایتاً به مقصد تحویل داده می شوند. در عمل اکثر خدمتگزارهای ارتباطی مستقیماً به یکدیگر متصل هستند. در اصل هر برنام کاربردی صف خاص خود را دارد که دیگر برنامه های کاربردی می توانند به آن پیام ارسال کنند. هر صف فقط بوسیله برنامه کاربردی متناظر با آن قابل خواندن است، ام این امکان هم وجود دارد که چندین برنامه کاربردی یک صف مشترک داشته باشند.
یکی از جنبه های مهم سیستم های صف بندی پیام آن است که به فرستنده فقط این تضمین داده می شود که پیام او در نهایت در صف گیرنده درج خواهد شد. هیچ تضمینی در مورد زمان تحویل پیام و یا حتی اینکه این پیام واقعاً خوانده خواهد شد یا خیر داده نمی شود. این روش اجازه می دهد تا ارتباط سست پیوند در زمان پیاده سازی شود. بنابراین دیگر لزومی ندارد که گیرنده در لحظه ارسال پیام به صف آن در حال اجرا باشد و همچنین لزومی ندارد که فرستنده در لحظه ای که پیام او توسط گیرنده دریافت می شود، فعال باشد. فرستنده و گیرنده می توانند کاملاً به طور مستقل از یکدیگر اجرا شوند. در واقع، هنگامی که یک پیام در صف قرارداده می شود، فارغ از اینکه فرستنده و گیرنده مربوطه در حال اجرا باشد یا خیر، تا زمان برداشته شدن در همانجا باقی خواهد ماند. بر همین اساس، بسته به حالت اجرای فرستنده و گیرنده، چهار احتمال مختلف وجود دارد که در شکل3-4 نشان داده شده.

شکل3-4 چهار ترکیب ارتباط سست پیوند با استفاده از صف

در شکل3-4 الف فرستنده وگیرنده در کل زمان مخابره پیام در حال اجرا هستند. ب، فقط فرستنده در حال اجراست و گیرنده غیر فعال می باشد، به این معنا که در این حالت تحویل پیام غیرممکن است. پ، ترکیب فرستنده غیرفعال و گیرنده در حال اجرانمایش داده شده است. در این حالت، گیرنده قادر به خواندن پیام های ارسالی بوده، اما لزومی ندارد که فرستنده های مربوطه هم در حال اجرا باشند. ت، سیستم حتی در صورت غیر فعال بودن گیرنده و فرستنده باز هم قادر به ذخیره سازی پیام هاست

واسطه پیام
یکی از موارد مهم کاربرد سیستم های صف بندی پیام تلفیق برنامه های کاربردی فعلی و جدید به صورت یک سیستم اطلاعات توزیع شده منسجم و منفرد است. برای چنین تلفیقی لازم است که برنامه های کاربردی قادر به درک پیام های دریافتی باشند. در عمل، این ویژگی باعث می شود تا فرستنده پیام های ارسالی خود را با قالبی همانند گیرنده ایجاد کند. یکی از معایب این روش این است که هر بار که یک برنامه کاربردی جدید به سیستم افزوده می شود، تمامی گیرنده های احتمالی آن طوری تنظیم شوند کهامکان تولید قالب موردنظر فراهم شود. روش دیگری که که در پروتکل های متعارف شبکه مورد استفاده قرار می گیرد، توافق بر سر یک قالب مشترک است. متاسفانه این رهیافت معمولاً در مورد سیستم های صف بندی پیام عملی نیست. مشکل از سطح انتزاعی این سیستم ها ناشی می شود. قالب پیام مشترک فقط در صورتی معنادار و قابل استفاده است که مجموعه فرآیندهایی که از آن قالب استفاده می کنند، واقعاً به اندازه کافی با هم اشتراک داشته باشند.
هدف سیستم های عمومی صف بندی پیام فقط حمایت از کاربران نهایی نیست. یک هدف مهم از ایجاد آنها برقراری امکان ارتباطات پایدار بین فرآیندهاست، مستقل از این که آیا فرآیند در حال اجرا یک برنامه کاربردی کاربر است، یا دسترسی به یک پایگاه داده را بر عهده دارد، و یا به انجام محاسبات مشغول است.

ارتباطات جویبارگرا
سیستم های توزیع شده برای تبادل اطلاعات وابسته به زمان معمولاً از جویباغر داده پشتیبانی می کنند. جویبارهای داده ای را می توان در هر نوع رسانه های پیوسته و گسسته مورد استفاده قرار دارد. از نمونه های جویبارهای داده گسسته می توان به لوله های یونیکس یا اتصالات tcp/ip اشاره کرد. پخش فایل های صوتی غالباً نیازمند ایجاد یک جویبار داده پیوسته بین فایل و وسیله صوتی است. در جویبار های داده پیوسته زمانبندی نقش کلیدی ایفا می کند. برای داشتن زمانبندی مناسب معمولاً بین روش های مختلف انتقال تفاوت وجود دارد.
درحالت انتقال ناهمگام اقلام داده در یک جویبار یکی پس از دیگری ارسال می شوند، اما محدودیت دیگری از نظر زمانبندی وجود ندارد.
در حالت انتقال همگام به ازای هر بسته در جویبار داده یک حداکثر تاخیر انتها به انتها تعریف می شود. انتقال بسته داده با سرعت بیشتر از حداکثر تاخیر قابل تحمل مشکلی ایجاد نمی کند. در حات تبادل متوازن واحدهای داده باید درست سروقت ارسال شوند. این بدان معناست که تبادل داده در معرض نوعی حداکثر و حداقل تاخیر انتها به انتها قرار دارد، که به آن لرزش محدود شده گفته می شود.
جویبارها ممکن است ساده یا پیچیده باشند. جویبار ساده فقط از یک زنجیره داده تشکیل می شود، در حالیکه جویبار پیچیده متشکل از چندین جویبار ساده مرتبط با یکدیگر، موسوم زیرجویبار است. ارتباط بین زیرجویبار پیچیده غالباً وابسته به زمان نیز می باشد. از نقطه نظر سیستم های توزیع شده ، پشتیبانی از جویبارها مستلزم وجود عناصر مختلفی است.

3-4 ارتباطات چند پخشی
یکی از موضوعات مهم در ارتباطات سیستم های توزیع شده پشتیبانی از ارسال داده به چند گیرنده، موسوم به ارتباطات چندپخشی است. همگام با ظهور فن آوری نظیر به نظیر و بویژه مدیریت روی هم گذاری ساخت یافته، راه را برای ایجاد مسیرهای ارتباطی هموارتر شد. از آنجاییکه راه حل های نظیر به نظیر نوعاً در لایه کاربرد پیاده می شوند، تکنیک های چندپخشی سطح کاربرد معرفی شده اند. ارتباطات چندپخشی به روش های دیگری غیر از ایجاد مسیرهای ارتباطی صریح هم می تواند انجام شود.

3-4-1 چندبخشی سطح کاربرد
ایده اصلی در چند پخشی سطح کاربرد این است که گره ها به یک شکل یک شبکه روی هم گذاری سازماندهی شده و سپس برای انتشار اطلاعات به اعضای گروه به کاربرده شوند. یکی از مشاهدات مهم این است که مسیریاب های شبکه به عضویت هیچ گروهیدر می آیند. در نتیجه اتصالات بین گره ها در شبکه روی هم گذاری ممکن است در قیاس با آنچه بوسیله مسیریابی سطح شبکه انجام می شود، بهینه نباشد. یکی از مسائل بسیار مهم ساخت شبکه روی هم گذاری است. در کل، دو رهیافت در این زمینه وجود دارد. در روش اول، گره ها مستقیماً به شکل یک درخت سازماندهی می شوند، که در اینصورت بین هر زوج گره فقط یک مسیر روی هم گذاری وجود خواهد داشت. در روش دوم، گره ها می توانند به صورت یک شبکه مشبک سازماندهی شوند، که در آن هر گره دارای چندین همسایه بوده، و در کل بین هر زوج گره چندین مسیر وجود خواهد داشت. تفاوت اصلی بین این دو رهیافت آن است که روش دوم مقوم تر است. اگر چنانچه یکی از اتصالات (مثلاً در اثر خرابی یک گره) قطع شود، باز هم می توان بدون نیاز به سازماندهی مجدد و فوری کل شبکه روی هم گذاری، اقدام به انتشار اطلاعات کرد.

مدل های انتشار اطلاعات
الگوریتم های همه گیر بر اساس نظریه همه گیری ها استوار است که به مطالعه نحوهه شیوع بیماری های عفونی می پردازد. در مورد سیستم های توزیع شده بزرگ مقیاس این الگوریتم ها به جای پراکندن بیماری ها، باعث پراکندن اطلاعات می شوند. تحقیق در مورد همه گیری ها در سیستم های توزیع شده با هدفی کاملاً متفاوت دنبال می شود: طراحان الگوریتم های همه گیر در سیستم های توزیع شده تلاش می کنند تا تمامی گره ها را با سرعت هر چه تمامتر با اطلاعات جدید آلوده کنند.
با استفاده از اصطلاحات مورد استفاده در بیماری های همه گیر، یک گره که بخشی از یک سیستم توزیع شده محسوب می شود، و اطلاعاتی دارد که می خواهد به گره های دیگر منتشر کند، گره آلوده نامیده می شود. به گرهی که تا کنون این اطلاعات را ندیده است، نیز گره مستعد ابتلا گفته می شود. به همین ترتیب، یک گره که نمی خواهد یا نمی تواند این اطلاعات را توزیع کند، گره سالم خوانده می شود.
یکی از مدل های انتشار معروف مدل ضدآنتروپی است. در این مدل، گرهp یک گره دیگر، Q، را به صورت تصادفی انتخاب کرده و سپس به هنگام سازی ها رابا آن مبادله می کند. سه رهیافت برای تبادل به هنگام سازی ها وجود دارد:
1*P صرفاً به هنگام سازی های خود را به Q می فرستد. (فرستادن)
2* P فقط به هنگام سازی های خود را از Q می گیرد. (کشیدن)
3* P وQ به هنگام سازی های خود را با یکدیگر مبادله می کنند. (فرستادن-کشیدن)
در هنگام نیاز به انتشار سریع به هنگام سازی ها، تنها روش نامناسب از بین سه روش فوق رهیافت اول است. در روش فرستادن، به هنگام سازی ها فقط از طریق گره های آلوده قابل پخش هستند. با این وجود، چنانچه تعداد زیادی از گره ها آلوده شده باشند، احتمال انتخاب یک گره مستعد ابتلا نسبتاً ناچیز خواهد بود. در نتیجه این احتمال وجود دارد که یک گره خاص فقط به این دلیل که توسط یک گره آلوده انتخاب نشده، برای مدت زمانی طولانی در انتظار آلوده شدن بماند.
از سوی دیگر، روش کشیدن آلودگی فقط در صورتی بهترین کارآیی را خواهد داشت که تعداد زیادی از گره ها آلوده شده باشند. در این حالت، پخش به هنگام سازی ها اساساً بوسیله گره های مستعد ابتلا انجام می شود. احتمال زیادی وجود دارد که چنین گرهی با یک گره آلوده تماس برقرار کرده، به هنگام سازی ها را به طرف خود کشیده و آلوده شود.
روش فرستادن-کشیدن باز هم بهترین راهبرد خواهد بود. یک دور به عنوان فاصله زمانی که در آن هر گره حداقل یک بار اقدام به تبادل به هنگام سازی ها با یک گره تصادفاً انتخاب شده دیگر می کند، تعریف می شود.

3-4-2 همگام سازی جویبار
یکی از مسائل مهم در سیستم های چند رسانه ای این است که جویبار های مختلف که احتمالاً به شکل جویبار پیچیده هستند، به صورت دو طرفه همگام سازی می شوند. همگام سازی جویبارها به معنی حفظ روابط زمانی بین جویباره است. دو نوع همگام سازی وجود دارد. ساده ترین شکل همگام سازی بین یک جویبار داده گسسته و یک جویبار داده پیوسته است. برای نممونه، نمایش یک اسلاید همراه با صورت روی وب را در نظر بگیرید. هر اسلاید به شکل یک جویبار اده گسسته از خدمتگزار به مشتری انتقال می یابد. در همان حال مشتری بایدبخش مشخصی از جویبار صوتی را که با اسلاید حاضر هماهنگ است و از خدمتگزار پیش واکشی شده پخش کند. در این حالت جویبار صوتی باید با نمایش اسلایدها همگام شود. همگام سازی در سطح واحدهای داده تشکیل دهنده جویبار انجام می شود. به بیان دیگر، دو جویبار فقط در سطح واحدهای داده قابل همگام سازی هستند. درک واقعی یک واحد داده تا حد زیادی بستگی به سطح انتزاع انتخابی برای مشاهده جویبار داده دارد.

فصل چهارم- تحمل خرابی

4-1 مقدمه ای بر خرابی پذیری
یکی از مشخصه های سیستم های توزیع شده که آن را از سیستم های تک ماشین متمایز می کند، موضوع خرابی جزئی است. خرابی یا نارسایی جزئی زمانی اتفاق می افتد که یکی از اجزاء سیستم توزیع شده از کار بیفتد. این اتفاق می تواند روی کار برخی از اجزاء سیستم تاثیر بگذارد، در حالیکه ممکن است اجزاء دیگر متوجه آن هم نشوند. بر خلاف آن در سیستم های غیر توزیع شده خرابی هر جزء تمامی سیستم را در برمی گیرد، وحتی می تواند به از کار افتادن کل آن بینجامد. یکی از مهمتری جنبه های طراحی سیستم های توزیع این است که سیستم بگونه ای ساخته شود که بتواند بطور خودکار خرابی های جزئی را ترمیم و جبران کند، به قسمتی که کارآیی کل سیستم دچار نقصان جدی نشود. یک سیستم توزیع شده باید بتواند حتی در صورت خرابی جزئی و در زمانی که سیستم در حال تعمیر است، به نحو قابل قبول به کارش ادامه دهد؛ یعنی باید بتواند تا حد معقولی خرابی را تحمل کند. کلیدی ترین تکنیک مقابله با خرابی افزونگی است.

4-1-1 مفاهیم اساسی
خرابی پذیری ارتباط تنگاتنگی با آنچه که با عنوان سیستم قابل اتکا شناخته می شود، دارد. قابلیت اتکا اصلاحی است که چندین ویژگی مفید را پوشش می دهد، از جمله:
1* دسترس پذیری
2* قابلیت اطمینان
3* ایمنی
4* قابلیت نگهداری
دسترس پذیری یعنی اینکه یک سیستم بلافاصله آماده کار باشد. دسترس پذیری را می توان به عنوان احتمال عملکرد صحیح سیستم در یک لحظه خاص در برابر درخواست کاربرانش نیز تقسیم کرد. به عبارت دیگر، هر چه احتمال عملکرد صحیح سیستم در یک لحظه خاص بیشتر باشد، آن سیستم دسترس پذیرتر است.
قابلیت اطمینان به ویژگی یک سیستم برای کارکرد پیوسته و بدون خرابی اطلاق می شود. بر خلاف دسترس پذیری که در یک لحظه خاص تعریف می شود، قابلیت اطمینان بر حسب یک محدوده زمانی سنجیده می شود. هر چه دوره زمانی کارکرد بدون عیب یک سیستم طولانی تر باشد، آن سیستم قابلیت اطمینان بیشتری دارد.
ایمنی به حالتی اطلاق می شود که وقتی یک سیستم بطور موقت از کار می افتد، هیچ اتفاق فاجعه باری رخ ندهد.
قابلیت نگهداری نیز نشان می دهد که تعمیر یک سیستم تا چه حد آسان است. سیستم های با قابلیت نگهداری بالا معمولاً از نظر دسترس پذیری نیز وضعیت مطلوبی دارند، بخصوص اگر بتوانند خرابی ها را بطور خودکار تشخیص داده و رفع کنند. سیستم های قابل اتکا معمولاً به درجات بالایی از امنیت نیز نیاز دارد. وقتی یک سیستم نتواند کاری را که از ان انتظار می رود انجام دهد، اصلاحاً می گویند دچار نقص شده است.
خرابی ها معمولاً به سه دسته تقسیم می شوند: گذرا، متناوب و دائمی.
خرابی گذرا یک بار ظاهر شده و سپس ناپدید می شود. در این حالت با تکرار همان عمل قبلی می توان خرابی را برطرف کرد.
خرابی متناوب ظاهر می شود، سپس خود به خود ناپدید شده و بعد از مدتی دوباره ظاهر می شود و این سیکل همچنان تکرار خواهد شد. خرابی های متناوب واقعاً دردسرساز هستند، چون تشخیص آنها بسیار دشوار است.
خرابی دائمی از لحظه بروز پابرجا می ماند و تا زمانیکه جزء خراب تعویض نشود، ادامه خواهد داشت. قطعات سوخته کامپیوتر، باگ های نرم افزار و یا دیسک هایی که هد آنها خراب شده را می توان به عنوان نمونه هایی از خرابی های دائمی برشمرد.

4-1-2 مدل های خرابی
سیستمی که دچار نقص می شود، دیگر نمی تواند به همان خوبی قبل سرویس هایی را که از آن انتظار می رود، ارائه کند. اگر یک سیستم توزیع شده را مجموعه ای از خدمتگزار ها در نظر بگیریم که با یکدیگر و با مشتریان خود ارتباط برقرار می کنند. عدم ارائه سرویس مناسب یعنی خدمتگزارها یا کانال های ارتباطی آنطور که انتظار می رود کار نمی کنند. برای درک بهتر شدت خرابی روش های تقسیم بندی مختلفی توسعه داده شده اند. که در جدول زیر نشان داده شده است.

جدول 4-1 نوع خرابی با توضیحات
نوع خرابی
توضیح
خرابی فروپاشی
خدمتگزار از کار می افتد ولی تا قبل از آن به خوبی کار می کرده است.
خرابی جا افتادگی
جا افتادگی دریافت
جا افتادگی ارسال
خدمتگزار موفق به پاسخگویی به درخواست های ورودی نمی شود
خدمتگزار موفق به دریافت پیام های ورودی نمی شود
خدمتگزار نمی تواند پیام ها را ارسال کند
خرابی تنظیم زمان
پاسخ خدمتگزار در محدوده زمانی مشخص شده قرار ندارد
خرابی پاسخ
خرابی مقدار
خرابی گذار حالت
پاسخ خدمتگزار نادرست است
مقدار پاسخ خدمتگزار اشتباه است
خدمتگزار از کنترل روند صحیح منحرف می شود
خرابی دلبخواه
خدمتگزار در زمان های دلبخواه پاسخ های دلبخواه تولید می کند.

خرابی فروپاشی وقتی رخ می دهد که خدمتگزار بکلی از کار بیفتد، ولی تا قبل از آن بدرستی کار کرده باشد. مهمترین جنبه خرابی فروپاشی این است که دیگر هیچکس چیزی از این خدمتگزار نخواهد شنید. یکی از رایجترین علل خرابی فروپاشی از کار افتادن خردکننده سیستم عامل خدمتگزار است، که در این حالت فقط یک راه حل باقی می ماند: راه اندازی مجدد کامپیوتر
خرابی جا افتادگی وقتی اتفاق می افتد که یک خدمتگزار نتواند به درخواست ها پاسخ دهد. در اینجا عوامل زیادی می توانند دخیل باشند. در خرابی جا افتادگی دریافت خدمتگزار احتمالاً قادر به دریافت پیام های ورودی نیست. اگر ارتباط خدمتگزار و مشتری مشکلی نداشته باشد، به احتمال زیاد ریسمن شنونده پیام های ورودی در خدمتگزار از کار افتاده است. خرابی جا افتادگی دریافت حالت خدمتگزار را تحت تاثیر قرار نمی دهد چون خدمتگزار اصلاًمتوجه نمی شود که پیامی به آن فرستاده شده است. در خرابی جا افتادگی ارسال خدمتگزار کارش را انجام داده ولی به دلایلی نمی تواند پیام را ارسال کند. سر ریز شدن پشته ارسال پیام در خدمتگزار می تواند یکی از دلایل چنین رویدادی باشد. خرابی های جا افتادگی همیشه از مشکلات مخابراتی ناشی نمی شوند و ممکن است مسائلی از قبیل مدیریت حافظه و یا سایر خطاهای نرم افزاری نیز به چنین وضعیتی منجر شوند.
خرابی تنظیم زمان وقتی رخ می دهد که پاسخ در محدوده زمانی مشخص شده قرار نداشته باشد. ارسال پیش از موقع داده ها می تواند گیرنده را دچار مشکل کند، چون هنوز بافر دریافت آن آماده پذیرش داده های جدید نیست. با این حال خرابی تنظیم زمان بیشتر به تاخیر خدمتگزار در ارائه پاسخ مربوط می شود، که در این حالت گفته می شود کارایی خدمتگزار دچار نقص شده است.
خرابی پاسخ یکی از انواع وخیم خرابی بشمار می رود، که در آن پاسخ خدمتگزار نادرست است. خرابی پاسخ بر دو نوع است: در نوع اول، که به آن خرابی مقدار گفته می شود، پاسخی که خدمتگزار به مشتری می دهد، غلط است.
خرابی گذار حالت خرابی زمانی اتفاق می افتد که پاسخ خدمتگزار به درخواست ورودی غیرمتقربه باشد.
وخیم ترین نوع خرابی خرابی دلبخواه است که به آن خرابی بیزانسی نیز گفته می شود. در اینجا مشتری باید آماده بدترین وضعیت ممکن باشد، بخصوص اگر خدمتگزار پاسخی دهد که هرگز نباید بدهد و تشخیص نادرستی آن نیز ممکن نباشد. خرابی های دلبخواه ارتباط تنگاتنگی با خرابی های فروپاشی دارند. تعریفی که از خرابی فروپاشی کردیم، خوش خیم ترین حالت این نوع خرابی بود، که به آن خرابی نقص-توقف نیز گفته می شود. خرابی توقف بگونه ای است که فرایندهای دیگر می توانند متوجه از کار افتادن خدمتگزار شوند. گاهی خدمتگزار آنقدر خوب طراحی شده که قبل از متوقف شدن به همه اعلام می کند در حال فروپاشی است و گاهی هم به سادگی از کار می افتد.

4-1-3 پوشش خرابی با افزونگی
اگر یک سیستم بخواهد خرابی پذیر باشد، باید کاری کند که فرایندهای دیگر متوجه بروز خرابی در آن نشوند. کلیدی ترین تکنیک در پوشش خرابی استفاده از افزونگی است. سه نوع افزونگی وجود دارد:
1- افزونگی اطلاعات 2- افزونگی زمان 3- افزونگی فیزیکی
افزونگی اطلاعات از بیت های افزوده برای تشخیص بیت های خراب استفاده می شود.. کد همینگ این روش را برای تشخیص و رفع نویز در خطوط انتقال بکار می گیرد.
در افزونگی زمان عملی انجام شده و سپس در صورت نیاز آن عمل تکرار می شود. تراکنش ها در واقع نوعی رهیافت متکی به افزونگی زمان هستند. اگر یک تراکنش لغو شود می توان آن را بدون هیچ مشکلی دوباره اجرا کرد. افزونگی زمان بویژه در خرابی های گذرا و متناوب مفید است.
در روش افزونگی فیزیکی از تجهیزات یا فرایندهای اضافی برای بالابردن مقاومت سیستم در مقابل خرابی اجزاء آن استفاده می شود. افزونگی فیزیکی را می توان در سخت افزار یا نرم افزار انجام داد. افزونگی فیزیکی یکی از روش های شناخته شده دست یابی به خرابی پذیری است. در تجهیزات الکترونیکی نیز افزونگی فیزیکی کاربرد گسترده ای یافته است.

4-2 مسائل طراحی
کلیدی ترین رهیافت برای مقابله با خرابیفرایندها این است که چندین فرایند یکسان را در یک گروه فرایند سازماندهی کنیم و مسئولیت کار را به این گروه بسپاریم. مهمترین ویژگی چنین گروهی آن است که وقتی پیامی به یک گروه فرستاده می شود، همه اعضای این گروه پیام را دریافت خواهند کرد. گروه های فرایند می توانند دینامیک باشند. به عبارت دیگر، گروه های جدید تشکیل شده و گرو هایی که دیگر به آنها نیاز نیست، از بین بروند. فرایندها می توانند به گروه ها پیوسته و یا از آنها جدا شوند. همچنین، یک فرایند می تواند همزمان عضو گروه های متعددی باشد. هدف از معرفی مفهومی بنام گروه این است که فرایندها بتوانند با مجموعه ای از فرایندهای دیگر به عنوان یک واحد تعامل داشته باشد. در این حالت، فرایندها می توانند بدون اینکه فرایندهای عضو یک گروه را بشناسند پیام خود را به آن گروه بفرستند و انتظار پاسخ داشته باشند.

گروه تخت یا گروه سلسله مراتبی؟
یکی از وجوه تمایز مهم گروه ها نحوه سازماندهی داخلی آنهاست. در برخی گروه ها، همه فرایندها مساوی هستند: هیچکس رئیس نیست، و تصمیم ها بصورت دسته جمعی گرفته می شوند. در گروه های دیگر نوعی سلسله مراتب وجود دارد. برای مثال، یکی از فرایندها هماهنگ کننده است و دیگران کارگر هستند و دستورات را اجرا می کنند. هر یک از این سازماندهی ها مزایا ومعایب خاص خود را دارند. گروه تخت (flat) متقارن است و هرگز از یک نقطه ضربه نمی خورد. ویژگی های گروه سلسله مراتبی درست عکس گروه تخت است. یک گروه سلسله مراتبی با از کار افتادن هماهنگ کننده بکلی فلج می شود، ولی تا زمانیکه این هماهنگ کننده فعال باشد، تصمیم گیری ها به سرعت انجام خواهند شد.

عضویت در گروه
وقتی از گروه فرایند استفاده می کنیم باید متدهایی برای ایجاد و از بین بردن گروه ها داشته باشیم، و همچنین یک فرایند باید بتواند به عضویت گروه درآید یا آن را ترک کند. یک رهیافت استفاده از مرکزیتی بنام خدمتگزار گروه است که کلیه درخواست ها به آن فرستاده می شوند. خدمتگزار گروه در هر لحظه لیست کامل گروه ها و اعضای آنها را در اختیار دارد.
روش دیگر این است که مدیریت گروه ها را به صورت توزیع شده انجام دهیم. برای مثال، اگر چند پخشی در سیستم وجود داشته باشد، فرایندهای خارجی می توانند پیام درخواست عضویت خود را به تمامی فرایندهایی که در حال حاضر عضو گروه مورد نظرهستند، بفرستند.
برای ترک گروه هم یک فرایند به سادگی پیام خداحافظی خود را به تمام اعضای گروه می فرستد. ولی مسئله این است که ترک گروه و پیوستن به آن بایستی با پیام های داده ای که در حال مبادله شدن هستند، همگام باشد. به عبارت دیگر، به محض اینکه یک فرایند عضو گروه می شود، بایستی تمامی پیام هایی را که به آن گروه فرستاده می شوند، دریافت کند. همچنین، به محض خروج یک فرایند از گروه، دیگر نباید بتواند هیچ پیامی را از گروه دریافت کند، و یا به اعضای گروه پیام بفرستد. یکی از روش های یکپارچه کردن عضوین ترک گروه با جریان تبادل پیام های داده این است که این عمل را هم به صورت توالی چند پیام درآوریم.

4-2-1پوشش خرابی و تکثیر
گروه فرایند یکی از روش های ساخت سیستم های خرابی پذیری است، و اجازه می دهند تا خرابی یک یا چند فرایند تاثیری روی سرویس دادن آنها به کل سیستم نداشته باشد. اگر یک فرایند را تکثیر کرده و آنها را به صورت یک گروه سازماندهی کنیم، می توانیم احتمال خطر را تا حد زیادی کاهش دهیم. دو روش برای این نوع تکثیر وجود دارد: پروتکل های اولیه -محور و پروتکل های نوشتن تکثیرشده.
در سیستم های خرابی پذیر تکثیر اولیه محور معمولاً به صورت پروتکل اولیه پشتیبان ظاهر می شود، که در آن یکی از نسخه های تکثیری نقش نسخه اولیه را بازی می کند، و کلیه عملیات نوشتن را هماهنگ می کنند. در عمل نسخه اولیه ثابت است، ولی هر یک از نسخه های پشتیبان می توانند جای آن را بگیرند. یکی از مسائل مهم در استفاده از گروه های فرایند برای ایجاد خرابی پذیری درسیستم، تعیین تعداد نسخه های تکثیری مورد نیاز است.

4-2-2تشخیص خرابی
برای پوشش و برطرف کردن خرابی ها ابتدا باید آنها را تشخیص دهیم. تشخیص خرابی نقش کلیدی در خرابی پذیری سیستم های توزیع شده دارد. در یک گروه فرایند، فرایندهای سالم باید بتوانند تشخیص دهند کدام فرایند همچنان عضو گروه است، و کدام نیست. به عبارت دیگر، وقتی یک فرایند خراب می شود باید بتوانیم آن را شناسایی کنیم. وقتی به موضوع شناسایی فرایندهای معیوب می رسیم، اساساً دو مکانیزم بیشتر وجود ندارد: یا اینکه هر فرایند بطور فعال وضعیت فرایندهای دیگر را جویا شود و یا منفعلانه منتظر دریافت پیام از آنها بماند. رهیافت اول فقط زمانی می تواند مناسب باشد که از وجود یک کانال ارتباطی مناسب بین فرایندها مطمئن باشیم. در این قبیل موارد معمولاً از پینگ کردن فرایندها استفاده می شود. کار نظری وسیعی روی موضوع تشخیص خرابی صورت گرفته است، اما همه آنها در یک نقطه به اتفاق نظر می رسند: نوعی مکانیزم تایم اوت برای تشخیص فرایندهایی که از کار افتاده اند. اما در دنیای واقعی، استفاده از این رهیافت دو مشکل بزرگ دارد. اول اینکه، به علت غیر قابل اطمینان بودن شبکه ها، اتکای صرف به عدم دریافت پاسخ پیام پینگ برای صدور حکم از کارافتادگی یک فرایند، نمی تواند همیشه درست باشد. به عبارت دیگر چنین معیاری می تواند به سادگی نتایج مثبت کاذب تولید کند.
یکی از مسائل مهم در طراحی زیر سیستم های تشخیص خرابی این است که آنها باید بتوانند بین خرابی شبکه و خرابی گره ها تفاوت قائل شوند. یک روش این است که تصمیم گیری درباره فروپاشی یک گره را به گروهی از همسایه های آن محول کنیم، نه فقط یک گره. در این روش، وقتی یک فرایند در زمان مشخصی پاسخی برای پینگ خود دریافت نمی کند، به گره های دیگر متوسل شده و از آنها می خواهد تا وضعیت گره مورد نظر را بررسی کنند. وقتی یکی از همسایه ها به پینگ پاسخ ندهد، گره پینگ کننده بلافاصله به حالتی سوئیچ می کند که دیگر به پینگ گره های دیگر پاسخ ندهد. از آنجائیکه هر گره با گره های متعددی تماس دارد، این وضعیت به سرعت کل گروه را به یک حالت هشدار خرابی می برد. سیستم FUSE صدمه آنچنانی از خرابی لینک ها نمی بیند چون در آن برای ارتباط بین اعضای گروه از پروتکل نقطه به نقطه TCP استفاده می شود.

4-3 ارتباط بین مشتری و خدمتگزار
بخش بزرگی از خرابی پذیری سیستم های توزیع شده به موضوع فرایندهای معیوب می پردازد، ولی اشکالات ارتباطی را نیز باید از نظر دور داشت. کانال های ارتباطی نیز می توانند دچار خرابی هایی از نوع فروپاشی، جاافتادگی، تنظیم زمان، و خرابی دلخواه شوند. خرابی های فروپاشی و جا افتادگی در کانال های ارتباطی اهمیت بیشتری دارند، و در ساخت کانال های قابل اطمینان توجه بیشتری به آنها می شود. خرابی دلبخواه بیشتر به شکل ارسال تکراری پیام ها نمود پیدا می کند، چون در شبکه های کامپیوتری پیام ها برای مدتهای نسبتاً طولانی بافر می شوند تا در صورت درخواست از طرف فرستنده بتوان آنها را دوباره ارسال کرد.

4-3-1 ارتباط نقطه به نقطه
در اغلب سیستم های توزعی برای ایجاد ارتباطات قابل اطمینان ا پروتکل های انتقال قدرتمند، مانندTCP ، استفاده می شود. پروتکل TCP می تواند با استفاده از مکانیزم تصدیق دریافت و ارسال مجدد، خرابی جاافتادگی را که به صورت گم شدن پیام ها بروز می کند بخوبی پوشش دهد. این نوع خرابی ها بکلی از دید مشتری TCP پنهان خواهند ماند. با این همه، پروتکل TCP قادر به پوشش خرابی فروپاشی که به صورت قطع ناگهانی و کامل کانال ارتباطی خود را نشان می دهد نیست.

4-3-2 فراخوانی روال راه دور در حضور خرابی
هدفRPC این است که فراخوانی رویه های راه دور را شبیه فراخوانی های محلی کرده و وجود کانال ارتباطی را از دید مشتری پنهان کند. در واقع اگر مشتری و خدمتگزار بدون نقص کار کنند، RPC نیز کار خود را بخوبی انجام خواهد داد. مشکل از جایی شروع می شود که سیستم دچار نقص شود. خرابی های RPC را به پنج دسته تقسیم می کنیم:
1* مشتری قادر نیست خدمتگزار را پیدا کند.
2*پیام درخواست مشتری از خدمتگزار گم می شود.
3*خدمتگزار بعد از دریافت درخواست مشتری، از کار می افتد.
4* پیام پاسخ خدمتگزار به مشتری گم می شود.
5* مشتری بعد از ارسال درخواست، از کار می افتد.
1- مشتری نمی تواند خدمتگزار را پیدا کند
گاهی پیش می آید که مشتری نمی تواند خدمتگزار مناسب را پیدا کند. ممکن است همه خدمتگزارها خاموش باشند. یک علت دیگر ممکن است این باشد که نرم افزار RPC مشتری با کدهای خدمتگزار سازگاری ندارد.
یک راه حل این است که در هنگام بروز چنین خطاهایی یک استثناء صادر شود. در برخی زبان های برنامه نویسی مانند جاوا، برنامه نویس می تواند برای مقابله با برخی خطاهای خاص کد بنویسد. در C نیز می توان از سیگنال ها برای این منظور استفاده کرد. به عبارت دیگر، می توان سیگنال جدیدی مانند SIGNOSERVER تعریف کرد، و برای آن کد نوشت.

2- پیام درخواست گم می شود
دومین دسته از خرابی های مربوط به گم شدن پیام درخواست است، که ساده ترین نوع آن نیز هست: کافیست سیستم عامل یا برنامه کاربردی پس از ارسال درخواست یک تایمر راه اندازی کند. اگر این تایمر قبل از بازگشت پاسخ یا تصدیق دریافت خدمتگزار منقضی شود، پیام دوباره فرستاده می شود. اگر این پیام واقعاً قبل از رسیدن به خدمتگزار از بین رفته باشد، خدمتگزار هیچ تفاوتی بین پیام اولیه و پیام دوباره فرستاده شده نخواهد گذاشت، و همه چیز به خوبی پیش خواهد رفت.

3- خدمتگزار از کار می افتد
سومین دسته از خراب هایRPC وقتی است که خدمتگزار دچار فروپاشی شده باشد. توالی عادی رویدادها در یک خدمتگزار سالم در شکل4-1الف نشان داده می شود: درخواستی از راه می رسد، کار خواسته شده انجام شده و پیام پاسخ برگردانده می شود. اما در قسمت ب درخواستی از راه رسیده و کار خواسته شده انجام می شود، ولی درست قبل از اینکه خدمتگزار بتواند پیام پاسخ را به مشتری برگرداند، از کار می افتد. و در قسمت پ خدمتگزار درخواست مشتری را دریافت کرده، ولی قبل از اینکه بتواند آن را احرا کند، از کار افتاده است و در این حالت هم پاسخی برگردانده نخواهد شد.

4- پیام پاسخ گم می شود
گم شدن پاسخ نیز از آن دسته مشکلاتی است که راه حل ساده ای ندارد. در اینجا هم می توان از همان روش ست کردن تایمر توسط سیستم عامل مشتری استفاده کرد: اگر پاسخ در مدتی معقول و مشخص برنگشت، درخواست یک بار دیگر تکرار می شود. مشکل این رهیافت آن است که مشتری واقعاً دلیل عدم دریافت پاسخ را نمی داند: آیا درخواست مشتری به دست خدمتگزار نرسیده، یا پاسخ خدمتگزار در راه بازگشت گم شده، و یا خدمتگزار هنوز فرصت نکرده درخواست مشتری را اجرا کند.
یک روش حل این مشکل این است که تمامی درخواست ها را به صورت هم توان سازماندهی کنیم. روش دیگر این است که مشتری به هر درخواست خود یک عدد توالی نسبت دهد. یک روش دیگر این است که در سرباره هر پیام یک بیت خاص وجود داشته باشد که درخواست های اولیه را از درخواست های تکراری متمایز کند. ایده اصلی این روش آن است که درخواست های اولیه همیشه باید انجام شوند، اما در اجرای درخواست های تکراری بایستی دقت شود.

5- مشتری از کار می افتد
آخرین دسته از خرابی های RPC فروپاشی مشتری است. چه اتفاقی خواهد افتاد اگر مشتری درخواستی به یک خدمتگزار بفرستد، ولی قبل از دریافت پاسخ از کار بیفتد؟ در این حالت محاسبه ای در جریان است، ولی کسی نیست منتظر پاسخ آن باشد. به چنین محاسبه ناخواسته ای یتیم گفته می شود. یتیم ها می توانند در کار طبیعی سیستم ایجاد اختلال کنند. حداقل این است که آنها توان پردازشیCPU را تلف می کنند. اگر یک یتیم فایل ها یا منابع دیگر سیستم را در اختیار خود گرفته باشد، باعث اتلاف منابع نیز خواهد شد. اگر مشتری پس از راه اندازی مجدد دوباره همانRPC را اجرا کند، یتیم بلافاصله پاسخ می دهد، که این می تواند باعث سردرگمی مشتری شود.

4-4 ارتباط قابل اطمینان بین اعضای گروه
با توجه به اهمیت تکثیر در رجعت فرایندها، جای تعجب نخواهد بود که ایجاد سرویس های چند پخشی قابل اطمینان نیز به همان اندازه مهم باشد. چنین سرویس هایی تضمین می کنند که پیام ها به دست تمامی اعضای گروه برسند. متاسفانه، پیاده سازی سرویس های چندپخشی قابل اطمینان کاری فوق العاده پیچیده است.

4-4-1 روش های ساده چند پخشی قابل اطمینان
یک تعریف ساده می تواند چنین باشد: وقتی یک پیام به گروهی از فرایندها فرستاده می شود، بایستی به دست تمامی آنها برسد. ولی اگر وسط کار فرایند جدیدی وارد گروه شود، چطور؟برای پوشش این قبیل وضعیت ها، بایدبین ارتباط قابل اطمینان در حضور فرایندهای معیوب با ارتباط قابل اطمینان دانسته می شود که بتوانیم تحویل پیام به تمامی اعضای سالم گروه را تضمین کنیم. پیاده سازی این شکل ضعیف چند پخشی قابل اطمینان نسبتاً ساده است، بویژه اگر تعداد اعضای گروه زیاد نباشد. فرایند فرستنده به هر پیام چندپخشی یک عدد توالی نسبت می دهد. فرض می کنیم پیام ها به همان ترتیبی که فرستاده شده اند، دریافت می شوند. با یان روش گیرنده بسادگی می تواند گم شدن پیام ها را تشخیص دهد. فرستنده هرپیام چند پخشی را در بافری موسوم به بافر تاریخچه نگه می دارد. از آنجائیکه فرستنده همه گیرنده ها را می شناسد، با گرفتن تصدیق دریافت پیام (ACK) از هر مشتری، پیام مربوط به وی را از بافر تاریخچه پاک می کند. اگریکی از گیرنده ها متوجه شود که پیامی را از دست داده می تواند با ارسال یک تصدیق دریافت منفی به فرستنده، از وی بخواهد تا آن پیام را دوباره برای وی بفرستد. روش دیگر این است که گیرنده هیچ اقدامی نکند ولی فرستنده بعد از مدتی مشخص در صورت عدم دریافتACK آن پیام را تکرار کند. مشکل اصلی این روش این است که نمی تواند تعداد زیاد گیرنده ها را پشتیبانی کند. اگرNگیرنده داشته باشیم، فرستنده باید آمادگی دریافت حداقلNپیامACK از گیرنده ها را داشته باشدوقتی تعداد گیرنده ها خیلی زیاد می شود، فرستنده زیر بار پیام های بازخورد غرق خواهد شد، پدیده ای که به انفجار باز خورد معروف است. علاوه بر آن باید برای حالتی که گیرنده ها روی یک شبکه گسترده پراکنده اند نیز آمادگی داشته باشیم. راه حل این مشکل این است که لزوم بازگرداندن ACK توسط گیرنده ها را حذف کنیم. به جای آن گیرنده فقط زمانی با فرستنده تماس می گیرد که پیامی را از دست داده باشد.

4-4-2 گسترش پذیری در چند پخشی قابل اطمینان
روش های مختلفی برای چند پخشی قابل اطمینان گسترش پذیر وجود دارد:
1- کنترل بازخورد غیر سلسله مراتبی
2- کنترل بازخورد سلسله مراتبی

4-4-3 چند پخشی تقسیم ناپذیر
برای نشان دادن اهمیت تقسیم ناپذیری، یک سیستم توزیع شده را در نظر بگیرید که از آن برای پیاده سازی یک پایگاه داده تکثیری استفاده شده است. این سیستم توزیع شده دارای امکانات چندپخشی قابل اطمینان است، بویژه می توان با آن گروه های فرایند ساخت که رساندن پیام به آنها با اطمینان صورت گیرد. به همین دلیل این پایگاه داده تکثیری به صورت یک گروه فرایند طراحی و پیاده سازی شده است. عمل های به هنگام سازی را به صورت محلی انجام می دهند.

همگامی مجازی
چندپخشی قابل اطمینان در حضور فرایندهای معیوب را می توان با استفاده از مفاهیم گروه فرایند و عضویت در گروه تعریف کرد.. ایده اصلی در چندپخشی تقسیم ناپذیر این است که هر پیام چند پخشیM بطور منحصر به فرد به گروهی از فرایندها وابسته است که بایستی به آنها نحویل شود. این گروه از فرایندها همان مجموعه ای هستند که فرستنده در لحظه ارسال M به عنوان مقصد می بیند، و به آن نمای گروه گفته می شود. نکته مهم این است که هر فرایند عضو این گروه همان نما را از گروه مشاهده خواهد کرد. به عبارت دیگر، تمام اعضای گروه در هر لحظه توافق دارند که پیام M به کدام فرایندها تحویل شود و به کدام فرایندها خیر.

ترتیب پیام
همگامی مجازی را می توان به نوعی تقسیم زمان به دوره های مختلف، که هر شروع دوره بایک تغییر آرایش در گروه مشخص می شود، تصور کرد. برای یک عمل چندپخشی چهارنوع ترتیب مختلف می توان نام برد:
1- چندپخشی نامرتب
2- چندپخشی با ترتیبFIFO
3- چندپخشی با ترتیب علیتی
4- چند پخشی کاملاً مرتب

1- چندپخشی قابل اطمینان نامرتب نوعی چندپخشی همگام مجازی است که در آن هیچ تضمینی درباره تحویل مرتب پیام ها به فرایندهای گروه داده نمی شود. عمل دریافت تا زمانی که فرایند فراخوانی کننده پیام را تحویل نگرفته باشد، آن را مسدود می کند.
2- در چند پخشی قابل اطمینان با ترتیبFIFO لایه مخابراتی مجبور است پیام های هر فرایند را به همان ترتیبی که ارسال شده اند، به لایه بالاتر تحویل دهد.
3- در چندپخشی قابل اطمینان با ترتیب علیتی لایه مخابراتی پیام ها را به گونه ای تحویل لایه بالاتر می دهد که رابطه علت و معلولی بالقوه بین آنها حفظ شود.
4- تحویل کاملاً مرتب قیدی است افزون بر سه قید دیگر (نامرتب، ترتیب FIFO، و ترتیب علیتی) و تضمین می کند که در هر حالت پیام ها با ترتیب یکسان به تمام فرایندهای عضو گروه تحویل می شوند. اگر یک پروتکل چندپخشی قابل اطمینان همگام مجازی دارای ویژگی تحویل کاملاً مرتب نیز باشد، به آن چند پخشی تقسیم ناپذیر گفته خواهد شد.

4-5 تعهد اجرایی توزیع شده
تعهد اجرایی توزعی یعنی یک عمل یا توسط تمام اعضای یک گروه فرایند اجرا می شود، یا هیچکدام آن را اجرا نمی کنند. در چند پخشی قابل اطمینان، این عمل تحویل پیام است. در سیستم های توزیع شده ، عمل می تواند اجرای یک تراکنش در یک سایت باشد. تعهد اجرایی توزیع شده اغلب توسط یک هماهنگ کننده انجام می شود. در نمونه های ساده این هماهنگ کننده است که به سایر فرایندها که به آنها شرکت کننده گفته می شود، می گوید عملی را به صورت محلی انجام دهند یا خیر. اینروش که به پروتکل تعهد اجرایی یک مرحله ای معروف است، یک عیب آشکار دارد: اگر یکی از شرکت کننده ها نتواند عمل مورد نظر را انجام دهد، راهی ندارد تا به هماهنگ کننده اطلاع دهد.

4-5-1 تعهد اجرایی دو مرحله ای
اولین پروتکل تعهد اجرایی دو مرحله ای یا به اختصار2PC دو مرحله دارنده که هر کدام در دوگام انجام می شوند:
1-هماهنگ کننده یک پیامVOTE_REQUEST (درخواست مشارکت) به تمام شرکت کننده ها می فرستد.
2-وقتی یک شرکت کننده پیام VOTE_REQUEST را دریافت کرد، دو اتفاق می تواند بیفتد: اگر شرکت کننده آماده انجام سهم خود از تراکنش باشد، با یک پیامVOTE_COMMIT (تعهد اجرای مشترک) به هماهنگ کننده پاسخ می دهد؛ در غیر اینصورت، شرکت کننده یک پیامVOTE_ABORT (لغو مشارکت) به هماهنگ کننده برمی گرداند.
3-هماهنگ کننده رای تمام شرکت کننده ها را جمع می کند. اگر همه شرکت کننده ها رای به انجام سهم خود از تراکنش داده باشند، هماهنگ کننده نیز آماده انجام آن می شود.
4- تمام شرکت کننده هایی که انجام سهم خود از تراکنش را متعهد شده اند، منتظر آخرین واکنش هماهنگ کننده می مانند.
مرحله اول (گام های 1و2) مرحله رای گیری است، و مرحله دوم (گام های 3و4) مرحله تصمیم گیری.

4-5-2 تعهد اجرایی سه مرحله ای
پروتکل تعهد اجرایی سه مرحله ای در آن فرایندها در صورت عدم حضور هماهنگ کننده مسدود نمی شوند. در 3pc فرایندها نیز به دو دسته تقسیم می شوند: یک هماهنگ کننده و تعدادی شرکت کننده.
1- اساس پروتکل 3pc بر تحقق دو شرط زیر توسط هماهنگ کننده و شرکت کننده ها استوار است:
1- هیچ حالت واحدی وجود نداشته باشد که بتوان از آن مستقیماً به یکی از حالت ها COMMIT یا ABORT گذار کرد.
2- حالتی وجود نداشته باشد که در آن نتوان به تصمیم نهایی رسید، و بتوان از آن به حالتCOMMIT گذار کرد.
4-6 ترمیم خرابی و برگشت سیستم
ترمیم خطا یکی از مفاهیمی است که نقشی اساسی در خرابی پذیری دارد. خطا آن بخش از سیستم است که می تواند منجر به نقص و خراب شود. ایده اصلی این است که حالت خطا آلود سیستم را با حالتی عاری از خطا جایگزین کنیم. ترمیم خطا بر دو نوع اساسی است: ترمیم پسرو و ترمیم پیشرو.
در ترمیم پسرو مسئله اصلی برگرداندن سیستم از حالت خطا آلود فعلی به حالتی صحیح که در گذشته داشته است. برای این منظور لازم است در فواصل منظم حالت سیستم را ثبت کنیم، تا بتوانیم در صورت خرابی آن را به یکی از این حالتها برگردانیم. هربار که حالت فعلی سیستم یا بخشی از آن ثبت می شود، اصطلاحاً می گوییم یک نقطه بازرسی ایجاد شده است.
ترمیم پیشرو نوع دیگری از ترمیم خطا است که در آن سعی می کنیم تا سیستم را به حالت جدیدی که بتواند بدرستی عمل کند، هدایت کنیم.
تکنیک های ترمیم خطای پسرو به عنوان مکانیزم اصلی برگشت از خرابی در سیستم های توزیع شده پذیرفته شده اند. مزیت اصلی ترمیم خطای پسرو این است که می توان آن را در همه جا بکار برد، و از نوع خرابی مستقل است. به عبارت دیگر، می توان آن را به صورت یک سرویس همه منظوره در سیستم توزیع شده ادغام کرد. بسیاری از سیستم های توزیع شده خرابی پذیر از ترکیب نقاط بازرسی با تکنیک ثبت پیام استفاده می کنند. در این روش، بعد از اینکه نقطه بازرسی ایجاد شد، فرایند فرستنده پیام هایی را که می فرستد ثبت خواهد کرد این روش به ثبت فرستنده محور معروف است. رهیافت دیگر این است که فرایند گیرنده پیام ها را ثبت کند، که به این روش ثبت گیرنده محور گفته می شود. وقتی یک فرایند گیرنده از کار می افتد به آخرین نقطه بازرسی برمی گردد، و پیام های ثبت شده از آن نقطه به بعد را دوباره به لایه برنامه کاربردی می فرستد.

ذخیره سازی پایدار
برای اینکه بتوانیم به یک حالت قبلی برگردیم، باید اطلاعات مربوط به آن حالت را در جایی مطمئن ذخیره کنیم. مطمئن یعنی این ذخیره سازی باید در مقابل فروپاشی فرایند، سایت و حتی رسانه ذخیره سازی مصون باشد. ذخیره سازی پایدار نقش مهمی در ترمیم یستم های توزیع شده بازی می کند. اطلاعات را می توان به سه طریق ذخیره کرد: در حافظه RAM معمولی، روی دیسک های معمولی، و ذخیره سازی پایدار. ذخیره سازی پایدار بطور گسترده مورد مطالعه قرار گرفته و بصورت وسیع در سیستم هایی که به درجات بالایی از خرابی پذیری نیاز دارند استفاده می شود. اگر داده ها را روی چنین دیسک هایی بنویسیم و سپس یک بارآنها را بخوانیم، احتمال از دست رفتن اطلاعات بسیارناچیز خواهد بود.

4-6-2 نقطه بازرسی
برای اینکه بتوانیم در یک سیستم توزیع شده خرابی پذیر ترمیم خطای پسرو داشته باشیم، باید حالت سیستم را در فواصل منظم به صورت پایدار ذخیره کنیم. بویژه باید بتوانیم یک حالت سازگار فراگیر از سیستم که به آن تصویر لحظه ای توزیع شده گفته می شود، را ثبت کنیم. در رهیافت ترمیم خطای پسرو، هر فرایند حالت خود را در فواصل منظم در یک فضای ذخیره سازی پایدار محلی ذخیره می کند. برای برگشت از یک خرابی سیستم یا فرایند، باید بتوانیم با استفاده از این حالت های ثبت شده پراکنده و محلی یک حالت سازگار فراگیر ایجاد کنیم. مهمترین نکته آن است که بتوانیم به آخرین تصویر لحظه ای توزیع شده ، که به آن خط بازسازی گفته می شود، برگردیم. به عبارت دیگر، خط بازسازی عبارتست از آخرین مجموعه سازگار از نقاط بازرسی.

نقطه بازرسی مستقل
هیچ نقطه ای غیر از حالت اولیه نمی تواند به یک حالت سازگار فراگیر منجرشود، و بجز آن خط بازسازی دیگری وجود ندارد. این همان پدیده ای است که آن را به نام اثر دومینو می شناسیم. به این مدل نقاط بازرسی مستقل نیز گفته می شود، چون فرایندها به صورت محلی و مستقل نقاط بازرسی را ایجاد می کنند. برای حل این مشکل می توان ایجاد نقاط بازرسی را به صورت فراگیر مدیریت و هماهنگ کرد، ولی این روش به همگام سازی نیاز دارد و می تواند کارایی سیستم را تحت تاثیر قرار دهد. مهمترین نقطه ضعف روش نقاط بازرسی مستقل در همین مشکل بودن محاسبه خط بازسازی نهفته است، ولی این روش اشکالات دیگری نیز دارد، از جمله اینکه به وسیله ای نیاز داریم تا در فواصل منظم نقاط بازرسی محلی را پاک کند. برای پیاده سازی رهیافت نقاط بازرسی مستقل بایستی بتوانیم وابستگی ها را بگونه ای ثبت کنیم که فرایند ها بتوانند به یک حالت سازگار فراگیر برگردند.

نقاط بازرسی هماهنگ شده
در رهیافت نقاط بازرسی هماهنگ شده فرایندها به صورت هماهنگ حالت خود را ذخیره می کنند. مهمترین مزیت روش نقاط بازرسی هماهنگ شده این است که حالت های ذخیره شده ذاتاً سازگار هستند و دیگر خط برگشت های زنجیره ای وجود ندارد. برای ایجاد نقاط بازرسی هماهنگ شده می توان از الگوریتم تصویر لحظه ای توزیع شده استفاده کرد. این الگوریتم نمونه ای است از هماهنگی غیر مسدود کننده نقاط بازرسی.

4-6-3 ثبت پیام
یکی از تکنیک های مهم در سیستم های توزیع شده ثبت پیام است. ایده اصلی در روش ثبت پیام این است که اگر بتوان ارسال پیام ها را باز پخش کرد. همچنان می توان به یک حالت سازگار فراگیر دست یافت. این رهیافت بر فرضی استوار است که به آن مدل قطعیت بخشی می گویند. در چنین مدلی، فرض بر این است که اجرای فرایندها درفواصل زمانی مشخص صورت می گیرد، و رویدادها در این فواصل زمانی مشخص صورت می گیرد. در مدل قطعیت بخشی، هر فاصله زمانی با رویدادی غیر قطعی مانند دریافت یک پیام، شروع می شود. ولی از آن لحظه به بعد اجرای فرایند بطور کامل قطعی است. یک فاصله زمانی با آخرین رویداد قطعی قبل از رخ دادن رویداد غیرقطعی بعدی پایان می یابد.

4-6-4 محاسبات ترمیم گرا
یکی از روش های ترمیم خرابی این است اساساً همه چیز را از نوع شروع کنیم. ایده بنیادی در این روش پوشش خرابی آن است که بهینه سازی ترمیم خرابی بسیار کم هزینه تر خواهد بود. این روش عمدتاً در سیستم هایی بکار می رود که برای مدت های طولانی بدون اشکال کار می کنند. این رهیافت به محاسبات ترمیم گرا نیز معروف است. انواع مختلفی از محاسبات ترمیم گرا وجود دارد. در یکی از این انواع که کاربرد آن در خدمتگزارهای اینترنت مورد بررسی قرار گرفته به سادگی سیستم یا بخشی از آن مجدداً بوت می شود. برای اینکه بتوانیم فقط بخشی از سیستم را مجدداً بوت کنیم، باید بتوانیم موضع خرابی را به دقت معلوم کنیم. بوت مجدد یعنی حذف تمام موارد اجزای شناسایی شده، حذف تمام ریسمان هایی که روی این اجزاء کار می کنند و اغلب تکرار درخواست های وابسته به آنها. برای اینکه بتوانیم اجزاء مختلف را مستقلا‍ بوت کنیم، لازم است تا آنها را بگونه ای وسیع از یکدیگر تفکیک کنیم و وابستگی بین آنها را به هیچ برسانیم.

فصل پنجم- امنیت

5-1 مقدمه ای بر امنیت
آخرین اصلی که در سیستم های توزیع شده به آن می پردازیم امنیت است. امنیت در سیستم های توزیع شده را می توان به دو بخش تقسیم کرد. بخش اول به ارتباط بین کاربران و فرایندها می پردازد. مهمترین اصل در داشتن ارتباطات ایمن بوجودآوردن کانال های امن بین کاربران و فرایندها می پردازد. مهمترین اصل در داشتن ارتباطات ایمن، بوجودآوردن کانال های امن بین کاربران و فرایندها است.

5-1-1 تهدیدهای امنیتی: سیاست ها و مکانیزم ها
امنیت یک سیستم کامپیوتری ارتباط تنگاتنگی با قابل اتکا بودن آن دارد. طبق تعریف، سیستمی قابل اتکا محسوب می شود که بتواند سرویس های خود را به نحوی مطمئن ارائه کند. یک سیستم قابل اتکا باید دسترس پذیر، قابل اطمینان، ایمن و قابل نگهداری باشد. اما اگر بخواهیم واقعاً به یک سیستم کامپیوتری اطمینان کنیم، باید ویژگی هایی مانند محرمانگی و یکپارچگی را نیز لحاظ کنیم. محرمانگی یعنی یک سیستم کامپیوتری باید اطلاعات خود را فقط برای افراد مجاز فاش کند. یکپارچگی نیز یعنی دستکاری و تغییر در دارایی های سیستم فقط به روش مجاز ممکن باشد. به عبارت دیگر، یک سیستم کامپیوتری امن باید بتواند دستکاری غیر مجاز در دارایی های خود را تشخیص داده و جلوی آنها را بگیرد. مهمترین دارایی های یک سیستم کامپیوتری سخت افزار و نرم افزار و داده های آن است. تهدیدهای امنیتی را می توان به چهار نوع تقسیم کرد.
1- راهزنی
2- گسیختگی
3- دستکاری
4- جعل
1- راهزنی به وضعیتی اطلاق می شود که در ان یک فرد غیر مجاز به سرویس یا داده ها دسترسی پیدا می کند. استراق سمع ارتباطات بین افراد و فرایندهای مجاز یکی از روش های راهزنی است. کپی کردن غیرقانونی فایل ها و دایرکتوری ها توسط نفوذگران نیز نوعی راهزنی محسوب می شود.
2- گسیختگی وقتی اتفاق می افتد که یک فایل خراب شود و یا از بین برود اما بیشتر به وضعیتی گفته می شود که یک سرویس دیگر در دسترس نباشد تخریب شود و یا نتوان از ان استفاده کرد. با این تعریف حملات عدم پذیرش را می توان جزء تهدیدات امنیتی از نوع گسیختگی دسته بندی کرد.
3- دستکاری به تغییر غیر مجاز داده ها یا دستکاری یک سرویس گفته می شود بطوریکه از هدف اولیه آن منحرف شود. حملات دستکاری معمولا با دستبرد شروع می شوند و نفوذگر (بعد از دزدیدن اطلاعات اصلی) آنها را به نفع خود تغییر داده و سپس به سمت گیرنده هدایت می کند.
4- جعل به وضعیتی اطلاق می شود که در ان نفوذگرداده های جدیدی که وجود خارجی ندارند تولیدکرده و به گیرنده می فرستد. اضافه کردن کلمه عبور جدید به یک سیستم (یا اضافه کردن رکوردهای جدید به یک پایگاه داده) نوعی حمله جعل به حساب می آید.
نمی توان یک سیستم امن را صرفاً با گفتن اینکه سیستم باید بتواند با انواع تهدیدهای امنیتی مقابله کند، ساخت. نیاز به سیاست امنیتی دقیق وجود دارد. سیاست امنیتی نشان می دهد که هر موجودیت سیستم چه کارهایی را می تواند انجام دهد، و از چه کارهایی منع شده است. همین که سیاستامنیتی تعیین شده می توان روی مکانیزم های امنیتی تمرکز کرد؛ در واقع، مکانیزم امنیتی روش اجرای سیاست امنیتی است. مهمترین مکانیزم های امنیتی عبارتند از:
1- رمز گذاری
2- احراز هویت
3- کنترل مجوز
4- حسابرسی
1- رمز گذاری نقشی بنیادی در امنیت سیستم های کامپیوتری دارد. رمز گذاری داده ها را بگونه ای تغییر می دهد که افراد متجاوز نتوانند از آنها سر در بیاورند. به عبارت دیگر رمزگذاری یکی از روش های محرمانه نگه داشتن داده هاست
2- از مکانیزم احراز هویت برای اطمینان از هویت اعلام شده توسط کاربر، مشتری، خدمتگزار، میزبان یا هر موجودیت دیگر استفاده می شود. متداول ترین روش برای احراز هویت استفاده از کلمه عبور است.
3- بعد از اینکه هویت مشتری محرز شد باید ببینیم آیا وی مجوز اجرای عمل درخواست شده را دارد یا خیر. برای این منظور از مکانیزم کنترل مجوز استفاده می شود. نوع دسترسی موجودیت های مختلف توسط مجوزهای آنها مشخص می شود.
4- حسابرسی برای تعیین اینکه موجودیت ها از کدام منابع استفاده کرده اند، بکار برده می شود. گزارشات حسابرسی وسیله ای بسیار مفید رای تحلیل نقاط ضعف امنیتی سیستم است، و می توان به کمک آنها اقدامات بعدی علیه متجاوزان را مشخص کرد.

5-1-2 مسائل طراحی
هر سیستم توزیع شده باید دارای سرویس های امنیتی باشد که بتوانند سیاست های امنیتی آن را پیاده سازی کنند. سه نکته مهم در طراحی یک سرویس امنیتی قرار دارد: تمرکز کنترل، لایه بندی مکانیزم های امنیتی، و سادگی

تمرکز کنترل
وقتی با مسئله حفاظت از یک برنامه کاربردی مواجهیم سه رهیافت کلی وجود دارد:
1- اولین رهیافت مستقیماً بر حفاظت از داده های برنامه تمرکز می کند. منظور از مستقیم این است که هدف اصلی ما اطمینان از یکپارچگی داده هاست. این نوع سیستم معمولاً در سیستم های پایگاه داده که از قیدهای مختلف برای حفظ یکپارچگی داده ها استفاده می کنند، بکار برده می شود.
2-در رهیافت دوم عمل های مجاز روی داده ها بطور دقیق مشخص می شوندو عمل های تعریف نشده بکلی رد خواهند شد. در این رهیافت تمرکز اصلی ما روی مکانیزم های کنترل دسترسی است.
3- رهیافت سوم مستقیماً بر کنترل کاربران تمرکز می کند و وقتی مجوز دسترسی به یک کاربر داده شد، وی می تواند هر عملی روی داده ها انجام دهد. سیستم های پایگاه داده مالی و بانکی از این رهیافت برای محدودکردن دسترسی های غیر مجاز استفاده می کنند.

لایه بندی مکانیزم های امنیتی
یکی از مسائل مهم طراحی سیستم های امن این است که مکانیزم های امنیتی را در کدام لایه یا سطح قرار دهیم. سازماندهی لایه ای سیستم های توزیع شده به لایه های برنامه های کاربردی، میان افزار، سرویس های سیستم عامل و هسته سیستم عامل تقسیم می شود. ترکیب این دو سازماندهی لایه ای به چیزی شبیه
شکل 5-1 تبدیل می شود.

شکل5-1 سازماندهی منطقی یک سیستم توزیع شده به چند لایه

در سازماندهی شکل5-1 سرویس های همه منظوره از سرویس های ارتباطاتی جدا شده اند. این جداسازی برای درک امنیت در سیسیستم های توزیع شده و بویژه مفهوم اعتماد بسیار حائز اهمیت است. اینکه مکانیزم های امنیتی را در کدام لایه قرار دهیم بستگی به این دارد که کاربر آنها را در کدام لایه امن تر بداند. در سیستم های توزیع شده ، مکانیزم های امنیتی در لایه میان افزار قرار داده می شوند. اگر آلیس حتی به SSL اعتماد نداشته باشد، می تواند از سرویس RPC امن استفاده کند. در این مورد هم آلیس به سرویس RPC اعتماد می کند، و آن را برای احراز هویت خدمتگزار و مشتری کافی می داند. زمانی واقعاً می توان به سرویس های امنیتی که در لایه میان افزار یک سیستم توزیع شده قرار داده می شوند، اعتماد کرد که خود آنها از سرویس های امن استفاده کرده باشند.

توزیع مکانیزم های امنیتی
وابستگی بین سرویس ها از نظر اعتماد به نظریه ای موسوم به پایگاه محاسباتی معتمد منجر می شود. یک TCB مجموعه ایست از تمامی مکانیزم های امنیتی در یک سیستم کامپیوتری که برای اعمال سیاست امنیتی مورد نیاز هستند و باید به آنها اعتماد کرد. هر چه TCB کوچکتر باشد، بهتر است. اگر سیستم توزیع شده بهصورت لایه میان افزاری روی یک سیستم عامل شبکه بنا نهاده شده باشد، امنیت آن به احتمال زیاد به امنیت سیستم عامل زیربنایی وابسته خواهد بود. به عبارت دیگر، TCB می تواند شامل سیستم عامل محلی کامپیوترها نیز باشد. یک خدمتگزار فایل که در یک سیستم عامل شبکه بنا نهاده شده باشد.
بنابراین سیستم های توزیع شده میان افزار محور باید بتوانند به سیستم عامل محلی خود اعتماد کنند. اگر چنین اعتمادی وجود نداشته باشد، آنگاه می توان بخشی از عملکرد سیستم عامل محلی را به داخل سیستم توزیع شده منتقل کرد.

سادگی
یکی دیگر از نکات مهم در تصمیم گیری برای تعیین لایه ای که مکانیزم های امنیتی در آن قرار گیرند، سادگی است. طراحی یک سیستم کامپیوتری امن اصلاً کار ساده ای نیست. در نتیجه، هرچه مکانیزم های بکارگرفته شده کمتر و ساده تر باشند، بهتر خواهد بود. متاسفانه، در پیاده سازی سیاست های امنیتی مکانیزم های ساده همیشه بهترین نتیجه را بدست نمی دهند. برنامه های کاربردی ذاتاً موجودات پیچیده ای هستند، و اضافه کردن مکانیزم های امنیتی فقط آنها را پیچیده تر خواهد کرد. سیستم های پرداخت دیجیتالی نمونه ای از برنامه های کاربردی هستند که از پروتکل های امنیتی بسیار پیچیده تر خواهد کرد. درچنین سیستم هایی بسیار مهم است که مکانیزم های زیربنایی مورد استفاده در پیاده سازی پروتکل های امنیتی نسبتاً ساده و قابل درک باشند. سادگی یک سیستم با اعتماد کاربران به آن نسبت مستقیم دارد.

5-1-3 رمز نگاری
تکنیک های رمز نگاری نقش کلیدی در امنیت سیستم های توزیع شده دارند. ایده اصلی رمز نگاری ساده است. ایده اصلی رمز نگاری ساده است. فرض کنید فرستندهS می خواهد پیام M را به گیرنده R بفرستد. برای حفاظت از این پیام در مقابل تهدیدهای امنیتی، فرستنده پیام خود را به صورت یک پیام نامفهوم M رمز گذاری می کند و سپس M را به گیرنده R می فرستد. پس از دریافتRوM باید آن را رمز گشایی کند تا بتواند پیام اولیه M را بخواند.
برای پارامتری کردن رمز گذاری و رمز گشایی از عناصری موسوم به کلید استفاده می شود. وقتی پیامی به صورت رمز متنC فرستاده می شود، سه نوع تهدید مختلف هست که باید با آنها مقابله کنیم، و رمز گذاری چنین کاری را برای ما انجام می دهد. اول اینکه ممکن است متجاوز فقط پیام ها را را استراق سمع کنده که در این حالت فرستنده یا گیرنده هیچکدام متوجه آنچه اتفاق می افتد، نخواهند شد.
نوع دیگر حمله تغییر دادن محتویات پیام هاست. دستکاری پیام های متن آشکار ساده است؛ ولی تغییر دادن متنی که بخوبی رمز شده باشد، کار چندان ساده ای نیست، چون متجاوز ابتدا باید رمز متن را رمزگشایی کرده، آن را تغییردهد، سپس دوباره متن را رمزگذاری کرده و به گیرنده بفرستد.
سومین نوع حمله ارسال پیام های جعلی بهگیرنده Rاست، بگونه ای که گیرنده تصور کند که آنها از سوی فرستندهSفرستاده شده اند. یکی از تفاوت های اساسی در سیستم های رمزنگاری این است که کلیدهای رمزگذاری و رمزگشایی یکسان باشند یا نباشند. در یک سیستم رمزنگاری متقارن کلیدهایی که پیام ها را رمزگذاری و رمزگشایی می کنند، یکسان هستند. به عبارت دیگر سیستم های رمزنگاری متقارن به نام سیستم های کلیدمخفی یا کلید مشترک نیز شناخته می شوند، چون در آنها فرستنده و گیرنده هردو از یک کلید استفاده می کنند و برای حفظ امنیت پیام ها این کلید بایستی مخفی بماند و هیچکس دیگری نباید آن را ببیند. برای این سیستم از نمادKA,B استفاده می کنیم، که نشان می دهد کلید بینAوBمشترک است.
سیستم رمزنگاری نامتقارن از کلیدهای رمزگذاری و رمز گشایی متفاوت استفاده می کند، ولی هر دو کلید با هم یک زوج منحصر بفرد را تشکیل می دهند. به عبارت دیگر، هر پیام دو کلید KE برای رمزگذاری و KD برای رمزگشایی خواهد داشت بگونه ای که:
P=DKD (EKE (P)) در سیستم رمزنگاری نامتقارن، یکی از کلیدها خصوصی نگه داشته می شود، ولی کلید دیگر را می توان در اختیار همگان قرار دارد، به همین دلیل به سیستم های رمزنگاری نامتقارن سیستم کلید عمومینیز گفته می شود.

سیستم های رمزنگاری متقارن : DES
اولین نمونه از الگوریتم های رمزنگاری که مورد بررسی قرار می دهیم، استاندارد رمزگذاری داده یا به اختصار DESنام دارد. DES که یک سیستم رمزنگاری متقارن است، روی بلوک های داده 64بیتی کار می کند. الگوریتم DES هربلوک 64بیتی ورودی را در 16دور، که هردور یک کلید رمزگذاری 48بیتی متفاوت دارد، به خروجی رمز 64 بیتی تبدیل می کند. هریک از این16 کلید48بیتی از یک کلید56بیتی اصلی مشتق می شوند. بلوک ورودی قبل از اینکه وارد مراحل 16گانه رمزگذاری شود، تقلیب می شود؛ بعد از 16دور رمز گذاری یک تقلیب دیگر نیز روی آن انجام می گیرد تا خروجی نهایی بدست می آید.
اصول DES چندان پیچیده نیست، ولی شکستن این الگوریتم با استفاده از روش های تحلیلی بسیار دشوار است. DES سه بار متوالی با ترتیب رمزگذاری، رمزگشایی، رمزگذاری و با سه کلید متفاوت به کار برده شود، امنیت بسیار بالایی خواهد داشت. این روش که به آن DES سه گانه یا3DES گفته می شود، هنوز هم بطور وسیعی مورد استفاده است.

سیستم های رمزنگاری کلید عمومی: RSA
دومین نمونه از الگوریتم های رمزنگاری که کاربرد گسترده ای در سیستم های کلید عمومی دارد، RSA نامیده می شود. امنیت الگوریتم RSA از این حقیقت ناشی می شود که هیچ روش موثری برای تجزیه اعداد بزرگ به عوامل اول نمی شناسیم. در الگوریتم RSA، هرکلید خصوصی و عمومی از دو عدد اول بسیار بزرگ ساخته می شوند. شکستن کلیدهای RSA مستلزم یافتن این دو عدد اول است. یکی از نقاط ضعف RSA نسبت به سیستم های رمزنگاری متقارن مانندDES پیچیدگی محاسبات آن است. معلوم شده که بسته به تکنیک های بکار رفته رمزگذاری پیام با الگوریتم RSA صدتا هزار بار کندتر از DES است. به همین دلیل از RSA بیشتر برای مبادله مطمئن کلیدهای مشترک استفاده می شود، و پیام های معمولی کمتر به این روش رمزگذاری می شوند.
5-2 کانال های امن
تامین امنیت سیستم های توزیع شده اساساً به دو مسئله عمده خلاصه می شود. مسئله اول چگونگی برقراری ارتباط امن بین مشتری و خدمتگزارهاست. برای داشتن یک ارتباط امن لازم است دو طرف هویت خود را به روشنی مشخص کنند. در اغلب موارد یکپارچگی پیام ها و محرمانه نگه داشتن آنها نیز ضروری است. محافظت از ارتباطات بین گروهی از خدمتگزارها را می توان بخشی از این مسئله محسوب کرد.
مسئله دوم کنترل مجوزهای مشتری است: بعد از اینکه خدمتگزار درخواست مشتری را پذیرفت، چگونه می تواند مطمئن شود که این مشتری مجوز اجرای عمل درخواست شده را دارد؟برای محافظت ارتباطات بینمشتریان و خدمتگزارها می توان از کانال امن استفاده کرد. یک کانال امن فرستنده وگیرنده را در مقابل راهزنی، دستکاری و جعل پیام ها محافظت می کند، اما الزاماً تاثیری روی حملات گسیختگی ندارد. کانال های امن محرمانه هستند و قابل استراق سمع نیستند، بنابر این می توانند در مقابل حملات راهزنی مقاومت کنند. برای محافظت در مقابل حملات دستکاری و جعل، کانال های امن از پروتکل های احراز هویت متقابل و یکپارچگی پیام استفاده می کنند.

5-2-1 احراز هویت
احراز هویت و یکپارچگی پیام همیشه باید باهم باشند. در اغلب پروتکل ها این ترکیب به صورت زیر انجام می شود. بعد از اینکه احراز هویت انجام شد، اغلب برای اطمینان از حفظ یکپارچگی پیام ها از رمز نگاری کلید مخفی با کلید نشست استفاده می شود. کلید نشست یک کلید مخفی مشترک است که برای رمز کردن پیام ها و حفظ یکپارچگی و احتمالاً محرمانگی آنها به کار می رود. کلید نشست فقط تا زمانی که کانال ارتباطی برقرار است اعتبار دارد؛ بعد از بسته شدن کانال ؛ کلید نشست وابسته به آن دور انداخته می شود.

5-2-2 یکپارچگی پیام و محرمانگی
علاوه بر احراز هویت، یک کانال امن باید یکپارچگی پیام ها و محرمانگی آنها را تضمین کند. یکپارچگی پیام یعنی کسی نتواند پیام ها را دستکاری کند؛ محرمانگی نیز یعنی اطمینان از اینکه کانال ارتباطی از دستبرد مصون است، و پیام ها استراق سمع نمی شوند. رسیدن به محرمانگی کار چندان سختی نیست: کافیست پیام ها را قبل از ارسال رمزگذاری کنیم تا محرمانه بمانند.

کلید نشست
بعد از پایان مرحله احراز هویت در برقراری کانال امن، معمولاً طرفین ارتباط از یک کلید نشست مشترک محصر به فرد استفاده می کنند؛ پس از بسته شدن کانال این کلید به روش های امن دور انداخته می شود. یک رهیافت دیگر این است که از همان کلیدهایی که برای بازکردن کانال بکار رفته اند، برای رمزگذاری پیام ها نیز استفاده می شود. استفاده از کلیدهای نشست مزایای مهمی دارد: 1- اول اینکه شکستن کلیدهایی که به دفعات بکار گرفته می شوند، ساده تر است. ایده اساسی این است که اگر نفوذگر بتواند مقدار زیادی از اطلاعات را که با یک کلید واحد رمزگذاری شده اند، استراق سمع کند، احتمال اینکه بتواند به برخی مشخصات این کلید پی ببرد و آن را بشکند، بسیار بیشتر خواهد شد. 2- استفاده از کلیدهای نشست یک بار مصرف باعث مصونیت کانال امن در مقابل حملات باز پخش خواهد شد. چون نفوذگر دیگر قادر نیست همه نشست ها را بازپخش کند. برای محافظت از تک تک پیام نیز می توانیم از تمهیداتی مانندبرچسب زمانی یا شماره توالی و قرار دادن آنها در دلپیام استفاده کنیم.

5-2-3 ارتباطات گروهی امن
در یک سیستم توزیع شده اغلب لازم است که ارتباط امنی بین چندین طرف برقرار شود. این نوع ارتباط چند طرفه امن، خدمتگزارهای تکثیری هستند که گاهی لازم است مبادله اطلاعات بین آنها درست مثل کانال های امن دوطرفه در مقابل تهدیداتی مانند استراق سمع، دستکاری و جعل محافظت شود.

5-3 کنترل دسترسی
در مدل مشتری خدمتگزار، وقتی مشتری یک کانال امن با خدمتگزار برقرارکرد، می تواند درخواست هایش را به خدمتگزار بفرستد. اماوقتی برای اجرای یک درخواست نیاز به مصرف منابع باشد، خدمتگزار آن راکنترل می کند. کنترل خدمتگزار شامل این می شود که آیا مشتری مجوز دسترسی مناسب به منبع خواسته شده را دارد یا خیر. احراز هویت یعنی صدور مجوز دسترسی برای یک مشتری یا کاربر در مقابل، فرایند کنترل مجوز دسترسی که به اختصار به آن کنترل دسترسی گفته می شود، صحت این مجوزها را چک می کند. احراز هویت و کنترل دسترسی ارتباط تنگاتنگی با یکدیگر دارند، و حتی اغلب به جای یکدیگر برده می شوند. یکی از مهمترین ابزارهای کنترل دسترسی به منابع یک سیستم توزیع شده استفاده از دیواره آتش است.
کنترل دسترسی به یک شئ یعنی حفاظت از آن در مقابل فراخوانی از طرف آنهایی که مجاز به این کار نیستند. این حفاظت گاهی شامل مسائل مدیریتی نیز می شود. حفاظت از اشیاء اغلب توسط برنامه ای موسوم به ناظر ارجاع اعمال می شود. ناظر ارجاع فهرستی از عمل های مجاز هر فاعل روی اشیاء موجود در اختیار دارد، و بر اساس آن تصمیم می گیرد که آیا فاعل خاص مجاز به اجرای عمل درخواست شده روی شئ مورد نظر هست یا خیر. سیستم عامل مسئول باهر درخواست عمل روی یک شئ ناظر ارجاع را فراخوانی می کند. به همین دلیل بسیار مهم است که خود این ناظر ارجاع دخل و تصرف ناپذیر باشد؛ به عبارت دیگر، نفوذگران نباید بتوانند آن را فریب بدهند.

ماتریس کنترل دسترسی
یکی از رهیافت های مدل سازی مجوزهای دسترسی فاعل ها به اشیاء ایجاد یک ماتریس کنترل دسترسی است. هر سطر این ماتریس نماینده یک فاعل است، و ستون های ماتریس نیز نشان دهنده اشیاء هستند. اگر ماتریس کنترل دسترسی را با M نشان دهیم، آنگاه عنصر M[s,o] دقیقاً نشان می دهد که فاعلs اجرای متدm را روی شئ o درخواست می کند، ناظر ارجاع باید چک کند که آیا m در m[s,o] ثبت شده است یا خیر.
یک رهیافت متداول برای پیاده سازی ماتریس کنترل دسترسی این است که هر شئ لیستی از فاعل های مجاز و مجوزهای دسترسی هر یک از آنها را داشته باشد. به بیان دیگر، ماتریس کنترل دسترسی به صورت ستونی در میان تمام اشیاء توزیع می شود، که با این کار عنصرهای خالی از بین خواهند رفت. این رهیافت پیاده سازی ماتریس کگنترل دسترسی به لیست کنترل دسترسی یا به اختصار ACL معروف است.

دامنه حفاظتی
پیاده سازی ماتریس با استفاده از روش های ACL و لیست توانمندی ها، با حذف عناصر خالی ماتریس، بسیار بهینه و موثر است. یکی از روش های متداول کوچک کردن اندازه ACL استفاده از دامنه های حفاظتی است. یک داونه حفاظتی مجموعه ایست از زوج های شئ مجوز دسترسی که دقیقآ نشان می دهند چه اعمالی را می توان روی یک شئ خاص انجام داد. درخواست های انجام یک عمل همیشه در داخل یک دامنه صادر می شوند. بنابراین، وقتی یک فاعل اجرای عملی روی یک شئ را درخواست می کند، ناظر ارجاع ابتدا دامنه حفاظتی متناظر با آن درخواست را مشخص می کند. پس از مشخص شدن دامنه حفاظتی، ناظر ارجاع می تواند چک کند که آیا این درخواست مجاز هست یا خیر.

5-3-1 دیوار آتش
با استفاده از تکنیک های رمزنگاری، همراه با ماتریس کنترل دسترسی می توان از اشیاء حفاظت کرد. اما این روش ها فقط تا زمانی کارایی دارند که همه طرف های ارتباط به قوانین پایبند باشند. در عمل حفاظت از منابع یک سیستم توزیع شده در مقابل دسترسی های خارجی توسط نوع خاصی از ناظر ارجاع موسوم به دیواره آتش انجام می شود. مهم ترین وظیفه دیوار آتش ایزوله کردن همه بخش های یک سیستم توزیع شده ازدنیای خارج است. همانند شکل 5-2 تمام بسته های خروجی و از آن مهمتر همه بسته های ورودی به کامپیوتر خاصی هدایت شده و در آنجا بازرسی می شوند. تمام بسته های خروجی و از آن مهمتر همه بسته های ورودی به کامپیوتر خاصی هدایت شده و قبل از عبور در آنجا بازرسی می شوند. بسته های عبوری غیرمجاز دور انداخته شده، و نمی توانند به راه خود ادامه دهند. نکته مهم این است که خود دیوار آتش باید در مقابل هر نوع تهدید امنیتی حفاظت شده باشد: دیوار آتش نباید هرگز از کار بیفتد.

شکل5-2 روش متداول پیاده سازی دیوار آتش

دو نوع مختلف از دیوار آتش وجود دارد، که اغلب با یکدیگر ترکیب می شوند. دیوار آتش نوع اول دروازه فیلترکننده بسته نام دارد، که به صورت یک مسیر یاب عمل کرده و بر اساس آدرس مبدا و مقصد بسته های شبکه که در سرایند بسته ها وجود دارد تصمیم می گیرد که آنها را عبور دهد یا خیر. معمولاً آن دروازه فیلتر کننده بسته که در LAN بیرونی قرار دارد، حفاظت در مقایل بسته های ورودی را بر عهده دارد، و آن دروازه ای که در LAN داخلی قرار گرفته، بسته های خروجی رافیلتر می کند.
دیوار آتش نوع دوم دروازه سطح برنامه کاربردی است، که در واقع محتویات بسته های ورودی و خروجی را چک می کند. یک دروازه ایمیل که ایمیل های ورودی یا خروجی را بر اساس فرستنده/ گیرنده یا حجم آنها فیلتر می کند، نمونه ای از این دروازه است. انواع پیشرفته ای از دروازه های ایمیل وجود دارند که می توانند بطور خودکار هرزنامه را تشخیص داده و فیلتر کند.
نوع خاصی از دروازه سطح برنامه کاربردی وجود دارد، که به آن دروازه پروکسی گفته می شود. این نوع دیوار آتش به عنوان خط مقدم برخی از برنامه های کاربردی خاص عمل می کند و تضمین می کند که فقط پیام هایی با معیارهای خاص بتوانند عبور کنند. وب گردی یکی از مواردی است که در آن از دروازه پروکسی استفاده می شود.

حفاظت هدف
با اینکه حفاظت از کدهای سیار در مقابل میزبان های بدجنس اهمیت دارد، اما همواره توجه بیشتری به حفاظت از میزبان ها در مقابل کدهای سیار مخرب شده است. کاربران همواره می توانند برای انجام کارهای خود به روش های دیگریمتوسل شوند؛ اما هیچ راه دیگری برای جلوگیری از ورود عامل ها به یک سیستم وجود نداد، مگر اینکه آن را بکلی از دنیای خارج ایزوله کنیم.
یکی ازرهیافت های حفاظت سیستم در مقابل کدهای سیار، ایجاد حصار به دور آنهاست. حصار تکنیکی است که به کمک آن دستورات برنامه بارگیری شده در شرایطی کاملاً کنرل شده اجرا خواهند شد. اگر این برنامه بخواهد دستوری را اجرا کند که از نظر میزبان ممنوع باشد، اجرای آن بلافاصله متوقف می شود. دسترسی به نقاط حساس سیستم مانند برخی ثبات ها و نقاط حافظه نیز منجر به توقف اجرای برنامه خواهد شد.
روش دیگر این است که دستورات برنامه را در هنگام بارگیری آن چک کنیم، ویا اگر چک کردن برخی از دستورات بدون اجرای آنها ناممکن باشد، برای کنترل آنها دستورات اضافی در برنامه داخل کنیم.
دومین جزء از یک حصار جاوا چک کننده سلامت بایت کد است، که تبعیت کلاس های بارشده از اصول امنیتی حصار را چک می کند. چک کردن کدهای مرتبط با حافظه و پشته و اطمینان از اینکه دستورات غیر مجاز در آنها وجود ندارد. مهمترین بخش از وظایف چک کننده سلامت بایت کد است. فقط آنهایی که از خدمتگزار های خارجی دریافت می شوند، بایستی حتماً چک شوند.

5-3-2 عدم پذیرش سرویس
کنترل دسترسی یعنی اطمینان از اینکه فقط فرایندهایی که مجاز هستند به منابع دسترسی پیدا کنند. اما نوع حمله مرتبط با کنترل دسترسی هست که حتی اجازه نمی دهد این فرایندهای مجاز به منابع دسترسی یابند. در سیستم های توزیع شده که از طریق اتصال به اینترنت مرزهای خود را باز می کنند، دفاع درمقابل این نوع حمله که به آن حمله عدم پذیرش سرویس یا به اختصار حمله DOS گفته می شود، روز به روز اهمیت بیشتری می یابد. اگر حمله DOS از یک یا چند منبع محدود منشاءبگیرد، مقابله با آن چندان دشوار نیست؛ اما دفاع در مقابل حملات DDOS می تواند بسیار دشوارتر باشد. در حملات DDOS گروه بزرگی از فرایندها می کوشند تا دراتحاد با یکدیگر یک سرویس شبکه را از کار بیندازد.
حمله DOS به دو نوع تقسیم می شود: 1- تهی سازی پهنای باند 2- تهی سازی منابع
برای اجرای یک حمله تهی سازی پهنای باند، حمله کنندگان تعداد زیادی پیام به ماشین می فرستند. تعداد زیاد پیام های جعلی روی پهنای باند محدود خدمتگزار هدف باعث می شود تا اغلب پیام های واقعی نتوانند به مقصد برسند.
درحمله تهی سازی منابع، حمله کنندگان می کوشند تا منابع ماشین هدف را صرف پردازش پیام های بی ارزش کنند. یکی از تکنیک های شناخته شده حمله تهی سازی منابع، به غرقابTCP SYN معروف است. در این روش، حمله کننده تعداد زیادی اتصال TCP با خدمتگزار برقرار می کند
5-4 مدیریت امنیت
بسیاری از سیستم های امن از سرویس های مخصوی مانند مرکز توزیع کلید یا مرجع صدور گواهینامه استفاده می کنند. سرویس های امنیتی باید از دسترس پذیری بالایی برخوردار باشند. راه حل دستیابی به دسترس پذیری بالا استفاده از تکنیک های تکثیر است. کنترل مجوز های دسترسی یکی از بخش های مهم در امنیت سیستمهای توزیع شده است. در یک سیستم توزیع نشده مدیریت مجوزهای دسترسی کاری نسبتاً ساده است. وقتی در چنین سیستمی یک کاربر جدید ایجاد کنیم، مجوزهای اولیه (مانند مجوز ایجاد فایل و دایرکتوری، مجوز ایجادت فرایند، مجوز استفاده از زمانCPU و غیره) بطور خودکار به وی داده خواهند شد. در یک سیستم توزیع شده کار پیچیده تر است، چون منابع در ماشین های متعدد و مختلف پراکنده شده اند. اگر برای نگهداری و مدیریت شناسه های کاربری یک خدمتگزار مرکزی داشته باشیم، اوضاع کمی ساده تر خواهد شد. هرگاه کاربری قصد استفاده از یک منبع را داشته باشد، مجوزهای وی را یا این خدمتگزار مرکزی چک خواهد شد.

واگذاری مجوز
واگذاری مجوزهای دسترسی یکی از تکنیک های مهم در حفاظت از کامپیوتر ها وسیستم های توزیع شده است. اگر بتوانیم مجوزهای دسترسی خاصی را از یک فرایند به فرایند دییگر منتقل کنیم، توزیع کارها بین فرایندهای مختلف ساده تر خواهد شد. در سیستم های توزیع شده بسیار امکان دارد که فرایندها در ماشین های مختلفو حتی در دامنه های سرپرستی مختلف پراکنده شده باشند.
روش های مختلفی برای پیاده سازی واگذاری مجوز وجود دارد. یکی از این روش ها استفاده از پروکسی است. پروکسی عبارتست از از یک نشانه که به دارنده آن اجازه می دهد تا عملی را با همان مجوزهای فاعل واگذار کنندهنشانه یا زیر مجموعه ای از آنها انجام دهد.

فصل ششم- سیستم های توزیع شده شئ محور

6-1 نام گذاری
یکی از جنبه های جالب نام گذاری در سیستم های توزیع شده شئ محور حول روش پشتیبانی از مرجع های اشیاء دور می زند. در این روش ارجاع به اشیاء راه دور وابسته به زبان برنامه نویسی است. که از CORBA کمک می گیریم تا نشان دهیم که چگونه می توان یک سیستم نام گذاری ساده و مستقل از زبان و پلاتفرم فراهم آورد.

6-1-1 مرجع شئ در CORBA
یکی از نکات اساسی در CORBAنحوه ارجاع به اشیاء است. وقتی مشتری یک مرجع شئ را در اختیار می گیرد، می تواند از اینمرجع برایاحضار متدهای پیاده سازی شده در آن شئ استفاده کند. نکته مهم این است که باید بین مرجعی که فرایند مشتری برای احضار یک متد بکار می برد، و مرجعی که RTS زیربنایی پیاده سازی می کند، تفاوت قائل شویم.
فرایندها فقط می توانند از پیاده سازی مرجع های وابسته به زباناستفاده می کنند. مرجع شئ به شکل اشاره گری به یک نمایش از شئ محلی پیاده سازی می شود. چنین مرجعی را نمی توان از فرایندA به فرایندB پاس کرد، چون اشاره گرهای فرایند A فقط در فضای آدرس همان فرایند معنا دارند. بجای آن، فرایندA باید قبل از پاس کردن یک اشاره گر، آن را به شکل نمایشی مستقل از فرایند کدگذاری کند. متد مورد نیاز برای این ار توسط RTS فراهم می شود. همین که این اشاره گر کدگذاری شد، می توان آن را به فرایند B پاس کرد، که در آنجا مجدداً کدگشایی خواهد شد. ممکن است فرایندهای A وb برنامه هایی را اجرا کنند که به زبان های متفاوت نوشته شده اند.
بر خلاف آن RTS زیربنایی نمایش مستقل از زبان خاص خود را از مرجع های اشیاء خواهد داشت. این نمایش حتی می تواند با نمایش کدگذاری شده ای که فرایندها بین خود مبادله می کنند، تفاوت داشته باشد. نکته مهم این است که وقتی فرایندی به یک شئ ارجاع می کند، RTS زیربنایی آن باید اطلاعات کافی داشته باشد که بداند واقعاً به کدام شئ ارجاع شده است. این اطلاعات معمولاً از طرف بنیان های سمت مشتری و خدمتگزار که با استفاده از مشخصات واسط شئ ایجاد شده اند پاس می شوند.
یک از مشکلات ویرایش های اولیه CORBA این بود که هر پیاده سازی می توانست تصمیم بگیرد یک مرجع شئ را چگونه نمایش دهد. در نتیجه، اگر فرایند A می خواست یک مرجع را به فرایند B پاس کند، فقط در صورتی کارش با موفقیت همراه می شد که هر دو از یک پیاده سازی CORBA استفاده می کردند. در غیر اینصورت مرجع کدگذاری شده فرایند A هیچ مفهومی برای RTS بکار رفته توسط فرایند B نمی داشت.
درحال حاضر تمام سیستم های CORBA از یک نمایش مستقل از زبان یکسان برای مرجع های اشیاء پشتیبانی می کنند. این نمایش به مرجع شی مبادله پذیر یا به اختصار IOR معروف است. وقتی دو سیستم مختلف CORBA می خواهند یک مرجع شئ را بین خود مبادله کنند، آن را به صورت IOR پاس می کنند. یک IOR حاوی تمام اطلاعات لازم برای شناسایی یک شئ است. در شکل6-1 الگوی کلی یک IOR، به همراه اطلاعات مشخص در مورد پروتکل ارتباطی بکار رفته در CORBA نشان داده شده است.

شکل 6-1 ساختار یک IOR همراه با اطلاعات ویژه برای IIOP

هر IOR با یک شناسه مخزن شروع می شود. این شناسه به یک واسطه نسبت داده می شود، بگونه ایکه بتوان آن را در یک مخزن واسط ذخیره و سپس بازیابی کرد. از این شناسه در زمان اجرا برای بازیابی اطلاعات مربوط به واسط استفاده می شود، و می توان آن را مثلاً برای کنترل نوع یا ایجاد دینامیک احضار به گرفت. مهمترین بخش در هر IOR به گزارش برچسب دار معروف است. هر IOR می تواند چندین گزارش برچسب دار داشته باشد. هر گزارش برچسب دار دارای اطلاعات کامل برای احضار یک شئ است. اگر یک خدمتگزار شئ از پروتکل های مختلفی پشتیبانی کند، می تواند برای هر پروتکل یک گزارش برچسب دار داشته باشد. برای ارتباط بین گره ها در CORBA از پروتکلی به نام پروتکل بین ORB اینترنتی یا به اختصار IIOP استفاده می شود. ORB نام سیستم زمان اجرای CORBA یعنی دلال درخواست شئ. در واقع IIOP اختصاصاً برای پشتیبانی از احضار متد راه دور طراحی شده است.
هرگزارش IIOP با یک فیلد شناسه گزارش در گزارش برچسب دار شناسایی می شود.
فیلد میزبان یک رشته نوشتاری است که دقیقاً مشخص می کند شئ مورد نظر در کجا قرار گرفته استومحل این میزبان را می توان با استفاده از یک نام دامنه DNS یا با استفاده از آدرس IP میزبان مشخص کرد.
فیلد پورت شماره پورتی را مشخص می کند که خدمتگزار شئ برای دریافت درخواست های ورودی به آن گوش می کند.
فیلد کلید شئ اطلاعاتی را مخصوص خدمتگزار شی در بر دارد که از آنها برای تفکیک درخواست های ورودی استفاده می کند.
در آخر فیلد اجزاء قرار دارد، که یک فیلد اختیاری است و می توان اطلاعات دیگری را که برای احضار صحیح شئ ارجاع شده مورد نیاز است مانند اطلاعات امنیتی لازم برای ارجاع به یک شئ یا اینکه چه باید کرد در آن گنجاند.

مرجع شئ در گلوب
روشی متفاوت برای ارجاع به اشیاء. در گلوب، به هر شئ مشترک توزیع شده یک شناسه فراگیر و منحصر به فرد (OID) که یک رشته 256 بیتی است اختصاص داده می شود. این شناسه می تواند بگونه ای یکتا و منحصر بفرد شئ را مشخص کند. به عبارت دیگر، هر OID گلوب به حداکثر یک شئ مشترک توزیع شده ارجاع می کند، و هرگز به هیچ شئ دیگری اشاره نخواهد کرد؛ هر شئ گلوب فقط و فقط یک OID دارد.
در گلوب از OID فقط برای مقایسه مرجع های اشیاء می توان استفاده کرد. برای مثال فرایندهایA وB هر دو به یک شئ مشترک توزیع شده پیوند برقرار کرده اند. هر یک از این دو فرایند یک OID درخواست می کنند تا بتوانند به این شئ متصل شوند. اگر این دو OID یکسان باشند، می توان فرض کرد که AوB به یک شئ پیوند برقرار کرده اند. بر خلاف مرجع های CORBA از OID های گلوب نمی توان مستقیماً برای تماس با اشیاء استفاده کرد. برای پیداکردن یک شئ و دسترسی به آن ابتدا باید آدرس تماس آن را با استفاده از یک سرویس مکان یابی پیدا کنیم. آدرس های تماس گلوب را می توان با مرجع های اشیاء وابسته به مکان در CORBA ودیگر سیستم های توزیع شده مقایسه کرد. هر آدرس تماس دو بخش دارد:
بخش اول یک شناسه آدرس است که سرویس مکان یابی با استفاده از آن گره برگ مورد نظر، که عمل های حذف و درج آدرس تماس متناظر به آن هدایت می شوند، را پیدا می کند.
بخش دوم آدرس تماس حاوی آدرس واقعی شئ است، ولی این اطلاعات هیچ مفهومی برای سرویس مکان یابی ندارند. از نظر سرویس مکان یابی، یک آدرس فقط آرایه ای از بایت ها است که می تواند نمایانگر هر چیزی، آدرس شبکه شئ اشاره گر واسط کدگذاری شده آن یا حتی یک پروکسی کدگذاری شده تمام و کمال باشد.
گلوب از دو نوع آدرس پشتیبانی می کند. نوع اول، آدرس انباشته، یک مجموعه پروتکل لایه ای را نمایش می دهد، که هر لایه آن با یک رکورد سه فیلدی مشخص می شود. در شکل 6-2 ساختار کلی یک لایه پروتکل را مشاهده می کنید.
جدول 6-1 انواع فیلد و کارهای آنها
فیلد
توضیح
شناسه پروتکل
ثابتی که یک پروتکل شناخته شده را نمایش می دهد
آدرس پروتکل
آدرس پروتکل ویژه
قبضه پیاده سازی
مرجع یک فایل در مخزن کلاس
فیلد شناسه پروتکل ثابتی است که یک پروتکل شناخته شده مشخص می کند. پروتکل های TCP، UDPوIP جزء پروتکل های متداول هستند. فیلد آدرس پروتکل حاوی اطلاعات اختصاصی پروتکل انتخاب شده توسط فیلد قبل است، مانند شماره پورتTCPیا یک آدرس شبکه IPV4 بالاخره، از فیلد قبضه پیاده سازی که یک فیلد اختیاری است می توان برای ارجاع به پیاده سازی پیش فرض پروتکل مورد نظر استفاده کرد.
دومین نوع آدرس تماس، آدرس نمونه نام دارد، که از دو فیلد نشان داده شده در شکل6-3 تشکیل می شود. در این آدرس هم یک فیلد قبضه پیاده سازی وجود دارد، که چیزی نیست جز ارجاع به فایلی در یک مخزن کلاس، جائیکه می توان پیاده سازی یک شئ محلی را در آن یافت. فرایندی که می خواهد به این شئ محلی متصل شود، باید این پیاده سازی را فضای آدرس خود بار کند.

فیلد
توضیح
قبضه پیاده سازی
مرجع یک فایل در مخزن کلاس
رشته آماده سازی
رشته ای که برای آماده سازی یک پیاده سازی بکار برده می شود
بار کردن پیاده سازی شئ تابع یک پروتکل استاندارد مانند بار کردن کلاس های جاوا است. بعد از اینکه این پیاده سازی بار شده و شئ محلی ایجاد شد، آماده سازی آن با استفاده از فیلد بعدی، فیلد رشته آماده سازی انجام خواهد شد. در این نقطه، شناسه شئ بطور کامل تحویل شده است.
ارجاع به اشیا در CORBA و گلوب با یکدیگر متفاوت است، و این تفاوت در اغلب سیستم های توزیع شده شئ محور به چشم می خورد. در جائیکه مرجع های CORBA حاوی تمام اطلاعات مورد نیاز برای تماس با یک شئ هستند، مرجع های گلوب به سرویس های مکان یابی برای بازیابی این اطلاعات وابسته اند. از این رو، مرجع های CORBA به مرجع مستقیم، و مرجع های گلوب غیرمستقیم معروف هستند.

همگام سازی
در زمینه همگام سازی اشیاء توزیع شده در سیستم های توزیع شده فقط چند نکته هست که باید مورد توجه قرار دهیم. این نکته که جزئیات پیاده سازی معمولاً در پس واسط ها پنهان می شوند، بویژه می تواند مشکل ساز شود: وقتی فرایندی یک شئ راه دور را احضار می کند، هیچ اطلاعی از این موضوع ندارد که آیا این احضار باعث احضار اشیاء دیگر خواهد شد یا خیر. در نتیجه، اگر یک شئ در مقابل دسترسی همزمان محافظت شده باشد، ممکن است با آبشاری از قفل ها روبرو شویم که فرایند احضار کننده از آن بی خبر است. از طرف دیگر وقتی با منابع داده ای مانند فایل ها یا جدول های پایگاه داده که با استفاده از قفل محافظت می شوند سر وکار داریم، الگوی کنترل جریان برای فرایندهایی که از این منابع استفاده می کنند، واضح و روشن است. در چنین وضعیتی فرایندها می توانند کنترل بیشتری بر اوضاع داشته باشند.
یک رهیافت جایگزین این است که مسدود شدن فقط در خدمتگزار اتفاق بیفتد. این روش به خوبی کار می کند، مگر اینکه مشتری در میانه راه از کار بیفتد. برای مقابله باچنین وضعیتی به پروتکل های نسبتاً پیچیده ای نیاز داریم، وکارایی کل سیستم نیز ممکن است تحت تاثیر احضار متد راه دور قرار گیرد.

6-2 سازگاری و تکثیر

6-2-1 سازگاری مدخل
سازگاری داده مدار برای اشیاء توزیع شده معمولاً به شکل سازگاری مدخل دیده می شود. در این مدل هدف گروه بندی عمل ها روی داده های مشترک با استفاده از متغیرهای همگام سازی است. از آنجاییکه اشیاء ذاتاً ترکیبی از داده ومتد هستند، قفل کردن آنها باعث می شود تا احضار ها به ترتیب انجام شوند، و سازگاری حفظ شود. باید به طریقی جلوی اجرای همزمان چند احضار روی یک شئ واحد را بگیریم. به عبارت دیگر وقتی یکی از متدهای یک شئ در حال اجراست، به متدهای دیگر آن نباید اجازه اجرا شدن داد. این تمهید تضمین می کند که دو فرایند به طور همزمان به داده های داخلی یک شئ دسترسی پیدا نخواهند کرد. برای این منظور می توان بسادگی از قفل های محلی استفاده کرد.
مسئله دیگر این است که باید مطمئن شویم حالت تمام نسخه های تکثیری یک شئ یکسان باقی بمانند. به بیان دیگر نباید اجازه دهیم تا دو احضار بطور همزمان روی دو نسخه مختلف از یک شئ اجرا شوند. این بدان معناست که همه نسخه های تکثیری یک شئ باید احضارها را به ترتیب یکسان مشاهده کنند. این کار را به دو روش می توان انجام داد: 1- استفاده از رهیافت اولیه محور، یا 2- استفاده از چندپخشی کاملاً مرتب.

چارچوب های تکثیر
یکی از جنبه های جالب اغلب سیستم های توزیع شده شئ محور این است که معمولاً می توان بین کارکرد اشیا و عملکردهای اضافی آنها به روشنی تمایز قائل شد. یکی از مکانیزم های قدرتمند برای این کار استفاده از جداساز است. احضار اشیاءدر سه نقطه مختلف جداسازی می شوند.
1- در سمت مشتری، درست قبل از اینکه احضار به بنیان تحویل داده شود.
2- در بنیان مشتری، جائیکه جداسازی بخشی از الگوریتم تکثیر را تشکیل می دهد.
3- در سمت خدمتگزار، درست قبل از اینکه شئ احضار شود.

6-3 تحمل خرابی
مانند تکثیر اغلب سیستم های توزیع شده شئ محور از مکانیزم های یکسان برای مقابله به خرابی استفاده می کنند. اما وقتی پای استاندارد سازی به میان می آید، CORBAبه میزان قابل ملاحظه ای از سایر سیستم ها پیش است و جامعترین کیفیت را ارائه می کند.

6-3-1 خرابی پذیری در CORBA
رهیافت اصلی مقابله با خرابی در CORBAتکثیر اشیاء و سازماندهی آنها در گروه های شئ است. یک گروه شئ اساساً چیزی نیست جز چند کپی یکسان از یک شئ که می توان به عنوان یک شئ واحد به آن ارجاع کرد. یک گروه شئ دارای همان واسطی است که اشیاء تکثیر شده داخل آن دارا هستند. به عبارت دیگر، تکثیر شئ به طور کامل از دید مشتری شفاف است. CORBA از راهبردهای تکثیر مختلف و تکثیر حدنصاب محور برای ایجاد گروه های شئ پشتیبانی می کند.
برای داشتن بیشترین حد ممکن از شفافیت تکثیر و شفافیت خرابی، یک گروه شئ نباید هیچ تفاوت قابل تشخیصی با اشیاء معمولی CORBA داشته باشد. نکته مهم در رابطه با گروه های شئ چگونگی ارجاع به آنهاست. در CORBA برای این منظور نوع خاصی از IOR، موسوم به مرجع گروه شئ مبادله پذیر یا به اختصارIOGR بکار گرفته می شود.
وقتی مشتری یک IORG را به RTSخود پاس می کند، RTS سعی می کند با یکی از نسخه های تکثیری ارجاع شده پیوند برقرار کند. در مورد IIOP، ممکن استRTS اطلاعات اضافی دیگری نیز در یکی از گزارش های IIOP پیدا کند. این قبیل اطلاعات را می توان در فیلد اجزاء ذخیره کرد. اگر RTS نتواند با یکی از نسخه های تکثیری پیوند برقرار کند با استفاده از هر مدلی که خود مناسب می داند نسخه های دیگر را امتحان خواهد کرد. اما از دید مشتری فرایند برقراری پیوند کاملاً شفاف است: چیزی که مشاهده می کند، هیچ تفاوتی با پیوند به یک شئ معمولی CORBA ندارد.

مقایسه RPC و CORBA
یکی از متداول ترین انتزاع های مورد استفاده فراخوانی روال راه دور RPC است. RPC به این معناست که یک سرویس بوسیله روالی پیاده سازی می شود که بدنه آن در خدمتگزار اجرا می شود. فقط امضای روال، یعنی نام روال به همراه پارامترهای آن، به مشتری ارائه می شود. هنگامی که مشتری این روال را فراخوانی می کند، پیاده سازی سمت مشتری که مشتری مجازی نامیده می شود، اقدام به بسته بندی پارامترها به شکل یک پیام و ارسال آن به خدمتگزار می کند. این خدمتگزار، روال را فراخوانی کرده و نتایج را مجدداً به شکل پیام باز می گرداند. مشتری مجازی مقادیر دریافتی پیام را از پیام بازگشتی استخراج کرده و آن را به برنامه کاربردی مشتری فراخوانی کننده باز می گرداند.
RPC ها امکانات ارتباطی همگام را ارائه می کنند، که بوسیله آن مشتری تا زمان ارسال پاسخ توسط خدمتگزار مسدود می شود. CORBA یک استاندارد شناخته شده برای سیستم های توزیع شده است. CORBA یک استاندارد جامع است. آنچه پیام رسانید CORBA را با سیستم های دیگر متفاوت می کند، رویکرد ذاتاً شئ محور آن به ارتباطات است. سرویس پیام رسانی CORBA باید از مدل ارتباطی آن که مقید است همه کارها با احضار اشیاء انجام شوند، پیروی کنند. در مورد پیام رسانی قیدهای طراحی باعث بوجود آمدن دو نوع احضار متد ناهمگام شده است. احضار متد ناهمگام مشابه RPC ناهمگام است: فرایند فراخوانی کننده بعد از احضار متد منتظر نتیجه آن نمی ماند، و به کار خود ادامه می دهد. در مدل پس فراخوانی CORBA یک شئ در اختیار مشتری قرار داده می شود که واسطی حاوی متدهای پس فراخوانی کننده را پیاده سازی می کند.

منابع و ماخذ:
کتاب DISTRIBUTED SYSTEM
سیستم های توزیع شده
نویسندگان: تانن باوم. مارتن فان استین

1

ح