• Гідрологія і Гідрометрія
• Господарське право
• Економіка будівництва
• Економіка природокористування
• Економічна теорія
• Земельне право
• Історія України
• Кримінально виконавче право
• Медична радіологія
• Методи аналізу
• Міжнародне приватне право
• Міжнародний маркетинг
• Основи екології
• Предмет Політологія
• Соціальне страхування
• Технічні засоби організації дорожнього руху
• Товарознавство продовольчих товарів

Програмне керування консоллю

Наперед визначені дескриптори у Win32

Наперед визначені дескриптори у Win32 пов'язані із консоллю. Відмінність від POSIX полягає в тому, що такі дескриптори не відповідають конкретним цілим числам, а завжди є результатом виклику функції GetStdHandle( )

HANDLE GetStdHandle(DWORD std_const);

Параметр std_constвизначає, який дескриптор буде повернуто функцією, і за­дається як константа STD_INPUT_HANDLE, STDOUTPUT_HANDLEабо STD_ERROR_HANDLE.

char buf[1024]; DWORD bytes-read,bytes_written;

HANDLE stdin, stdout;

//одержати стандартні дескриптори

Stdin - GetStdHandle(STD_INPUT_HANDLE);

stdout = GetStdHandle(STD_OUTPUT_HANDLE);

//зчитати дані з файлу стандартного вводу

ReadFile(stdin, buf, sizeof(buf). &bytes_read, 0);

//вивести їх же у файл стандартного виводу

WriteFile(stdout, buf,Bytes_read, &bytes_written, 0):

На відміну від UNIX, у Win32 консоллю за замовчуванням володіють лише спе­ціалізовані консольні застосування або ті, для яких було встановлено прапорець CREATE_NEW_C0NS0LE, проте будь-яке застосування, що використовує графічний інтер­фейс, може створити собі консоль явно. Для цього використовують функцію А1locConsole( ). Після її виклику можна працювати зі стандартними вводом і виво­дом, вони будуть спрямовані на створену консоль. Після завершення роботи ре­сурси консолі можна вивільнити, викликавши FreeConsole( ).

AllocConsole():

// ... введення-виведення з використанням дескрипторів,

// повернутих GetStdHandle()

FreeConsole():

Для керування режимами консолі Win32 пропонує аналоги tcgetattr() і tcse­tattr()- функції GetConsoleMode( )і SetConsoleMode( ).Як перший параметр вони приймають дескриптор відкритої консолі, другим є маска прапорців режимів кон­солі (ENABLE_ECHO_INPUTзадає роботу в режимі луни).

GetConsoleMode(stdin, &mode);

SetConsoleMode(stdin. mode &~ENABLE_ECHO_INPUT);

// ... введення з використаннямstdinбез луни

SetConsoleMode(stdin, mode);//відновлення режиму

Лекція №2.

Тема: Командний інтерфейс користувача.

План:

1. Командний интерфейс користувача: принцип роботи командного інтерпритатора (Л1 ст.445-446).

2. Переспрямування потоків введення-виведення (Л1 ст.446-447).

3. Використання каналів (Л1 ст.448-449).

1.

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

В UNIX-системах командний інтерпретатор називають оболонкою (shell). Роз­роблено багато версій інтерпретаторів, серед них sh (вихідний варіант), csh (C-shell) і bash. Інтерпретатор bash входить у стандартну поставку більшості дистрибути­вів Linux. Системи лінії Windows ХР включають спеціалізований інтерпретатор cmd, який використовують під час роботи в режимі консолі.

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

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

$ cat myfile.txt

вміст файла myfile.txt

$ ... очікування введення

Унаслідок виконання цього командного рядка буде створено новий процес, куди буде завантажено код утиліти cat,параметром якої є ім'я файла. Утиліта зчитує цей файл і відображає його на стандартний вивід. Після завершення вико­нання утиліти інтерпретатор подає підказку і очікує введення наступного ко­мандного рядка.

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

$ updatedb &

$ ... очікування введення, updatedb продовжує виконання

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

Набори команд інтерпретатора можуть зберігатися в командних файлах (такі інтерпретатори, як bash, дають можливість використати в них досить потужну мову програмування). Цей командний файл може бути виконаний за тими сами­ми правилами, що і будь-який файл скрипта.

2.

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

$ sort > out.txt

$ sort < in.txt

Під час виконання таких команд результат виведення опиниться не на екрані, а у файлі out.txt, а введення буде виконано не з клавіатури, а з файла in.txt. При цьому очікування введення із клавіатури не буде.

