Література

1. http://www.linuxcenter.ru/lib/books/ftp/

Тема 12. Обмін файлами у мережах. Nfs, smb, BitTorrent

Вирішення задачі передачі даних з використанням мережевих файлових систем

На даний момент у вашому розпорядженні повинно бути працююче TCP/IP-підключення до вашої мережі. Ви повинні бути в змозі пінгувати інші комп'ютери мережі і, якщо ви відповідним чином налаштували шлюз, ви також повинні бути в змозі пінгувати комп'ютери в Інтернеті. Як відомо, головною метою підключення комп'ютера до мережі, є отримання доступу до інформації. Хоча деякі люди можуть підключати комп'ютер до мережі просто так, більшість людей хотіли б надавати і отримувати доступ до файлів і принтерів. Вони хотіли б отримувати доступ до документів в Інтернеті або грати в онлайнові ігри. Встановивши у свою нову систему Slackware підтримку TCP/IP і необхідне програмне забезпечення, ви все це отримаєте, а проте, встановивши тільки підтримку TCP/IP, функціональність буде дуже обмеженою. Щоб надавати і отримувати загальний доступ до файлів, нам буде потрібно переносити їх туди і назад, використовуючи FTP або SCP. Ми не можемо поглядати на нашому нової комп'ютері зі Slackware дерево файлів через значки "Мережеве оточення" або "Вся мережа" з Windows-комп'ютерів. Ми хотіли б мати можливість мати постійний доступ до файлів на інших Unix-машинах.

В ідеалі ми хотіли б використовувати мережеву файлову систему, що дозволяє нам мати прозорий доступ до файлів на комп'ютерах. Програмами, які ми використовуємо для роботи з інформацією, що зберігається на комп'ютерах, насправді навіть не треба знати на якому комп'ютері зберігається потрібний файл. Їм потрібно тільки знати, що цей файл існує, і спосіб для його отримання. Подальше вже є завданням операційної системи, що забезпечує доступ до цього файлу за допомогою доступних локальних і мережевих файлових систем. Дві найбільш часто використовувані мережеві файлові системи – це SMB (реалізована через Samba) і NFS.

Протокол NFS

Мережева файлова система (далі - NFS) є одним з видів файлових систем, відомих як розподілені файлові системи. Вона дозволяє користувачам звертатися до зберігаються на віддалених системах файлів навіть не підозрюючи, що вони працюють через мережу. Це дозволяє файловим системам бути розподіленими серед комп'ютерів. Ці віддалені системи можуть знаходитися в тій же кімнаті або на відстані декількох миль.

Щоб отримати доступ до таких файлів, необхідно виконати дві дії. Перше: дистанційна система повинна зробити файли доступними для інших систем в мережі. Друге: ці файли повинні бути змонтовані на локальній системі, щоб до них можна було звертатися. Процес монтування файлів призводить до того, що вони виглядають так, як ніби знаходяться в локальній системі. Система, яка робить свої файли доступними з мережі, називається сервером, і система, яка використовує віддалений файл, називається клієнтом.

NFS надає клієнтам прозорий доступ до файлів і файлової системи сервера. Це відрізняється від FTP, який забезпечує передачу файлів. За допомогою FTP здійснюється повне копіювання файлу. NFS здійснює доступ тільки до тих частин файлу, до яких звернувся процес, і основна перевага NFS в тому, що він робить цей доступ прозорим. Це означає, що будь-який додаток клієнта, яке може працювати з локальним файлом, з таким же успіхом може працювати і з NFS файлом, без яких або модифікацій самої програми.

NFS це додаток клієнт-сервер, побудований з використанням Sun RPC. NFS клієнти отримують доступ до файлів на NFS сервері шляхом відправки RPC запитів на сервер. Це може бути реалізовано з використанням звичайних користувальницьких процесів - а саме, NFS клієнт може бути користувача процесом, який здійснює конкретні RPC виклики на сервер, який так само може бути користувача процесом. Однак, NFS зазвичай реалізується інакше, це робиться з двох причин. По-перше, доступ до NFS файлів повинен бути прозорим для клієнта. Тому, виклики NFS клієнта здійснюються операційною системою клієнта від імені користувача процесу клієнта. По-друге, NFS сервера реалізовані всередині операційної системи для підвищення ефективності роботи сервера. Якби NFS сервер був користувача процесом, кожний запит клієнта і відгук сервера (включаючи дані, які будуть лічені або записані) повинен пройти через роздільник між ядром і користувача процесом, що взагалі досить дороге задоволення.

На рисунку 12.1 показані типові налаштування NFS клієнта і NFS сервера.

Рисунок 12.1 – Типові налаштування NFS клієнта і NFS сервера

На цьому рисунку необхідно звернути увагу на наступне:

