и телефонні компанії, що конкурують комп'ютерні фірми і навіть уряди провідних країн світу, були смертельно налякані, що IBM може використовувати свій сектор ринку з тим, щоб змусити всіх використовувати стандарт SNA, який вона могла змінювати на власний розсуд. Модель OSI створювалася з метою справити схожу на стандарт IBM еталонну модель і стек протоколів і зробити їх всесвітніми стандартами, управляти не однією компанією, а нейтральною організацією, ISO.
Модель OSI разом з визначеннями служб і протоколів надзвичайно складна. Якщо роздрукувати всі стандарти і скласти їх один на одного, то вийде стопка паперів висотою майже в метр. До того ж стандарти важко реалізувати і неефективні в роботі. У даному контексті згадується жарт, сформульована Полом Мокапетріс (Paul Mockapetris). p> Крім неможливості зрозуміти стандарти OSI, ще одна проблема полягала в тому, що деякі функції, такі як адресація, управління потоком, обробка помилок, повторювалися знову і знову в кожному рівні. Так, наприклад, для того, щоб контроль за помилками був ефективним, він повинен здійснюватися на самому верхньому рівні, тому повторення його знову і знову на кожному рівні часто виявляється зайвим і неефективним.
Іншим аспектом є той факт, що рішення помістити ту чи іншу функцію в певному рівні не завжди очевидно. Протягом майже всієї розробки стандарту управління віртуальним терміналом, зараз перебуває у прикладному рівні, містилося в рівні уявлення. Його перемістили в прикладний рівень, оскільки комітет ніяк не міг вирішити, для чого використовувати рівень представлення. Аспекти безпеки даних і шифрування інформації були настільки суперечливими, що з питання їх розміщення так і не було знайдено задовольняє всіх рішення, тому обидві ці функції були залишені за межами моделі. З аналогічних причин був опущений також питання управління мережею.
Ще одним критичним зауваженням на адресу оригінального стандарту було те, що він повністю ігнорував служби без встановлення з'єднання і протоколи без встановлення з'єднання, хоча більшість локальних мереж працювало саме таким чином. Наступні доповнення (звані в світі програмування bug fixes) виправили ці недоліки.
Можливо, найбільш сильним є наступне критичне зауваження: в моделі домінує комунікаційна ментальність. Взаємовідносини комп'ютерної індустрії і комунікацій майже ніде не згадуються, і деякі з рішень, використаних в моделі, абсолютно неприйнятні з точки зору роботи комп'ютерів і програмного забезпечення. Як приклад розгляньте примітиви OSI, наведені в табл. 1.2. Зокрема, гарненько подумайте про те, як використовувати ці примітиви в програмі.
Примітив CONNECT.request досить простий. Можна уявити собі бібліотечну процедуру connect, яку програми можуть викликати для встановлення зв'язку. Тепер розглянемо примітив CONNECT.indication. Коли прибуває повідомлення, що отримує процес повинен бути про це поінформовано. У результаті цей процес повинен отримати переривання, що навряд чи є прийнятною концепцією в програмах, написаних на будь-якому сучасному мові програмування високого рівня. Зрозуміло, на самому нижньому рівні індикація (переривання) відбувається. p> Якби програма очікувала вхідного дзвінка, вона могла б сама звернутися до бібліотечної процедурі receive. Але в такому разі чому receive ні зроблено примітивом замість indication? Примітив receive орієнтований на метод роботи комп'ютерів, тоді як indication швидше відображає спосіб роботи телефонів. Комп'ютери відрізняються від телефонів. Телефони дзвонять. Комп'ютери не дзвонять. Коротше кажучи, семантична модель системи, заснованої на переривання, є поганою ідеєю, абсолютно не узгоджується з усіма сучасними ідеями структурного програмування.
В
2.3 Невдала реалізація
огляду на величезну складність моделі і протоколів, то, що початкові реалізації виявилися громіздкими, незграбними і повільними, не стало несподіванкою. Невдачу зазнали всі, хто спробував реалізувати цю модель. Тож невдовзі поняття "OSI" стало асоціюватися з "поганою якістю". І хоча з часом продукти покращилися, асоціації залишилися.
Перші реалізації TCP/IP, засновані на Berkley UNIX В®, навпаки, були досить гарні (НЕ кажучи вже про те, що вони були відкритими). Вони досить швидко увійшли в вживання, що призвело до появи великої спільноти користувачів. Це викликало виправлення і поліпшення реалізації, в результаті співтовариство користувачів ще зросла. У даному випадку зворотний зв'язок явно була позитивною.
2.4 Невдала політика
Через особливості первісної реалізації багато, особливо в університетських колах, вважали TCP/IP частиною системи UNIX, а до системи UNIX в університетських колах в 1980-і рр.. випробовували почуття середні між батьківськими (у ті часи некоректно, в світлі утиску прав чоловічого населення, звані материнськими) і почуттями до яблучному пирогу.
З іншого боку, OSI вва...