Можна переспрямовувати одночасно і потік введення, і потік виведення:

$ sort < in.txt > out.txt

У даному випадку програма зчитує дані з одного файла, обробляє їх і записує в інший файл.

Стандартний дескриптор, що відповідає файлу повідомлень про помилки stderr,при цьому не переспрямовують. Для його переспрямування використову­ють такий синтаксис:

$ sort 2> err.txt

3.

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

$ grep linux * I sort

У цьому разі результати виконання утиліти дгер передаватимуться на стан­дартний ввід утиліті sort. Канали можуть об'єднувати будь-яку кількість процесів.

Ще один спосіб використання каналів зводиться до обміну даними між про­цесом і командним інтерпретатором, під час якого результати виконання процесу будуть підставлені в командний рядок інтерпретатора. Таку технологію назива­ють командною підстановкою (command substitution), для цього командний ря­док виклику застосування, результати виконання якого потрібно використати, беруть у зворотні лапки: ~виконуваний_файл параметри¹.

$ grep linux 'cat filelist.txt'

У даному випадку файл filelist.txt містить список імен файлів, у яких потрібно зробити пошук. Внаслідок виконання утиліти cat список має видаватись на стан­дартний вивід, але замість цього його підставляють у командний рядок виклику утиліти grep.

Лекція №3.

Тема: Графічний інтерфейс користувача.

План:

1. Графічний интерфейс користувача (Л1 ст.450).

2. Интерфейс віконної та графічної підсистеми Windows XP (Л1 ст.450-451).

3. Система X-Window: базова архітектура системи X-Window(Л1 ст. 455-456).

4. Віконні менеджери X-Window (Л1 ст.456-457).

5. Клієнтські застосування та інструментальні бібліотеки X-Window (Л1 ст. 457-458).

6. Служби Windows XP(Л1 ст.462-463).

1.

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

Розрізняють два основних підходи до реалізації графічного інтерфейсу кори­стувача. Для першого характерна тісна інтеграція у систему засобів його підтрим­ки (вони, наприклад, можуть бути реалізовані в режимі ядра). Другий реалізує підтримку такого інтерфейсу із використанням набору застосувань і бібліотек рівня користувача, який ґрунтується на засобах підсистеми введення-виведення. У цьому розділі як приклад інтегрованої підтримки графічного інтерфейсу кори­стувача буде описано віконну і графічну підсистеми Windows ХР, а як приклад реалізації його підтримки в режимі користувача - систему X Window

2.

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

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

Таку постійну готовність складно реалізувати із використанням послідовного виконання коду. У Win32 (і більшості систем, що реалізують графічний інтер­фейс користувача) використовують інший підхід до організації програмного ко­ду: в ній реалізовані застосування, керовані повідомленнями (message-driven appli­cations). Усі дії користувача (введення із клавіатури, переміщення миші тощо) ОС перехоплює і перетворює у повідомлення (messages), які скеровує застосуван­ню, що володіє вікном, із яким працював користувач. Код застосування містить цикл обробки повідомлень, де відбуваються очікування повідомлень та їхні необ­хідні перетворення, а також оброблювач повідомлень, що його викликають у разі отримання кожного повідомлення. В оброблювачі реалізовано код, який визначає реакцію застосування на ту чи іншу дію користувача. Цикл обробки повідомлень триває доти, поки в нього не потрапить особливе повідомлення, що змушує за­вершити роботу застосування.

3.

У деяких ОС графічні підсистеми не є інтегрованими і не виконуються у режимі ядра. Таким прикладом є система X Window (X Window System), яку дотепер широко використовують в UNIX-системах. Система X Window розроблена із використанням клієнт-серверного підходу, але її базові ідеї відрізняються від традиційних концепцій цієї архітектури.

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

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

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

Клієнти і сервери можуть перебувати на різних комп'ютерах і виконуватися під різними операційними системами (рис. 17.2). Х-протокол звичайно працює поверх TCP/IP, фактично він є набором домовленостей про передавання спе­ціальних двійкових даних. Один сервер може одночасно відображати інформацію від клієнтів, що перебувають на різних комп'ютерах. Наприклад, комп'ютер під керуванням Linux може відображати засоби редагування відеоінформації, запуще­ні на комп'ютері Silicon Graphics під керуванням ОС IRIX, та адміністративний інтерфейс (вікно додавання нового користувача), запущений на іншій Linux-маши­ні. При цьому жодне із цих застосувань не перебуває у пам'яті комп'ютера, на яко­му виконується Х-сервер. З іншого боку, комп'ютери, на яких запущені Х-клієнти, можуть взагалі не підтримувати графічного відображення інформації — для них досить наявності зв'язку із сервером через мережу.