1. Клієнту байдуже, чи отримує він доступ до локального файла або до NFS файлу. Ядро визначає це, коли файл відкритий. Після того як файл відкритий, ядро передає всі звернення до локальних файлів в квадратик, позначений як "доступ до локальних файлів", а всі посилання на NFS файли передаються в квадратик "NFS клієнт".

2. NFS клієнт відправляє RPC запити NFS сервера через модуль TCP/IP. NFS зазвичай використовує UDP, однак більш нові реалізації можуть використовувати TCP.

3. NFS сервер отримує запити від клієнта у вигляді UDP датаграм на порт 2049. Незважаючи на те, що NFS може працювати з перетворювачем портів, що дозволяє серверу використовувати динамічно призначаються порти, UDP порт 2049 жорстко закріплений за NFS в більшості реалізацій.

4. Коли NFS сервер отримує запит від клієнта, він передаються локальної підпрограмі доступу до файлу, яка забезпечує доступ до локальному диску на сервері.

5. Сервера може знадобитися час, для того щоб обробити запити клієнта. Навіть доступ до локальної файлової системи може зайняти деякий час. Протягом цього часу сервер не хоче блокувати запити від інших клієнтів, які також повинні бути обслужені. Щоб справитися з подібною ситуацією, більшість NFS серверів запускаються кілька разів, тобто усередині ядра існує кілька NFS серверів. Конкретні методи рішення залежать від операційної системи. У більшості ядер Unix систем не «живе» кілька NFS серверів, замість цього запускається кілька користувальницьких процесів (які зазвичай називаються nfsd), які здійснюють один системний виклик і залишаються всередині ядра в якості процесу ядра.

6. Точно так само, NFS клієнту потрібен час, щоб обробити запит від користувача процесу на хості клієнта. RPC видається на хост сервера, після чого очікується відгук. Для того, щоб користувальницькі процеси на хості клієнта могли в будь-який момент скористатися NFS, існує кілька NFS клієнтів, запущених всередині ядра клієнта. Конкретна реалізація також залежить від операційної системи. Unix система зазвичай використовує техніку, що нагадує NFS сервер: користувальницький процес, званий biod, здійснює один єдиний системний виклик і залишається всередині ядра як процес ядра.

Більшість Unix хостів може функціонувати як NFS клієнт і як NFS сервер, або як і те й інше одночасно. Більшість PC реалізацій (MS-DOS) мають тільки реалізації NFS клієнта. Більшість IBM мейнфреймів надає тільки функції NFS сервера.

NFS насправді – це щось більше, ніж просто NFS протокол. В таблиці 12.1 показані різні програми RPC, які використовуються з NFS.

Версії, які було наведено в таблиці 12.2 у вигляді одиниць, знайдені в таких системах як SunOS 4.1.3. Нові реалізації надають більш нові версії деяких програм. Solaris 2.2, наприклад, також підтримує версії 3 і 4 перетворювача портів і версію 2 демона mount. SVR4 також підтримує версію 3 перетворювача портів.

Демон монтування викликається на хості NFS клієнта, перед тим як клієнт може отримати доступ до файлової системи сервера. Ми опишемо цей процес нижче.

Менеджер блокування і монітор статусу дозволяють клієнту заблокувати частина файлів, які знаходяться на NFS сервері. Ці дві програми не залежні від протоколу NFS, тому що блокування потребує ідентифікації клієнта і на хості клієнта, і на сервері, а NFS сам по собі "байдужий". (Нижче ми скажемо про байдужості NFS більш докладно.) Глави 9, 10 і 11 [X/Open 1991] документують процедури, які використовуються менеджером блокування і монітором статусу для блокування в NFS.

Таблиця 12.1 - Різні RPC програми, використовувані в NFS

Додаток	Номер програми	Номер версії	Кількість процедур
Перетворювач портів	100000	2	4
NFS	100003	2	15
Програма mount	100005	1	5
Менеджер блокування	100021	1,2,3	19
Монітор статусу	100024	1	6

Одна з основ NFS реалізується описувачем файлів. Для звернення до файлу або директорії на сервері об'єкта використовується opaque. Термін opaque позначає, що сервер створює описувач файлу, передає його назад клієнтові, який клієнт потім використовує при зверненні до файлу. Клієнт ніколи не переглядає вміст описателя файлу - його вміст становить інтерес тільки для сервера.

NFS клієнт отримує описувач файлу кожного разу коли відкриває файл, який насправді знаходиться на NFS сервері. Коли NFS клієнт читає або пише в цей файл (за дорученням користувача процесу), описувач файлу передається назад серверу. Це вказує на те, що доступ до файлу був здійснений.

Зазвичай користувальницький процес не працює з описувачем файлів. Обмін описувачем файлів здійснюють NFS клієнт і NFS сервер. У версії 2 NFS описувач файлу займає 32 байти, а у версії 3 він виріс до 64 байт.

Unix сервери зазвичай зберігають у описувач файлу наступну інформацію: ідентифікатор файлової системи (major і minor номера пристрою файлової системи), номер инода (i-node) (унікальний номер усередині файлової системи), номер покоління инода (номер, який змінюється кожен раз, коли инод повторно використовується для іншого файлу).

