Вступ до розподілених обчислень

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Тема 1. Вступ до розподілених обчислень

Питання

1. Загальні питання про розподілені обчислення.

2. Модель розподілених обчислень.

3. Різниця між локальними та розподіленими обчисленнями.

4. Вісім оман щодо розподілених обчислень.

5. Десять технологічних тенденцій розвитку мережних розподілених обчислень.

6. Масштаби мережних розподілених обчислень.

Більшість сучасних обчислень є розподіленими. Локальні обчислення, що є основою комп'ютерних наук, і розвиваються до сих пір, є швидше винятком, ніж правилом.

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

ВОВ-модель допоможе організувати інформацію й описати потік даних через локальну комп'ютерну систему; це є основним завданням у локальних обчисленнях.

Однак очевидно, що це не відповідає сучасній комп'ютерній реальності, хоча якимось чином і проявляється в деяких нових моделях програмування.

Більшість сьогоднішніх комп'ютерів є частиною мережі. ВОВ-модель залишається корисною, особливо для початківців, але її спрощене представлення стає фундаментально помилковим, як тільки програма виходить за межі локальних обчислень. Таке фундаментально неправильне застосування легко приведе до ненавмисним, але дорогих наслідків. Наочним прикладом можуть служити численні комп'ютерні віруси, що широко поширилися по сучасному мирі. Типовою для перших ПК була ВОВ модель програмування, заснована на припущенні, що кожний ПК буде автономним. Наші ПК як і раніше залишаються уразливими для докучливих вірусів через це помилкове раннє допущення, що було необхідним для того, щоб програмування стало корисним, але стало неповним внаслідок нинішнього вибуху мережних застосувань ПК і інших «думаючих» пристроїв.

2. Розподілені обчислення виступають у декількох формах, кожна з яких вимагає свого набору понять, коли наступає час побудови розумної моделі програмування, тобто такої моделі, для якої її архітектори продумано розглядають аспекти, не охоплені ВОВ-моделлю (модель “ввід-опрацювання-вивід”) розгортання ПЗ (програмне забезпечення) в системі. У табл. 1.1 представлена ієрархічна класифікація систем РО (розподілених обчислень), що природно охоплює системи МРО (мережних розподілених обчислень).

Розподілені системи можуть вбудовуватися в один пристрій або можуть працювати в кластері пристроїв, у якому вузли працюють спільно і здаються одним вузлом, підтримуючи уніфікований вид системних ресурсів для певних застосувань. Такі кластерні системи звичайно підключаються до фіксованих високошвидкісних ліній передачі даних, а не до відкритої мережі й можуть розміщатися в одному приміщенні, будинку, населеному пункті, залежно від використання і якості з'єднання між вузлами. За цією ж ознакою набір убудованих процесорів, тісно зв'язаних закритим протоколом передачі даних, може також легко представляти кластер. Різниця між РО і МРО полягає в способі передачі даних; МРО призначені для роботи зі стандартними протоколами, а не з закритою лінією передачі даних. Розподілені обчислення створюють ще один рівень складності для прикладного програмування, особливо для тих, які працюють у неконтрольованому просторі поза закритою ЛОМ (локальна обчислювальна мережа) або закритої ГОМ (глобальна обчислювальна мережа)у такому середовищі, як відкритий Інтернет. У загальних словах, проста модель для розуміння й організації інформації й потоку інформації в середовищі МРО складається з ВОВ-моделі й додаткового рівня складності (див. рис. 1)

Рис. 1. Проста модель МРО

Таблиця 1. Ієрархічна класифікація мереж розподілених обчислень

Сімейство	Тип обчислень	Типове використання
Локальна (вбудована, наприклад, в автомашину)	Закриті РО	Один користувач
Локальна (від однієї кімнати до комплексу будинків)	Кластерні РО	Багато-багатокористувальницька
Мережна (закрита ЛОМ)	Закриті МРО	Багато-багатокористувальницька
Мережна (закрита ГОМ)	Закриті МРО	Багатокористувальницька
Мережна (відкрита ЛОМ)	Відкриті МРО	Багатокористувальницька
Мережна (Інтернет)	Відкриті МРО	Вбудована/однокористувальницька/ багатокористувальницька

У цій моделі МРО вихідні дані одного вузла стають входом іншого вузла. У дійсності, як показує модель, інформація може передаватися в обох напрямках.

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

3. Є чотири ключових розходження між локальними обчисленнями і віддаленими (або розподіленими) обчисленнями:

затримка;

доступ до пам'яті;

паралельність;

часткова відмова.

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

Доступ до пам'яті, здійснюваний з арбітражем через рівні абстракції, є корисним і застосовним. Зверніть увагу, що серед інших особливостей, посередниками для пам'яті також служать мови визначення інтерфейсу IDL; такі підходи іноді дозволяють досить добре приховувати фундаментальні різниці пам'яті вузлів МРО, залежно від використання й контексту.