Використання системи X Window не виключає можливості консольного доступу до ОС. З одного боку, на машині з Х-сервером є можливість перемикання між ним і текстовою консоллю, з іншого боку, всі поставки системи X Window включають клієнтську програму xterm, що реалізує емуляцію терміна­ла. Це застосування дає можливість користувачу запускати командний інтерпре­татор і консольні застосування на віддаленій машині та відображати результати їхнього виконання на екрані Х-сервера.

4.

Команди, надіслані клієнтами сервера, звичайно пов'язані із необхідністю відобра­ження інформації у вікні застосування - ділянці екрана, якою володіє відповідне застосування. Важливою властивістю системи X Window є те, що Х-сервер не відповідає за роботу із такими вікнами, для цього використовують спеціальне клієнтське застосування — віконний менеджер (window manager). В обов'язки та­кого менеджера входить підтримка базових операцій над вікнами (їхнього пере­міщення, закриття або зміни розмірів), а також «декорування» вікон (відображен­ня рамки, заголовка тощо).

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

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

5.

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

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

На практиці застосування розробляють із використанням набору функцій високого рівня, реалізованих із використанням XLib. Такі функції можуть відповідати за відображення конкретних елементів керування і за обробку дій, виконаних користувачем із цими елементами; вони доступні в рамках інструментальних бібліотек (toolkit libraries). Елементи керування в термінології X Window називають віджетами (widgets), тому такі бібліотеки називають ще бібліотеками віджетів (widget toolkits). Є так само багато інструментальних бібліотек, як і віконних менеджерів, серед найвідоміших можна виокремити Motif (найпоширеніша 6ібліотека початку 90-х років, не є безкоштовною), Gtk, Qt (дві останні доступні у вихідних кодах, і їх широко використовують у сучасних системах, зокрема в Linux)

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

6.

Аналогом демонів у Windows ХР є служби (services) - фонові процеси, які мо­жуть виконуватися навіть тоді, коли із системою не працює жоден користувач . За керування службами відповідає ме­неджер служб (Service Control Manager). Він приймає керуючі команди від засто­сувань і відповідно до них виконує дії зі службами (наприклад, запускає на вико­нання або зупиняє).

Користувацький інтерфейс менеджера служб реалізовано двома способами:

· за допомогою вікна керування службами (Services), яке викликають через під-меню Administrative Tools головного меню системи (це вікно відображає список служб, дає змогу запускати і зупиняти окремі служби, дізнаватися про їхні властивості тощо);

· за допомогою утиліти net. ехе, що входить у поставку Windows ХР; наприк­лад, команда net start ім'я_служби дає команду менеджерові запустити відпо­відну службу, net stop і м' я_служби - зупинити її.

Для керування службами необхідно мати адміністративні права у системі.

Розділ 9. Мережні засоби операційних систем.

(аудиторних6/4г. , самостійних- 12/4г.)

Лекція №1.

Тема: Рівні мережної архітектури та протоколи.

План:

1. Загальні принципи мережної підтримки (Л1 ст. 397).

2. Рівні мережної архітектури і мережні сервіси (Л1 ст. 398).

3. Мережні протоколи (Л1. ст. 398-399).

4. Рівні мережної архітектури TCP/IP (Л1 ст. 399-400).

1.

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

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

Відомий усім Інтернет (з великої літери)- це, фактично, сукупність пов'яза­них між собою інтернетів, відкритих для публічного доступу, які використовують визначений набір протоколів (стек протоколів TCP/IP) і охоплюють увесь світ.

2.

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

У разі використання цього підходу для кожного типу мереж проектують ета­лонну модель протоколів, що описує функції окремих рівнів і зв'язки між рівня­ми. Фактично ця модель визначає мережну архітектуру, а рівні є її складовими частинами. Як приклад можна навести мережну архітектуру Інтернету, яку наве­дено у розділі 16.2.

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

Розрізняють сервіси, орієнтовані на з'єднання (connection-oriented services), і без з'єднань, або дейтаграмні сервіси (connectionless services).

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

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

3.

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

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

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

Мережний протокол надає два інтерфейси.

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

2. Інтерфейс сервісу (service interface) призначений для взаємодії із засобами ви­щого рівня; за його допомогою фактично реалізують мережний сервіс. Інтер­фейс сервісу забезпечують правилами інкапсуляції пакетів вищого рівня в па­кети цього протоколу.