На протязі 1994 року було випущені специфікації для версії 3 протоколи NFS [Sun Microsystems 1993]. Реалізації, як очікується, стануть доступними протягом 1994 року.

Тут коротко описані основні відмінності між версіями 2 і 3. Ми будемо називати їх V2 і V3:

1. Описувачі файлів у V2 це масив фіксованого розміру - 32 байта. У V3 це масив змінного розміру з розміром до 64 байт. Масив змінної довжини в XDR визначається 4-байтним лічильником, за яким слідують реальні байти. Це зменшує розмір описателя файлу в таких реалізаціях, як, наприклад, Unix, де потрібно всього близько 12 байт, проте дозволяє не-Unix реалізаціям обмінюватися додатковою інформацією.

2. V2 обмежує кількість байт на процедури READ або WRITE RPC розміром 8192 байта. Це обмеження не діє в V3, що, у свою чергу, означає, що з використанням UDP обмеження буде тільки в розмірі IP датаграми (65535 байт). Це дозволяє використовувати великі пакети при читанні і запису у швидких мережах.

3. Розміри файлів і початкове зміщення байтів для процедур READ і WRITE розширені з 32 до 64 біт, що дозволяє працювати з файлами більшого розміру.

4. Атрибути файлу повертаються в кожному виклику, який може вплинути на атрибути. Це зменшує кількість викликів GETATTR, необхідних клієнтом.

5. Записи (WRITE) можуть бути асинхронними, тоді як у V2 вони повинні були бути синхронними. Це може поліпшити продуктивність процедури WRITE.

6. Одна процедура була видалена (STATFS) і сім були додані: ACCESS (перевірка прав доступу до файлу), MKNOD (створення спеціального файлу Unix), READDIRPLUS (повертає імена файлів у директорії разом з їх атрибутами), FSINFO (повертає статистичну інформацію про файлову систему ), FSSTAT (повертає динамічну інформацію про файлову систему), PATHCONF (повертає POSIX.1 інформацію про фото) і COMMIT (передає раніше зроблені асинхронні запису на постійне зберігання).

Процедури авторизації і монтування

Клієнт використовує NFS протокол монтування, щоб змонтувати файлову систему сервера, перед тим як отримати доступ до NFS файлів. Зазвичай це відбувається при завантаженні клієнта. У результаті клієнт отримує описувач файлу файлової системи сервера.

На рисунку 12.2 описана послідовність дій Unix клієнта при виконанні команди mount.

При цьому здійснюються наступні кроки:

1. При завантаженні сервера на ньому стартує перетворювач портів.

2. Після перетворювача портів на сервері стартує демон монтування (mountd). Він створює кінцеву точку TCP і кінцеву точку UDP, а також призначає кожній з них динамічно призначається номер порту. Потім він реєструє ці номери у перетворювача портів.

3. Клієнт виповнюється команду mount, яка видає RPC виклик на перетворювач портів сервера, щоб отримати номер порту від демона монтування на сервері. Для обміну між клієнтом і перетворювачем портів можуть бути використані і TCP і UDP, проте зазвичай використовується UDP.

4. Перетворювач портів повідомляє номер порту.

5. Команда mount видає RPC виклик демону монтування, щоб змонтувати файлову систему сервера. І знову може бути використаний як TCP, так і UDP, проте зазвичай використовується UDP. Тепер сервер може перевірити "придатність" клієнта ґрунтуючись на його IP адресу і номер порту, щоб переконатися, чи можна цьому клієнту змонтувати зазначену файлову систему.

6. Демон монтування відгукується описувачем файлу зазначеної файлової системи.

7. Команда mount клієнта видає системний виклик mount, щоб зв'язати описувач файлу, отриманий у кроці 5, з локальною точкою монтування на хості клієнта. Описувач файлу зберігається в коді NFS клієнта, і з цього моменту будь-яке звернення користувача процесів до файлів на файловій системі сервера буде використовувати описувач файлу як стартову точку.

Рисунок 12.2 – Протокол монтування, використовуваний Unix командою mount

Подібна реалізація віддає весь процес монтування, крім системного виклику mount на клієнті, призначеним для користувача процесам, а не ядра. Три програми, які ми показали - команда mount, перетворювач портів і демон монтування - користувача процеси.

У цьому прикладі на хості sun (NFS клієнт) була виконана команда

# mount -t nfs bsdi:/usr /nfs/bsdi/usr

Ця команда монтує директорію /usr на хості bsdi (NFS сервер) як локальну файлову систему /nfs/bsdi/usr. На рисунку 12.3 показаний результат.

Рисунок 12.3 – Монтування директорії bsdi:/usr як /nfs/bsdi/usr на хості sun

