مخفف کلمه اختصاری IPC است ارتباطات بین پردازشی ، یعنی تعامل فرآیندها. معمولاً این به انتقال پیام های مختلف بین پردازش ها در هر سیستم عامل اشاره دارد. در این حالت می توان از اشکال مختلف هماهنگ سازی مورد نیاز انواع مختلف تعامل ، به عنوان مثال از طریق حافظه مشترک استفاده کرد.
در فرآیند توسعه خانواده یونیکس سیستم عامل ها در طول 30 سال گذشته ، روش های پیام رسانی به شرح زیر تکامل یافته است:
■ کانال ها (لوله ها - فصل 4) اولین شکل استفاده گسترده از تعامل فرآیند در دسترس برنامه ها و کاربر (از مفسر فرمان) بود. اشکال اصلی کانالها عدم امکان استفاده از آنها بین فرایندهایی است که والد مشترک (اجداد) ندارند ، اما این اشکال با ظهور لوله های نامگذاری شده (لوله های نامگذاری شده) یا کانال های FIFO (فصل 4) حذف شد.
que صف های پیام سیستم V (فصل 4) در اوایل دهه 80 به هسته های سیستم V اضافه شدند. از آنها می توان برای انتقال پیام بین پردازش ها در همان گره صرف نظر از اینکه این فرایندها در ارتباط باشند استفاده می شود. با وجود پیشوند "سیستم V" ، اکثر نسخه های مدرن یونیکس ، از جمله نسخه های برگرفته از سیستم V ، از این صف ها پشتیبانی می کنند.
توجه داشته باشید
برای فرآیندهای یونیکس ، اصطلاح "خویشاوندی" به معنای این است که فرایندها یک جد مشترک دارند. این قابل درک است که فرایندهایی که بستگان هستند توسط این فرآیند اجداد با استفاده از یک یا چند چنگال ایجاد شده اند. ساده ترین مثال فراخوانی چنگال در یک فرآیند دو بار است که منجر به ایجاد دو فرآیند تخم ریزی می شود. سپس می توانیم در مورد رابطه این فرایندها با یکدیگر صحبت کنیم. به طور طبیعی ، هر فرآیند تولید شده نسبت به فرآیندی است که آن را تولید کرده است. والدین می توانند قبل از تماس با چنگال از امکان تعامل با فرآیند تخم ریزی (با ایجاد یک لوله یا صف پیام) مراقبت کنند و این شیء IPC توسط فرایند تخم ریزی به ارث می رسد. برای اطلاعات بیشتر در مورد وراثت شی IPC ، به جدول مراجعه کنید. 1.4. همچنین لازم به ذکر است که کلیه فرایندهای یونیکس به لحاظ تئوری از فرزندان فرآیند init هستند که تمام مراحل لازم را در طی فرآیند راه انداز (bootstrapping) اجرا می کند. از نقطه نظر عملی ، بهتر است که رابطه پردازش ها را از پوسته ورود به سیستم و کلیه فرآیندهای ایجاد شده توسط آن حساب کنید. فصل 9 جلسات و روابط مرتبط با فرآیندها را با جزئیات بیشتری تشریح می کند.
توجه داشته باشید
یادداشتهایی از این دست برای شفاف سازی ویژگی های اجرای ، ارائه پیشینه تاریخی و نکات مفید توسط ما استفاده می شود.
ues صف های پیام Posix (صف های پیام Posix - فصل 5) به استاندارد Posix اضافه شده است (1003.1b-1993 ، که با جزئیات بیشتر در بخش 1.7 بحث شده است). آنها می توانند برای تعامل فرآیندهای مرتبط و نامربوط در هر گره مورد استفاده قرار گیرند.
calls تماس با روش از راه دور (RPC ، قسمت 5) در دهه 80 به عنوان ابزاری برای تماس با توابع در یک سیستم (سرور) توسط برنامه ای که روی سیستم دیگری (مشتری) اجرا می شود ، ظاهر شد. این ابزار به عنوان جایگزینی برای ساده سازی برنامه نویسی شبکه ساخته شده است. از آنجا که اطلاعات معمولاً بین مشتری و سرور منتقل می شود (آرگومان ها برای فراخوانی تابع و مقادیر بازگشتی منتقل می شوند) ، و از آنجا که می توان از یک تماس از راه دور استفاده کرد بین مشتری و سرور در همان گره استفاده کرد ، RPC نیز می تواند نوعی انتقال پیام در نظر گرفته شود.
همچنین جالب است که به تکامل اشکال مختلف همگام سازی در طول توسعه یونیکس بپردازیم:
■ اولین برنامه هایی که نیاز به هماهنگ سازی دارند (اغلب برای جلوگیری از تغییر همزمان چندین فرآیند به طور همزمان محتوای پرونده) از ویژگی های سیستم فایل استفاده می کردند که برخی از آنها در بخش 9.8 توضیح داده شده است ،
lock قفل رکورد (فصل 9) در اوایل دهه 80 به هسته های یونیکس اضافه شد و در Posix.1 در سال 1988 استاندارد سازی شد.
sem سمفورسهای System V (سیستمهای V V semaphores - فصل 11) به همراه قابلیت اشتراک حافظه (حافظه اشتراکی سیستم V - فصل 14) و همزمان با صف های پیام V سیستم (اوایل دهه 80) اضافه شده اند. این IPC ها توسط اکثر نسخه های مدرن یونیکس پشتیبانی می شوند.
sem semaphores Posix (semaphores Posix - Chapter 10) و حافظه مشترک Posix (حافظه مشترک Posix - فصل 13) نیز به استاندارد Posix اضافه شد (1003.1b-1993 ، که قبلاً در ارتباط با صف های پیام Posix ذکر شده بود).
ex استثناء های متقابل و متغیرهای شرطی (mutex ، متغیر شرطی - فصل 7) دو شکل هماهنگ سازی هستند که توسط استاندارد موضوع نرم افزار Posix تعریف شده اند (موضوعات Posix ، Pthreads - 1003.1s-1995). اگرچه معمولاً از آنها برای همگام سازی بین موضوعات استفاده می شود ، اما می توان از آنها برای سازماندهی تعامل فرآیندها نیز استفاده کرد.
l قفل خواندن و نوشتن (فصل 8) شکل دیگری برای هماهنگ سازی است. هنوز در استاندارد Posix گنجانده نشده است ، اما به زودی به زودی منتشر خواهد شد.
1.2 فرآیندها ، موضوعات و به اشتراک گذاری اطلاعات
در مدل برنامه نویسی سنتی یونیکس می توان چندین فرآیند را بطور همزمان در یک سیستم اجرا کرد که به هر یک از آنها فضای آدرس اختصاصی خود اختصاص داده شده است. این در شکل نشان داده شده است. 1.1.
شکل 1.1. اشتراک اطلاعات بین فرآیندها
1. دو فرآیند در سمت چپ اطلاعاتی را که در یکی از اشیاء سیستم فایل ذخیره شده اند به اشتراک می گذارند. برای دستیابی به این داده ها ، هر فرآیند باید به هسته تبدیل شود (با استفاده از توابع خواندن ، نوشتن ، نوشتن ، نوشتن ، lseek و موارد مشابه). هنگام تغییر پرونده ، نوعی هماهنگ سازی لازم است ، برای از بین بردن تداخل در هنگام نوشتن چندین فرایند به طور همزمان و محافظت از فرآیندهای خواندن از پرونده از مواردی که برای آن می نویسند.
2. دو فرآیند در وسط تصویر اطلاعات ذخیره شده در هسته را به اشتراک می گذارد. نمونه هایی در این مورد کانال ، صف پیام یا یک semaphore System V است که در این حالت از تماس های سیستم برای دسترسی به اطلاعات اشتراکی استفاده می شود.
3. دو فرآیند در سمت راست از یک ناحیه حافظه مشترک استفاده می کنند که هر یک از فرایندها می توانند به آن دسترسی پیدا کنند. پس از دستیابی به این ناحیه حافظه ، فرآیندها قادر به دستیابی به داده ها بدون هیچ گونه کمکی از هسته خواهند بود. در این حالت ، مانند حالت اول ، فرآیندهای با استفاده از حافظه مشترک نیز نیاز به هماهنگ سازی دارند.
لطفاً توجه داشته باشید كه در هیچ یك از این موارد ، تعداد فرآیندهای تعامل به دو مورد محدود نمی شود. هر یک از روشهای توصیف شده برای تعداد دلخواه فرآیندهای تعامل کار می کند. در شکل ، ما فقط دو را برای سادگی ترسیم می کنیم.
جریانها
اگرچه مفهوم فرآیندهای روی سیستم های یونیکس مدت زمان طولانی است ، اما امکان استفاده از چندین موضوعات در همان فرآیند نسبتاً اخیر است. استاندارد موضوع Posix.1 با نام Pthreads در سال 1995 به تصویب رسید. از نظر تعامل فرآیندها ، تمام موضوعات یک فرآیند دارای متغیرهای مشترک جهانی هستند (یعنی استفاده از حافظه مشترک نمونه ای از یک مدل جریان است). با این حال ، موضوعات نیاز به هماهنگ سازی دسترسی به داده های جهانی دارند. به طور کلی ، هماهنگ سازی ، گرچه خود نوعی IPC نیست ، اما اغلب در رابطه با اشکال مختلف IPC برای کنترل دسترسی به داده ها استفاده می شود.
این کتاب تعامل بین فرآیندها و بین موضوعات را شرح می دهد. فرض می کنیم محیطی وجود دارد که در آن از برنامه نویسی چند رشته ای پشتیبانی می شود و از عبارات فرم استفاده می کنیم "اگر کانال خالی باشد ، جریان مکالمه مسدود می شود تا اینکه برخی جریان دیگر به کانال بنویسد". اگر سیستم از جریان پشتیبانی نمی کند ، می توانید "جریان" را با "پردازش" در این جمله جایگزین کنید و تعریف کلاسیک قفل را در یونیکس دریافت می کنید که هنگام خواندن از یک کانال خالی توسط دستور read انجام می شود. با این حال ، در سیستمی که از موضوعات پشتیبانی می کند ، فقط نخ مورد نظر داده ها را از کانال خالی مسدود می کند ، و تمام موضوعات پردازش دیگر به کار خود ادامه می دهند. موضوع دیگر با همان فرآیند یا برخی از موضوعات دیگر می تواند داده ها را به کانال بنویسد.
ضمیمه B برخی خصوصیات اساسی موضوعات را خلاصه می کند و پنج عملکرد اصلی Pthread مورد استفاده در برنامه های این کتاب را شرح می دهد.
1.3 زنده ماندن شیء IPC
شما می توانید ماندگاری هر IPC را به عنوان مدت زمان وجود آن تعریف کنید. در شکل 1.2 سه گروه ممکن را نشان می دهد که اشیاء بقا می توانند به آنها اختصاص دهند.
شکل 1.2 زنده ماندن شیء IPC
1. یک شی IPC که بقای آن توسط یک فرآیند (پایدار فرآیند) مشخص می شود تا زمانی که آخرین فرایندی که هنوز در آن باز است بسته شود وجود دارد. یک نمونه لوله های بدون نام و نامگذاری شده است (لوله ها ، FIFO).
2. یک شی IPC ، بقای آن توسط هسته (هسته ثابت) تعیین می شود ، تا زمانی که هسته دوباره راه اندازی شود یا تا زمانی که جسم به طور صریح حذف نشود ، وجود دارد. مثال ها صفحات پیام سیستم V ، semaphores و حافظه مشترک است. ماندگاری صف های پیام Posix ، semaphores و حافظه مشترک باید حداقل توسط هسته تعیین شود ، اما بسته به اجرای آن ممکن است توسط سیستم پرونده نیز تعیین شود.
3. یک شیء IPC که بقای آن توسط سیستم فایل مشخص می شود (فایل سیستم ثابت) تا زمانی که صریح حذف شود وجود دارد. مقدار آن حتی هنگام بازگرداندن هسته حفظ می شود. صف های پیام Posix ، semaphores و حافظه مشترک این ویژگی را دارند که اگر از طریق پرونده های نمایش داده شده اجرا شوند (همیشه اینگونه نیست).
در تعیین میزان بقای شیء IPC باید دقت کرد زیرا همیشه مشخص نیست. به عنوان مثال ، داده های موجود در لوله توسط هسته پردازش می شوند ، اما بقای کانال ها توسط پردازش ها تعیین می شود ، نه هسته ، زیرا پس از آخرین فرایندی که کانال برای خواندن باز شد ، آن را بسته می کند ، هسته تمام داده ها را مجددا تنظیم می کند و کانال را حذف می کند. به طور مشابه ، اگرچه کانالهای FIFO دارای نامهایی در سیستم فایل هستند ، بقای آنها نیز توسط فرآیندها مشخص می شود ، زیرا کلیه داده های موجود در چنین کانال بعد از آخرین فرایندی که در آن باز شده بازنشانی می شود.
در جدول 1.1 اطلاعات بقا از اشیاء IPC را که قبلاً ذکر شده است خلاصه می کند.
جدول 1.1. زنده ماندن انواع مختلف اشیاء IPC
| نوع IPC | نشاط را تعیین می کند |
|---|---|
| کانال برنامه (لوله) | روند |
| خط لوله نامگذاری شده (FIFO) | روند |
| استثناء متقابل Posix (mutex) | روند |
| متغیر شرطی Posix | روند |
| Posix خواندن / نوشتن قفل (قفل) | روند |
| قفل نوشتن Fcntl | روند |
| صف پیام Posix | هسته |
| Posix به نام semaphore (به نام semaphore) | هسته |
| Semaphore Posix در حافظه (سمفور مبتنی بر حافظه) | روند |
| حافظه به اشتراک گذاشته Posix (حافظه مشترک) | هسته |
| سیستم ارسال پیام پیام V | هسته |
| سیستم Semaphore V | هسته |
| هسته | |
| سوکت TCP | روند |
| سوکت UDP | روند |
| سوکت دامنه یونیکس (سوکت دامنه یونیکس) | روند |
توجه داشته باشید که هیچ نوع IPC در این جدول از ماندگاری تعریف شده توسط سیستم فایل برخوردار نیست. قبلاً هم اشاره کردیم که سه نوع اشیاء IPC در استاندارد Posix وجود دارد ممکن استبسته به اجرای این نوع زنده ماندن را داشته باشید. بدیهی است که نوشتن داده به یک پرونده بقاء تعیین شده توسط سیستم پرونده را فراهم می کند ، اما IPC ها معمولاً به این روش اجرا نمی شوند. اکثر اشیاء IPC به گونه ای طراحی نشده اند که پس از راه اندازی مجدد وجود داشته باشند ، زیرا فرایندها از آن زنده نمی مانند. الزام بقاء تعریف شده توسط سیستم فایل احتمالاً عملکرد این نوع IPC را کاهش می دهد و معمولاً یکی از وظایف توسعه دهنده اطمینان از عملکرد بالا است.
1.4. نامهای نام
اگر دو فرآیند غیرمرتبط از نوعی IPC برای تبادل اطلاعات استفاده کنند ، موضوع IPC باید دارای یک نام یا شناسه باشد تا یکی از فرایندها (که معمولاً سرور نامیده می شود) بتواند این شی را ایجاد کند ، و فرآیند دیگر (معمولاً یک یا چند مشتری مشتری است). می تواند به این شی خاص مراجعه کند.
کانال های نرم افزاری (لوله ها) نام ندارند (و بنابراین نمی توان از آنها برای تعامل بین فرآیندهای نامربوط استفاده کرد) ، اما کانال های FIFO به اسامی در سیستم پرونده ای که شناسه آنهاست ، نقشه برداری می شوند (بنابراین می توان از کانال های FIFO برای تعامل بین فرآیندهای نامربوط استفاده کرد). برای انواع دیگر IPC ، که در فصل های بعدی مورد بحث قرار می گیرد ، از کنوانسیون های نامگذاری اضافی استفاده می شود. مجموعه نامهای احتمالی برای نوع خاصی از IPC نام فضای نام آن است. Namespace اصطلاح مهمی است زیرا برای همه انواع IPC ، به استثنای کانال های ساده ، این نام چگونگی ارتباط مشتری و سرور را برای پیام رسانی با یکدیگر تعیین می کند.
در جدول 1.2 کنوانسیون نامگذاری برای انواع مختلف IPC خلاصه می شود.
جدول 1.2. مکان های نام برای انواع مختلف IPC
| نوع IPC | فضای نام برای ایجاد یا باز کردن | شناسه پس از باز کردن | Posix. 1 1996 | یونیکس 98 |
|---|---|---|---|---|
| کانال | (بدون نام) | توصیف کننده | ||
| فیو | نام پرونده (نام مسیر) | توصیف کننده | ||
| استثناء متقابل Posix | (بدون نام) | اشاره گر از نوع pthread_mutex_t | ||
| متغیر شرطی Posix | (بدون نام) | اشاره گر از نوع pthread_cond_t | ||
| (بدون نام) | اشاره گر از نوع pthread_rwlock_t | |||
| قفل ضبط Fcntl | نام پرونده | توصیف کننده | ||
| حافظه به اشتراک گذاشته شده با Posix | نام IPC Posix | توصیف کننده | ||
| سیستم ارسال پیام پیام V | کلید اصلی | IP IP System V ID | ||
| سیستم Semaphore V | کلید اصلی | IP IP System V ID | ||
| سیستم V حافظه مشترک | کلید اصلی | IP IP System V ID | ||
| درها | نام پرونده | توصیف کننده | ||
| تماس با روش از راه دور خورشید (RPC) | برنامه / نسخه | کنترل RPC | ||
| سوکت TCP | آدرس IP و پورت TCP | توصیف کننده | .1 گرم | |
| سوکت UDP | آدرس IP و پورت TCP | توصیف کننده | .1 گرم | |
| سوکت دامنه یونیکس (سوکت دامنه) | نام کامل پرونده | توصیف کننده | .1 گرم |
این همچنین نشان می دهد که فرم های IPC در استاندارد Posix.1 1996 وجود دارند و در استاندارد یونیکس 98 گنجانده شده اند. هر دو این استاندارد با جزئیات بیشتر در بخش 1.7 توضیح داده شده اند. برای مقایسه ، ما سه نوع سوکت در این جدول گنجانده ایم که به تفصیل در آنها توضیح داده شده است. توجه داشته باشید که رابط برنامه برنامه (API) توسط گروه کاری Posix.1g استاندارد شده است و باید در آینده بخشی از استاندارد Posix.1 شود.
اگرچه استاندارد Posix است. 1 و استفاده از سمفورها را ممکن می سازد ؛ پشتیبانی از آنها برای تولید کنندگان الزامی نیست. در جدول 1.3 توابع شرح داده شده در استانداردهای Posix.1 و Unix 98 خلاصه شده است .هر تابع می تواند اجباری ، تعریف نشده یا اختیاری باشد. برای توابع اختیاری ، ما نام ثابت (به عنوان مثال _POSIX_THREADS) را تعریف خواهیم کرد که مشخص می شود (معمولاً در پرونده هدر
جدول 1.3. در دسترس بودن اشکال مختلف IPC
| نوع IPC | Posix. 1 1996 | یونیکس 98 |
|---|---|---|
| کانال برنامه | مورد نیاز | مورد نیاز |
| فیو | مورد نیاز | مورد نیاز |
| استثناء متقابل Posix | _POSIX_THREADS | مورد نیاز |
| متغیر شرطی Posix | _POSIX_THREADS | مورد نیاز |
| استثنائات متقابل و متغیرهای شرطی بین فرآیندها | _POSIX_THREADS_PROCESS_SHARED | مورد نیاز |
| Posix خواندن / نوشتن قفل | (او تعریف شده است) | مورد نیاز |
| قفل ضبط Fcntl | مورد نیاز | مورد نیاز |
| ارسال پیام Posix | _POSIX_MESSAGE_PASSING | _XOPEN_REALTIME |
| Semaphores Posix | _POSIX_SEMAPHORES_ | _XOPEN_REALTIME |
| حافظه به اشتراک گذاشته شده با Posix | _POSIX_SHARED_MEMORY_OBJECTS | _XOPEN_REALTIME |
| سیستم ارسال پیام پیام V | (او تعریف شده است) | مورد نیاز |
| سیستم Semaphore V | (او تعریف شده است) | مورد نیاز |
| سیستم V حافظه مشترک | (او تعریف شده است) | مورد نیاز |
| درها | (او تعریف شده است) | (تعریف نشده است) |
| تماس رویه از راه دور تماس بگیرید | (او تعریف شده است) | (تعریف نشده است) |
| نقشه برداری حافظه Mmap | _POSIX_MAPPED_FILES یا POSIX_SHARED_MEMORY_OBJECTS | مورد نیاز |
| سیگنال های زمان واقعی | _POSIX_REALTIME_SIGNALS | _XOPEN_REALTIME |
1.5 عملکرد دستورات چنگال ، اجرا و خروج در اشیاء IPC
باید تأثیر عملکرد چنگال ، exec و _exit را بر روی اشکال مختلف IPC که در مورد آنها بحث می کنیم بفهمیم (آخرین مورد از این عملکردها توسط عملکرد خروجی نامیده می شود). اطلاعات مربوط به این شماره در جدول خلاصه می شود. 1.4.
بیشتر کارکردها بعداً در متن کتاب توضیح داده شده است ، اما در اینجا باید چند نکته را بیان کرد. در مرحله اول ، فراخوانی چنگال از یک فرآیند چند رشته منجر به آشفتگی در متغیرهای همگام سازی ناشناس (محرومیت های متقابل ، متغیرهای شرطی ، قفل ها و سمفورهای ذخیره شده در حافظه) می شود. بخش 6.1 کتاب شامل جزئیات لازم است. ما به سادگی علاوه بر جدول توجه می کنیم که اگر این متغیرها در حافظه مشترک ذخیره شوند و با یک ویژگی مشترک برای پردازشها ایجاد شوند ، در هر فرآیندی که بتواند به این ناحیه حافظه دسترسی پیدا کند ، در دسترس خواهند بود. ثانیا ، سه شکل IPC System V نمی تواند باز یا بسته شود. لیست 6.6 و تمرین های 11.1 و 14.1 نشان می دهد که همه چیزهایی که برای دسترسی به این سه شکل IPC باید بدانید یک شناسه است. بنابراین ، آنها در دسترس هستند برای تمام فرآیندهای شناخته شده از این شناسه ، اگر چه برخی از پردازش های خاص برای سمفورها و حافظه مشترک مورد نیاز است.
جدول 1.4. عملکرد IPC fork ، exec و _exit
| نوع IPC | چنگال | اعدام | _سایت کن |
|---|---|---|---|
| لوله های بدون نام و نامگذاری شده | فرآیند ایجاد شده نسخه ای از همه توصیف کنندگان مراحل والدین دریافت می کند | همه توصیف کنندگان باز باز هستند مگر اینکه بیت FD_CLOEXEC برای آنها تنظیم شده باشد. | همه توصیف کنندگان باز بسته هستند ، داده های کانال برنامه و FIFO پس از آخرین نزدیک حذف می شوند |
| ارسال پیام Posix | فرآیند ایجاد شده نسخه هایی از کلیه فرآیند های والدین باز را دریافت می کند | همه توصیف کنندگان صف ارسال پیام بسته هستند. | |
| صف سیستم پیام V | معتبر نیست | معتبر نیست | معتبر نیست |
| استثناء های متقابل و متغیرهای شرطی Posix | اگر از حافظه اشتراکی با یک ویژگی فرآیند اشتراکی استفاده شود به اشتراک گذاشته می شود | اگر در حافظه مشترک نباشد ، باز می ماند و دارای یک ویژگی تقسیم می شود | |
| قفل Posix را بخوانید و بنویسید | اگر در حافظه مشترک ذخیره نشود ، از بین می رود ، که باز و دارای ویژگی تقسیم شده است | اگر در حافظه مشترک ذخیره نشود ، از بین می رود ، که باز و دارای ویژگی تقسیم شده است | |
| semaphores Posix که در حافظه ذخیره می شوند | اشتراک در صورت استفاده از حافظه با دسترسی مشترک و یک ویژگی مشترک بین پردازش ها | اگر در حافظه مشترک ذخیره نشود ، از بین می رود ، که باز و دارای ویژگی تقسیم شده است | اگر در حافظه مشترک ذخیره نشود ، از بین می رود ، که باز و دارای ویژگی تقسیم شده است |
| پوزيك به عنوان سمفورس ناميده است | همه در روند والدین در کودک باز است. | همه نزدیک هستند | همه نزدیک هستند |
| سیستم سمفورهای V | تمام مقادیر semadj در فرآیند ایجاد شده 0 است | تمام مقادیر semadj به برنامه جدید منتقل می شود. | تمام مقادیر semadj به مقدار کلمات مربوطه اضافه می شوند. |
| قفل ضبط Fcntl | قفل در روند والدین توسط فرایند کودک به ارث نمی رسد | قفل تا زمانی که دسته بسته نشود تغییر نمی کند | همه قفل های غیر تنظیم مجدد تنظیم شده توسط این فرآیند قفل می شوند. |
| نقشه برداری حافظه | نگاشت های حافظه دوباره تنظیم می شوند (نقشه\u200cبرداری) | ||
| حافظه به اشتراک گذاشته شده با Posix | نگاشتهای حافظه پردازش والدین در کودک ذخیره می شوند | نگاشت های حافظه دوباره تنظیم می شوند | نگاشت های حافظه دوباره تنظیم می شوند |
| سیستم V حافظه مشترک | بخش های حافظه اشتراکی پیوست شده در فرآیند تخمیری ضمیمه می شوند | جداشده بخش های حافظه مشترک | |
| درها | فرآیند ایجاد شده نسخه هایی از همه توصیف کنندگان پروس open والدین را دریافت می کند ، اما در هنگام فعال سازی درها از طریق توصیف کننده ها ، فقط فرآیند والد سرور است. | همه توصیف کننده های درب باید بسته باشند زیرا با مجموعه بیت FD_CLOEXEC ایجاد شده اند. | همه توصیف باز نزدیک هستند |
1.6 هندلینگ خطا: توابع بسته بندی
در هر برنامه واقعی ، هر تماس نیاز به بررسی مقدار بازده برای یک خطا دارد. از آنجا که معمولاً وقتی کار خطایی انجام می شود ، کار برنامه ها به پایان می رسد ، می توانیم با تعریف توابع بسته بندی که تماس تابع واقعی را انجام می دهند ، مقدار متن را کاهش دهیم ، مقدار برگشتی را بررسی کنیم و در صورت بروز خطا از آن خارج شویم. مطابق با قراردادها ، نام توابع بسته بندی با اسم توابع همخوانی دارد ، به استثنای حرف اول ، که دارای حروف بزرگ است ، به عنوان مثال
نمونه ای از عملکرد بسته بندی در لیست 1.1 نشان داده شده است.
لیست 1.1. عملکرد بسته بندی به عملکرد sem_post390 اگر (sem_post (sem) \u003d\u003d –1)
391 err_sys ("خطای sem_post")؛
اگر در متن می بینید که یک اسم تابع با یک حرف بزرگ شروع می شود ، باید بدانید: این کارکرد بسته بندی خود ما است. این تابع با همان نام شروع می شود که با یک حرف کوچک شروع می شود. عملکرد بسته بندی در صورت وجود فرایند با یک پیام خطا خاتمه می یابد.
هنگام توصیف کد منبع موجود در کتاب ، ما همیشه در مورد عملکرد نامیده شده از پایین ترین سطح (به عنوان مثال sem_post) صحبت می کنیم ، و نه در مورد عملکرد بسته بندی (به عنوان مثال Sem_post). به همین ترتیب ، شاخص حروف الفبا نام کارکردها را به خود اختصاص می دهد ، نه بسته بندی برای آنها.
توجه داشته باشید
قالب کد منبع فوق در سراسر استفاده می شود. تمام خطوط غیر خالی شماره گذاری شده اند. متن توصیف بخش های کد با تعداد سطرهای اول و آخر در قسمت خالی در سمت چپ شروع می شود. بعضی اوقات در جلوی پاراگراف متن یک عنوان کوتاه به صورت پررنگ وجود دارد که محتوای اصلی کد توصیف شده را تشریح می کند.
در ابتدای کد ، نام پرونده منبع مشخص شده است. در این مثال ، این پرونده wrapunix.c در دایرکتوری lib است. از آنجا که کد منبع برای همه نمونه های این کتاب رایگان است (به مقدمه مراجعه کنید) ، می توانید به راحتی پرونده مورد نظر خود را پیدا کنید. تدوین ، اجرای و بویژه تغییر این برنامه ها هنگام خواندن کتاب بهترین روش برای یادگیری مفاهیم تعامل فرآیند است.
اگرچه ممکن است به نظر نرسد که استفاده از چنین کارکردهای بسته بندی بسیار سودمند است ، اما شما در فصل 7 از این تصور غلط خلاص می شوید ، در اینجا می یابیم که توابع نخ در هنگام بروز خطا ، مقداری به متغیر استاندارد یونیکس اختصاص نمی دهند. در عوض ، کد خطا به سادگی توسط عملکرد بازگردانده می شود. این بدان معنی است که وقتی ما تابع pthread را فراخوانی می کنیم ، باید هر بار حافظه را برای متغیر اختصاص دهیم ، مقدار برگشتی توسط تابع را در آن ذخیره کنیم و سپس قبل از فراخوانی تابع err_sys ، متغیر errno را روی این متغیر تنظیم کنیم (لیست B.4). برای این که متن را با بندهای فرفری جمع نکنید ، از اپراتور زبان C "کاما" استفاده می کنیم و انتساب مقدار errno و تماس err_sys را در یک جمله ، مانند مثال زیر ترکیب می کنیم.
if ((n \u003d pthread_mutex_lock (& \u200b\u200bndone_mutex))! \u003d 0) errno \u003d n، err_sys ("خطای pthread_mutex_lock")؛
جایگزین برای تعریف یک عملکرد جدید در استفاده از خطا است که یک کد خطا را به عنوان یک آرگومان در نظر می گیرد. با این وجود ، ما می توانیم این نوشتن کد را با نوشتن بسیار خواندنی تر کنیم
Pthread_mutex_lock (& \u200b\u200bndone_mutex)؛
جایی که ما از عملکرد بسته بندی خود استفاده می کنیم ، که در لیست 1.2 نشان داده شده است.
لیست 1.2. اجرای یک بسته بندی برای عملکرد pthread_mutex_lock126 Pthread_mutex_lock (pthread_mutex_t * mptr)
129 if ((n \u003d pthread_mutex_lock (mptr)) \u003d\u003d 0)
132 err_sys ("خطای pthread_mutex_lock")؛
توجه داشته باشید
با استفاده دقیق از قابلیت های زبان C ، می توان از ماکرو به جای توابع استفاده کرد که باعث افزایش سرعت اجرای برنامه می شود ، اما این توابع بسته بندی به ندرت (اگر اصلاً) تنگناها باشد.
توافق ما برای جایگزین کردن اولین حرف از نام تابع با یک حرف بزرگ یک سازش است. بسیاری از اشکال دیگر نشانه گذاری در نظر گرفته شده است: استفاده از پیشوند e () ، پسوند _e ، و غیره. گزینه ما به نظر می رسد که کمترین حواس پرتی باشد و در عین حال یک نشانه بصری مبنی بر اینکه برخی از عملکردهای دیگر نامیده می شود ، باشد.
این روش یک ویژگی مفید جانبی دارد: خطاهای برگشتی توسط عملکردهایی که کد بازگشت آنها معمولاً نادیده گرفته می شود ، مانند close و pthread_ mutex_lock را بررسی می کند.
در ادامه در متن کتاب ، ما از این توابع بسته بندی استفاده خواهیم کرد ، مگر اینکه بخواهیم صراحتا خطایی را بررسی کنیم و آن را به صورت دلخواه پردازش کنیم ، غیر از پایان مراحل. ما برای همه بسته بندی های موجود در کتاب کد منبع ارائه نمی دهیم ، اما به صورت رایگان در اینترنت موجود است (به مقدمه مراجعه کنید).
ارزش ارورنو
وقتی خطایی در عملکرد یونیکس رخ می دهد ، به متغیر errno جهانی مقدار مثبت داده می شود که نوع خطا را نشان می دهد. این تابع معمولاً مقدار -1 را برمی گرداند. عملکرد err_sys ما پیامی را مطابق با کد خطا نشان می دهد (برای مثال ، منابع به طور موقت در دسترس نیستند - در صورت تنظیم errno روی EAGAIN ، منبع موقتاً در دسترس نیست).
تابع فقط در صورت بروز خطا مقدار را به errno اختصاص می دهد. در صورت خاموش شدن معمولی ، مقدار این متغیر مشخص نشده است. تمام مقادیر مثبت مطابقت با ثابتهای دارای اسم های بزرگ با E شروع می شود ، که معمولاً در پرونده هدر تعریف می شوند
هنگام کار با موضوعات مختلف ، هر یک از آنها باید متغیر errno خود را داشته باشند. تخصیص متغیر به هر موضوع بطور خودکار اتفاق می افتد ، اما معمولاً این امر به نشانه ای از کامپایلر نیاز دارد که باید امکان ورود مجدد به برنامه وجود داشته باشد. این با استفاده از کلیدهای –D_REENTRANT یا –D_POSIX_C_SOURCE \u003d 199506L یا معادل آن تنظیم شده است. اغلب در عنوان
در متن دیگر ، عباراتی مانند "تابع mq_send EMSGSIZE را به دست می آوریم" استفاده می کنیم ، به این معنی که این تابع یک خطا را برمی گرداند (معمولاً مقدار بازده -1 است) و متغیر errno را روی مقدار ثابت مشخص شده قرار می دهیم.
1.7 استاندارد های یونیکس
استانداردهای یونیکس در حال حاضر توسط Posix و Open Group تعریف شده اند.
پوزيكس
نام Posix از "رابط سیستم عامل قابل حمل" گرفته شده است ، که تقریباً به معنای "رابط سیستم عامل قابل حمل" است. این یک استاندارد نیست بلکه یک خانواده کامل است که توسط انستیتوی مهندسان برق و الکترونیک (IEEE) ساخته شده است. همچنین استانداردهای Posix به عنوان استانداردهای بین المللی ISO (سازمان بین المللی استاندارد سازی ، سازمان بین المللی استاندارد سازی) و IEC (کمیسیون بین المللی الکترونیکی ، کمیسیون بین المللی الکتروتکنیک) یا ISO / IEC به تصویب رسیده است. استانداردهای Posix چندین مرحله از پیشرفت را پشت سر گذاشته است.
standard استاندارد IEEE 1003.1-1988 (317 صفحه) اولین استاندارد Posix بود. وی رابط بین زبان C و هسته یونیکس را در زمینه های زیر تعریف کرد: ابتدایی برای اجرای فرآیندها (چنگال ، اجرای تماس ، سیگنال و تایمر) ، محیط فرآیند (شناسه کاربر ، گروه های پردازش) ، پرونده ها و دایرکتوری ها (کلیه عملکردهای I / O) ، کار با ترمینال ، پایگاه داده های سیستم (رمز عبور و پرونده های گروهی) ، قالب های بایگانی tar و cpio.
توجه داشته باشید
اولین استاندارد Posix با نام IEEEIX در سال 1986 در بازار تولید شد. نام Posix توسط ریچارد استالمن مطرح شد.
■ سپس استاندارد IEEE 1003.1-1990 (356 صفحه) آمده است. همچنین این استاندارد بین المللی ISO / IEC 9945-1: 1990 بود. در مقایسه با نسخه 1988 ، تغییرات در نسخه 1990 حداقل بوده است. عنوان اضافه شده است: "قسمت 1: رابط برنامه کاربردی سیستم (API)" ("قسمت 1: رابط برنامه نویسی سیستم (API) [زبان C])" ، و این بدان معنی است که استاندارد توصیف واسط برنامه نویسی C (API) .
■ IEEE 1003.2-1992 در دو جلد با كل جلد حدود 1300 صفحه منتشر شد و عنوان آن شامل خط "قسمت 2: پوسته و نرم افزارها" (قسمت 2: "مترجم و كاربردها") بود. این قسمت مفسر را تعریف می کند (بر اساس پوسته بورن در سیستم یونیکس یکس) و حدود صد ابزار (برنامه هایی که معمولاً از مفسر خوانده می شوند - از awk و basename گرفته تا vi و wass). در این کتاب ، تحت عنوان Posix به این استاندارد اشاره خواهیم کرد. 2
■ IEEE 1003.1b-1993 (590 صفحه) در ابتدا با عنوان IEEE P1003.4 شناخته شده بود. این استاندارد علاوه بر استاندارد 1003.1-1990 بود و شامل پسوندهای در زمان واقعی است که توسط گروه کاری P1003.4 ایجاد شده است: همگام سازی پرونده ، ورودی-خروجی ناهمزمان ، semaphores ، مدیریت حافظه ، برنامه ریزی ، ساعت ، تایمر و صف های پیام.
■ نسخه IEEE 1003.1 ، 1996 (743 صفحه) ، شامل 1003.1-1990 (API اساسی) ، 1003.1b-1993 (پسوندهای زمان واقعی) ، 1003.1-1995 (Pthreads - موضوعات نرم افزاری Posix) و 1003.1i-1995 (اصلاحات فنی به 1003.1b). این استاندارد همچنین ISO / IEC 9945-1: 1996 نامیده می شود. سه فصل در مورد موضوعات و بخش های اضافی در مورد هماهنگ سازی نخ ها (محرومیت های متقابل و متغیرهای شرطی) ، برنامه ریزی موضوع و برنامه ریزی همگام سازی به آن اضافه شده است. در این کتاب ، ما این استاندارد Posix.1 را می نامیم.
توجه داشته باشید
بیش از یک چهارم از 743 صفحه استاندارد برنامه ای تحت عنوان "عقلان و یادداشت ها" ("توجیه و یادداشت ها") بود. این دلیل منطقی شامل اطلاعات تاریخی و توضیحی در مورد دلایل عدم وجود برخی کارکردها در استاندارد است. غالباً استدلال هیچ کمتری از خود استاندارد ندارد.
متأسفانه ، استانداردهای IEEE به صورت آزاد از طریق اینترنت در دسترس نیست. اطلاعاتی درباره نحوه سفارش کتاب در کتابشناسی در زیر لینک ارائه شده است. توجه داشته باشید که سمفورم ها در استاندارد برای پسوندهای زمان واقعی ، جدا از محرومیت های متقابل و متغیرهای شرطی (که در استاندارد Pthreads تعریف شده اند) تعریف شده اند ، که برخی از تفاوت های API های این ابزارها را توضیح می دهد.
در آخر توجه داشته باشید که قفل خواندن و نوشتن بخشی از استانداردهای Posix نیست. این با جزئیات بیشتر در فصل 8 توضیح داده شده است.
در آینده قصد داریم نسخه جدیدی از IEEE 1003.1 را منتشر کنیم که شامل استاندارد P1003.1g ، رابط های شبکه (سوکت و XTI) می باشد که در جلد اول این کتاب توضیح داده شده است.
در مقدمه Posix.1 در سال 1996 آمده است كه ISO / IEC 9945 از قسمت هاي زير تشكيل شده است:
1. رابط سیستم برای توسعه برنامه (API) (زبان C).
2. مترجم و خدمات.
3. مدیریت سیستم (در حال توسعه).
قسمت 1 و 2 همان چیزی است که ما آنها را Posix.1 و Posix.2 می نامیم.
کار بر روی استانداردهای Posix در حال انجام است و نویسندگان کتاب های مرتبط با آنها مجبور به شلیک به هدف در حال حرکت هستند. وضعیت فعلی استانداردها را می توانید در http://www.pasc.org/ception/sd11.html مشاهده کنید.
گروه باز
گروه باز (گروه باز) در سال 1996 توسط اتحادیه شرکت X / Open (تاسیس در سال 1984) و بنیاد نرم افزار آزاد (OSF ، تاسیس در سال 1988) تشکیل شد. این گروه یک کنسرسیوم بین المللی از تولید کنندگان و مصرف کنندگان صنعت ، دولت و مؤسسات آموزشی است. استانداردهای آنها همچنین در چندین نسخه ظاهر شده است:
در سال 1992 ، شماره چهارم (شماره 4) منتشر شد و در سال 1994 نسخه دوم آن (شماره 4 ، نسخه 2). مورد دوم همچنین به Spec 1170 معروف است ، جایی که شماره جادویی 1170 مجموع تعداد رابط های سیستم (926) ، هدرها (70) و دستورات (174) است. دو نام دیگر وجود دارد: X / Open Single Unix مشخصات و یونیکس 95.
در مارس 1997 نسخه دوم مشخصات یونیکس یونایتد اعلام شد. این استاندارد نرم افزاری نیز یونیکس 98 نام دارد و به این ترتیب است که ما بعداً در کتاب به این مشخصات مراجعه می کنیم. تعداد رابط های موجود در یونیکس 98 از 1170 به 1434 افزایش یافته است ، اگرچه این تعداد برای یک ایستگاه کاری به 3030 می رسد ، زیرا این تعداد شامل CDE (Common Desktop Environment) است که به نوبه خود به یک سیستم پنجره ایکس و یک کاربر احتیاج دارد. رابط موتیف. جزئیات در کتاب نوشته شده است. اطلاعات مفیدی را می توان در http://www.UNIX-systems.org/version2 نیز یافت.
توجه داشته باشید
از این سایت می توانید تقریباً به طور کامل مشخصات Unix Unified را بارگیری کنید.
نسخه های یونیکس و قابلیت حمل
تقریباً کلیه نسخه های یونیکس که ممکن است امروز با آنها روبرو شوید ، مطابق با نسخه های استاندارد Posix.1 یا Posix.2 است. ما می گویم "هر" زیرا بعد از ایجاد تغییر در Posix (به عنوان مثال افزودن برنامه های افزودنی در زمان واقعی در سال 1993 و جریان در سال 1996) ، تولید کنندگان معمولاً برای تطبیق برنامه های خود با این استانداردها ، به یک یا دو سال نیاز دارند.
از نظر تاریخی ، بیشتر سیستم های یونیکس فرزندان BSD یا System V هستند ، اما با حرکت تولید کنندگان به سمت استفاده از استانداردهای Posix ، اختلافات بین آنها به تدریج پاک می شود. تفاوتهای اصلی در حوزه مدیریت سیستم وجود دارد ، زیرا در حال حاضر حتی یک استاندارد Posix واحدی را توصیف نمی کند.
در اکثر نمونه های این کتاب ، ما از سیستم عامل های Solaris 2.6 و Digital Unix 4.0B استفاده کرده ایم. واقعیت این است که در زمان نوشتن کتاب (اواخر سال 1997 - اوایل سال 1998) ، فقط این دو سیستم عامل از موضوعات نرم افزاری System V IPC ، Posix IPC و Posix (Pthreads) پشتیبانی می کردند.
1.8 درباره نمونه های IPC نظر دهید
بیشتر اوقات ، سه الگوی (مدل) تعامل برای نشان دادن کارکردهای مختلف در یک کتاب استفاده می شود:
1. File server: برنامه سرویس دهنده-مشتری و مشتری با نام پرونده درخواستی را به سرور ارسال می کند و سرور مطالب خود را به مشتری باز می گرداند.
2. تولید کننده-مصرف کننده: یک یا چند موضوع یا فرآیند (تولید کنندگان) داده ها را در بافر عمومی قرار می دهند و سایر موضوعات یا فرآیندهای (مصرف کنندگان) عملیات های مختلفی را با این داده ها انجام می دهند.
3. افزایش تعداد دنباله: یک یا چند موضوع یا فرایند باعث افزایش شاخص مشترک برای همه می شود. این شماره می تواند در یک پرونده مشترک یا در یک منطقه حافظه مشترک ذخیره شود.
مثال اول اشکال مختلف پیام رسانی را نشان می دهد ، در حالی که دو مورد دیگر انواع مختلفی از هماهنگی و استفاده از حافظه مشترک را نشان می دهد.
جداول 1.5 ، 1.6 و 1.7 نوعی راهنما برای برنامه هایی است که ما در موضوعات مختلفی که در کتاب بیان شده است ، تهیه می کنیم. این جداول بطور خلاصه خود برنامه ها را شرح می دهد و تعداد لیست های مربوطه را نشان می دهد.
1.9 خلاصه
تعامل فرآیند به طور سنتی یکی از زمینه های مشکل در یونیکس بوده است. با توسعه سیستم راه حل های مختلفی ارائه شد و هیچ یک از آنها کامل نبود. ما IPC را به چهار نوع اصلی تقسیم می کنیم.
1. پیام رسانی (کانال ها ، FIFO ، صف های پیام).
2. همگام سازی (محرومیت های متقابل ، متغیرهای شرطی ، قفل خواندن و نوشتن ، سمفورس).
3. حافظه مشترک (نامگذاری نشده و نامگذاری شده).
4- مراحل تماس (درهای Solaris ، RPC Sun).
ما تعامل هر دو موضوع جداگانه یک فرآیند و چندین فرآیند مستقل را در نظر می گیریم.
ماندگاری هر نوع IPC بسته به مدت زمان وجود آن توسط فرآیند یا هسته یا سیستم پرونده تعیین می شود. هنگام انتخاب نوع IPC برای یک برنامه خاص ، باید بقای آن در نظر گرفته شود.
یکی دیگر از ویژگی های هر نوع IPC ، فضای نام است که شناسایی اشیاء IPC را توسط فرآیندها و موضوعات مورد استفاده از آن مشخص می کند. برخی از اشیاء دارای نام (کانال ، محرومیت متقابل ، متغیرهای شرطی ، قفل خواندن و نوشتن) نیستند ، برخی دیگر دارای اسم هایی در سیستم فایل (کانال های FIFO) هستند ، برخی دیگر با آنچه در "فصل 2" و "چهارم" نام های Posix IPC خوانده می شوند مشخص می شوند. - نوع دیگری از نام که در فصل 3 توضیح داده شده است (کلیدهای IPC یا شناسه های سیستم V). به طور معمول ، یک سرور یک شی IPC را با یک نام ایجاد می کند ، و مشتری ها از آن نام برای دسترسی به شی استفاده می کنند.
کدهای منبع تهیه شده در کتاب از توابع بسته بندی که در بخش 1.6 توضیح داده شده است برای کاهش میزان کد استفاده می کنند ، ضمن اینکه برای هر عملکردی که خوانده می شود ، یک برگرداندن خطا را ارائه می دهد. نام تمام توابع بسته بندی با یک حرف بزرگ شروع می شود.
استانداردهای IEEE Posix - Posix.1 که اصول اولیه رابط C را در یونیکس تعریف می کند ، و Posix.2 که دستورات اساسی را تعریف می کند ، معیارهایی است که اکثر تولید کنندگان به سمت آن حرکت می کنند. با این حال ، استانداردهای Posix به سرعت جذب می شوند (به عنوان بخشی از آنها) و توسط استانداردهای تجاری بخصوص گروه Open (Unix 98) گسترش می یابند.
جدول 1.5. نسخه های سرور مشتری Client
| لیست کردن | توضیحات |
|---|---|
| 4.1 | دو کانال بین فرآیندهای والدین و فرزند |
| 4.5 | از پاپن و گربه استفاده می کند |
| 4.6 | از دو کانال FIFO بین فرآیندهای والدین و فرزند استفاده می کند |
| 4.7 | دو کانال FIFO بین یک سرور مستقل و یک مشتری نامربوط |
| 4.10 | کانال های FIFO بین یک سرور سریال مستقل و چندین مشتری |
| 4.12 | کانال برنامه یا FIFO: ایجاد رکورد در یک بایت جریان |
| 6.7 | دو صفحه پیام سی |
| 6.12 | صف پیام یک سیستم V با چندین مشتری |
| 6.16 | یک صف پیام سیستم V برای هر مشتری؛ چندین مشتری |
| 15.15 | دسته را از طریق درب عبور می دهد |
جدول 1.6. نسخه های تولید کننده و مصرف کننده مدل
| لیست کردن | توضیحات |
|---|---|
| 7.1 | محرومیت متقابل ، چندین تولیدکننده ، یک مصرف کننده |
| 7.5 | محرومیت متقابل و متغیر شرطی ، چندین تولید کننده ، یک مصرف کننده |
| 10.8 | به نام سمفورهای Posix ، یک تولیدکننده ، یک مصرف کننده |
| 10.11 | semaphores Posix در ذهن ، یک تولید کننده ، یک مصرف کننده |
| 10.12 | semaphores Posix در حافظه ، چندین تولید کننده ، یک مصرف کننده |
| 10.15 | semaphores Posix در ذهن ، تولید کنندگان مختلف ، چندین مصرف کننده است |
| 10.18 | semaphores Posix در حافظه ، یک تولید کننده ، یک مصرف کننده: چند بافر |
جدول 1.7. نسخه های برنامه با افزایش تعداد متوالی
| لیست کردن | توضیحات |
|---|---|
| 9.1 | فهرست در پرونده ، بدون قفل |
| 9.3 | فهرست در پرونده ، با fcntl قفل کنید |
| 9.9 | فهرست در پرونده ، با استفاده از عملکرد باز قفل کنید |
| 10.10 | فهرست کردن در یک پرونده ، با استفاده از یک کلمه نامگذاری به نام Posix قفل کنید |
| 12.2 | فهرست حافظه به اشتراک گذاشته شده mmap ، با استفاده از یک Posaph به معنای semaphore ، قفل شود |
| 12.3 | فهرست کردن در حافظه مشترک mmap ، قفل با استفاده از Posph semaphore در حافظه |
| 12.4 | فهرست در حافظه مشترک 4.4BSD بدون نام ، مسدود کردن با استفاده از Posix به عنوان واضح است |
| 12.5 | فهرست حافظه اشتراك SVR4 / dev / صفر ، با استفاده از Posix به عنوان واژگان كلمه اي مسدود مي شود |
| 13.6 | فهرست حافظه اشتراك Posix ، قفل با استفاده از همكار Posix در حافظه |
| A.19 | اندازه گیری عملکرد: مسدود کردن با محرومیت متقابل بین موضوعات |
| A.22 | اندازه گیری عملکرد: قفل خواندن / نوشتن قفل بین موضوعات |
| A.23 | اندازه گیری عملکرد: قفل بین موضوعات با استفاده از سمفورم های حافظه Posix |
| A.25 | اندازه گیری عملکرد: مسدود کردن بین موضوعات با استفاده از Posix به عنوان semaphores نامگذاری شده است |
| A.28 | اندازه گیری عملکرد: قفل کردن بین نخ ها با استفاده از سمفورس های سیستم V |
| A.29 | اندازه گیری عملکرد: مسدود کردن بین موضوعات با استفاده از fcntl |
| A.33 | اندازه گیری عملکرد: قفل شدن بین پردازش ها با استفاده از استثناء های متقابل |
تمرینات
1. شکل 1.1 دو فرآیند دسترسی به یک فایل واحد را نشان می دهد. اگر هر دو فرآیند فقط داده ها را به انتهای پرونده اضافه کنند (احتمالاً طولانی) ، به چه نوع همگام سازی نیاز خواهید بود؟
2. پرونده هدر را بررسی کنید
3. جدول را تکمیل کنید. 1.3 ویژگی هایی که شما استفاده می کنید توسط سیستم های یونیکس پشتیبانی می شوند.
فصل 2
2.1. مقدمه
از میان انواع IPC موجود ، سه مورد زیر می تواند به عنوان Posix IPC طبقه بندی شود ، یعنی روشهای ارتباط فرآیند سازگار با Posix:
que صف پیام های Posix (فصل 5)؛
sem semaphores Posix (فصل 10)؛
memory حافظه مشترک Posix (فصل 13).
این سه نوع IPC خاصیت مشترکی دارند و از توابع مشابه برای کار با آنها استفاده می شود. این فصل در مورد الزامات عمومی برای نام کامل پرونده های مورد استفاده به عنوان شناسه ، پرچم هایی که هنگام باز کردن یا ایجاد اشیاء IPC و مجوزهای دسترسی مشخص شده است ، بحث می کند.
لیست کاملی از کارکردهای استفاده شده برای کار با این انواع IPC در جدول آورده شده است. 2.1.
جدول 2.1. ویژگی های IPC Posix
| صف های پیام | سمفورس | حافظه مشترک | |
|---|---|---|---|
| پرونده هدر | |||
| توابع ایجاد ، باز کردن و حذف | mq_open mq_close mq_unlink | sem_open sem_close sem_unlink sem_init sem_destroy | shm_open shm_unlink |
| عملیات مدیریت | mq_getattr mq_setattr | fstuncate fstat | |
| عملیات IPC | mq_send mq_receive mq_notify | sem_wait sem_trywait sem_post sem_getvalue | mmap munmap |
2.2. نامهای IPC
در جدول 1.2 خاطرنشان کردیم که سه نوع استاندارد IPC Posix دارای شناسه ها (نام ها) هستند که با این استاندارد مطابقت دارند. نام IPC به عنوان اولین آرگومان به یکی از سه عملکرد: mq_open ، sem_open و shm_open منتقل می شود و لازم نیست که با پرونده واقعی موجود در سیستم فایل مطابقت داشته باشد. استاندارد Posix.1 محدودیت های زیر را برای نام IPC اعمال می کند:
■ نام باید با الزامات موجود برای نام پرونده ها مطابقت داشته باشد (از طول بایت های PATHMAX تجاوز نکنید ، از جمله کاراکتر خاتمه دهنده با کد 0).
■ اگر نام با slash (/) شروع می شود ، فراخوانی هر یک از این توابع منجر به دستیابی به همان صف می شود. در غیر این صورت ، نتیجه به اجرای وابسته است.
■ تعبیر برشهای اضافی به یک نام بستگی به اجرای دارد.
بنابراین ، برای قابلیت حمل بهتر ، اسامی باید با برش (/) شروع شوند و حاوی برشهای اضافی نباشند. متأسفانه ، این قوانین به نوبه خود منجر به مشکلات حمل و نقل می شوند.
Solaris 2.6 به یک برش اولیه نیاز دارد و امکان استفاده از برش های اضافی را نمی دهد. به عنوان مثال برای یک پیام پیام ، سه پرونده در فهرست / tmp ایجاد می شوند و نام این پرونده ها با .MQ شروع می شود. به عنوان مثال ، اگر آرگومان تابع mq_open دارای فرم /queue.1234 باشد ، در پرونده های ایجاد شده اسامی /tmp/.MQDqueue.1234 ، /tmp/.MQLqueue.1234 و /tmp/.MQPqueue.1234 را نشان می دهد. در همان زمان ، در سیستم دیجیتال Unix 4.0B ، یک پرونده به سادگی با نام مشخص شده در هنگام فراخوانی عملکرد ایجاد می شود.
مشکل قابلیت حمل هنگام مشخص کردن یک نام با یک اسلش تک در ابتدای کار ایجاد می شود: در این حالت ، ما نیاز به مجوز نوشتن در فهرست فهرست داریم. به عنوان مثال ، یک صف با نام /tmp.1234 توسط استاندارد Posix قابل قبول است و در سیستم Solaris مشکلی ایجاد نمی کند ، اما Digital Unix در صورت عدم اجازه نوشتن به فهرست اصلی root ، از ایجاد پرونده ای ناکام می ماند. اگر نام /tmp/test.1234 را مشخص کنیم ، مشکلات در دیجیتال یونیکس و سیستم های مشابه در ایجاد پرونده با نام مشخص از بین می روند (وجود فهرست / / tmp و وجود مجوز برنامه برای نوشتن بر روی آن ، که معمول برای اکثر سیستم های یونیکس است) ، با این حال ، استفاده از Solaris امکان پذیر نخواهد بود.
برای حل چنین مشکلاتی با قابلیت حمل ، باید با استفاده از بخشنامه #define نام را در هدر تعریف کنید تا اطمینان حاصل شود که هنگام انتقال برنامه به سیستم دیگری ، به راحتی تغییر می یابد.
توجه داشته باشید
توسعه دهندگان به دنبال استفاده از صف های پیام ، سمفورها و حافظه مشترک برای هسته های یونیکس موجود و در سیستم های مستقل دیسک بودند. این در شرایطی است که استاندارد خیلی عمومی است و منجر به مشکلات قابل حمل می شود. برای Posix به این "چگونگی استاندارد شدن غیر استاندارد" گفته می شود.
استاندارد Posix.1 سه ماکرو را تعریف می کند:
که یک آرگومان واحد را نشان می دهند - یک اشاره گر به یک ساختار از نوع نوع stat ، محتویات آن توسط توابع fstat ، lstat و stat تنظیم می شود. این سه ماکرو اگر مقدار IPC مشخص شده (صفح message پیام ، semaphore یا بخش حافظه مشترک) به عنوان یک نوع خاص از پرونده اجرا شود مقدار ساختار غیرفعال را برمی گرداند و ساختار stat به این نوع اشاره دارد. در غیر این صورت ، ماکرو 0 را برمی گرداند.
توجه داشته باشید
متأسفانه استفاده از این ماکروها کافی نیست ، زیرا هیچ تضمینی برای اجرای این نوع IPC به عنوان انواع فایلهای جداگانه وجود ندارد. به عنوان مثال ، در Solaris 2.6 ، هر سه ماکرو همیشه 0 را برمی گردانند.
تمام ماکروهای دیگر که برای بررسی نوع پرونده استفاده می شوند دارای اسامی هستند که از S_IS شروع می شوند و همیشه یک آرگومان را به دست می آورند: زمینه st_mode ساختار stat. از آنجا که ماکروهای مورد استفاده برای آزمایش نوع IPC آرگومانهایی از یک نوع دیگر را می پذیرند ، نام آنها با S_TYPEIS شروع می شود.
عملکرد Px_ipc_name
راه حل دیگری برای این مشکل قابلیت حمل وجود دارد. شما می توانید عملکرد خود ما px_ipc_name را تعریف کنیم ، که فهرست مورد نیاز را به عنوان پیشوندی برای نام IPC Posix اضافه می کند.
char * px_ipc_name (const char) * نام);
/ * نشانگر موفقیت را نشان می دهد ، NULL روی خطا * /
توجه داشته باشید
این گونه است که لیست عملکردهای خود ما ، یعنی توابع غیر استاندارد توابع سیستم به نظر می رسد. به طور معمول ، فایل هدر unipc.h گنجانده شده است (لیست B.1).
استدلال پت(نام) نباید دارای برش باشد. سپس ، به عنوان مثال ، تماس با px_ipc_name ("test1") یک اشاره گر را به خط / test1 در Solaris 2.6 یا به خط / tmp / test1 در دیجیتال Unix 4.0B باز می گرداند. حافظه مربوط به رشته برگشتی با فراخوانی رایگان به صورت پویا اختصاص داده می شود. می توانید متغیر محیط دلخواه PX_IPC_NAME را تنظیم کنید تا یک فهرست پیش فرض دیگر تنظیم شود.
لیست 2.1 اجرای ما از این عملکرد را نشان می دهد.
لیست 2.1. عملکرد px_ipc_name در اجرای ماست.توجه داشته باشید
شاید این اولین بار باشد که عملکرد snprintf را در این لیست مشاهده کرده اید. بخش قابل توجهی از برنامه های موجود به جای آن از تابع sprintf استفاده می کنند ، اما حالت دوم بررسی جریان سرریز در بافر دریافتی را بررسی نمی کند. در مقابل ، snprintf اندازه بافر گیرنده را به عنوان آرگومان دوم می گیرد و متعاقباً از سرریز آن جلوگیری می کند. سرریز بافر عمدی بر روی برنامه ای که از sprintf استفاده می کند توسط هکرها برای کرک سیستم ها سالهاست استفاده می شود.
عملکرد snprintf هنوز جزئی از استاندارد ANSI C نیست ، اما قرار است در یک استاندارد به روز شده به نام C9X گنجانده شود. با این وجود ، بسیاری از تولید کنندگان آن را در کتابخانه استاندارد C قرار می دهند .در هرجای متن ، از تابع snprintf در نسخه خود استفاده می کنیم که در صورت عدم وجود عملکرد snprinft در کتابخانه سیستم ، یک فراخوانی Sprintf را فراهم می کند.
3 px_ipc_name (const char * name)
6 اگر ((dst \u003d malloc (PATN_MAX)) \u003d\u003d NULL)
8 / * می توان نام دایرکتوری دیگری را با استفاده از متغیر محیط * تنظیم کرد /
9 if ((dir \u003d getenv ("PX IPC_NAME")) \u003d\u003d NULL) (
11 dir \u003d POSIX_IPC_PREFIX؛ / * از "config.h" * /
13 dir \u003d "/ tmp /"؛ / * پیش فرض * /
16 / * نام فهرست باید با کاراکتر "/" * / پایان یابد
17 اسلش \u003d (dir \u003d\u003d "/")؟ "": "/"؛
18 snprintf (dst ، PATH_MAX ، "٪ s٪ s٪ s" ، dir ، slash ، name)؛
19 بازگشت (dst)؛ / * برای آزاد کردن این نشانگر می توانید با شماره رایگان تماس بگیرید () * /
2.3 کانال های IPC ایجاد و باز کنید
هر سه عملکرد مورد استفاده برای ایجاد یا باز کردن اشیاء IPC: mq_open ، sem_open و shm_open ، یک پرچم ویژه را بپذیرید oflag به عنوان استدلال دوم پارامترهای باز کردن شیء درخواست شده را به همان روشی که آرگومان دوم برای عملکرد استاندارد باز تعریف می کند. کلیه ثابت هایی که می توان این استدلال را تشکیل داد در جدول آورده شده است. 2.2.
جدول 2.2. ثابتهایی که هنگام ایجاد و باز کردن اجسام IPC مورد استفاده قرار می گیرند
| توضیحات | mq_open | sem_open | shm_open |
|---|---|---|---|
| فقط بخوانید | O_RDONLY | O_RDONLY | |
| فقط ضبط کنید | O_WRONLY | ||
| بخوانید و بنویسید | O_RDWR | O_RDWR | |
| اگر وجود نداشته باشد ایجاد کنید | O_CREAT | O_CREAT | O_CREAT |
| ایجاد انحصاری | O_EXCL | O_EXCL | O_EXCL |
| بدون قفل | O_NONBLOCK | ||
| موجود موجود را کوتاه کنید | O_TRUNC |
سه خط اول نوع دسترسی به شیء ایجاد شده را توصیف می کند: فقط بخوانید ، فقط بنویسید ، بخوانید و بنویسید. صف پیام می تواند در هر یک از سه حالت دسترسی باز شود ، در حالی که برای یک semaphore ، نشانه این ثابت ها لازم نیست (برای هر عملی با semaphore ، دسترسی خواندن و نوشتن لازم است). در آخر ، شی حافظه اشتراکی فقط برای نوشتن نمی تواند باز شود.
نشانگر پرچم های دیگر از جدول. 2.2 اختیاری است.
O_CREAT - ایجاد یک پیام پیام ، بخش سمفور یا بخش حافظه مشترک ، اگر کسی از قبل وجود نداشته باشد (همچنین پرچم O_EXCL را ببینید ، که روی نتیجه تأثیر می گذارد).
هنگام ایجاد یک صفح message پیام جدید ، semaphore یا بخش حافظه مشترک ، حداقل یک آرگومان اضافی که مشخص کننده حالت است ، لازم است. این آرگومان نشانگر بیت های اجازه دسترسی به پرونده است و با اضافه شدن منطقی بقایای ثابت از جدول تشکیل می شود. 2.3
جدول 2.3. دسترسی به حالت های حالت هنگام ایجاد یک شی جدید IPC
این ثابت ها در سربرگ تعریف می شوند.
همانطور که با یک پرونده تازه ایجاد شده ، هنگام ایجاد یک صف ارسال پیام ، سمفور یا بخش حافظه مشترک ، به آنها یک شناسه کاربر متناظر با شناسه کاربر فرآیند کارآمد اختصاص می یابد. شناسه یک گروه semaphore یا بخش حافظه مشترک برابر با شناسه فعلی فرآیند گروه یا شناسه گروهی است که به طور پیش فرض برای سیستم به طور کلی تنظیم شده است. شناسه گروهی صفحات پیام همیشه برابر با شناسه گروه فعلی فرایند است (ص 77-78 در مورد جزئیات بیشتر درباره شناسه گروه و کاربر بحث می کند).
توجه داشته باشید
عجیب به نظر می رسد که در تعیین شناسه گروهی برای انواع مختلف Posix IPC تفاوت وجود دارد. شناسه گروهی یک پرونده جدید ایجاد شده با استفاده از تابع باز ، روی شناسه واقعی گروه فرآیند یا شناسه گروه دایرکتوری که در آن پرونده ایجاد شده است تنظیم شده است ، اما توابع IPC نمی تواند از قبل فرض کند که یک پرونده واقعی برای موضوع IPC در سیستم فایل ایجاد می شود.
O_EXCL - اگر این پرچم همزمان با O_CREAT مشخص شود ، تابع فقط در صورت وجود ، یک پیام جدید ، semaphore یا یک حافظه مشترک ایجاد می کند. اگر جسم قبلاً وجود داشته باشد و O_CREAT | O_EXCL ، یک خطای EEXIST بازگردانده می شود.
تأیید وجود یک پیام پیام ، بخش متفاوتی یا بخش حافظه مشترک و ایجاد آن (در صورت وجود) باید فقط با یک فرآیند انجام شود. دو پرچم مشابه در سیستم V IPC موجود است ، که در بخش 3.4 توضیح داده شده است.
O_NONBLOCK - این پرچم بدون مسدود کردن یک صفحه پیام ایجاد می کند. معمولاً یک قفل برای خواندن از صف خالی یا نوشتن در صف کامل تنظیم می شود. این در جزئیات بیشتر در زیر بخش های مربوط به توابع mq_send و mq_receive در بخش 5.4 توضیح داده شده است.
O_TRUNC - اگر یک بخش حافظه اشتراکی موجود برای خواندن و نوشتن باز باشد ، این پرچم نشانگر لزوم کاهش اندازه آن به 0 است.
در شکل شکل 2.1 ترتیب واقعی عملیات منطقی را هنگام باز کردن یک شی IPC نشان می دهد. منظور از چک کردن مجوزهای دسترسی دقیقاً در بخش 2.4 توضیح داده شده است. رویکرد دیگر به روشی که در شکل نشان داده شده است. 2.1 در جدول ارائه شده است. 2.4
شکل 2.1. منطق افتتاح شیء IPC
توجه داشته باشید که در ردیف وسط جدول قرار دارد. 2.4 ، جایی که فقط پرچم O_CREAT تنظیم شده است ، ما هیچ اطلاعاتی راجع به اینکه یک شیء جدید ایجاد شده یا یک موجود موجود باز نشده است ، دریافت نمی کنیم.
جدول 2.4. منطق افتتاح شیء IPC
| استدلال oflag | شی وجود ندارد | شی موجود است |
|---|---|---|
| پرچم خاصی نیست | خطا ، errno \u003d ENOENT | |
| O_CREAT | خوب ، یک شی جدید ایجاد شده است. | خوب ، یک شیء موجود باز می شود. |
| O_CREAT | O_EXCL | خوب ، یک شی جدید ایجاد شده است. | خطا ، errno \u003d EEXIST |
2.4 مجوزهای IPC
یک صفحه پیام جدید ، یک semaphore یا بخش حافظه مشترک ، توسط توابع mq_open ، sem_open و shm_open ایجاد می شود ، مشروط بر اینکه آرگومان oflag حاوی O_CREAT ثابت است. مطابق جدول 2.3 ، به هر یک از این انواع IPC ، مجوزهای خاص ، مشابه مجوزهای پرونده یونیکس اختصاص داده شده است.
هنگامی که یک صفح message پیام پیام ، سمفور یا بخش حافظه مشترک را با همان کارکردها باز می کنید (در صورتی که پرچم O_CREAT مشخص نشده باشد یا O_CREAT بدون O_EXCL مشخص شده باشد و شیء از قبل وجود داشته باشد) ، بررسی اجازه انجام می شود:
1. بیت های مجاز در زمان ایجاد به IPC مورد بررسی قرار می گیرند.
2. نوع دسترسی درخواست شده بررسی می شود (O_RDONLY ، O_WRONLY ، O_RDWR).
3. شناسه معتبر کاربر فرآیند فراخوانی ، شناسه معتبر فرآیند گروهی و شناسه های فرایند گروهی اضافی (ممکن است این مورد پشتیبانی نشود) بررسی می شود.
اکثر سیستم های یونیکس چک های خاص زیر را انجام می دهند:
1. اگر شناسه معتبر کاربر برای فرآیند 0 (کاربر ممتاز) باشد ، دسترسی مجاز خواهد بود.
2. اگر شناسه کاربر پردازش معتبر با شناسه مالک IPC مطابقت داشته باشد: اگر بیت اجازه مربوطه برای کاربر تنظیم شده باشد ، دسترسی مجاز است ، در غیر این صورت دسترسی رد می شود.
منظور از بیت اجازه مربوطه ، منظور ما مثلاً بیت اجازه خواندن اگر فرآیند فقط موضوع را برای خواندن باز کند. اگر یک فرآیند برای نوشتن یک شیء را باز کند ، بیت نوشتار کاربر باید بر این اساس تنظیم شود.
3. اگر شناسه گروه فعلی یا یکی از شناسه های گروه پردازش اضافی با شناسه گروه IPC مطابقت داشته باشد: اگر بیت اجازه مربوط به گروه تنظیم شده باشد ، دسترسی مجاز خواهد بود ، در غیر این صورت دسترسی رد می شود.
4- در صورت تنظیم میزان اجازه دسترسی متناظر برای سایر کاربران ، دسترسی مجاز خواهد بود ، در غیر این صورت دسترسی رد خواهد شد.
این چهار چک به همین ترتیب انجام می شود. بنابراین ، اگر فرایند مالک IPC (مرحله 2) باشد ، دسترسی فقط براساس مجوزهای کاربر (مالک) مجاز یا رد می شود. مجوزهای گروه بررسی نمی شوند. به همین ترتیب ، اگر این فرآیند دارای IPC IPC نباشد ، اما متعلق به گروه مورد نظر باشد ، دسترسی به مجوزهای گروه مجاز یا رد می شود - مجوزها برای سایر کاربران بررسی نشده است.
توجه داشته باشید
مطابق جدول 2.2 ، عملکرد sem_open از پرچم های O_RDONLY ، O_WRONLY ، O_RDWR استفاده نمی کند. با این حال ، بخش 10.2 می گوید که برخی از اجرای یونیکس حاکی از پرچم O_RDWR است ، زیرا دسترسی به semaphore شامل خواندن و نوشتن مقدار آن است.
2.5. خلاصه
سه نوع Posix IPC - صف های پیام ، سمفورس ها و حافظه مشترک - با نام های کامل آنها مشخص می شوند. آنها ممکن است نام واقعی فایل در سیستم پرونده باشند یا نباشند ، و این باعث بروز مشکلات حمل و نقل می شود. راه حل استفاده از تابع بومی px_ipc_name است. هنگام ایجاد یا باز کردن یک موضوع IPC ، باید هنگام استفاده از عملکرد باز ، مجموعه ای از پرچم های مشابه آنچه مشخص شده را مشخص کنید. هنگام ایجاد یک شی IPC جدید ، باید با استفاده از همان ثابت S_xxx برای عملکرد باز ، مجوزهایی را برای آن مشخص کنید (جدول 2.3). هنگامی که یک شیء IPC موجود را باز می کنید ، مجوزهای فرآیند بررسی می شوند ، مانند بررسی هنگام باز کردن پرونده.
تمرینات
1. چگونه بیت های تعیین شناسه کاربر (set-ID-user، SUID) و تنظیم شناسه گروه (set-group-ID) (بخش 4.4) یک برنامه با استفاده از Posix IPC چگونه می تواند بر بررسی اجازه توضیح داده شده در بخش 2.4 تأثیر بگذارد؟
2. هنگامی که برنامه ای یک شیء IPC را باز می کند ، چگونه می تواند تعیین کند که آیا یک شی جدید IPC ایجاد شده است یا به یک شیء موجود دسترسی دارد؟
فصل 3
3.1 مقدمه
از میان انواع IPC موجود ، سه مورد زیر را می توان به System V IPC نسبت داد ، یعنی برای پردازش روشهای متقابل مطابق با استاندارد System V:
que صف های پیام سیستم V (فصل 6)؛
sem سمفورسهای سیستم V (فصل 11)؛
■ حافظه مشترک سیستم V (فصل 14).
اصطلاح "System V IPC" به منشأ این ابزارها اشاره دارد: آنها ابتدا در سیستم یونیکس V. ظاهر شدند. آنها مشترکات زیادی دارند: توابع مشابه برای سازماندهی دسترسی به اشیاء استفاده می شوند. همچنین اشکال ذخیره اطلاعات در هسته مشابه است. در این فصل ویژگی های مشترک برای سه نوع IPC توضیح داده شده است.
اطلاعات مربوط به عملکردها در جدول خلاصه می شود. 3.1
جدول 3.1. ویژگی های سیستم IP IPC
توجه داشته باشید
اطلاعات مربوط به تاریخچه توسعه و پیشرفت ویژگی های سیستم V IPC خیلی سریع در دسترس نیست. اطلاعات زیر را ارائه می دهد: صف های پیام ، سمفورس ها ، و این نوع از حافظه مشترک در اواخر دهه 70 در یکی از شرکت های وابسته به آزمایشگاه های بل در کلمبوس ، اوهایو ساخته شد ، برای یک نسخه از یونیکس برای استفاده داخلی. این نسخه Columbus Unix یا CB Unix نامیده شد. این سیستم در سیستم های به اصطلاح پشتیبانی عملیات - سیستم های پردازش معاملات - برای خودکارسازی مدیریت و ثبت سوابق در شرکت تلفن استفاده می شد. IPC های سیستم V در حدود 1983 به نسخه تجاری یونیکس سیستم V. اضافه شدند.
3.2 کلیدهای نوع key_t و عملکرد ftok
در جدول 1.2 ذکر شد که از مقادیر key_t در نامهای سه نوع System V IPC استفاده شده است. پرونده هدر
تابع ftok نام کامل و شناسه صحیح موجود را به مقدار نوع key_t (به نام کلید IPC) تبدیل می کند:
key_t ftok (const char) * مسیر نام ، int شناسه);
// در صورت بروز خطا ، کلید IPC یا -1 را برمی گرداند
در حقیقت ، این تابع از نام کامل پرونده و 8 بیت پایین شناسه برای تشکیل کلید عدد IPC استفاده می کند.
این عملکرد به فرض عمل می کند که برای یک برنامه خاص با استفاده از IPC ، مشتری و سرور از همان نام کاملاً واجد شرایط IPC استفاده می کنند ، که در متن برنامه معنایی دارد. این می تواند نام daemon سرور یا نام پرونده اطلاعاتی مورد استفاده توسط سرور یا نام برخی از شیء سیستم فایلهای دیگر باشد. اگر مشتری و سرور برای برقراری ارتباط فقط به یک کانال IPC نیاز داشته باشند ، می توانید شناسه را اختصاص دهید به عنوان مثال مقدار 1. اگر به چندین کانال IPC نیاز دارید (برای مثال ، یکی از سرور به مشتری و دیگری در جهت مخالف) ، شناسه ها باید مقادیر متفاوتی داشته باشند: مثلاً 1 و 2. پس از توافق مشتری و سرور در مورد نام و شناسه کامل ، هر دو آنها برای بدست آوردن همان کلید IPC با عملکرد ftok تماس می گیرند.
اکثر پیاده سازی های ftok تابع stat را فراخوانی می کنند و سپس ترکیب می کنند:
information اطلاعات سیستم پرونده ای که نام کامل به آنها اشاره دارد نام مسیر (زمینه st_dev ساختار stat)؛
number شماره گره (i- گره) در سیستم فایل (فیلد st_ino ساختار stat)
8 8 بیت پایین شناسه (که نباید صفر باشد).
ترکیبی از این سه مقدار معمولاً منجر به یک کلید 32 بیتی می شود. هیچ تضمینی وجود ندارد که برای دو مسیر مختلف با همان شناسه ، کلیدهای مختلفی بدست آید ، زیرا تعداد بیت اطلاعات در سه عنصر ذکر شده (شناسه سیستم فایل ، شماره گره ، شناسه IPC) می تواند از تعداد کل بیتها فراتر رود (نگاه کنید به تمرین 3.5 )
توجه داشته باشید
تعداد گره همیشه غیر صفر است ، بنابراین اکثر پیاده سازی ها ثابت IPC_PRIVATE (بخش 3.4) را صفر نشان می دهند.
اگر نام کامل مشخص شده وجود نداشته باشد یا در فرآیند فراخوانی در دسترس نباشد ، ftok -1 را برمی گرداند. به یاد داشته باشید که پرونده ای که نام آن برای محاسبه کلید استفاده شده است نباید یکی از آنهایی باشد که توسط سرور در حین کار ایجاد شده است حذف شود ، زیرا هر بار که دوباره آنها را ایجاد کردید ، این پرونده ها ، به طور کلی ، یک گره متفاوت را دریافت می کنند و این می تواند کلید را تغییر دهد. در تماس بعدی توسط ftok بازگشت.
مثال
برنامه در لیست 3.1 نام کامل را به عنوان آرگومان در خط فرمان می گیرد ، توابع stat و ftok را فراخوانی می کند ، سپس زمینه های st_dev و st_ino ساختار stat و کلید IPC حاصل را نمایش می دهد. این سه مقدار در قالب شش ضلعی نمایش داده می شوند ، بنابراین می توان دقیقاً چگونگی شکل گیری کلید IPC از بین این دو مقدار و شناسه 0x57 را مشاهده کرد.
لیست 3.1. دریافت و خروجی اطلاعات پرونده و کلید تولید IPC7 err_quit ("استفاده: ftok");
9 printf ("st_dev: & lx، st_ino:٪ Ix، key:٪ x \\ n"،
10 (u_long) stat.st_dev ، (u_long) stat.st_ino ،
اجرای این برنامه بر روی یک سیستم Solaris 2.6 نتایج زیر را تولید می کند:
خورشیدی٪ ftok / etc / system
st_dev: 800018، st_ino: 4a1b، key: 57018a1b
خورشیدی٪ ftok / usr / tmp
st_dev: 800015، st_ino: 10b78، key: 57015b78
خورشیدی٪ ftok /home/rstevens/Mail.out
st_dev: 80001f، st_ino: 3b03، key: 5702fb03
بدیهی است ، شناسه 8 بیت بالایی از کلید را مشخص می کند. 12 بیت پایین st_dev 12 بیت بعدی کلید را تعیین می کند ، و در آخر ، 12 بیت پایین st_ino 12 بیت پایین کلید را تعیین می کند.
هدف از این مثال ، تکیه نکردن متعاقبا به چنین روشی برای تولید کلید از اطلاعات ذکر شده نیست ، بلکه نشان دادن الگوریتم ترکیب نام و شناسه کامل با یک اجرای خاص است. در سایر پیاده سازی ها ، الگوریتم ممکن است متفاوت باشد.
توجه داشته باشید
FreeBSD از 8 بیت پایین شناسه ، 8 بیت پایین st_dev و 16 بیت پایین st_ino استفاده می کند.
توجه داشته باشید که نقشه برداری حاصل از عملکرد ftok یک طرفه است زیرا از بخشی از بیت های st_dev و st_ino استفاده نمی شود. این کلید نمی تواند نام کامل پرونده را برای محاسبات تعیین کند.
3.3 ساختار Ipc_perm
برای هر شیء IPC ، مانند یک پرونده معمولی ، مجموعه ای از اطلاعات در هسته در یک ساختار ذخیره می شوند.
uid_t uid؛ / * شناسه کاربر مالک * /
gid_tid / * شناسه گروه مالک * /
uid_t cuid؛ / * شناسه کاربر خالق * /
gid_t cgid؛ / * شناسه گروه سازندگان * /
حالت mode_t؛ / * مجوز خواندن / نوشتن * /
ulong_t seq؛ / * شماره سریال کانال * /
key_t کلید؛ / * کلید IPC * /
این ساختار به همراه سایر ثابتهای تغییر نام یافته برای توابع System V IPC در پرونده تعریف شده است
3.4 کانال های IPC ایجاد و باز کنید
سه عملکرد getXXX که برای ایجاد یا باز کردن اشیاء IPC (جدول 3.1) استفاده می شود ، یک کلید IPC (از نوع key_t) را به عنوان یکی از آرگومان ها برمی گرداند و یک شناسه عدد صحیح را برمی گرداند. این شناسه با شناسه منتقل شده به عملکرد ftok متفاوت است ، زیرا به زودی خواهیم دید. یک برنامه کاربردی برای مشخص کردن یک کلید دو گزینه دارد (اولین استدلال برای دریافت توابع xXX):
1. با ftok تماس بگیرید ، نام و شناسه کامل آن را بدهید.
2. ثابت IPCPRIVATE را به عنوان کلید مشخص کنید ، که ایجاد یک شیء منحصر به فرد IPC را تضمین می کند.
توالی اقدامات در شکل نشان داده شده است. 3.1
شکل 3.1 محاسبه شناسه های IPC توسط Key
هر سه عملکرد getXXX (جدول 3.1) مجموعه ای از پرچم ها را به عنوان آرگومان دوم می پذیرند oflag مشخص کردن بیت های مجوز خواندن / نوشتن (زمینه حالت ساختار ipc_perm) برای موضوع IPC و تعیین اینکه آیا یک شی IPC جدید ایجاد شده یا یک موجود موجود است. برای این قوانین قوانین زیر وجود دارد.
key کلید IPC_PRIVATE ایجاد یک شی منحصر به فرد IPC را تضمین می کند. هیچ ترکیب احتمالی از نام کامل و شناسه نمی تواند باعث شود عملکرد ftok IPC_PRIVATE به عنوان کلید بازگردد.
bit تنظیم مقدار آرگومان IPC_CREAT oflag در صورتی که قبلاً وجود نداشته باشد منجر به ایجاد یک رکورد جدید برای کلید مشخص شده می شود. در صورت یافتن سابقه موجود ، شناسه آن برمی گردد.
تنظیم همزمان بیت آرگومان IPC_CREAT و IPC_EXCL oflagمنجر به ایجاد یک رکورد جدید برای کلید مشخص شده تنها در صورت وجود چنین ضبط نمی شود. اگر یک رکورد موجود پیدا شود ، عملکرد یک خطای EEXIST را برمی گرداند (یک شیء IPC در حال حاضر وجود دارد).
ترکیبی از IPC_CREAT و IPC_EXCL برای اشیاء IPC مشابه عملکرد O_CREAT و O_EXCL برای عملکرد آزاد عمل می کند.
تنظیم فقط بیت IPC_EXCL بدون IPC_CREAT هیچ نتیجه ای ندارد.
نمودار منطقی توالی اقدامات هنگام باز کردن شی IPC در شکل نشان داده شده است. 3.2 در جدول 3.2 نمای دیگری از این فرآیند را نشان می دهد.
شکل 3.2 نمودار افتتاح شیء IPC
توجه داشته باشید که در ردیف وسط جدول قرار دارد. 3.2 برای پرچم IPC_CREAT بدون IPC_EXCL ، ما هیچ اطلاعاتی در مورد ایجاد یک شیء جدید یا دسترسی به یک موجود موجود دریافت نمی کنیم. برای اکثر برنامه ها ، سرور معمولی است که یک شیء IPC را با IPC_CREAT ایجاد کند (اگر فرقی نمی کند این شیء قبلاً وجود داشته باشد) یا IPC_CREAT | IPC_EXCL (در صورت صحت وجود شیء لازم است). مشتری به هیچ وجه پرچم ها را نشان نمی دهد ، با فرض اینکه سرور قبلاً شیء را ایجاد کرده است.
توجه داشته باشید
توابع IPC System V ، برخلاف توابع IPX Posix ، به جای استفاده از O_CREAT و OEXCL ، که توسط تابع استاندارد باز پذیرفته شده اند ، ثابت های IPC_xxx خود را تعریف می کنند (جدول 2.2).
توجه داشته باشید که توابع System V IPC ، ثابتهای IPC_xxx را با بیت های اجازه (که در قسمت بعدی توضیح داده شده است) در یک آرگومان تنها oflag ترکیب می کنند ، در حالی که تابع باز و عملکرد Posix IPC با دو آرگومان مشخص می شوند: oflag ، که در آن پرچم های فرم O_xxx تنظیم می شوند. ، و حالت ، که بیت اجازه دسترسی را تعریف می کند.
جدول 3.2. منطق ایجاد و باز کردن اشیاء IPC
| استدلال oflag | کلید وجود ندارد | کلید وجود دارد |
|---|---|---|
| هیچ پرچم خاصی تنظیم نشده است | خطا ، errno \u003d ENOENT | خوب ، باز کردن یک شی موجود |
| IPC_CREAT | خوب ، یک رکورد جدید ایجاد شده است. | خوب ، یک مورد موجود را باز کنید |
| IPC CREAT | IPC_EXCL | خوب ، یک رکورد جدید ایجاد شده است. | خطا ، errno \u003d EEXIST |
3.5. مجوزهای IPC
هنگام ایجاد یک شی IPC جدید با استفاده از یکی از توابع getXXX که با پرچم IPC_CREAT نامیده می شود ، اطلاعات زیر به ساختار ipc_perm وارد می شود (بخش 3.3):
1. بخشی از بیت های استدلال oflag مقدار فیلد حالت ساختار ipc_perm را تنظیم کنید. در جدول شکل 3.3 بیت های مجاز برای سه نوع IPC را نشان می دهد (نوشتن \u003e\u003e 3 به معنی جابجایی به سمت راست توسط سه بیت است).
2. قسمت cuid و cgid مقادیری برابر با شناسه معتبر کاربر و گروه فرآیند فراخوانی دریافت می کنند. به این دو زمینه شناسه های خالق گفته می شود.
3. زمینه های uid و gid از ساختار ipc_perm نیز با شناسه های موثر فرایند فراخوانی برابر است. به این دو قسمت شناسه مالک گفته می شود.
جدول 3.3. مقادیر حالت برای مجوزهای خواندن / نوشتن IPC
| تعداد (اکتال) | صف پیام | سمفور | حافظه مشترک | توضیحات |
|---|---|---|---|---|
| 0400 | MSG_R | SEM_R | SHM_R | کاربر خوانده شده |
| 0200 | MSG_W | SEM_A | SHM_W | کاربر - ضبط |
| 0040 | MSG R \u003e\u003e 3 | SEM_R \u003e\u003e 3 | SHM_R \u003e\u003e 3 | گروه - خواندن |
| 0020 | MSG_W \u003e\u003e 3 | SEM_A \u003e\u003e 3 | SHM_W \u003e\u003e 3 | ثبت گروه |
| 0004 | MSG_R \u003e\u003e 6 | SEM_R \u003e\u003e 6 | SHM_R \u003e\u003e 6 | دیگران - خواندن |
| 0002 | MSG_W \u003e\u003e 6 | SEM_A \u003e\u003e 6 | SHM_W \u003e\u003e 6 | دیگران - ضبط کنید |
شناسه خالق را نمی توان تغییر داد ، در حالی که با فراخوانی عملکرد ctlXXX برای این مکانیسم IPC با دستور IPC_SET می توان شناسه مالک را تغییر داد. سه عملکرد ctlXXX به این فرآیند اجازه می دهد تا بیت اجازه دسترسی (قسمت حالت) شیء IPC را تغییر دهد.
توجه داشته باشید
در اکثر پیاده سازی ها ، شش ثابت تعریف شده است: MSG_R ، MSG_W ، SEM_R ، SEM_A ، SHM_R و SHM_W که در جدول نشان داده شده است. 3.3 این ثابت ها در پرونده های هدر تعریف می شوند.
, و . با این حال ، استاندارد یونیکس 98 به آنها احتیاج ندارد. پسوند A در SEM_A به معنی "تغییر" (تغییر) است. سه عملکرد getXXX از ماسک استاندارد ایجاد فایل یونیکس استفاده نمی کند. مجوزهای صفحات پیام ، semaphore و حافظه مشترک دقیقا برابر با آرگومان تابع تنظیم می شوند.
Posix IPC از ایجاد کننده IPC نمی تواند مالکیت یک شی را تغییر دهد. Posix هیچگونه آنالوگ برای فرمان IPC_SET ندارد. اما ، در Posix IPC ، نام شی متعلق به سیستم پرونده است و بنابراین می توان مالک را با استفاده از دستور chown به عنوان کاربر ممتاز تغییر داد.
هنگامی که یک فرایند برای دستیابی به هدف IPC تلاش می کند ، بررسی دو مرحله ای انجام می شود: اولین بار که پرونده را باز می کنید (عملکرد getXXX) و سپس هر بار که به شی IPC دسترسی پیدا می کنید:
1. هنگام ایجاد دسترسی به یک موضوع IPC موجود با استفاده از یکی از توابع getXXX ، ابتدا آرگومان بررسی می شود oflag فرایند فراخوانی عملکرد. آرگومان نباید شامل بیت های دسترسی باشد که در قسمت حالت ساختار ipc_perm تنظیم نشده باشند (مربع پایین در شکل 3.2). به عنوان مثال ، یک فرآیند سرور می تواند با تنظیم مجدد بیت های خوانده شده برای گروه و سایر کاربران ، مقدار عضو حالت را برای صف پیام دریافتی خود تنظیم کند. هر فرایندی که سعی در مشخص کردن این بیت ها در یک استدلال دارد oflag عملکرد msgget خطایی دریافت می کند. لازم به ذکر است که این چک تولید شده توسط توابع getXXX کاربرد چندانی ندارد. این بدان معنی است که فرایند فراخوانی دارای اطلاعاتی است که در آن گروه از کاربران قرار دارد: ممکن است صاحب پرونده باشد ، ممکن است به همان گروه یا سایر کاربران تعلق داشته باشد. اگر فرآیند ایجاد مجدد برخی از بیت های مجوز را تنظیم کند و فرایند فراخوانی سعی در تنظیم آنها کند ، عملکرد getXXX خطایی را برمی گرداند. هر فرآیند می تواند با مشخص کردن یک استدلال ، این چک را به طور کامل پرش کند oflag برابر است با 0 اگر وجود یک شی IPC از قبل شناخته شده است.
2. برای هر عملیاتی با اشیاء IPC ، پروسه درخواست این عملیات مجوزها بررسی می شود. به عنوان مثال ، هر بار که یک فرایند سعی می کند با استفاده از دستور msgsnd یک پیام را صف کند ، بررسی های زیر انجام می شود (مراحل بعدی با دستیابی به دسترسی رد می شوند).
user کاربر ممتاز همیشه دسترسی دارد.
□ اگر شناسه معتبر کاربر معتبر با uid یا cuid از شیء IPC مطابقت داشته باشد و بیت اجازه دسترسی مربوطه در قسمت حالت موضوع IPC تنظیم شده باشد ، دسترسی مجاز خواهد بود. بیت مجوز دسترسی مربوطه بیتی است که اجازه می دهد خواندن را انجام دهد اگر فرایند فراخوانی درخواست خواندن را برای این شی IPC (به عنوان مثال دریافت پیام از صف) انجام دهد یا بیتی که در صورت تمایل می تواند آن را بنویسد نوشتن را امکان پذیر می کند.
□ اگر شناسه معتبر گروه معتبر با مقدار gid یا cgid شیء IPC مطابقت داشته باشد و بیت اجازه دسترسی مربوطه در قسمت mode از شی IPC تنظیم شده باشد ، دسترسی مجاز خواهد بود.
□ اگر دسترسی در مراحل قبلی مجاز نبود ، حضور بیت های دسترسی مجموعه تنظیم شده مربوط به سایر کاربران بررسی می شود.
3.6. استفاده مجدد از شناسه
ساختار ipc_perm (بخش 3.3) حاوی متغیر seq است که شماره سریال کانال را ذخیره می کند. این متغیر شمارنده ای است که هسته برای هر شیء IPC در سیستم شروع می کند. وقتی یک شی IPC حذف می شود ، تعداد کانال افزایش می یابد و هنگامی که سرریز می شود ، به صفر بازنشانی می شود.
توجه داشته باشید
در این بخش ، اجرای خاص SVR4 را شرح می دهیم. استاندارد یونیکس 98 امکان استفاده از گزینه های دیگر را ندارد.
به دو دلیل نیاز به پیشخوان است. ابتدا ، توصیف کننده های فایل ذخیره شده در هسته را برای هر یک از پرونده های باز به یاد بیاورید. آنها معمولاً اعداد صحیح کوچکی هستند که فقط در یک فرایند واحد مهم هستند - هر فرآیند توصیف کننده های خاص خود را دارد. خواندن از پرونده ای با توصیف 4 فقط در فرآیندی امکان پذیر است که یک پرونده باز با چنین توصیف کننده ای وجود داشته باشد. اینکه پرونده های باز با همان توصیف کننده در سایر مراحل وجود داشته باشد ، فرقی نمی کند. بر خلاف توصیف کننده پرونده ها ، شناسه های سیستم V IPC برای کل سیستم تنظیم می شوند ، نه برای فرآیند.
شناسه IPC توسط یکی از توابع getXXX برگردانده می شود: msgget، semget، shmget. مانند توصیف کننده پرونده ها ، شناسه ها عدد صحیحی هستند که برخلاف توصیف کننده ها ، برای همه پردازش ها یکسان هستند. اگر دو پردازش نامربوط (مشتری و سرور) از صف پیام یکسان استفاده کنند ، شناسه آن برگردانده شده توسط تابع msgget باید در هر دو فرآیند یک عدد صحیح یکسان داشته باشد تا دسترسی آنها به یک صف مشابه باشد. این ویژگی باعث می شود تا هر فرآیند ایجاد شده توسط یک مهاجم ، سعی کند تا پیامی را از صف ایجاد شده توسط برنامه دیگر بخواند ، مرتب سازی مرتبا از طریق شناسه های مختلف (اگر آنها عدد صحیح باشند) و به امید صف وجود داشته باشند که در حال حاضر باز است و برای همه قابل خواندن است. . اگر شناسه ها اعداد صحیح کوچک باشند (مانند توصیف کننده پرونده) ، احتمال یافتن شناسه صحیح در حدود 1/50 (با فرض حد 50 توصیف کننده فرآیند) خواهد بود.
برای از بین بردن این احتمال ، توسعه دهندگان ابزارهای IPC تصمیم گرفتند دامنه احتمالی مقادیر شناسایی را گسترش دهند تا همه عدد صحیح به طور کلی و نه فقط موارد کوچک شامل شود. پسوند دامنه با افزایش مقدار شناسه ای که با تعداد مدخل های موجود در جدول سیستم IPC در هر بار استفاده مجدد از یکی از آنها وارد فرایند فراخوانی شده ، فراهم می شود. به عنوان مثال ، اگر سیستم پیکربندی شده باشد که بیش از 50 صف پیام را به کار نبرد ، وقتی اولین بار برای اولین بار از رکورد استفاده می شود ، شناسه 0 به فرآیند برگردانده می شود پس از حذف این صف پیام ، هنگام تلاش برای استفاده مجدد از اولین رکورد در جدول ، شناسه 50 بازگردانده می شود و سپس مقادیر 100 را می گیرد. از آنجا که seq معمولاً به عنوان یک عدد صحیح طولانی بدون علامت تعریف می شود (ulong - به ساختار ipc_perm در بخش 3.3 مراجعه کنید) ، بازگشت به شناسه هایی که قبلاً مورد استفاده قرار گرفته اند ، هنگام ورود جدول استفاده می شود. 85899346 بار (با فرض اینکه عدد صحیح 32 بیتی باشد) 2/50 است.
دومین دلیل نیاز به وارد کردن شماره سریال کانال ، نیاز به از بین بردن استفاده مجدد از شناسه های System V IPC پس از مدت کوتاهی است. این کمک می کند تا اطمینان حاصل شود که سروری که زودرس خاتمه یافته و متعاقبا مجدداً راه اندازی شده است ، از همان شناسه استفاده نمی کند.
برای نشان دادن این ویژگی ، برنامه در لیست 3.2 ، ده مقادیر شناسایی کننده اول را که توسط msgget برگشت داده شده ، نشان می دهد.
لیست 3.2. شناسه صف ارسال پیام ده بار پشت سر هم7 msqid \u003d Msgget (IPC_PRIVATE ، SVMSG_MODE | IPC_CREAT)؛
8 printf ("msqid \u003d٪ d \\ n"، msqid)؛
9 Msgctl (msqid، IPC_RMID، NULL)؛
دفعه دیگر که حلقه عبور می کند ، msgget یک صف پیام ایجاد می کند ، و msgctl را با دستور IPC_RMID به عنوان یک آرگومان حذف می کند. SVMSG_MODE ثابت در پرونده هدر unipc.h ما (لیست B.1) تعریف شده و مجوزهای پیش فرض را برای صف پیام پیام سیستم V تعیین می کند. خروجی برنامه به این صورت خواهد بود:
هنگامی که برنامه را مجدداً راه اندازی کردید ، تصویر واضحی از این واقعیت خواهیم دید که شماره سریال کانال ، متغیری است که در هسته ذخیره می شود و حتی پس از اتمام فرآیند ، همچنان وجود دارد.
3.7 برنامه های Ipcs و ipcrm
از آنجا که اشیاء System V IPC در سیستم فایل ها به نام ها نقشه برداری نمی شوند ، نمی توانیم با استفاده از برنامه های استاندارد ls و rm ، لیست آنها را مشاهده یا حذف کنیم. درعوض ، در سیستمهایی که از این نوع IPC پشتیبانی می کنند ، دو برنامه ویژه ارائه می شود: ipcs ، که اطلاعات مختلفی را در مورد خواص سیستم V IPC و ipcrm نمایش می دهد ، که صف پیام پیام سیستم V ، semaphore یا بخش حافظه مشترک را حذف می کند. اولین این کارکردها از حدود ده گزینه خط فرمان پشتیبانی می کند که نمایش اطلاعات در مورد انواع مختلف IPC را کنترل می کند. دوم (ipcrm) می تواند تا شش پارامتر را مشخص کند. اطلاعات دقیق در مورد آنها را می توان در سیستم کمک دریافت کرد.
توجه داشته باشید
از آنجا که System V IPC توسط Posix بصورت استاندارد نیست ، این دستورات جزئی از Posix نیستند .2. آنها در استاندارد یونیکس 98 شرح داده شده اند.
3.8 محدودیت های هسته
اکثر پیاده سازی های سیستم IP IPC با محدودیت هسته داخلی مشخص می شوند. برای مثال ، این تعداد حداکثر صف های پیام یا حد مجاز در حداکثر تعداد semaphores در یک مجموعه است. مقادیر مشخصه این محدودیت ها در جدول آورده شده است. 6.2 ، 11.1 و 14.1. بیشتر محدودیت ها از اجرای اصلی سیستم V به ارث رسیده است.
توجه داشته باشید
بخش 11.2 كتاب و فصل 8 اجرای صف های پیام ، سمفورس ها و حافظه مشترك در سیستم V. شرح برخی از این محدودیت ها را در اینجا شرح داده است.
متأسفانه ، برخی از محدودیت های اعمال شده کاملاً دقیق هستند ، زیرا آنها از اجرای اصلی به ارث می برند ، که مبتنی بر سیستمی با فضای آدرس دهی کوچک بود (16 بیتی PDP-11). خوشبختانه ، اکثر سیستم ها به یک سرور اجازه می دهند برخی از محدودیت های پیش فرض را تغییر دهد ، اما مراحل مورد نیاز برای این کار مخصوص هر نسخه یونیکس است. در بیشتر موارد ، پس از ایجاد تغییرات ، راه اندازی مجدد هسته مورد نیاز است. متأسفانه ، برخی از پیاده سازی ها هنوز از اعداد صحیح 16 بیتی برای ذخیره برخی پارامترها استفاده می کنند ، و این در حال حاضر محدودیت های سخت افزاری را تنظیم می کند.
برای مثال در Solaris 2.6 20 چنین محدودیتی وجود دارد که می توان مقادیر فعلی آنها را با استفاده از دستور sysdef نمایش داد. توجه داشته باشید که اگر ماژول هسته مربوطه بارگیری نشود ، به جای مقادیر واقعی ، صفر نمایش داده می شود (یعنی قبلاً از این ابزار استفاده نشده است). با افزودن هر یک از عبارات زیر به پرونده / etc / system سیستم می توان این کار را حذف کرد. پرونده / etc / system هنگام راه اندازی مجدد سیستم خوانده می شود:
مجموعه msgsys: msginfo_msgseg \u003d مقدار
set msgsys: msginfo_msgssz \u003d مقدار
مجموعه msgsys: msginfo_msgtql \u003d مقدار
مجموعه msgsys: msginfo_msgmap \u003d مقدار
مجموعه msgsys: msginfo_msgmax \u003d مقدار
مجموعه msgsys: msginfo_msgmnb \u003d مقدار
مجموعه msgsys: msginfo_msgmni \u003d مقدار
تنظیم semsys: seminfo_semopm \u003d مقدار
تنظیم semsys: seminfo_semume \u003d مقدار
تنظیم semsys: seminfo_semaem \u003d مقدار
تنظیم semsys: seminfo_semmap \u003d مقدار
تنظیم semsys: seminfo_semvmx \u003d مقدار
تنظیم semsys: seminfo_semmsl \u003d مقدار
تنظیم semsys: seminfo_semmni \u003d مقدار
تنظیم semsys: seminfo_semmns \u003d مقدار
تنظیم semsys: seminfo_semmnu \u003d مقدار
تنظیم shmsys: shminfo_shmmin \u003d مقدار
shmsys را تنظیم کنید: shminfo_shmseg \u003d مقدار
shmsys را تنظیم کنید: shminfo_shmmax \u003d مقدار
تنظیم shmsys: shminfo_shmmni \u003d مقدار
شش شخصیت آخر نام در سمت چپ علامت برابر متغیرهای ذکر شده در جدول هستند. 6.2 ، 11.1 و 14.1.
در Digital Unix 4.0B ، sysconfig به شما امکان می دهد بسیاری از پارامترها و محدودیت های هسته را بشناسید یا تغییر دهید. در زیر خروجی این دستور ، با گزینه –q راه اندازی شده است. این فرمان محدودیت های فعلی را برای زیر سیستم ipc نشان می دهد. برخی از خطوط در خروجی که به ابزار IPC System V مربوط نیستند حذف شدند:
آلفا٪ / sbin / sysconfig –q ipc
با تغییر پرونده / etc / sysconfigtab می توانید مقادیر پیش فرض دیگر این گزینه ها را تعیین کنید. این کار باید با استفاده از برنامه sysconfigdb انجام شود. این پرونده همچنین در طی فرآیند راه اندازی سیستم خوانده می شود.
3.9 خلاصه
اولین آرگومان عملکردهایgetget ، semget و shmget کلید IPC System V است که این کلیدها با استفاده از عملکرد سیستم ftok با نام کامل پرونده محاسبه می شوند. همچنین می توانید کلید را روی IPCPRIVATE تنظیم کنید. این سه عملکرد یک شی جدید IPC ایجاد می کنند یا یک موجود موجود را باز می کنند و شناسه System V IPC را باز می گردانیم ، یک عدد صحیح که در آن برای شناسایی شیء در سایر عملکردهای مربوط به IPC استفاده می شود. این شناسه ها نه تنها در چارچوب یک فرآیند (مانند توصیف کننده پرونده) بلکه در کل سیستم نیز معنی دارند. آنها می توانند توسط هسته مورد استفاده مجدد قرار گیرند ، اما تنها پس از مدتی.
یک ساختار ipc_perm با هر شیء IPC IP System مرتبط است ، که شامل اطلاعاتی در مورد آن است ، مانند شناسه کاربر مالک ، شناسه گروه ، مجوزهای خواندن و نوشتن و غیره. اطلاعات همیشه در دسترس است (دسترسی به آن می توان با استفاده از یکی از توابع XXXctl با استدلال IPC_STAT به دست آورد) ، و در Posix IPC دسترسی به آن به اجرای آن بستگی دارد. اگر شیء Posix IPC در سیستم فایل ذخیره شود و نام آن را در آن بدانیم ، می توانیم با استفاده از ابزارهای استاندارد فایل سیستم ، به این اطلاعات دسترسی پیدا کنیم.
هنگام ایجاد یک شیء جدید یا باز کردن یک شی IPC موجود در سیستم ، getXXX دو پرچم (IPC_CREAT و IPC_EXCL) و 9 بیت مجوز را منتقل می کند.
بدون شک ، مشکل اصلی استفاده از System V IPC محدودیت های مصنوعی در اکثر پیاده سازی ها است. محدودیت هایی در اندازه اشیاء اعمال می شود و آنها از همان ابتدای اجرا به دست می آیند. این بدان معناست که استفاده فشرده از برنامه های IP V SystemCC نیاز به تغییر در محدودیت های هسته دارد و این تغییرات در هر سیستم متفاوت است.
تمرینات
1. در مورد عملکرد msgctl در بخش 6.5 بخوانید و برنامه را در لیست 3.2 تغییر دهید تا نه تنها شناسه نمایش داده شود ، بلکه زمینه Seq ساختار ipc_perm را نیز بدست آورید.
2. بلافاصله پس از اجرای Listing 3.2 ، برنامه ای را اجرا می کنیم که دو صف پیام ایجاد می کند. با فرض اینکه هیچ برنامه دیگری از زمان بوت شدن سیستم از صف های پیام استفاده نکرده است ، تعیین کنید که کدام مقادیر توسط شناسه به عنوان شناسه های پیام ارسال می شوند.
3. در بخش 3.5 اشاره شد که توابع getXXX System V IPC از ماسک ایجاد فایل استفاده نمی کند. یک برنامه آزمایشی بنویسید که کانال FIFO (با استفاده از عملکرد mkfifo که در بخش 4.6 توضیح داده شده است) و صف پیام System V را ایجاد کنید ، برای هر دو وضوح 666 (با فرمت هشت ضلعی) مشخص کنید. مجوزهای اشیاء ایجاد شده (FIFO ها و صف های پیام) را مقایسه کنید. قبل از شروع برنامه ، اطمینان حاصل کنید که مقدار umask غیر است.
4- سرور نیاز به ایجاد یک پیام منحصر به فرد برای مشتریان خود دارد. کدام یک ترجیح داده می شود: استفاده از برخی از نام فایل های ثابت (به عنوان مثال نام سرور) به عنوان آرگومان برای عملکرد ftok یا استفاده از کلید IPC_PRIVATE؟
5- لیست کردن 3.1 را طوری تغییر دهید که فقط کلید IPC و مسیر پرونده نمایش داده شود. برنامه find را اجرا کنید تا تمام پرونده های سیستم فایل خود را لیست کرده و خروجی را به برنامه تازه ایجاد شده خود منتقل کنید. با همان کلید در چه تعداد نام فایل مطابقت خواهد داشت؟
6. اگر سیستم شما دارای برنامه sar (گزارشگر فعالیت سیستم - اطلاعات مربوط به فعالیت سیستم) است ، دستور را اجرا کنید
تعداد عملیات در هر ثانیه با صف های پیام و سمفورها اندازه گیری شده در هر 5 ثانیه و 6 بار بر روی صفحه نمایش داده می شود.
یادداشت ها:
IPC مفهومی است که با آن ارتباط دارد ، اما درک این مسئله که مفصل تر است ، منطقی است.
مطالب:
صفحه نظری
همه حداقل یک کمی کار سیستم عامل معمولی را تصور می کنند.
حال تصور کنید که کار سیستم عامل ما که برای ما آشنا است ، به مضاعف شرارت آن تبدیل شده است ، که نه تنها به نظر نمی رسد به عنوان اصلی خود بلکه تمام وظایف خود را نیز انجام می دهد.
اگر در سیستم IPC ما وارد نشود ، چنین پیشرفتی می توانست اتفاق بیفتد.
اگر سوال وابستگی برنامه ها به یکدیگر را به خوبی مطالعه می کنید ، می توانید درک کنید که برنامه های کاملاً معدودی وجود دارند که به یکدیگر وابسته نیستند.
این کاملاً منطقی است ، زیرا برای ضریب بالای عملکرد هر سیستم ، بین اجزای آن صرفاً ضروری است.
به عنوان مثال ، هنگامی که یک فرد در کار خود یک سؤال دارد که به کار او بستگی دارد ، اطلاعات مورد نیاز خود را از برخی منبع دریافت می کند ، خواه آن شخص باشد یا از هر منبع دیگری.
اگرچه "هسته" رایانه ما جستجوی اطلاعات در یک منبع خاص است ، اما اصل روبات ها اساساً یکسان هستند.
اصل کار
برای عملکرد صحیح سیستم ، برنامه های کاربردی لزوماً نیاز به برقراری ارتباط بی وقفه بین خود دارند ، یا خود آنها باید بنا به درخواست فرآیندها ، اطلاعات لازم را ارائه دهند.
دقیقاً به همین دلیل نیاز به تبادل مداوم اطلاعات با برنامه ها است که تعدادی از مکانیسم ها در سیستم عامل ایجاد شده اند که وظیفه حفظ یک جریان ثابت و بدون خطا از اطلاعات را بر عهده دارند.
چنین مکانیسم ها یا برنامه ها "ارتباط بین پردازش" نامیده می شوند - با ترجمه ارتباطات فرآیندی (IPC).
مهم: IPC مکانیسم یا برنامه ای است که تبادل متقابل داده ها بین جریان / پردازنده اطلاعات پردازش را فراهم می کند.
این برنامه به طور مستقیم در سیستم عامل خود کار می کند ، و اساس انتقال هر گونه اطلاعات است.
نمونه های IPC
حتی قبل از توسعه فن آوری های شبکه ، مسئله نیاز به انتقال اطلاعات از یک پردازنده به پردازنده ای که روی یک رایانه واحد کار می کند ، اهمیت پیدا کرد.
نمونه های بسیار زیادی وجود دارد که این برنامه در مکانیسم های نسبتاً ابتدایی و امروزی مورد استفاده قرار گرفته است.
یکی از مثال های کلیدی را در نظر بگیرید که اهمیت IPC حتی در سیستم های بسیار ساده و اولیه را به وضوح نشان می دهد ، تا به امروز چیزی از نیازهای آن نگویید.
نسخه های قدیمی تر IPC مدرن در MS-DOS وجود داشت.
در فرآیند توسعه فناوری ، هنگامی که فناوری ها و سیستم های شبکه تازه شروع به توسعه مسیر طولانی خود می کردند ، نیاز به مکانیسم های ایجاد پردازنده های بهم پیوسته که در یک شبکه واحد پیاده سازی می شوند ، ظاهر می شود.
در آن زمان حل این مسئله بسیار مشکل ساز بود.
واقعیت این است که چنین ارتباطی می تواند داده ها را تبادل کند ، در صورتی که تنها سیستم عامل ها یا سیستم عامل های آنها به مدل های مشابه تعلق داشته باشد.
در یک شبکه مدرن ، این مشکلات مدت طولانی است که کسی را آزرده نمی کند. در اینجا نمونه ای کوتاه و مصور از کار در چنین شبکه هایی آورده شده است.
این فرایندها بر روی دو کامپیوتر مختلف انجام می شوند ، در دو مکان مختلف:
- مرورگر سیستم شما
- سرور - در هر سیستم دیگر یا کاملاً در هر نقطه.
و شما به هیچ وجه تعجب نمی کنید که سیستم عامل چیست.
با استفاده از اصول کلی عملکرد فرم هایی مانند IPC و نه تنها مانند آن ، از مفهوم مشتری-سرور عمدتاً استفاده می شود.
واضح است كه "مشتری" برنامه ای است كه اطلاعات را درخواست می كند ، و درخواست اطلاعات قبلاً به "سرور" می رود - برنامه ای كه اطلاعات لازم را ارائه می دهد.
موقعیت عمومی
با در نظر گرفتن تمام احتمالات و نمونه های استفاده از تعامل بین پردازنده ، خودتان می توانید اطمینان حاصل کنید که این نرم افزار برای سیستم عامل که به کار با آن عادت داریم ، کافی است.
زمینه های تعامل IPC در زیر ، هم در یک سیستم و هم در یک شبکه چند کاربره ذکر شده است.
امروزه الزامات سیستم عاملها متناسب با سطح فناوری در حال افزایش است.
این رشد ناشی از این واقعیت است که هر روز افزودنیهای بیشتر و بیشتری به سیستم عاملهای ما می آیند که به نوبه خود باعث بهبود مشخصات رایانه ما می شود.
اما کمتر کسی می داند که سیستم عامل های مدرن که پشتیبانی می کنند باید دارای چنین برنامه ها یا مکانیسم هایی باشند که هماهنگ سازی پردازنده ها را بدون استثناء متقابل و با حداقل تاخیر تضمین کنند.
این معیارها در عملکرد رایانه ما بسیار مهم هستند.
اگر ما در مورد یک سیستم چند منظوره ایده آل صحبت کنیم ، باید تمام فرآیندهای موجود در آن مستقل از یکدیگر باشند ، یعنی ناهمزمان.
در واقعیت ، چنین سیستم "ایده آل" غیرممکن است ، زیرا دیر یا زود موقعیت هایی بوجود می آیند که فرایندها نیاز به دسترسی به منابع مشترک دارند.
برای به دست آوردن این فرصت ، منابع ویژه در سطح سیستم عامل فراهم شده است که این فرصت را برای آنها فراهم می کند.
اما در اینجا ، البته ، بدون استثناء نیست. اجرای فرایندهای موازی می تواند باعث ایجاد مشکلاتی شود.
به عنوان مثال: هنگام کار با یکدیگر ، هر فرآیند دسترسی به داده های مشترک ، دسترسی به همه داده های دیگر را همزمان نمیسر می کند - این پدیده را طرد متقابل می نامند.
سه نوع اصلی IPC
- محلی
این نوع IPC کاملاً به رایانه شما گره خورده است ؛ کار فقط در یک سیستم (رایانه) انجام می شود.
این کار اصلی و اجباری برای کار فرآیندهای ارائه انتقال داده از طریق سیستم ، یعنی برای کانالها ، صف های پیام و حافظه مشترک است.
داده های IPC به دلیل محدودیت های آن از نظر فضای ارتباطی ، فقط می توانند در محدوده خاص خود کار کنند.
اما به لطف این محدودیت می توان از رابط های سریعتر و ساده تر برای آنها استفاده کرد.
- از راه دور
برای اطمینان از تعامل درون سیستم با یک پردازنده یا بین برنامه ها در پردازنده های مختلف متصل از طریق یک شبکه ، از مکانیزم های ویژه ای استفاده می شود که IPC از راه دور را ارائه می دهد.
- سطح بالا
آخرین و شاید یکی از دشوارترین استفاده از IPC سطح بالا است.
این نمایش یک بسته نرم افزاری است.
این بسته داده به اصطلاح "لایه میانی" ایجاد می کند ، که امکان برقراری ارتباط بین سیستم عامل و برنامه را فراهم می کند.
اطمینان از عملکرد صحیح تبادل داده
ابزارهای ICP همراه با عملکرد اصلی آن ، اطمینان از تعامل پردازنده ، به حل مشکلاتی که هنگام سازماندهی محاسبات موازی بوجود می آیند متصل می شوند.
در اینجا نمونه هایی از حوزه فعالیت آنها آورده شده است:
1 بهرقابتیه شرایط بین فرآیندها.ما می توانیم یک سیستم ایده آل را تصور کنیم که در آن تنها یک عمل انجام می شود ، آن خواندن داده ها از یک پرونده است. این سیستم تا زمانی که یکی از فرایندها نیاز به تغییر این پرونده داشته باشد در آرامش کامل قرار دارد. در این حالت ، "وضعیت رقابتی" بین فرایندها بوجود می آید. این را می توان با نوع سنگریزه در نوعی مکانیسم مقایسه کرد.
2 اطلاعات ضبط متوالی صف. به منظور فراهم آوردن امکان ثبت سریع و قابل اعتماد اطلاعات به کاربران ، صف های خاصی ایجاد می شوند. من فکر می کنم شما می دانید که یک خط چیست. اما در حقیقت ، نه یک ، بلکه دو صف ایجاد می شود. این صف ها فقط با واقعی تفاوت دارند که یکی از آنها فقط برای خواندن استفاده می شود و دیگری در حال حاضر به ما امکان می دهد تا اطلاعات لازم را ضبط کنیم. این صف به منظور جلوگیری از بن بست ایجاد شده است که در ادامه کمی صحبت خواهیم کرد.
در مورد فرایندهایی که به سرعت ذاتی در تصمیم خود نیاز دارند چیست؟
پیش از این ، هنگامی که صف های ذکر شده در بالا ایجاد شد ، مشکلی پیش آمد که در آن بعضی از فرآیندها می توانند مدت طولانی برای صف خود صبر کنند ، در زمانی که این روند فوری بود.
پس از مدتی ، این ایده ایجاد صف هایی بود که چنین روالهایی را انجام می داد که هیچ دخالتی در فرآیندهای اصلی یا مهمتر ندارند.
همچنین ، اصطلاحی وجود دارد که هم در تئوری و هم در عمل با نام آن قابل توجیه است - این یک بن بست است
خصوصیت آن این است که اگرچه فرایندها از قبل آزاد شده اند ، اما آنها برای تکمیل روند نمی توانند به مرحله بعدی حرکت کنند.
اگر توضیح ساده تر باشد ، در عمل موارد زیر بدست می آید: ما یک پروسه X داریم ، وقتی به پرونده X دسترسی پیدا می کند ، شروع به انتظار می کند تا پرونده Y آزاد شود ، تا کار خود را کامل کند. اما در کنار آنها ، روند Y با دسترسی به پرونده Y ، منتظر می ماند تا پرونده X آزاد شود.
این مراحل در حال حاضر بین خود بسته شده و در حالی که پرونده آنها منتشر نشده است منتظر انتشار متقابل پرونده هستند.
درصورتیکه کاربر از شماره گذاری منابع اطمینان حاصل کند ، از چنین "بسته شدن" جلوگیری می شود.
آنها همچنین باید به ترتیب صعودی از اعداد ساخته شوند.
نمونه های کنونی ICP
برای تجسم تعامل برنامه ها بر روی یک کامپیوتر ، یک منبع آشنا وجود دارد - کلیپ بورد.
تعجب نکنید ، کلیپ بورد قدیمی خوب ما نیز یکی از مکانیسم های IPC است.
و اصل کار آن به شرح زیر است: متنی که شما بعد از انتخاب از یک ویرایشگر متن انتخاب کرده اید در یک برنامه یا برای همان طرح قرار داده شده است.
شما خود می توانید اطمینان حاصل کنید که ردپای مکانیسم های ارتباطی بین پردازش حتی با جزئیات کوچک نیز می توان یافت.
تلاش های زیادی برای ایجاد برنامه ها یا سازوکارهایی انجام شده است که انتقال سریع و کارآمد اطلاعات بین پردازنده ها را تضمین می کند.
اگرچه تعداد کمی از چنین ابزارهایی ایجاد شده اند ، اما بسیاری از آنها هنوز پایه ای برای مدل های بعدی حفظ شده اند.
شایان ذکر است که بسیاری از آنها در ویندوز 9x و حتی بیشتر در ویندوز NT / 2000 پیاده سازی شده اند.
من می خواهم توجه شما را به این واقعیت جلب کنم که وجود یک روش جهانی برای تبادل داده هایی که در همه شرایط مفید باشند ، به سادگی غیرممکن است.
هر محیطی که کاربر خود را در آن پیدا کند - دقیقاً یکی از روشها ترجیح داده می شود ، اگرچه تفاوت زیادی در شرایط عادی وجود ندارد ، بین آنها.
اما می توانیم به شما اطمینان دهیم که پس از این مقاله ، دیگر امکان استفاده از منابع مرتبط با IPC یا انتخاب یک روش خاص روبات دشوار نخواهد بود ، وزن همه جوانب مثبت و منفی.
برای افرادی که فکر می کنند توسعه در این فناوری پیش بینی نشده است ، یک واقعیت وجود دارد که نظر شما را تغییر خواهد داد.
برنامه ها و مکانیسم هایی که با IPC در ارتباط هستند مستقیماً با سیستم عامل مرتبط هستند. یعنی با پیشرفت روبات ها ، کارایی و قابلیت اطمینان این منابع افزایش می یابد.
بسیاری از کاربران شبکه های محلی غالباً گمان نمی کنند که درایوهایشان منابع شبکه ای باشند که بتوانند به آنها متصل شوند ، به آنها منابع پنهان اداری و مشترک C $ ، ADMIN $ ، FAX $ ، IPC $ ، PRINT $ گفته می شود. اگر نیازی به آنها ندارید باید آنها را غیرفعال کنید!
انواع اشتراک شبکه در ویندوز XP / 200
به طور پیش فرض ، سهام اداری پنهان زیر می تواند در ویندوز XP / 2000 ایجاد شود:
- پارتیشن های ریشه یا حجم C $ ( D $ ، E $ ، F $ ، و غیره);
- دایرکتوری ریشه سیستم عامل ADMIN $
- سهم FAX
- سهم IPC $
- به اشتراک بگذارید PRINT $.
برای پارتیشن های ریشه ای و حجم به عنوان نام منبع اشتراکی از نام دیسک استفاده شده است که نماد "" $ " به عنوان مثال ، برای دسترسی به درایوها ج و د منابع اشتراکی ایجاد می شوند C $ و D $.
دایرکتوری ریشه سیستم عامل ( ٪ SYSTEMROOT٪) دایرکتوری است که سیستم عامل ویندوز در آن نصب شده است. منبع اشتراکی $ $ مدیر دسترسی مدیران به این پوشه را از طریق شبکه فراهم می کند.
اشتراک FAX استفاده شده توسط کاربران برای ارسال فکس. این پوشه پرونده ها و صفحات تحت پوشش در سرور پرونده را ذخیره می کند.
سهم IPC هنگام سازماندهی اتصالات موقتی ایجاد شده توسط برنامه های کاربردی برای تبادل داده ها با استفاده از لوله های نامگذاری شده استفاده می شود. به عنوان یک قاعده ، از آن برای مدیریت از راه دور سرورها در شبکه استفاده می شود.
به اشتراک بگذارید PRINT $ مورد استفاده برای مدیریت از راه دور چاپگرها.
اگر منابع اداری پنهان ایجاد شده توسط سیستم عامل را حذف کنید ( به عنوان مثال ADMIN $ یا C $) ، پس از راه اندازی مجدد رایانه یا راه اندازی مجدد سرویس سرور ، آنها دوباره ایجاد می شوند. اگر منابع اداری پنهان ایجاد شده توسط کاربران را حذف کنید ، پس از راه اندازی مجدد رایانه ، آنها دوباره بازیابی نخواهند شد. Microsoft Windows XP Home Edition سهام اداری پنهان ایجاد نمی کند.
اتصال به اشتراک شبکه در Windows XP / 2000
برای اتصال به اشتراک های پنهان اداری و شبکه می توانید از دستور استاندارد Windows XP / 2000 استفاده کنید. استفاده خالص:
دستور استفاده خالص این مورد برای اتصال و قطع ارتباط از منابع شبکه و نمایش اطلاعات در مورد اتصالات فعلی به این منابع مورد استفاده قرار می گیرد. اگر منبع شبکه درایو فعلی باشد یا توسط برخی برنامه در حال اجرا استفاده شود ، جدا کردن از چنین منبع غیرممکن است.
در زیر نمونه ای از استفاده از دستور استفاده خالص برای اتصال به یک اشتراک استاندارد است C $، رایانه ای که ویندوز 2000 با نام کامل Pro2000 در شبکه محلی واقع شده است:
دستور استفاده خالص با موفقیت تحت نام کاربری Administrator و یک رمز عبور خالی به پایان رسید! در اکثر موارد ، پس از نصب ویندوز ، رمز ورود به حساب کاربری با نام Administrator که به طور پیش فرض ایجاد شده است ، فراموش می شود یا به سادگی نمی خواهید تنظیم شود ، اما اتفاق می افتد که در هنگام نصب یک حساب کاربری دیگر ایجاد شده است ، و حسابی با نام Administrator به طور پیش فرض ایجاد می شود. بی نظیر مانده!
C: \\\u003e cd / d q: Q: \\\u003e dir حجم در دستگاه Q دارای برچسب نیست. جلد شماره سریال: 407D-A72A محتوای پوشه Q: 03/13/2012 08:46 0 AUTOEXEC.BAK 03/13/2012 08:57 اسناد و تنظیمات 06/17/2012 08:34 اینتل 04/01/2012 04:02 AM MySoft 06/17/2012 11: 35 NC 06/18/2012 10:10 OpenSSL-Win32 06/18/2012 10:08 فایلهای برنامه 06/25/2012 15:48 PUBLIC 05/18/2012 10:53 rms 04/29/2012 10:48 Temp 11/06/2012 10:28 PM WINDOWS 1 پرونده 0 بایت 10 پوشه 1 919 221 760 بایت رایگان Q: \\\u003e
پس از اتصال منبع C $ و ارتباط آن با نامه درایو ، منبع C $ در کاوشگر شما در دسترس خواهد بود و کار با آن درست مانند دیسک محلی معمولی امکان پذیر خواهد بود ، خوب ، و سپس همه چیز به توانایی ها و تخیل شما بستگی خواهد داشت ...
توجه !!! منابع اشتراك فقط در صورت فعال / اجراي خدمات سرور در دسترس خواهد بود ، و اگر نمي خواهيد منابع خود را به اشتراك گذاريد ، بهتر است نه فقط آن را متوقف كنيد بلكه كاملاً آن را غير فعال كنيد. سرویس سرور - پشتیبانی از اشتراک فایلها ، چاپگرها و لوله های نامگذاری شده برای یک کامپیوتر مشخص از طریق اتصال به شبکه را فراهم می کند. اگر سرویس متوقف شود ، چنین عملکردهایی با شکست مواجه می شوند. اگر این سرویس مجاز نیست ، شما نمی توانید خدمات کاملاً وابسته ای را شروع کنید.
مثال بالا به وضوح آسیب پذیری منابع شبکه باز را نشان می دهد. و حساب سرپرست ایجاد شده به طور پیش فرض با یک رمز عبور خالی! برای جلوگیری از شکل گیری چنین شکافهایی و در نتیجه نصب مجدد ویندوز با آناتیمای بعدی بیل گیتس ، فقط کافی است ابتدا ، به اصطلاح ، همه شکاف ها و حفره ها را بپوشانید.
غیرفعال کردن / حذف سهام شبکه
ساده ترین راه غیرفعال کردن سرویس دهنده سرور است ، اما برخی سرویس ها و برنامه ها به پشتیبانی آن نیاز دارند ، در این صورت غیرفعال کردن سرویس سرور برای ما مناسب نیست.
برای غیرفعال کردن سهام اداری و شبکه ( C $ ، ADMIN $ ، FAX $ ، IPC $ ، PRINT $) در ویندوز XP / 2000 شما نیاز دارید:
توجه داشته باشید! در ویندوز 2000 ، نیازی به افزودن پارامتر AutoShareWks نیست.
پس از راه اندازی مجدد رایانه ، کلیه منابع شبکه اشتراکی حذف می شوند ، به جز یک IPC $ ، نمی توان آن را حذف کرد:
منبع ویژه IPC $
منبعی را برای دسترسی به لوله های نامگذاری شده که ارتباط بین برنامه ها را فراهم می کند ، نشان می دهد. استفاده می شود برای مدیریت از راه دور یک کامپیوتر و مشاهده منابع مشترک در یک کامپیوتر. این منبع حذف نمی شود.
سهم ویژه IPC $ برای سرویس دهی به سرویس دهنده لازم است و نمی توان آن را حذف کرد. برای مشاهده لیست اشتراک های شبکه فعلی ، از دستور net sharing استفاده کنید
ما تکرار می کنیم که برای جلوگیری از ایجاد شکاف در منابع شبکه اشتراکی و در نتیجه مجدداً نصب مجدد ویندوز با آناتیمای بعدی بیل گیتس ، شما فقط باید ابتدا آن را بپوشانید ، به اصطلاح ، تمام شکاف ها و حفره ها را !!!
IPC $ چیست؟ من شنیده ام که هک از راه دور از طریق آن امکان پذیر است؟ آیا غیرفعال کردن این منبع ضروری است ، اگر چنین است ، چگونه آن را انجام دهیم؟
IPC $ یا همان ارتباط بین فرآیند ، یک منبع ویژه اداری برای ایجاد لوله های نامگذاری شده است. از طریق دوم ، رایانه اطلاعات مختلف سرویس را در وب تبادل می کند. IPC $ همچنین برای مدیریت سرور از راه دور (شکل 10.1) خدمت می کند.
شکل 10.1فعال کردن سرویس اشتراک شبکه IPC $
برای تصمیم گیری در مورد غیرفعال کردن این منبع یا نه ، باید موارد زیر را در نظر بگیرید:
¦ اگر این یک ایستگاه کاری است که باید از راه دور کنترل شود ، بهتر نیست که از هم جدا شوید.
¦ اگر ایستگاه کاری به مدیریت از راه دور نیازی ندارد ، می توانید آن را غیرفعال کنید.
¦ اگر این یک سرور است ، پس جدا کردن آن به هیچ وجه ارزش آن را ندارد ، زیرا دستیابی به آن از طریق شبکه غیرممکن خواهد بود.
IPC $ از طریق CMD با دستور net share ipc $ / Delete غیرفعال است (پس از راه اندازی مجدد ، این منبع هنوز به تنهایی روشن است ، بنابراین می توانید فایل BAT مربوطه را بنویسید و آن را در autoload قرار دهید).
رایانه من در یک شبکه محلی است. لازم است تا اطمینان حاصل شود كه دستگاه منبعی را برای دسترسی عمومی فراهم می كند و در عین حال به گونه ای كه منابع اشتراك پنهان C $ ، D $ و غیره در دسترس نباشد. چگونه آن را انجام دهیم؟
تنها کاری که باید انجام دهید ایجاد یک پارامتر AutoshareWks از نوع DWORD با مقدار تهی در بخش زیر است:.
کلاهبرداری چیست و چگونه می توانید خود را از آن محافظت کنید؟
در حقیقت ، کلاهبرداری جایگزین است. در این حالت منظورم IP spoofing است ، یعنی IP spoofing. جانشینی ، که در آن یک کاربر مخرب ، با استفاده از یک آدرس IP خارجی واقع در منطقه مورد اعتماد آدرس های IP یا یک آدرس خارجی مجاز ، وانمود می کند که می تواند شیء قابل اعتماد باشد. بیشتر اوقات ، برای محافظت در برابر کلاهبرداری IP ، از روش اتصال آدرس IP به آدرس کارت شبکه (آدرس MAC) استفاده می شود ، اما این روش نیز ناقص است: در حال حاضر ، برنامه های کاربردی که جایگزین MAC فعلی هستند شناخته می شوند.
چه چیزی خوفناک است و آیا پاداشهای خاصی در برابر آن وجود دارد؟
در ساده ترین حالت ، خرابکاری به معنای ضبط بسته از طریق وب است. به طور خاص تر: اسنایفر کارت شبکه (جایی که نصب شده است) را به اصطلاح "حالت نامفهوم" قرار می دهد ، به لطف آن دستگاه حمله کننده تمام بسته های شبکه ، حتی آنهایی را که برای آن در نظر گرفته نشده است ، ضبط می کند. نمونه ای از اسنایفر Cain & Abel است. به عنوان محافظت در هنگام ساختن شبکه محلی ، می توانید از سوییچ ها (سوئیچ) استفاده کنید نه هاب (توپی) و همچنین استفاده از پروتکل هایی که داده ها را به صورت واضح انتقال نمی دهند (SSH، SSL، Kerberos). اما حتی در این حالت ، امکان رهگیری بسته ها با استفاده از تکنیک های پیشرفته (به عنوان مثال ARP Poizoning) وجود دارد.
فیشینگ چیست و آیا می توانید خود را از آن محافظت کنید؟
فیشینگ روشی است برای فریب بازدید کنندگان سایت. خط آخر: بازدید کننده به سایتی بسیار شبیه به اصلی می رود ، ستون هایی را که نیاز به اطلاعات محرمانه دارند (شماره کارت اعتباری ، رمز عبور و غیره) پر می کند. علاوه بر این ، تمام این اطلاعات به مهاجمی که این سایت دروغین را ایجاد کرده است ارسال می شود. ابزارهای محافظت از فیشینگ را می توان در جدیدترین نسخه های مرورگرهای اینترنت و همچنین در بسته های ضد ویروس و فایروال ها یافت. با این حال ، باید دانست که تا به امروز هیچ روش موثری برای محافظت در برابر فیشینگ وجود ندارد. ابزار اصلی محافظت در این حالت هوشیاری کاربر است.
مشخص است که بسیاری از ویروس ها فایل های سیستم را با خود جایگزین می کنند. چگونه می توان این تعویض را تعیین کرد؟
برای اینکه همیشه از چنین "ترفندهای" آگاهی داشته باشید ، باید عملکرد اعلان محافظت از فایل را فعال کنید. این کار با وارد کردن رجیستری در HKEY_ LOCAL_MACHINE \\ Software \\ Microsoft \\ Windows \\ CurrentVersion \\ Sys-temFileProtection یک پارامتر از نوع DWORD ShowPopups برابر با 1 است.
چگونه رمزهای عبور ذخیره شده را در اینترنت اکسپلورر پاک کنیم؟
یک چیز نسبتاً راحت در Internet Explorer - خودکار و ذخیره سازی رمز عبور - یکپارچه شده است. برای پاک کردن رمزهای عبور ذخیره شده ، فقط موارد زیر را انجام دهید: در اینترنت اکسپلورر بروید ابزار\u003e گزینه های اینترنت\u003e محتوا\u003e داده های شخصی\u003e تکمیل خودکار ،سپس دکمه را فشار دهید رمزهای عبور را پاک کنید
چگونه می توانم آدرس سایت های بازدید شده را که به طور خودکار در نوار آدرس نمایش داده می شوند مخفی کنم وقتی وارد یک آدرس جدید می شوم؟
با حذف مطالب مربوط به رجیستری در ، چنین اثری قابل حذف است. توجه: سایر ردپاها در اینجا ذخیره می شوند ، مانند سابقه دسترسی به درایوهای از راه دور C $ ، D $ برای LAN ، تاریخچه آنچه که در فرم های جستجو تایپ کرده اید و غیره.
پس از بررسی توسط کسپرسکی ، مشخص شد که سابقه اصلی بوت در سیستم تغییر یافته است. چه چیزی می تواند باشد و چگونه می توان حالت اولیه ضبط بوت را بازیابی کرد (شکل 10.2)؟
شکل 10.2سوابق بوت را بررسی کنید؟
به احتمال زیاد ، bootloader اصلاح شده عواقب ویروس boot است ، اگرچه ممکن است که bootloader تغییر کرده باشد و نه به دلیل عفونت ویروس. می توانید bootloader را از کنسول بازیابی بازیابی کنید: برای این کار ، وارد کنسول ریکاوری شوید و دستورات تعمیر mbr و ثبت بوت را ثبت کنید. با انتخاب دیسک XP قابل راه اندازی ، می توانید از طریق دیسک XP قابل راه اندازی به Recovery Console باشید تعمیر instaLLation ویندوز XP ®و بازیابی ConsoLe ©.با این حال ، بهبودی از این طریق بهترین راه نیست. در بیشتر موارد ، بوت لودر هنوز بهبود نمی یابد. فقط نرم افزارهای تخصصی می توانند چنین مشکلاتی را حل کنند که نمونه بارز آن ADINF32 است.
به من بگویید که به روز رسانی ها در آنتی ویروس Kaspersky 7.0 ثبت شده اند. و سپس هنگام نصب مجدد سیستم ، مجبور خواهید شد بار دیگر همه به روزرسانی ها را بارگیری کنید.
به روزرسانی ها - پوشه بانک اطلاعاتی در محل قرار دارد و تنظیمات \\ همه کاربران \\ داده های برنامه \\ آزمایشگاه کسپرسکی \\ AVP7 \\ پایگاه ها.
با توجه به نتایج آزمایش های بیشمار ، می توان گفت که هیچ یک از مرورگرهای موجود 100٪ ایمن نیستند. در همین حال ، هنوز هم برخی از محصولات کاملاً بی خطر تلقی می شوند. یکی از این محصولات اپرا است.
اوضاع این است: رایانه من در شبکه محلی است و من از طریق کارت به اینترنت دسترسی دارم. محدودیت کارت قدیمی خسته شده است ، اما امکان ورود به سیستم و گذرواژه جدید وجود ندارد ، زیرا وقتی سعی می کنید به هر سایتی وارد شوید ، پنجره تأیید اعتبار با سرور ظاهر نمی شود (کلیه تنظیمات سرور پروکسی صحیح است). چگونه پنجره ورودی و رمز ورود را برگردانیم؟
برای ظاهر شدن مجدد پنجره تأیید اعتبار ، باید ورود و گذرواژه قدیمی را از طریق ضربه محکم و ناگهانی حذف کنید حسابهای کاربری(شکل 10.3) - برای این کار ، به منو بروید شروع کنید دویدندر قسمت پنجره ظاهر شده ، بر روی فرمان کنترل userpasswords2 وارد شوید بعلاوه؟ مدیریت رمز عبور؟ حذف کنید
هنگام بارگیری سیستم ضد ویروس کسپرسکی ، که قبلاً بدون خرابی کار می کرد ، به دلایلی شروع به کار کرد. وقتی سعی می کنید یک شروع را شروع کنید ، خودش را نیز جدا می کند. چه می تواند باشد و چگونه می توان با آن مقابله کرد؟
به احتمال زیاد ، سیستم شما به ویروس آلوده شده است که آنتی ویروس Kaspersky را غیرفعال می کند. چنین آلودگی به احتمال زیاد برای غیرفعال کردن سایر محصولات ضد ویروس محبوب است. راه کار این است که از یک محیط تمیز ، مانند دیسک بوت (Windows LiveCD) استفاده کنید. در ادامه ، به عنوان گزینه ، سیستم تحت این محیط را با یک آنتی ویروس که نیازی به نصب ندارد ، بررسی کنید (چنین ضد ویروس می تواند از طریق فلش درایو راه اندازی شود ، به عنوان مثال محصول محبوب Dr.Web CureIt Scanner (شکل 10.4) که می توانید از وب سایت رسمی Dr.Web بارگیری کنید)). .
شکل 10.3مدیریت رمز عبور
شکل 10.4اسکنر CureIt در عمل
من هارد من را با کسپرسکی چک کردم و ویروس واقعی را در توزیع پاندا تیتانیوم پیدا کردم! چگونه باشد
به احتمال زیاد پرونده به هیچ چیز آلوده نیست و نباید زنگ خطر را بالا بکشید. بیشتر برنامه های ضد ویروس هر وقت اسکن پرونده های سایر آنتی ویروس ها انجام می شوند.
من یک مدیر سیستم مبتدی هستم و می خواهم نظر شما را بدانم که کدام یک از سیستم عامل های سرور را می توان مطمئن ترین و پرکاربرد دانست؟
فایروال من دائماً بسته هایی را که از جایی با پرچم "syn" گزارش می شوند ، گزارش می دهد. این به چه معنی است؟
به احتمال زیاد ، شخص یا چیزی (مثلاً کرم شبکه) دستگاه شما را اسکن می کند. اسکن معمولاً آمادگی برای حمله است. بنابراین ، شما باید چیزی راجع به آن فکر کنید.