Набір протоколів різного рівня, що забезпечують реалізацію певної мережної архітектури, називають стеком протоколів (protocol stack) або набором протоко­лів (protocol suite).

4.

Сукупність протоколів, які лежать в основі сучасного Інтернету, називають набо­ром протоколів Інтернету (Internet Protocol Suite, IPS) або стеком протоколів TCP/IP за назвою двох основних протоколів.

Мережна архітектура TCP/IP має чотири рівні, яки показані на рис. 16.1. Розгля­немо їх знизу вгору.

Канальний рівень (data link layer) відповідає за передавання кадру даних між будь-якими вузлами в мережах із типовою апаратною підтримкою (Ethernet, FDDI тощо) або між двома сусідніми вузлами у будь-яких мережах (SLIP, РРР). При цьому забезпечуються формування пакетів, корекція апаратних помилок, спільне використання каналів. Крім того, на більш низькому рівні він забезпечує передавання бітів фізичними каналами, такими як коаксіальний кабель, кручена пара або оптоволоконний кабель (іноді для опису такої взаємодії виділяють окре­мий фізичний рівень — physical layer).

Перш ніж перейти до наступного рівня, дамо два означення. Хостом (host) є вузол мережі, де використовують стек протоколів TCP/IP. Мережним інтер­фейсом (network interface) є абстракція віртуального пристрою для зв'язку із мере­жею, яку надає програмне забезпечення канального рівня. Хост може мати декіль­ка мережних інтерфейсів, зазвичай вони відповідають його апаратним мережним пристроям.

На мережному рівні (network layer) відбувається передавання пакетів із вико­ристанням різних транспортних технологій. Він забезпечує доставлення даних між мережними інтерфейсами будь-яких хостів у неоднорідній мережі з довіль­ною топологією, але при цьому не бере на себе жодних зобов'язань щодо надійно­сті передавання даних. На цьому рівні реалізована адресація інтерфейсів і мар­шрутизація пакетів. Основним протоколом цього рівня у стеку TCP/IP є IP (Internet Protocol).

Транспортний рівень (transport layer) реалізує базові функції з організації зв'язку між процесами, що виконуються на віддалених хостах. У стеку ТСР/ІР на цьому рівні функціонують протоколи TCP (Transmission Control Protocol) і UDP (User Datagram Protocol). TCP забезпечує надійне передавання повідомлень між віддаленими процесами користувача за рахунок утворення віртуальних з'єднань. UDP забезпечує ненадійне передавання прикладних пакетів (подібно до ІР), виконуючи винятко­во функції сполучної ланки між ІР і процесами користувача.

Прикладний рівень (application layer) реалізує набір різноманітних мережних сервісів, наданих кінцевим користувачам і застосуванням. До цього рівня нале­жать протоколи, реалізовані різними мережними застосуваннями (службами), наприклад, НТТР (основа організації Web), SMTP (основа організації переси­лання електронної пошти).

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

Лекція №2.

Тема: Передавання даних стеком протоколів Інтернету.

План:

1. Канальний рівень (Л1 ст. 401).

2. Мережний рівень (Л1 ст.401-402).

3. Транспортний рівень (Л1 ст. 402-403).

4. Передавання даних стеком протоколів Інтернету (Л1 ст. 403-405).

1.

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

Як зазначено вище, кількість мережних інтерфейсів звичайно співвідносить­ся з кількістю мережних апаратних пристроїв хоста. Крім того, виділяють спеці­альний інтерфейс зворотного зв'язку (loopback interface); усі дані, передані цьому інтерфейсу, надходять на вхід реалізації стека протоколів того самого хоста.

2.

Читайте також:

1. D-тригер з динамічним керуванням
2. II.1 Програмне забезпечення
3. Автократично-демократичний континуум стилів керування.
4. Автоматизація водорозподілу на відкритих зрошувальних системах. Методи керування водорозподілом. Вимірювання рівня води. Вимірювання витрати.
5. Автоматизація меліоративних помпових стацій. Автоматизація керування помповими агрегатами.
6. Агресивне керування портфелем акцій
7. Алгоритми керування ресурсами
8. Аналіз конструкції рульового керування.
9. Апарати керування пневматичними приводами.
10. Багатокритеріальні завдання оптимального керування
11. Блок формування імпульсів керування
12. Будівлі органів керування, кредитування й громадських організацій

Переглядів: 732