NFS сервер надає 15 процедур, які ми зараз опишемо. (Числа, які використані при описі, не збігаються з номерами NFS процедур, так як ми згрупували їх за функціональною ознакою). Попри те, що NFS розроблялася таким чином, щоб працювати між різними операційними системами, а не тільки між Unix системами, деякі з процедур засновані саме на Unix функціонуванні, що, у свою чергу, може не підтримуватися іншими операційними системами (наприклад, жорсткі лінки, символічні лінки, групове користування, права доступу на виконання і так далі).

1. GETATTR. Повертає атрибути файлів: тип файлу (звичайний файл, директорія і так далі), права доступу, розмір файлу, власника файлу, час останнього звернення і так далі.

2. SETATTR. Встановлює атрибути файлу. Встановлено може бути тільки певний набір атрибутів: права доступу, власник, групове володіння, розмір, час останнього звернення і час останньої модифікації.

3. STATFS. Повертає статус файлової системи: розмір вільного простору, оптимальний розмір для передачі і так далі. Використовується, наприклад, Unix командою df.

4. LOOKUP. "Оцінює" файл. Ця процедура викликається клієнтом щоразу, коли користувальницький процес відкриває файл, який знаходиться на NFS сервері. Повертається описувач файлу, разом з атрибутами файлу.

5. READ. Читає з файлу. Клієнт вказує описувач файлу, початковий зсув в байтах і максимальна кількість байтів, яке необхідно вважати (до 8192).

6. WRITE. Записує у файл. Клієнт вказує описувач файлу, початковий зсув в байтах, кількість байт, яке необхідно записати, і дані, які необхідно записати.

7. Потрібно, щоб NFS записи були синхронними (з очікуванням). Сервер не може відповісти OK доти, поки дані не були успішно записані (і будь-яка інша інформація про фото, яка повинна бути оновлена) на диск.

8. CREATE. Створює файл.

9. REMOVE. Видаляє файл.

10. RENAME. Перейменовує файл.

11. LINK. Робить жорсткий лінк на файл. Жорсткий лінк це Unix концепція, яка визначає, що конкретний файл на диску може мати будь-яку кількість точок входу (імен, які також називаються жорсткими лінками), які вказують на цей файл.

12. SYMLINK. Створює символічний лінк на файл. Символічний лінк це файл, який містить ім'я іншого файлу. Більшість операцій, що здійснюються над символічним лінком (наприклад, відкриття), насправді відбуваються з тим файлом, на котрий вказує символічний лінк.

13. READLINK. Читання символічного лінка повертає ім'я файлу, на який вказує символічний лінк.

14. MKDIR. Створює директорію.

15. RMDIR. Видаляє директорію.

16. READDIR. Читаю директорію. Використовується, наприклад, Unix командою ls.

Насправді, наведені імена процедур починаються із префікса NFSPROC_, який ми опустили.

NFS був спочатку написаний, щоб використовувати UDP, і цю можливість надають всі виробники. Однак, більш нові реалізації, також підтримують TCP. Підтримка TCP використовується для роботи в глобальних мережах, які стає все швидше. Тому використання NFS в даний час вже не обмежена локальними мережами.

Межі між локальними і глобальними мережами стираються, і все це відбувається дуже швидко. Часи повернення змінюються в дуже широкому діапазоні, і все частіше виникає переповнення. Ці характеристики глобальних мереж призводять до того, що все частіше в них використовуються алгоритми, які ми розглядали для TCP - повільний старт і уникнути переповнення. Так як UDP не надає нічого схожого на ці алгоритми, то вони або їм подібні повинні бути вбудовані в NFS клієнт і сервер, інакше необхідно використовувати TCP.

Реалізація NFS Berkeley Net/2 підтримує як UDP, так і TCP. [Macklem 1991] описує цю реалізацію. Давайте розглянемо, чим відрізняється використання NFS при роботі поверх TCP.

Коли сервер завантажується, він запускає NFS сервер, який здійснює активне відкриття на TCP порт 2049, очікуючи приходу запиту на з'єднання від клієнта. Це зазвичай робиться на додаток до звичайного NFS UDP, який очікує входять датаграми на UDP Порті 2049.

Коли клієнт монтує файлову систему сервера з використанням TCP, він здійснює активне відкриття на TCP порт 2049 на сервері. При цьому встановлюється TCP з'єднання між клієнтом і сервером для цієї файлової системи. Якщо той же самий клієнт монтує ще одну файлову систему на тому ж самому сервері, створюється ще одне TCP з'єднання.

І клієнт, і сервер встановлюють TCP опцію "залишайся в живих" на своїх кінцях з'єднання. Це дозволяє визначити момент виходу з ладу або перезавантаження того чи іншого учасника обміну.

Всі додатки на клієнті, які використовують файлову систему сервера, ділять одне і те ж TCP з'єднання для цієї файлової системи. Наприклад, якщо була на рисунку 12.3, б ще одна директорія на bsdi, з ім'ям smith, нижче директорії /usr, звернення до файлів в /nfs/bsdi/usr/rstevens та /nfs/bsdi/usr/smith ділили б одне і те ж TCP з'єднання.