Треті й четверте ключові розходження можуть бути не настільки ж очевидними, але вони проте реальні.

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

Паралельність у даному вузлі має на увазі існування процесу системи, що поводиться як «планувальник» і відкладає виконуване поточне завдання, після того, як вона відробить свій інтервал часу («квант часу». Планувальник також відповідає за вибір наступного завдання для виконання і його (пере)запуску.

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

Багатопотокова обробка є видом багатозадачної обробки з малими непродуктивними витратами й без захисту завдань один від другого; всі потоки спільно використовують ту саму пам'ять.

В одиночному вузлі компонента системи або працюють, або ні, і керівний центр, наприклад операційна система, управляє всіма ресурсами. Безліч вузлів розподіленої системи забезпечують потенційно більше ресурсів, але відсутність керівного центра збільшує ресурсну невизначеність. Ця проблема є неминучою, і її нерозумно ігнорувати. В одиночному вузлі задана транзакція або відбувається (і це відомо), або не відбувається (що теж можна довідатися); у мережі додається ймовірність того, що транзакція може відбутися, але часткова відмова не дозволить нам це довідатися. Наприклад, або час віддаленого вузла мине до завершення транзакції, або він завершить транзакцію й потім його час мине, але вузол не зможе підтвердити транзакцію до завершення часу. Ця обставина збільшує в моделі МРО невизначеність, якої немає в локальній моделі і яка виникає майже цілком через відсутність керівного центра.

4. Кожен, хто вперше створює розподілений додаток, робить наступні припущення. Всі вони зрештою виявляються помилковими, і всі викликають великі неприємності, а саме:

1. Мережа є надійною.

2. Затримка дорівнює нулю.

3. Смуга пропускання необмежена.

4. Мережа є безпечною.

5. Топологія не змінюється.

6. Є тільки один адміністратор.

7. Транспортні витрати дорівнюють нулю.

8. Мережа однорідна.

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

Табл. 2. Омани і ключові розходження: головні причини

Ключові відмінності	Омани	Головна причина
Часткова відмова, паралельність	Мережа є надійною	Криється в мережному проекті/реалізації
Затримка	Затримка рівна нулю	Кінечність швидкості світла
Паралельність	Смуга пропущення не обмежена	Криється в мережному проекті/реалізації
	Мережа є безпечною	Відсутність керівного центру
Часткова відмова, паралельність	Топологія не змінюється
	Є тільки один адміністратор
Паралельність	Транспортні витрати рівні нулю	Криється в проекті/реалізації передачі даних
Доступ до пам'яті	Мережа однорідна	Криється в мережному проекті/реалізації

Взагалі, здається неможливим обійти при проектуванні МРО фундаментальне обмеження, що стосується керівного центру. І щоб упоратися з розходженнями, перерахованими вище: межею швидкості світла, неминучістю часткової відмови і слабких можливостей паралельної роботи, у МРО потрібно ігнорувати гарантії, позначувані лише на словах і пропоновані в моделях, у яких намагаються сховати ці розходження. МРО повинні якимось чином пристосовуватися до властивим їм недоліків і або відкривати їх перед розроблювачами ПЗ, або приховувати їх, сподіваючись на краще.

Контекст МРО

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

Експоненціальні закони

Трьома мета тенденціями, що виражаються в експоненціальному виді, є:

- закон Мура: щільність транзисторів подвоюється кожні 18-24 місяців;

- закон Джілдера: загальна смуга пропускання засобів обміну інформацією подвоюється кожні 6 місяців;

- закон Меткалфа: потенційна цінність мережі дорівнює квадрату кількості вузлів.

Ці три “експоненціальні закони” можуть розглядатися як мета тенденції; при описі загальної картини ці закони виражаються в конкретних термінах, але до них не можна застосувати який-небудь безпосередній вимір.

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

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

Відгомони експонентних законів

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

1. Декомпозиція і перехід до компонентів: на певному критичному стику обчислення повинні бути розподілені ще далі. Це справедливо як для макро-, так і для мікрорівнів і обумовлюється зменшенням розмірів фізичних компонентів, ростом мережі і іншими економічними факторами.

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

5. Всі основні технологічні тенденції сьогодні прямо чи побічно залежать від мета тенденцій (експонентних законів), і безпосередньо впливають на розвиток МРО. МРО також впливають на кожну тенденцію, і їх технології сприяють створенню співтовариств користувачів і значно підвищують продуктивність.

При спробі створити список з десяти основних технологічних тенденцій необхідне об'єднання декількох з них. Хоча цей список не претендує на те, щоб бути повним, він показує масштаб і глибину прискорюваного проникнення мета тенденцій.

1. Бездротові й мобільні обчислення.

2. Веб-служби і семантична Web.

3. Робототехніка.

4. Розшифрування геномів і біотехнологія.

5. Матеріалознавство і нанотехнологія.

6. Internet2, «всепроникаючі» і «всюдисущі» обчислення.

7. Глобалізація, СОТS і посилення конкуренції.

8. Системи реального часу і вбудовані системи, системи grid-обчислень, кластери і компонованість.

9. Безпека, глобальна прозорість і закритість.

10. Конкуруючі інфраструктури МРО, глобальна операційна система і рекомбінантне ПЗ.

Масштаби МРО

У табл. 3 перераховані загальні області досліджень в МРО.

Таблиця 3. Деякі області досліджень і розробок у МРО

Grid-обчислення	Однорангові системи
Семантична WеЬ	Операційні системи
Веб-служби	Проміжне ПЗ
Безпека	Просторові обчислення
Всюдисущі обчислення	Розподілене сховище (пам'ять)
Всепроникаючі обчислення	Розподілені агенти
Обчислення реального часу і вбудовані	Розподілені алгоритми
Кластерні концепції	Розподілені бази даних
Колективні обчислення	Розподілені мультимедіа
Масові паралельні системи	Розподілені файлові системи
Мобільні і бездротові системи	Мережні протоколи
Надійні системи	Мови

Є очевидні зв'язки між цими областями, наприклад, безпека МРО тісно зв'язана з усіма іншими категоріями розробки МРО. Розподілені агенти мають багато загального, принаймні, з “всепроникаючими” і “всюдисущими” обчисленнями тощо.

Всюдисущі і всепроникаючі обчислення

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

«Всепроникаючі» обчислення робили б інформацію доступною в будь-якому місці; «всюдисущі» обчислення вимагали б наявності інформації в будь-якому місці. Це тонке, але певне розходження.

Веб-служби

До стандартизованого підходу з веб-службами до МРО необхідно підходити критично. Можливо необхідно віддати перевагу більш природним підходам, що втілені в розподілених обчисленнях і змішані із проявами обчислень реального часу і вбудованих обчислень. Частина дослідників вважає, що прихід протоколу SОАР ознаменував не найкращий день у світі стандартів Інтернету.

Веб-служби базуються на декількох випливають із ХМL концепцій, призначених для забезпечення стандартизованого мобільного обміну даними «компонентів» у МРО-cередовищах.

Архітектури G1оbаl ХМ Web Servises Architecture (розробники - Microsoft і ІМ.) включає ХМL (розширювана мова розмітки), SОАР (протокол простого доступу до об'єкту) і UDDI (інтерфейс універсального каталогу і виявлення), WSDL (мова опису веб-служб).

Архітектура G1оbа1 ХМ Web Servises Architecture визначила б також принципи специфікації, які у зв'язуванні з аспектами семантичної Web могли б у майбутньому обумовити становлення інфраструктури МРО, що була б:

- модульною - з компонованими модулями, які можуть комбінуватися, як це необхідно, для забезпечення наскрізних можливостей (нові модульні елементи вставляються в ансамблі в міру виникнення необхідності);

- загального призначення - призначеної для роботи в широкому діапазоні сценаріїв ХМ Web Servises, від рішень «бізнес для бізнесу» і інтеграції додатків підприємства до однорангових додатків і служб «бізнес для споживача»;

- федеративної - повністю розподіленої, призначеної для підтримки служб ХМ Web Servises, що перетинають границі організацій і довірчих середовищ, що не вимагають централізованих серверів або функцій адміністрування;

- заснованої на стандартах - заснованої на протоколах, що підкоряються відповідним органам стандартизації.

Колективні обчислення

Головна ідея полягає в тому, щоб розглядати програму як засіб зв'язку з людьми, а не як набір команд комп'ютеру.

Саме в колективних обчисленнях МРО з'явилася більшість реалізацій ПЗ колективної роботи, концепції, під якою розуміють групи людей, що працюють спільно над загальними проектами. До видів ПЗ колективної роботи відносяться інструменти колективного малювання і написання текстів, інфраструктури наукового співробітництва, спільно використовувані додатки, інструменти обміну відеоінформацією, проведення телеконференцій на основі Web, інструменти організації потоків робіт і керування ними, нова область керування знаннями і навіть електронною поштою.

Деякі дослідження в області колективних обчислень відображають настрої відмови від кібернетичного організму, принаймні, в області керування знаннями (КМ - knowledge management).

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

Колективні обчислення були б також плідним заняттям для учених, що прагнуть спільно використовувати дані. Дослідники в області біотехнологій, наприклад, добре інформовані про потенціал таких технологій, як ХМL, які при правильному розширенні можуть полегшити колективні зусилля, характерні для дослідницьких дисциплін.

Широкий спектр колективних обчислень, представлених у МРО, є міждисциплінарним по своїй природі; швидше за все, через зусилля НДДКР (науково-дослідницька, дослідницько-конструкторська робота) в цій широкій категорії буде відчуватися гуманізаційний вплив МРО на інформатику в цілому.

Надійні системи

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

У міру росту залежності від МРО у глобальному масштабі ймовірність криз через відмови в мережах і системах також росте. Чим більше МРО-додатків стануть нормою, тим більше розповсюдженими стануть відмови. Надійні системи повинні породжувати довіру в багатьох відносинах, якщо нам потрібно, щоб МРО продовжували збагачувати людську діяльність, не піддаючи її в такому ж ступені ризику.

Далі наведені два приклади з багатьох відмовостійких підходів до ПЗ, застосовних до розробки МРО-додатків. Ці методи в сполученні з іншими добре спроектованими процесами розробки і компонентами послужать створенню більше надійного ПЗ для МРО-систем.

1. Метод перезапуску з контрольної точки

Основна частина досліджень надійного ПЗ для МРО проводилася паралельно росту Інтернету. Торес-Помалес привів ряд загальних підходів до відмовостійкості ПЗ, багато з яких можна застосувати до МРО, включаючи методи підвищення відмовостійкості ПЗ в одній версії (тобто, у єдину версію якої-небудь частини ПЗ вводяться додатковий програмний механізм, призначений для виявлення відмов і відновлення після них). Найпоширенішим прикладом такого підходу, наведеним Торрес-Помалесом, є механізм перезапуску з контрольної точки, схема якого наведена на рис. 2.

Рис. 2. Метод єдиної версії з перезапуском з контрольної точки

Більшість відмов ПЗ (після завершення розробки) є непередбаченими і звичайно залежать від стану. Відмови такого типу часто поводяться подібно помилковим відмовам (збоям) апаратури: вони виникають, заподіюють шкоду і зникають, не залишаючи слідів. У таких випадках, перезапуск модуля часто є найкращою стратегією для успішного виконання його завдання, що має ряд переваг і є досить загальним для використання на багатьох рівнях МРО-системи або середовища. Перезапуск може бути динамічним або статичним, залежно від контексту: при статичному перезапуску модуль переводиться у визначений стан; при динамічному перезапуску можуть використовуватися контрольні точки, динамічно створювані через фіксовані інтервали або в певних важливих крапках під час виконання. Все це, звичайно, залежить від способу виявлення помилки, що також має кілька застосовуваних варіантів.

2. Метод відновлюючих блоків

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

Тому, якщо одна версія відмовить при даній вхідній інформації, те необхідну вихідну інформацію надасть альтернативна версія.

Один із прикладів, наведених Торес-Помалесом, називається методом «відновлюючих блоків», що сполучить основну ідею перезапуску з контрольної точки з декількома версіями даного компонента: якщо помилка виявлена під час обробки одного варіанта, то виконується інша версія. Як показано на рис. 3, контрольна крапка створюється до виконання, і виявлення помилки в даному модулі може відбуватися в різних контрольних крапках по ходу виконання, а не тільки при вихідному тестуванні.



Рис. 3. Метод відновлюючих блоків

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

Безпека в МРО базується на математиці, але здійснюється інженерами-проектувальниками, і в контексті МРО будь-яке обговорення безпеки готовить парадокс. Виражаючись більш практично, безпека базується на шифруванні, але одного шифрування далеко не досить, щоб забезпечити прийнятні гарантії для МРО. Інформація може бути схована методами шифрування, але шифрування не вирішує інших, більш фундаментальних питань: довіри, включаючи перевірку джерела даних, контроль доступу і захист даних.

З'єднання прикладних розробок і чистої математики є одним зі способів вивчити безпеки МРО. Іншою, більше парадоксальною дихотомією є збалансованість захисту і прозорості даних, яка приводить до характеристик, що піддаються виміру, доступності, якщо вона добре реалізована

Група IЕТ запропонувала такі елементи безпеки в RFC 2828, що визначають потреби Інтернету.

1. Міри, прийняті для захисту системи.

2. Стан системи в результаті проведення і підтримки мер для захисту теми.

3. Стан ресурсів системи, захищений від несанкціонованого доступу і від несанкціонованої або випадкової зміни, руйнування або втрати даних.

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

Підтримка безпеки в межах одного вузла є простою у порівнянні із проблемами безпеки в середовищі МРО; більшість “проколів” у захисті одиночних вузлів виникає через погане проектування, що теоретично цілком розв'язно. Забезпечення безпеки в середовищі МРО, у якій всі апаратні компоненти перебувають під фізичним контролем одного власника, є також порівняно простим; багато систем проектуються для надійної роботи в таких середовищах. Наступним за труднощами є середовище, у якому кінцеві точки контролюються власником, але мережі є відкритими; у таких випадках намагаються вирішити питання безпеки МРО за допомогою віртуальних приватних мереж VPN (virtual private network).

На жаль, більшість сучасних додатків МРО не можуть бути зведені до таких моделей, якщо вони в підсумку повинні реалізувати “всюдисущі” обчислення.

У контексті МРО вплив безпеки проявляється на багатьох рівнях. Вона потенційно може бути вбудована на фундаментальному рівні протоколу, може бути включена на більше високих рівнях протоколу, вона може бути орієнтована на додаток або навіть на мережу.

Роботи в області МРО висунули комп'ютерні мови на передній край досліджень. Наприклад, мова програмування JAVA, безперечно, дала початок новому поколінню Інтернет-додатків. За допомогою JAVA-специфікації мова С++ без яких-небудь обмежень була об'єднана з байт-кодом і девізом “Написано один раз, працює скрізь”, і з'явилася можливість створити нові моделі для додатків, які б охоплювали відкриті мережі. Платформа JAVA була значним кроком у напрямку мережної платформи.

Приклади НДДКР, що ведуться в області мов, про які варто знати розроблювачам МРО:

- JAVA/С#. Об'єктно-орієнтовані мови, які інтерпретуються віртуальними машинами;

- ХМL;

- Проект Fох (Fох Рrоjесt) Проміжна мова зі строгим контролем типів і кодом, що несе докази безпеки.

- -саlсиlus. Теоретична модель обчислень для мобільного коду.

Кожна із цих розробок мов для МРО представляє свій рівень реалізації мови і рівною мірою представляє еволюційну природу мов сучасного періоду.

У цих прикладів розвитку мов у МРО є три такі загальні риси;

1. Їхнє серйозне дослідження почалося в 1995 році (нульовому році Мережної ери) або після нього.

2. Усі вводять у комп'ютерні мови відсутні до того мережні принципи роботи.

3. Усі переглядають підходи до інформаційного обміну між розподіленими вузлами обчислень.

Кластерні концепції

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

Ключем до поняття кластерних обчислень є ідея єдиного образу системи. У кластерах передбачена плавна зміна розмірів і подолання відмов: коли один підвузол у кластері відмовляє, то інший готовий зайняти його місце так, щоб додатки (включаючи і його користувачів) практично цього не помітили. Також застосовуються гібридні кластери, у яких забезпечується достатня кількість підвузлів і є “інтелектуальні” засоби для подолання відмов і зміни розмірів.

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

Глобальний кластер, що використовує відкритий Інтернет для передачі даних, проте не так легко собі представити внаслідок невизначеності, у цей час властивої мережі й стану протоколів Інтернету незалежно від смуги, що збільшується, пропущення. Але все-таки можуть існувати розумні підходи до подолання навіть цих внутрішніх обмежень.

Розподілені агенти

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

У будь-якій моделі, що базується на агентах, агент може передати (делегувати) деякі повноваження агентові, що може мати інтелект, бути мобільним або й тим, і іншим. Внаслідок невдалого початку, що трапилося зі штучним інтелектом, можливо, не зовсім реалістично говорити про інтелектуальних агентів у МРО. Проте можна сказати, що інтелектуальний агент міг би мати здатність робити висновки на основі правил і проводити імовірнісні аналізи рішень чи навчання від імені свого клієнта.

У контексті МРО мобільний агент може пересуватися між вузлами для виконання доручених йому завдань; такий погляд становить особливий інтерес для мобільних користувачів і мобільних засобів зв'язку. При цьому виникає багато питань у зв'язку з безпекою і моделями, що базується на довірі.

У МРО агенти і характеристики розподілених агентів спочатку розглядалися в проблемному просторі керування системами і мережами. Стандартизація розподілених агентів зараз проводиться в контексті семантичної, а також мови розмітки агентів DAML.

Розподілені алгоритми

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

МРО вводять цікаві вимірювання складності, що “в'язнуть” у змінних часу і простору, які просто не видні моделям локальних обчислень.

Сьогодні алгоритмічно обумовленими в МРО є три основні архітектурні моделі, що розрізняються по ступені синхронізації і роздільності.

1. Модель синхронної передачі повідомлень.

2. Модель асинхронної передачі повідомлень.

3. Модель із асинхронним спільним використанням пам'яті.

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

Крім питань синхронності, предметом розподілених алгоритмів також є мережна топологія; визначення форм і границь динамічних мереж з метою ефективної передачі даних.

Розподілені бази даних

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

Перед виготовлювачами баз даних стояли цікаві і важкі проблеми протягом ряду років. Такі компанії, як Огасlе, внесли значний вклад у корпоративний сектор за останні два десятиліття, балансуючи між потребами в критично важливих даних і часто взагалі ненадійними СOTS-технологіями, які їх споживачі були змушені розгортати під збільшуючим конкурентним тиском.

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

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

Тема 2. Теорія МРО

Питання:

1. Основні принципи МРО.

2. Взаємовідношення теорії і практики в МРО.

3. Системи передачі повідомлень.

4. “Візантійські відмови” і проблема вибору лідера.

5. Проблеми “взаємного виключення” в МРО.

6. Проблеми “відмовостійкості” в МРО.

7. Проблеми “синхронності”, “причинних зв'язків” і “часу” в МРО.

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

Таблиця 4. Класи відмов у МРО

Тип відмови	Джерело	Опис
Зупинка	Вузол	Вузол зупиняється і не перезапускається. Інші вузли можуть виявити такий стан
Вихід з ладу	Вузол	Вузол виходить з ладу і не перезапускається. Інші вузли можуть бути не здатні виявити такий стан
Помилка в каналі	Канал	Передане повідомлення ніколи не приходить
Помилка передачі	Вузол	Вузол завершив передачу, але повідомлення не прийняте
Помилка прийому	Вузол	Повідомлення прийняте але процес на вузлі його не опрацьовує
Візантійська	Вузол чи канал	Вузол/канал поводиться довільно, включаючи помилки, довільні повідомлення, зупинки чи некоректні кроки опрацювання
Годинник (Таймер)	Вузол	Вузол перевищив допустиму границю (межу) відхилення таймера
Продуктивність вузла	Вузол	Вузол перевищив межу інтервалу опрацювання
Продуктивність каналу	Вузол	Перевищено межі передачі повідомлення

В МРО найбільш важким типом відмови є візантійські відмови. Наприклад, на вузлі можуть установитися неточні значення даних, або процес на вузлі може повернути невірне значення у відповідь на запит. Крім неточних або неповних даних, випадкові відмови можуть містити в собі одиничні випадки пропадання повідомлень або відмови через часові співвідношення. Такі відмови виявити значно важче, і тому відновлення після візантійських відмов стало однієї із самих вивчених областей теоретичної інформатики.

Задача про візантійських генералів. Група генералів повинна домовитися про атаку або відступ. Одному з них, що є головнокомандуючим (лідером), необхідно віддати наказ або про атаку, або про відступ. Іншим потрібно вирішити, чи будуть вони атакувати або відступати; але всім відомо, що один або декілька генералів одного з ними рангу можуть виявитися зрадниками, і в даній ситуації це означає схильність до довільних відмов. Якщо лідер є зрадником, то він запропонує атакувати одному генералові і відступати іншому. Якщо один з інших генералів є зрадником, то він повідомить одному генералові рівного з ним рангу, що лідер наказав атакувати, і одночасно повідомить іншого генерала, що наказано відступати. Задача про візантійських генералів пов'язана із завданням досягнення консенсусу (повної згоди) між вузлами, але в той же час відрізняється від неї.

У задачі про візантійських генералів замість вузлів, що пропонують кожного своє значення, потрібно виконати такі умови.

- завершення. Кожний вузол у підсумку встановлює свою змінну рішення;

- угода. Змінна рішення коректна, якщо всі вузли мають однакове значення і перебувають у стані рішення;

- цілісність. За умови коректності лідера всім вузлам необхідно погодитися з будь-якою його пропозицією.

Такий підхід до консенсусу допускає випадкову відмову при участі в процесі більше трьох вузлів. У випадку із трьома і менше МРО-вузлами, що передають неоднозначні (точно не розпізнавані) повідомлення, синхронно або несинхронно не буде існувати рішення, що гарантує виконання умови задачі про візантійських генералів, якщо один з вузлів може відмовити.

Крім візантійських відмов, які можуть містити випадкові відмови розроблювач сучасних МРО-систем повинен добре розбиратися в питаннях безпеки, які ортогонально пов'язані з візантійськими проблемами.

Вибір лідера

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

Є кілька алгоритмічних підходів до вибору лідера. Це завдання подібне до досягнення консенсусу в тім плані, що в підсумку кожний вузол повинен прийти до одному із двох висновків: або він лідер, або ні, і в такому випадку їм точно є один з вузлів одного з ним рангу. Один з підходів алгоритмічно розв'язує задачу досягненням таких умов:

- кінцевий стан - вузол або обраний, або ні;

- коректністъ рішення - лідером обраний точно один вузол; всі інші вузли не обрані.

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

В одному із простих алгоритмів для кільцевої мережі з унікальними ідентифікаторами, показаному на рис. 4,

Рис. 4. Вибір лідера за допомогою ідентифікаторів

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

У підсумку вузол з найбільшим унікальним значенням (п5 на рис. 4) одержить повідомлення, що містить свій власний ідентифікатор, і це буде означати завершення процесу вибору. Кількість повідомлень, переданих у цьому прикладі, буде дорівнює 2n- 1, що є справедливим для будь-якої кільцевої мережі, у якій вузли однозначно розташовані, як показано на рисунку, незалежно від кількості вузлів.

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

Проблема взаємного виключення в МРО полягає в призначенні неподільного ресурсу, що не може використовуватися паралельно і одночасно декількома вузлами. Прикладом такого ресурсу може служити принтер: якщо до нього будуть мати одночасний доступ кілька вузлів. Важливими для рішення проблеми взаємного виключення в МРО є такі умови:

- безпека. Одночасно в критично важливій області може виконувати дії тільки один вузол;

- впорядкованість. Запити на вхід у критично важливу область обробляються в хронологічному порядку; вхід надається в тім порядку, у якому запити були прийняті.

Найпростішим підходом до досягнення взаємного виключення в МРО є підхід із центральним сервером, що наведено на рис. 5.

Рис. 5. Взаємне виключення в МРО, що керується центральним сервером

Для входу у область вузол посилає повідомлення з запитом в сервер і очікує відповіді. Маркер, що означає дозвіл на вхід у критичну область, міститься у кінцевій відповіді сервера.

У наведеному прикладі вузол n0 запитує ресурс, який в даний час використовується вузлом n1. Вузол вже помістив запит в чергу, що керується центральним сервером. Коли n1 закінчить свою роботу в критичній області, то звільняється даний ресурс. Потім центральний сервер передає маркер дозволу входу вузлу n2 і, відповідно, обновлює чергу, роблячи n0 наступним в черзі.

Даний підхід має певні недоліки, наприклад, якщо ні один з процесів не використовує критичної області, для функціонування системи необхідно передавати два повідомлення (запит і передачу маркера дозволу входу), що додає непотрібні затримки.

Тому використовуються інші алгоритми.

В системі МРО може відбутися часткова відмова, коли виходить із ладу один компонентів; така відмова може вплинути на коректність функціонування будь-якої кількості інших компонентів і в той же час не робити явного впливу на роботу іншої частини системи Однієї із ключових особливостей проектування МРО-систем є значно вища потреба в ПЗ, що може відновлюватися після відмов і продовжувати працювати прийнятним чином, коли МРО-компоненти неминуче будуть відмовляти.

Питання об'єднання в просторі МРО, ріст мереж і вузлів і злиття бездротових і мобільних обчислень із Інтернетом, обумовили перехід на такий рівень складності, для якого може бути властивим збільшення труднощів задач підвищення надійності програмних служб. Надання надійного ПЗ на рівні компонентів гостро порушує питання надійності компонованих ансамблів, особливо якщо передбачаються динамічні, спеціалізовані об'єднання ПЗ.

Відновлення після відмов продовжує бути областю, що розвивається в теорії МРО.

Опрацювання транзакцій

Системи опрацювання транзакцій, подібно до алгоритмів взаємного виключення, захищають критичні МРО-ресурси від одночасного доступу з боку однорангових вузлів. Розподілені системи транзакцій - це такі системи, які надають доступ до критичних областей даних і їх модифікацію у вигляді однієї “атомарної” операції.

Опрацювання транзакцій в інформатиці відбувається подібно до опрацювання транзакцій у бізнесі.

Властивості транзакцій. Транзакції в інформатиці мають такі властивості:

- атомарність. Операція неподільна із зовнішньої точки зору;

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

- ізольованість. Транзакція не взаємодіє з іншими паралельними транзакціями.

- надійність. Виконана один раз транзакція незмінна.

Показники надійності

Відмови класифікуються як часові, перемежовані (блукаючі) і постійні. Постійні відмови не проходять доти, поки не буде замінений компонент, що відмовив. Необхідно враховувати всі види відмов, щоб отримати відмовостійкі системи МРО.

Реплікація даних і компонентів

Крім алгоритмів відновлення після візантійських відмов і методів відновлюючих блоків, ще однією основною альтернативою для відмовостійкої системи є реплікація (дублювання) даних і компонентів

Причинні зв'язки стосуються порядку подій у часі.. У МРО відсутність керівного центра історично змістило акцент у часову область; синхронізація годинника у мережі може бути проблематичною. Наприклад, в алгоритмі Рікарта і Агравалі для взаємного виключення передбачається, що у вузлів у мережі є якась угода щодо часу, щоб здійснювати ефективний арбітраж мережних ресурсів.

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

Синхронність часу

Із самого початку МРО проблеми відхилення часу від точних показів і їх розфазування доставляли багато неприємностей розроблювачам. За кілька минулих років відбувся деякий прогрес у синхронізації годин МРО за допомогою нових апаратних і програмних механізмів, що дозволяють синхронізувати системи до декількох мілісекунд з універсальним скоординованим часом UTC (Coordinated Universal Time, що є синонімом середньому грінвичському часу GМТ - Greenwich Mean Time).

Прогрес у часовій синхронізації МРО можна описати у виді етапів:

1. Синхронізація фізичних годинників.

2. Імовірнісна синхронізація. В 1989 році Флавіу Крістіан опублікував статтю “Імовірнісна синхронізація часу” у якій він запропонував використовувати сервер часу. Такий сервер одержує інформацію точного часу з перевіреного джерела UТС (такого, як сигнал теле- чи радіомовлення), відправляє її потім пристроям по їх запиту. Тому що час передачі часто є досить коротким, то Крістіан описав алгоритм прив'язки часу в клієнта як імовірнісний - синхронізація досягається тільки в тому випадку, якщо спостережувана затримка проходження повідомлення в обидва боки між сервером і клієнтом є істотно меншою в порівнянні з необхідною точністю.

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

Мережний протокол служби часу (NTP). Протокол був уведений в 1995 році для того, щоб дозволити всім вузлам в Інтернеті синхронізуватися з UТС за допомогою декількох підходів, залежно від характеристик локальної мережі. Для високошвидкісних ЛОМ підтримується режим багатоадресної передачі, режим виклику процедур, симетричний режим, призначений для використання серверами часу у ЛОМ. У всіх режимах здійснюється ненадійна передача повідомлень за допомогою стандартного транспортного протоколу Інтернету UDP (протокол передачі користувацьких дейтаграм).

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

Тема 3. Протоколи МРО

Питання:

1. Історична довідка про протоколи МРО

2. Концепція OSI 7

3. Cтруктура ТСР/ІР стосовно МРО

4. Керуюче програмне забезпечення МРО

Протоколи передачі даних лежать в основі існування Інтернету Знання принципів передачі даних на елементарному рівні також важливо для розроблювачів МРО, як і будь-які знання про мову програмування, середовищу розробки або платформі розгортання.

Коротка історія: від АRРАNЕТ до сучасного Інтернету

Керування перспективних досліджень і розробок уряду США (АRРА) стало замовником проекту АRРАNЕТ в 1968 р. Первісною метою АRРАNЕТ було посприяти установам США в придбанні досвіду взаємного з'єднання комп'ютерів і підвищенні продуктивності досліджень в області інформатики за допомогою кращого колективного використання ресурсів і ідей.

Були ретельно відібрані наукові установи з врахуванням наявних у них можливостей мережної підтримки або інших унікальних ресурсів, які могли б бути використані. Також розглядалися й технічні можливості, тому що вважалося, що для АRРАNЕТ необхідно розробити протоколи, що дозволяють здійснювати інформаційний обмін між різними типами комп'ютерів. Були обрані чотири об'єкти, які відповідали вимогам такої «родоначальної» мережі: Стенфордський дослідницький інститут, Каліфорнійський університет у Лос-Анджелесі, Каліфорнійський університет у Санта-Барбарі, Університет штату Юта.

Первісний протокол інформаційного обміну називався інтерфейсним процесором повідомлень ІМР і призначався для розміщення на кожному об'єкті. Тоді виникла ідея, що обміном між множиною різних комп'ютерних систем може керувати одна комунікаційна система, для якої було необхідно створити стандартний комунікаційний процесор, що надає сполучення з АRРАNЕТ. Тоді на кожному об'єкті було б необхідно розробити тільки один інтерфейс для одного стандартного ІМР. У цій ранній системі був покладений початок стандартам інформаційного обміну для Інтернету. У ній використовували модифікований комп'ютер DDP-516 (стійку розміром з холодильник і з пам'яттю 12 Кбайт), що був у той час одним із самих потужних на ринку міні-комп'ютерів. Передача першого слова LOGIN закінчилась на другій букві - мережа вийшла з ладу.

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

ДО 1981 року обмінювалися даними 213 хостів, і до них приблизно кожні 20 днів додавався новий хост. В 1982 році, коли як комунікаційний протокол для з'єднаних хостів був обраний ТСР/ ІР, був уперше використаний термін «Інтернет», і дійсно з'явилася сучасна мережа з комутацією пакетів.

З погляду керівництва, ріст Інтернету став результатом анархії в співробітництві. В 1979 році була сформована Рада з контролю над Інтернетом і його конфігурацією ІССВ, покликаний спостерігати за проектуванням і реалізацією протоколів усередині існуючого Інтернету. В 1983 році ІССВ був перейменований у Раду по діяльності в Інтернеті ІАВ, який фактично перетворився в організацію по стандартизації стандартів Інтернету.

В 1986 році ІАВ знову перетвориться, щоб здійснювати функцію спостереження за допомогою декількох допоміжних груп. З'явилися дві перші групи: Дослідницька група Інтернету IRTF для спостереження за дослідницькою діяльністю, пов'язаною із ТСР/ IP-Архітектурою Інтернету, і Група по інженерних проблемах Інтернету IЕТF, відповідальна за короткострокові і середньострокові інженерні проблеми, що стосуються Інтернету. Обидві групи існують дотепер.

До 1984 року, коли Вільям Гібсон придумав термін «кіберпростір», кількість хостів в Інтернеті перевищило 1000. Трьома роками пізніше їх стало 10 000. В 1995 році, коли почалася Мережна ера, число хостів в Інтернеті виросло приблизно з 4,8 до 9,5 мільйонів, і URL-Адреси (адреси електронної пошти) почали з'являтися в телевізійній рекламі.