Звичним способом вказівки програми, яку ми хочемо запустити, є вказівка її імені в файлової системі, наприклад: C: \ WinNT \ System32 \ cmd.exe або \\ server \ games \ tetris \ tet.exe.
Однак такі символічні імена мають істотний недолік: вони не унікальні. Як, справді, розробник клієнт-серверної системи повинен вибирати назву для серверного компонента, якщо є присутнім ризик, що розробник іншої системи вибере таке ж ім'я для своїх власних потреб? Як адміністратор зможе розмістити ці дві системи на одному сервері?
Така ж проблема існує не тільки на мережевому, але і на Внутримашинное рівні: спроба розробника додатку шукати динамічну бібліотеку (DLL) в загальносистемному каталозі по імені цілком може привести до того, що буде помилково завантажена бібліотека з тим же ім'ям, але встановлена іншим пакетом і зберігає інший набір підпрограм (з іншими або - ще гірше - однаковими іменами). Цієї проблеми можна було б уникнути, якби в бібліотек назви виду «фірма_продукт_компонент», але поки назви типу StrUtil, MyUtil або xBase можна зустріти набагато частіше.
Тому в протоколах передачі управління і даних через мережу, альтернативних HTTP з надбудовою у вигляді CGI-BIN, таких як CORBA і Microsoft DCOM, виклик серверного компонента здійснюється не по імені файлу, а по GUID. GUID вдає із себе 128-розрядне двійкове число, сгенерированное автоматичним чином на комп'ютері розробника з наступних компонентів:
Про зручність читабельності і запомінабельності мова не йде, тому що GUID ніколи не доводиться вводити вручну: програма-клієнт завжди зберігає фіксований GUID програми-сервера, для взаємодії з якої вона розроблена, а при розробці GUID призначається створюваним компонентам якщо не автоматично, то через буфер обміну шляхом Cut'n'Paste.
Відповідність між GUID і ім'ям файлу програми, яку запускає по приходять з мережі запитам, зберігається десь в загальносистемних налаштуваннях, куди заноситься при інсталяції програми. Наприклад, в Windows для цього використовується гілка реєстру HKEY_CLASSES_ROOT \ CLSID. а реєстрації в ній - утиліта RegSvr32. GUID в Windows призначаються не тільки мережевих сервісів, а й взагалі усього, що може бути запущено або завантажено, і потребує однозначної ідентифікації: DLL-бібліотекам, класам і т.д.
За рахунок чого файлообмінна мережу досконаліше HTTP / FTP?
P2P-мережу є повноцінною розподіленої системою, тобто:
- одні й ті ж дані резервуються на безлічі вузлів;
- список вузлів формується і оновлюється автоматично;
- у клієнта існує можливість так само автоматично вибирати вузли для отримання даних;
- при виході з ладу частини вузлів система залишається працездатною.
У той же час, FTP / HTTP використовують тільки ту інформацію про файл, яка надається їм файлової системою, на якій файл розташований: ім'я, розмір, дата створення і останнього доступу - ніякі з цих метаданих не унікальні.
З цієї причини ні базовий FTP, ні базовий HTTP розподіленими системами не є. Один і той же файл або веб-сторінка можуть мати на різних вузлах різний ім'я. І навпаки, різні файли і сторінки на різних вузлах можуть називатися однаково. У клієнта немає надійного способу визначити, на яких вузлах знаходяться необхідні дані. І, як уже говорилося, FTP- / HTTP-клієнти в міру отримання даних не стають їх розповсюджувачами і не розвантажують від запитів оригінальний сервер. Звичайно, широко практикується створення т.зв. дзеркал (mirrors), автоматично синхронізуються з сайтом-оригіналом, але ручними операціями залишаються як створення сайту-дзеркала - для адміністратора, так і вибір найближчого дзеркала - для користувача.
Літак = автомобіль + крила
Залишаючись в рамках FTP / HTTP-протоколів передачі через мережу, напевно, можна було б домогтися близькою до P2P-функціональності внісши такі доповнення в поведінку клієнтів і серверів:
- на кожному клієнті в фоновому режимі запускається FTP / HTTP-сервер, щоб віддавати файли іншим клієнтам;
- додаткова програма, яка запускається на кожному сервері, обчислює контрольні суми для публікованих файлів і записує їх в розташовані поруч службові файли-описатели;
- разом з файлами викачуються їх описатели;
- один або кілька комп'ютерів виконують роль пошукових серверів, тобто в якості клієнтів переглядають каталоги всіх Веб-серверів і самі, в свою чергу, надають до результатів пошуку Веб-інтерфейс, зручний для автоматичного розбору.
- перед початком закачування клієнти завантажують з пошукових серверів базу з відомостями про файли, в той же час повідомляючи серверам про своє існування (за допомогою записів, що залишаються в log-файлі сервера, або спеціальними повідомленнями через CGI-BIN).
Очевидно, що при таких серйозних удосконалень легше розробити абсолютно новий протокол і програмне забезпечення з нуля, ніж чіплятися за вже існуючі стандарти - що і було зроблено Napster'ом, а слідом за ним і багатьма іншими.
Аеропорт = літаки + тягачі
Питання на майбутнє
Якщо мова йде про протокол, то цікавтеся наступними аспектами:
- Чи потрібна окрема сервер-координатор?
- Які програми-клієнти його підтримують?
- Наскільки широко клієнти і сервери даного протоколу поширені в Інтернеті?
- Для передачі якої інформації (мультимедіа, ISO-образи і т.д.) в першу чергу розроблявся протокол і підтримують його програми?
- Розвитком якого протоколу є даний протокол, і в якій мірі вони сумісні?
- Чи існує відкрите опис або ліцензування протоколу (наслідком чого буде більш широкий вибір програм)?
- Якщо протокол закритий і потрібна окрема програма-сервер, то чи можна підключатися до вузлів-серверів безкоштовно? Чи можна її скачати для використання в приватній мережі?
Стосовно до програми важливі відповіді на наступні питання:
- Які протоколи вона підтримує?
- Наскільки вона безкоштовна (shareware, adware, open source)?
- На які платформи вона перенесена (windows, linux)?
Відповідей на ці питання по відношенню до найбільш популярних протоколах і програмами P2P буде присвячена наступна частина статті.