Якщо клієнт визначає, що сервер вийшов з ладу або перезавантажився (після отримання TCP помилки "з'єднання закрито по тайм-ауту" або "з'єднання закрито хостом"), він намагається повторно під'єднатися до сервера. Клієнт здійснює ще одне активне відкриття, щоб повторно встановити TCP з'єднання для цієї файлової системи. Будь-який запит від клієнта, для якого відпрацьований тайм-аут на попередньому з'єднанні, повторно видається на нове з'єднання.

Якщо клієнт вийшов з ладу, то ж відбувається і з додатками, які працювали до виходу з ладу. Коли клієнт перезавантажується, він, можливо, повторно змонтує файлову систему сервера з використанням TCP, причому буде використано інше TCP з'єднання з сервером. Попереднє з'єднання між клієнтом і сервером для цієї файлової системи знаходиться в напіввідкритому стані (сервер думає, що воно все ще відкрито), однак оскільки сервер встановив опцію "залишайся в живих", це напіввідкрите з'єднання буде закрито, коли TCP сервер пошле наступну пробу " залишайся в живих ".

З часом і інші виробники планують розпочати підтримку NFS поверх TCP.

Стек NetBIOS/SMB

Фірми Microsoft і IBM спільно працювали над мережевими засобами для персональних комп'ютерів, тому стек протоколів NetBIOS/SMB є їх сумісним дітищем. На фізичному і канальному рівнях цього стека використовуються всі найбільш поширені протоколи Ethernet, Token Ring, FDDI і інші. Засоби NETBIOS з'явилися в 1984 році як мережеве розширення стандартних функцій базової системи вводу/виводу (BIOS) IBM РС для мережевої програми РС Network фірми IBM, яка на прикладному рівні (табл. 12.2) використовувала для реалізації мережевих сервісів протокол SMB (Server Message Block).

Таблиця 12.2 - Стек NETBIOS/SMB

Прикладний	SMB
Відображення
Сеансів
Транспортний	NetBIOS
Мережевий
Канальний	Канальний
Фізичний

Надалі цей протокол був замінений так званим протоколом розширеного призначеного для користувача інтерфейсу NetBEUI NetBIOS Extended User Interface. Для забезпечення сумісності додатків як інтерфейс до протоколу NetBEUI був збережений інтерфейс NetBIOS. Протокол NetBEUI розроблявся як ефективний протокол, що споживає небагато ресурсів і призначений для мереж, що нараховують не більше за 200 робочих станцій. Цей протокол містить багато корисних мережевих функцій, які можна віднести до мережевого, транспортного і сеансовому рівнів моделі OSI, однак з його допомогою неможлива маршрутизація пакетів. Це обмежує застосування протоколу NetBEUI локальними мережами, не розділеними на підмережі, і унеможливлює його використання в складових мережах. Деякі обмеження NetBEUI знімаються реалізацією цього протоколу NBF (NetBEUI Frame), яка включена в операційну систему Microsoft Windows NT.

Протокол SMB (Server Message Block) виконує функції сеансового, представницького і прикладного рівнів. На основі SMB реалізовується файлова служба, а також служби друку і передачі сполучень між додатками.

Протокол NETBIOS працює на трьох рівнях моделі взаємодії відкритих систем: мережевому, транспортному і сеансовому. NETBIOS може забезпечити сервіс більш високого рівня, ніж протоколи IPX і SPX, проте не володіє здатністю до маршрутизації. Таким чином, NETBIOS не є мережевим протоколом в строгому сенсі цього слова. NETBIOS містить багато корисних мережевих функцій, які можна віднести до мережевого, транспортного і сеансового рівнів, проте з його допомогою неможлива маршрутизація пакетів, оскільки в протоколі обміну кадрами NETBIOS не вводиться таке поняття як мережа. Це обмежує застосування протоколу NETBIOS локальними мережами, не розділеними на підмережі. NETBIOS підтримує як дейтаграммний обмін, так і обмін зі встановленням з'єднань. Протокол SMB (Server Message Block) виконує функції сеансового, представницького і прикладного рівнів моделі OSI. На основі SMB реалізовується файлова служба, а також служби друку і передачі сполучень між додатками. У функції SMB входять наступні операції:

• Управління сесіями. Створення і розрив логічного каналу між робочою станцією і мережевими ресурсами файлового сервера.

• Файловий доступ. Робоча станція може звернутися до файл-серверу із запитами на створення і видалення каталогів створення, відкриття і закриття файлів, читання і запис у файли, перейменування і видалення файлів, пошук файлів, отримання і установку файлових атрибутів, блокування записів.

• Сервіс друку. Робоча станція може ставити файли в чергу для друку на сервері і отримувати інформацію черги друку.

