ЛАБОРАТОРНА РОБОТА.
з предмету «Розподілені системи».
Тема: «Зв'язок типу Newcastle ».
Лабораторна робота.
Тема: Звязок типу NEWCASTLЕ .
Мета:Ознайомитись з принципом систем з менш сильним звязком.
Хід роботи.
Розглянемо системи з менш сильним зв'язком, які складаються з машин, що роблять звертання до файлів, що перебувають на других машинах. У мережі, що складається з персональних комп'ютерів і робітників станцій, наприклад, користувачі часто звертаються до файлів, розташованих на великій машині. У наступних двох розділах ми розглянемо такі конфігурації систем, у яких всі системні функції виконуються в локальних підсистемах, але при цьому є можливість звертання до файлів (через функції підсистеми керування файлами), розташованих на інших машинах.
Для ідентифікації віддалених файлів у цих системах використається один з наступних двох шляхів. В одних системах у складене ім'я файлу додається спеціальний символ: компонента імені, що передує цьому символу, ідентифікує машину, інша частина імені - файл, що перебуває на цій машині.
Так, наприклад, складене ім'я
"sftig!/fs1/mjb/rje"
ідентифікує файл "/fs1/mjb/rje", що перебуває на машині "sftig". Така
схема ідентифікації файлу відповідає угоді, встановленій програмою uucp щодо передачі файлів між системами типу UNIX. В іншій схемі віддалені файли ідентифікуються додаванням до імені спеціального префіксу, наприклад:
/../sftig/fs1/mjb/rje
де "/../" - префікс, що свідчить про те, що файл віддалений; друга компонента імені файлу є ім'ям віддаленої машини.
Процес-клієнт Процес-сервер
+-----------------------------+ +----------------------------+
| Таблиця | | Процес- |
| Сі-бібліотека відкритих | | супутник Запит |
| файлів | | (користу- на читання|
| +------+ | | вацький | | |
| +------------------ | | | рівень) | | |
| | +------+ | | | | |
| | локальний | | | | +-------------+ | |
| | +------+ | | | | |
| | +-------- | | | | | |
| | | +------+ | | | | |
| | | | | | | | | |
| | | +------+ | | | | |
| | +-----+ | | | | |
+----+------------------------+ +----+-----------------+-----+
| | віддалений | |
+----+------------------------+ +----+-----------------+-----+
| | Мережний | | | Мережний |
| Ядро інтерфейс | | Ядро інтерфейс |
| | | | | |
+--------------------+--------+ +----------------------+-----+
| мережа |
+-------------------------------------+
Малюнок 13.9. Формулювання запитів до файлового сервера (процесору)
У даній схемі використовується звичний синтаксис імен файлів у системі UNIX, тому на відміну від першої схеми тут користувальницьким програмам немає необхідності пристосовуватися до використання імен, що мають незвичайну конструкцію (див. [Pike85]).
Всю частину, що залишилася, ми присвятимо розгляду моделі системи, яка використовує зв'язок типу Newcastle, у якій ядро не займається розпізнаванням віддалених файлів; ця функція повністю покладає на підпрограми з стандартної Сі-бібліотеки, що виконують у цьому випадку роль системного інтерфейсу. Ці підпрограми аналізують перший компонент імені файлу, у 2 описаних способах ідентифікації утримуюча ознака дальності файла. У цьому складається відступ від заведеного порядку, при якому бібліотечні підпрограми не займаються синтаксичним розбором імен файлів. На
малюнку 13.9 показано, яким чином формулюються запити до файлового серверу. Якщо файл локальний, ядро локальної системи обробляє запит звичайним способом. Розглянемо зворотній випадок:
open("/../sftig/fs1/mjb/rje/file",O_RDONLY);
Підпрограма open із Сі-бібліотеки аналізує перші два компоненти складного імені файлу й дізнається, що файл варто шукати на віддаленій машині "sftig". Щоб мати інформацію про те, чи був раніше в процесі зв'язок з даною машиною, підпрограма заводить спеціальну структуру, у якій запам’ятовує цей факт, і у випадку негативної відповіді встановлює зв'язок з файловим сервером, що працює на віддаленій машині. Коли процес формулює свій перший запит на дистанційну обробку, віддалений сервер підтверджує запит, якщо буде потреба веде запис у поля користувальницького й групового кодів ідентифікації й створює процес-супутник, що буде відрізнятися від імені процесу-клієнта.
Щоб виконувати запити клієнта, супутник повинен мати на віддаленій машині тіж права доступу до файлів, що й клієнт. Інакше кажучи, користувач "mjb" повинен мати і до віддалених, і до локальних файлів однакові права доступу. На жаль, не виключена можливість того, що код ідентифікації клієнта "mjb" може збігтися з кодом ідентифікації іншого клієнта віддаленої машини. Таким чином, адміністраторам систем на працюючих у мережі машинах треба або стежити за призначенням кожному користувачеві коду ідентифікації, унікального для всієї мережі, або в момент формулювання запиту на мережне обслуговування виконувати перетворення кодів. Якщо це не буде зроблено, процес-супутник буде мати на віддаленій машині права іншого клієнта.
Більш делікатним питанням є одержання відносно роботи з віддаленими файлами прав суперкористувача. З одного боку, клієнт-суперкористувач не повинен мати ті ж права відносно віддаленої системи, щоб не вводити в оману засобу захисту віддаленої системи. З іншого боку, деякі із програм, якщо їм не надати права суперкористувача, просто не зможуть працювати. Прикладом такої програми є програма mkdir, що створює новий каталог. Віддалена система не дозволила б клієнтові створювати новий каталог, оскільки на видаленні права суперкористувача не діють. Проблема створення віддалених каталогів служить серйозною підставою для перегляду системної функції mkdir убік розширення її можливостей в автоматичному встановленні всіх необхідних користувачеві зв'язків. Проте, одержання setuid-програмами (до яких відноситься й програма mkdir) прав суперкористувача стосовно віддалених файлів все ще залишається загальною проблемою,