• Сервіс повідомлень. SMB підтримує просту передачу повідомлень з наступними функціями: послати просте повідомлення; послати широкомовне повідомлення; послати початок блоку повідомлень; послати текст блоку повідомлень; послати кінець блоку повідомлень; переслати ім'я користувача; відмінити пересилку; отримати ім'я машини.

На канальному рівні стеку NetBIOS/SMB використовують ті самі протоколи та технології, що й для стеку TCP/IP. SMB (Server Message Block) – протокол, що забезпечує прикладному процесу доступу до файлів та принтерів інших комп’ютерів. NetBIOS (Network Basic Input/Output System) – протокол, що доповнює базову систему (BIOS) персональних комп’ютерів типу IBM PC функціями для роботи у мережі.

Порівнюючи між собою можливості двох стеків NetBIOS/SMB та TCP/IP, бачимо, що кожен з них займає своє особливе місце за призначенням. Стек NetBIOS/SMB дозволяє легко створювати невеликі мережі, а ті ускладнення, які пов’язані з використанням стеку TCP/IP, виправдовуються можливістю утворення міжмережних зв’язків та підключення до всесвітньої мережі Інтернет. Через велику кількість додатків, які використовують функції API, NETBIOS, що надаються, в багато мережевих ОС ці функції реалізовані у вигляді інтерфейсу до своїх транспортних протоколів. У NetWare є програма, яка емулює функції NETBIOS на основі протоколу IPX, існують програмні емулятори NETBIOS для Windows NT і стека TCP/IP.

Протокол SMB/CIFS

Загальний протокол доступу до файлів Інтернет (Common Internet File System - CIFS) своїм походженням зобов'язаний технології блока серверних повідомлень (Server Message Block - SMB), яка вперше з'явилася в MS DOS 3.3. У стандарті SMB описаний протокол відправки команд файлової системи (відкрити файл, вважати, записати, блокувати і закрити) від клієнта до файлового серверу.

Перед обговоренням технічних подробиць технологій CIFS і SMB необхідно з'ясувати основні відмінності між ними. Спочатку існувала тільки технологія SMB, яка використовувалася як клієнт-серверного файлового протоколу в світі персональних комп'ютерів. У середині 1980-х років компанія Microsoft дала своєї реалізації протоколу SMB на ¬ звання CIFS і почала позиціонувати CIFS в якості прямого конкурента стандартів WebNFS і NFS. Компанія Microsoft надала ознайомчий документ RFC на розгляд групі IETF (Internet Engineering Task Force), і згодом термін дії документа закінчився без спроб перетворити RFC в одну з специфікацій IETF.

Незалежні від компанії Microsoft постачальники пристроїв NAS приступили до розробки специфікації CIFS і організували кілька заходів для популяризації CIFS. Асоціація SNIA (Storage Networking Industry Association) взяла на себе завдання публікації CIFS. Компанія Microsoft також випустила специфікацію CIFS (вона називалася Common Internet Filesystem Access Protocol), що розповсюджувалася безкоштовно.

У схожих один на одного специфікаціях SNIA CIFS і CIFS від компанії Microsoft описується протокол, використовуваний клієнтами Windows NT 4.0 для отримання доступу до ресурсів серверів Windows NT. В обох специфікаціях не розглядається протокол SMB, який застосовується в нових версіях Windows (наприклад, не зачіпається клієнтське кешування, яке підтримується в Windows 2000). Крім того, у специфікаціях не описані всі протоколи взаємодії між серверами. Новий стандарт SMB, що не належить до безкоштовних специфікаціям, описаний у відповідній специфікації, яка за певну плату поширюється компанією Microsoft, що стало можливим завдяки судовим рішенням Європейського Союзу та уряду США.

Таким чином, компанія Microsoft знову стала називати свою реалізацію описуваної технології блоком SMB. По суті, SMB від Microsoft - це закритий протокол, який представляє собою розширену версію індустріального стандарту CIFS.

Крім того, слід звернути увагу на історичний зв'язок між SMB/CIFS і NetBIOS. Програмний інтерфейс NetBIOS (рівень сеансу в моделі OSI) на даний момент безнадійно застарів. Інтерфейс реалізує рівень абстракції, який дозволяє додаткам працювати з різними транспортними протоколами, наприклад TCP/IP, NetWare або вже забутим протоколом XNS (Xerox Network System). Необхідність в програмному інтерфейсі додатків, який надає можливість створення додатків, що не залежать від мережевого протоколу, існує і понині. Однак зараз для цього зазвичай використовується інтерфейс сокетів, зокрема у світі Windows - інтерфейс Winsock.

Компанія Microsoft використовувала NetBIOS для перетворення імен (пре ¬ освіти імені сервера в мережевий адресу), але зараз для цього призначена стандартна служба DNS.

Спочатку Microsoft не використала TCP/IP в якості транспортного протоколу, що кардинально змінилося з часом, проте підтримка NetBIOS продовжувала бути присутнім. Проте роль NetBIOS постійно зменшувалася. Після призначення порту TCP/IP для файлових серверів SMB залежність від NetBIOS була повністю "вилікувана", принаймні в контексті базового протоколу. Але ситуація залишалася заплутаною, оскільки деяким вторинним службам клієнтів і серверів Windows все одно був потрібний протокол NetBIOS. Хорошим прикладом буде оголошення серверами про свою присутність в мережі і надання списку доступних служб, а також передача цих оголошень клієнтам іншими серверами. З часом служби були перероблені і NetBIOS був повністю знятий з рахунків з виходом Windows 2000.

Нарешті, спадщина SMB можна помітити в кожному запиті CIFS, оскільки кожний запит і відповідь повинні починатися зі значення "0xFF", після чого йдуть такі символи ASCII, як "SMB".

Альтернативна реалізація із вільним вихідним кодом – сервер SAMBA

Samba – вільна реалізація мережевого протоколу SMB/CIFS. Samba випускається під ліцензією GNU. Назва Samba походить від SMB – назви протоколу, який використовується Microsoft Windows для мережевої файлової системи. Головною перевагою Samba є те, що з її допомогою можливо використовувати у мережі одночасно комп'ютери з операційними системами Windows та Unix, організовувати обмін файлами між ними без окремого Windows-сервера.

Починаючи з третьої версії Samba надає служби файлів і друку для різних клієнтів Microsoft Windows, і може інтегруватися з Windows Server: або як Основний контролер домену (PDC), або як член домену. Вона також може бути частиною домену Active Directory. З версії 3 Samba підтримує файлові сервіси та сервіси для друку.

Виконується на більшості Unix-подібних систем, таких як: Linux, Solaris, BSD, Mac OS X Server. Входить до більшості дистрибутивів Linux. В OS/2 портований samba-клієнт, плагіном до віртуальної файлової системи NetDrive.

Головною відмінністю від серверних версій Windows є відсутність підтримки для групових політик (непряма підтримка в принципі можлива) і налаштувань профайлів користувачів і комп'ютерів.

Ендрю Триджелл (Andrew Tridgell) розробив першу версію Samba Unix в 1992 році, в Австралійському національному університеті. «nbserver 1.5» був випущений в грудні 1993 року. Триджелл пізніше з'ясував, що протокол був багато в чому схожий на той, який використовується в інших мережевих серверних системах, зокрема Microsoft’s LAN Manager. І тоді він вирішив зосередитися на мережевій сумісності з продуктами Microsoft.

Самба спочатку називався smbserver. Назва була змінена у зв'язку із сповіщенням від компанії «Syntax», яка є власником товарного знаку на «SMBserver», про порушення права на торгову марку.

Під загальною назвою Samba знаходяться декілька пакетів, що служать для роботи Samba, налаштування і виконання необхідних функцій:

smbd – демон Samba, що забезпечує обслуговування користувачів, які хочуть доступитися до загальних документів сервера;

nmbd – демон сервера імен NetBIOS, які забезпечують доступ до служб імен NetBIOS через IP, одним словом, завдяки цьому системи під керівництвом Windows бачать в своєму мережевому оточенні систему під керівництвом Unix-подібних систем;

samba-client – пакет, що дозволяє працювати із загальними документами на системі під Windows та серверів Linux

samba-SWAT (Samba Web Administration Tool) – засіб що дозволяє керувати сервером Samba через веб-інтерфейс;

smbstatus – пакет для моніторингу Samba;

smbpasswd – керування паролями Samba;

testparm – перевірка конфігураційного файла Samba;

testprns – перевірка конфігурації принтерів;

і є кілька незначних пакунків:

Ksamba – для прихильників KDE режиму в Linux утиліта для конфігурації Samba;

smbedit – програма для редагування конфігураційного файла для операційної системи Windows.

Для встановлення Samba на операційній системі FreeBSD достатньо виконати такі команди:

# cd /usr/ports/net/samba4

# make install clean

Мережі обміну даними peer-to-peer на прикладі протоколу BitTorrent

BitTorrent (букв. англ. «Бітовий потік») - пірінговий (P2P) мережевий протокол для кооперативного обміну файлами через Інтернет. Файли передаються частинами, кожен torrent-клієнт, отримуючи (викачувавши) ці частини, в той же час віддає (закачує) їх іншим клієнтам, що знижує навантаження і залежність від кожного клієнта-джерела і забезпечує надмірність даних.

Протокол був створений Бремом Коеном, який написав перший torrent-клієнт «BitTorrent» на мові Python 4 квітня 2001. Запуск першої версії відбувся 2 липня 2001 року. Існує безліч інших програм-клієнтів для обміну файлами по протоколу BitTorrent. Роздача може містити як один файл, так і декілька, наприклад, вміст директорії.

Для кожної роздачі створюється файл метаданих з розширенням. Torrent, який містить наступну інформацію:

-URL трекера;

-Загальну інформацію про файли (ім'я, довжину і ін.) в даній роздачі;

-Контрольні суми (точніше, хеш-суми SHA1) сегментів файлів, що роздаються;

-Passkey користувача, якщо він зареєстрований на даному трекері, довжина ключа встановлюється трекером;

- (Необов'язково) хеш-суми файлів цілком;

- (Необов'язково) Альтернативні джерела, що працюють не за протоколом BitTorrent, найбільш поширена підтримка так званих web-сідів (протокол HTTP), але допустимими також є ftp, ed2k, magnet URI.

Розмір сегмента регулюється при створенні торрента і, як правило, вибирається розмір, відповідний ступеню двійки. При виборі розміру необхідно дотримувати баланс, пов'язаний з механізмом роботи протоколу (див. нижче). Розмір сегмента найчастіше лежить в діапазоні від 128 кілобайт до 2-4 мегабайт, хоча на дуже великих роздачах (порядку сотні гігабайт) можуть використовуватися сегменти розміром 32-64 мегабайта.

Якщо роздача складається з декількох файлів, то в процесі хешування вони зчитуються поспіль і розглядаються як безперервний потік даних. Тому найчастіше сегмент, що містить кінець одного файлу, також містить і початок наступного. Разом з тим для того, щоб переконатися в правильності завантаженого сегмента, необхідно мати його весь цілком. Саме тому, незважаючи на те, що більшість клієнтів підтримує скачування не всіх файлів в роздачі, а тільки деяких, майже завжди буде викачаний також і початковий і/або кінцевий шматок файлів, що не обраних для скачування.

Так як хеші в. Torrent-файлі містять у собі імена і структуру директорій роздачі, то перейменування файлів із збереженням можливості їх роздавати в загальному випадку неможливо. Однак, деякі клієнти підтримують зміну структури, наприклад, створення або перейменування директорій і перейменування або переміщення файлів.

Файл метаданих є словником в bencode форматі. Файли метаданих можуть поширюватися через будь-які канали зв'язку: вони (або посилання на них) можуть викладатися на веб-серверах, розміщуватися на домашніх сторінках користувачів мережі, розсилатися по електронній пошті, публікуватися в блогах або новинних стрічках RSS. Також є можливість отримати info частина публічного файлу метаданих безпосередньо від інших учасників роздачі завдяки розширенню протоколу "Extension for Peers to Send Metadata Files". Це дозволяє обійтися публікацією тільки Magnet-посилання. Отримавши-яким чином файл з метаданими, клієнт може починати скачування. Принцип роботи протоколу.

Принцип роботи BitTorrent: навантаження на розповсюджувача файлу зменшується завдяки тому, що клієнти починають обмінюватися даними відразу ж, навіть якщо файл не докачаєте ними до кінця.

Перед початком скачування клієнт під'єднується до трекера за адресою, вказаною в торрент-файлі, повідомляє йому свою адресу і хеш-суму торрент-файлу, на що у відповідь клієнт отримує адреси інших клієнтів, що викачують або роздають цей же файл. Далі клієнт періодично інформує трекер про хід процесу і отримує оновлений список адрес. Цей процес називається оголошенням (англ. announce).

Клієнти з'єднуються один з одним і обмінюються сегментами файлів без безпосередньої участі трекера, який лише зберігає інформацію, отриману від підключених до обміну клієнтів, список самих клієнтів та іншу статистичну інформацію. Для ефективної роботи мережі BitTorrent необхідно, щоб якомога більше клієнтів були здатні приймати вхідні з'єднання. Неправильна настройка NAT або брандмауера можуть цьому перешкодити.

При з'єднанні клієнти відразу обмінюються інформацією про наявні у них сегментах. Клієнт, що бажає викачати сегмент (лічер), посилає запит і, якщо другий клієнт готовий віддавати, отримує цей сегмент. Після цього клієнт перевіряє контрольну суму сегменту. Якщо вона збіглася з тією, що записана в торрент-файлі, то сегмент вважається успішно скачаним, і клієнт оповіщає всіх приєднаних бенкетів про наявність у нього цього сегменту. Якщо ж контрольні суми розрізняються, то сегмент починає викачуватися заново. Деякі клієнти банять тих бенкетів, які занадто часто віддають некоректні сегменти.

Таким чином, обсяг службової інформації (розмір торрент-файлу і розмір повідомлень зі списком сегментів) безпосередньо залежить від кількості, а значить, і розміру сегментів. Тому при виборі сегмента необхідно дотримувати баланс: з одного боку, при великому розмірі сегмента обсяг службової інформації буде менше, але в разі помилки перевірки контрольної суми доведеться завантажувати ще разів більше інформації. З іншого боку, при малому розмірі помилки не так критичні, тому що необхідно заново завантажити менший обсяг, але зате розмір торрент-файлу і повідомлень про наявні сегментах стає більше.