План нмв 2004 р. Укладачі

Вид материала

Документы

Содержание Взаємодія процесів в ос unix 2 Основні положення 2.2 Програмний інтерфейс сокетів Sock_stream ipproto_tcp (tcp) 2.3 Приклад використання сокета 3 Контрольні запитання 4 Домашнє завдання 5 Лабораторне завдання 6 Зміст протоколу Програмна реалізація протоколів тср/ір 2 Основні положення 3 Контрольні запитання 4 Домашнє завдання 5 Лабораторне завдання 6 Зміст протоколу

Подобный материал:

• Перлина українського театру, 100.45kb.
• Конспект лекции Методика формализованного составления обзора План, 144.39kb.
• Пояснительная записка данная рабочая учебная программа составлена в соответствии, 120.81kb.
• Принят Государственной Думой 24 мая 1996 года. Одобрен Советом Федерации 5 июня 1996, 39.78kb.
• Програма дій щодо реалізації положень Болонської декларації в системі вищої освіти, 77.05kb.
• Одобрен Советом Федерации 24 сентября 2003 года Распоряжением Правительства, 2307.63kb.
• Список статей периодических изданий. Базисный план для среднего (полного) общего образования., 191.48kb.
• Краткое содержание темы, 108.84kb.
• Вестник Банка России, n 2, 14. 01. 2004; указанием Банка России от 1 июня 2004 года, 20.19kb.
• Указатель литературы, 117.65kb.

Лабораторна робота № 16

ВЗАЄМОДІЯ ПРОЦЕСІВ В ОС UNIX

ЗА ДОПОМОГОЮ ІНТЕРФЕЙСУ СОКЕТІВ

1 Мета роботи


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


2 Основні положення


2.1 Загальні вимоги до міжпроцесної взаємодії


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

• впорядковане доставлення даних;
  
• відсутність дублювання даних;
  
• надійне доставлення даних;
  
• підтримку передавання екстрених даних;
  
• попереднє встановлення зв’язку.
  

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

Усім наведеним вимогам задовольняють спеціальні об’єкти — сокети (socket). Сокети створюються у межах певного комунікаційного домена (communication domain), який описує набір характеристик взаємодії. Сокет означає поняття комунікаційного вузла, який забезпечує приймання та передавання даних для процесу. Адресування сокетів, їхнє розташування, протоколи передавання даних можуть бути різними. Це описується в понятті комунікаційного домена. Сокети мають інтерфейс доступу до файлової системи UNIX та можуть бути адресовані цілим числом — дескриптором. На відміну від звичайних файлів, сокети — це віртуальний об’єкт, який існує доти, поки на нього посилається хоча б один з процесів.

Взаємодія з попереднім установленням з’єднання передбачає створення віртуального каналу поміж джерелом та одержувачем даних. Це позбавляє від необхідності ідентифікувати передавальну сторону у кожному пакеті даних. Ідентифікування відбувається на початковому етапі встановлення зв’язку, а потім зберігається для усіх пакетів, які належать даному віртуальному каналові.

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

У BSD UNIX зреалізовані такі основні типи сокетів:

• сокет дейтаграм (Datagram Socket), через який здійснюється теоретично ненадійне, незв’язане передавання пакетів;
  
• сокет потоку (Stream Socket), через який здійснюється передавання потоку даних без зберігання меж повідомлень. Цей тип сокетів підтримує передавання екстрених повідомлень;
  
• сокет пакетів (Packet Socket), через який здійснюється надійне передавання даних без дублювання з попереднім встановленням зв’язку. Межі повідомлень зберігаються;
  
• сокет низького рівня (Raw Socket), через який здійснюється безпосередній доступ до комунікаційного протоколу.
  

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


2.2 Програмний інтерфейс сокетів


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

• Сокет дейтаграм — SOCK_DGRAM
  
• Сокет потоку — SOCK_STREAM
  
• Сокет пакетів — SOCK_SEQPACKET
  
• Сокет низького рівня — SOCK_RAW
  

Останній тип сокетів використовується для переглядання ICMP-повідомлень.

Для створення сокета процес має зазначити тип сокета та комунікаційний домен, у рамцях якого використовуватиметься сокет. Комунікаційний домен може підтримувати використання кількох протоколів, тому процес може зазначити конкретний комунікаційний протокол для взаємодії. Але якщо його не зазначено, система сама обирає найбільш придатний зі списку протоколів, доступних для даного комунікаційного домена. Для створення сокета використовується системний виклик socket(2):

#include

#include

int socket (int domain, int type, int protocol)

Аргумент domain визначає комунікаційний домен, type — тип сокета, а protocol — використовуваний протокол, за умовчанням зазначається непрямо і може дорівнювати 0. У разі успішного виконання системний виклик повертає додатне ціле число, аналогічне файловому дескриптору, яке трактується далі як адреса даного сокета у подальших викликах.

Комунікаційний домен визначає сім’ю протоколів (Protocol Family), припустимих у межах даного домена. Можливі значення аргументу domain такі:

AF_UNIX — домен локальної міжпроцесної взаємодії у межах однієї ОС UNIX, внутрішні протоколи.

AF_INET — домен взаємодії процесів віддалених систем, протокол Internet (TCP/IP).

AF_NS — домен взаємодії процесів віддалених систем, протокол

Хerox NS.

Префікс AF визначає адресний простір взаємодії; припустимі є також назви з префіксом PF (Protocol Family); PF_UNIX, PF_INET тощо. Для домена AF_INET можливі такі комбінації типу сокета та використовуваного комунікаційного протоколу:

SOCK_STREAM IPPROTO_TCP (TCP)

SOCK_DGRAM IPPROTO_UDP (UDP)

SOCK_RAW IPPROTO_ICMP (ICMP)

SOCK_ RAW IPPROTO_RAW (IP)

Для однозначної ідентифікації сокета його слід прив’язати до простору імен конкретного комунікаційного домена. Кожний комунікаційний канал визначається двома вузлами — джерелом та отримувачем даних і схарактеризовується п’ятьма параметрами:

• комунікаційним протоколом,
  
• локальною адресою,
  
• локальним процесом,
  
• віддаленою адресою,
  
• віддаленим процесом.
  

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

На рис. 2.1 подано взаємодію поміж процесами при віртуальному комунікаційному каналі з попереднім встановленням зв’язку.





Рисунок 2.1 — Взаємодія поміж процесами при створюванні віртуального каналу з попереднім встановленням зв’язку


На рис. 2.2 подано взаємодію, базовану на дейтаграмах без попереднього встановлення зв’язку.





Рисунок 2.2 — Взаємодія поміж процесами, базована на дейтаграмах

без попереднього встановлення зв’язку


Фактичному передаванню даних передує первісна фаза зв’язування (Binding) сокета засобами встановлення додаткової інформації, необхідної для визначення комунікаційного вузла. Зв’язування зреалізовується за допомогою системного виклику bind(2):

#include

#include

int bind (int sockfd, struct sockaddr *localaddr, int addrlen).

Дескриптор сокета, sockfd, отримується при створюванні сокета; аргумент localaddr визначає локальну адресу, з якою треба зв’язати сокет; параметр addrlen визначає розмір адреси. У процедурі зазначається локальна адреса, яка визначає два параметри комунікаційного каналу: локальну адресу та локальний процес.


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

struckt sockaddr {

u_short sa_family;

char sa_data[14];

};

Поле sa_family визначає комунікаційний домен (сім’ю протоколів), а sa_data вміщує саме адресу, формат якої визначено для кожного домена. Наприклад, для внутрішнього домена UNIX адреса, визначена y , має вигляд

struckt sockaddr_un {

short sun_family; /*= = AF_UNIX*/;

char sun_path[108];

};

У цьому разі взаємодіючі процеси виконуються під керуванням однієї ОС на одному хості, комунікаційний вузол може бути однозначно визначено лише одним параметром — локальним процесом. У домені UNIX за адресу вважається ім’я файла.




Рисунок 2.3 — Адреси сокетів


У разі мережного обміну даними слід зазначити адресу як локального процесу, так і хоста, на якому виконується даний процес. Для домена Internet (сім’я протоколів ТСР/ІР) використовується формат адрес, визначений у файлі :

struct sockaddr_in {

short sin_family; /*= = AF_INET */;

u_short sin_port;

struckt in_addr sin_addr;

char sin_zero[8];

};

Адреса цього домена (ІР-адреса) — це 32-розрядне ціле число sin_addr, а процес-додаток адресується 16-розрядним номером порту sin_port (рис. 2.3).

Зв’язування потрібне для привласнення сокетові локальної адреси й тим самим визначення комунікаційного вузла і зреалізовується системною функцією bind(2):

1. Сервер реєструє свою адресу, яка має бути відома заздалегідь клієнтам, які “спілкуються” з сервером. Зв’язування необхідне перш ніж сервер буде готовий до приймання запитів від клієнтів.
   
2. За взаємодії без попереднього встановлення зв’язку та створення віртуального каналу клієнт також повинен заздалегідь зареєструвати свою адресу, яка є унікальною в межах комунікаційного домена. У разі домена UNIX цим опікується додаток. Ця адреса не повинна бути відома серверові, тому що запит завжди ініціює клієнт і автоматично передає разом з ним власну адресу. Отримана адреса віддаленого вузла використовується сервером для мультиплексування повідомлень, які надсилаються різним клієнтам.
   
3. У разі взаємодії з використанням віртуального каналу клієнт може зареєструвати власну адресу й не спрямовувати цю функцію системі.
   

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

#include

#include

int connect (int sockfd, struct sockaddr *servaddr, int addrlen);

Системний виклик connect(2) створює віртуальний канал та виконується для попереднього встановлення зв’язку між комунікаційними вузлами. Клієнтові не треба зв’язувати сокет за допомогою системного виклику bind(2). Локальний вузол комунікаційного каналу зазначається дескриптором сокета sockfd, для якого система автоматично обирає потрібні значення локальної адреси та процесу. Віддалений вузол визначається аргументом servaddr, який вказує на адресу серверові, а addrlen задає його довжину.

Виклик connect(2) може також використовуватися і клієнтами, які створюють сокети дейтаграм без створення віртуального каналу. У такому разі connect(2) не зреалізовує фактичного з’єднання з сервером, а може бути використаний для зберігання параметрів адреси сервера, якому буде спрямовано дейтаграми. Клієнт буде позбавлений від необхідності зазначати адресу серверові при кожному відправленні даних.

Системний виклик listen(2) інформує систему про готовність сервера приймати запитання. Він має такі параметри:

#include

#include

int listen (int sockfd, int backlog);

Параметр backlog зазначає максимально можливу кількість запитань на встановлення зв’язку, які можуть очікувати, коли їх опрацює сервер. Якщо запит надходить, коли черга очікуючих запитів є повна, виклик connect(2) клієнта завершиться для домена UNIX (AF_UNIX) з помилкою ECONNRЕFUSED. Для інших доменів результат буде залежати від того, чи підтримує протокол повторне передавання запиту. Протокол ТСР (домен AF_INET) передаватиме повторні запити, допоки кількість запитів у черзі не зменшиться або не настане тайм-аут, окреслений для протоколу. У цьому разі виклик клієнта завершиться з помилкою ETIMEDOUT.

Фактичне опрацювання запиту клієнта на встановлення зв’язку зреалізовує системний виклик accept(2):

#include

#include

int accept (int sockfd, struct sockaddr *clntaddr, *int addrlen);

Виклик accept(2) обирає перший запит з черги і створює новий сокет, характеристики якого не відрізняються від сокета sockfd і завершує створення віртуального каналу з боку сервера. Одночасно accept(2) повертає параметри віддаленого комунікаційного вузла — адресу клієнта clntaddr та його розмір addrlen. Новий сокет використовується для обслуговування створеного віртуального каналу, а отримана ним адреса клієнта виключає його анонімність. Типовий сценарій взаємодії має вигляд:

sockfd = socket(...); Створити сокет

bind (sockfd, …); Сполучити його з відомою локальною адресою

listen (sockfd, …); Організувати чергу запитів

for ( ; ; ) {

newsockfd = accept (sockfd, …) ; Отримати адресу

if /fork( ) = = 0 { ; Породити дочірній процес

close (sockfd) ; Дочірній процес

·

·

·

exit (0);

}

else

close (newsockfd); Батьківський процес

}


У цьому сценарії, у той час, коли дочірній процес забезпечує фактичний обмін даними з клієнтом, батьківський процес продовжує “прослуховувати” запити, котрі знову надходять, породжуючи для кожного з них окремий процес-опрацьовувач. Черга дозволяє буферизувати запити на той час, коли сервер завершує виклик accept(2), а потім створює дочірній процес. Новий сокет newsockfd, який створюється викликом accept(2), адресує повністю визначений комунікаційний канал: протокол та повні адреси обох вузлів — клієнта та сервера. Для сокета sockfd визначено лише локальну частину каналу. Це дозволяє серверові продовжувати використання sockfd для “прослуховування” наступних запитів.

Системні виклики listen(2) та accept(2) використовуються сервером лише в разі встановлення віртуального каналу поміж сервером та клієнтом.

Якщо для сокетів потоку під час приймання та передавання даних можуть використовуватися стандартні виклики read(2) та write(2), то сокети дейтаграм мають користуватися спеціальними системними викликами, які також є доступними для інших типів сокетів.

#include

#include

int send (int s, const char *msg, int len, int flags);

int sendto (int s, const char *msg, int len, int flags,

const struct sockaddr *toaddr, int tolen);

int recv (int s, char *buf, int len, int flags);

int rеcvfrom (int s, char *buf, int len, int flags,

struct sockaddr *fromaddr, int * fromlen)

Функції send(2) та sendto(2) використовуються для передавання даних віддаленому вузлу, а функції recv(2) та rеcvfrom(2) — для їхнього приймання. Основною відміною поміж ними є те, що функції send(2) та recv(2) використовуються лише для “долученого” сокета, тобто після виклику connect(2).

Усі ці виклики використовують перший аргумент — дескриптор сокета, через який зреалізовується обмін даними. Аргумент msg вміщує повідомлення довжиною len, яке передається за адресою toaddr, довжина його становить tolen байтів. Для функції send(2) використовується адреса одержувача, встановлена попереднім викликом connect(2). Аргумент buf — це буфер, у який копіюються отримані дані.

Параметр flags може набирати таких значень:

MSG_OOB Передати або прийняти екстрені дані (out of band) замість звичайних

MSG_PEEK Переглянути дані без вилучення їх з системного буфера (наступні операції читання отримають ті ж самі дані)


2.3 Приклад використання сокета


Взаємодію поміж процесами за допомогою сокетів можна продемонструвати на прикладі домена UNIX. Функціональність розподіленої системи у цьому разі полягає в тому, що клієнт надсилає серверові повідомлення, сервер переспрямовує його клієнтові, який і виводить його після отримання на термінал, оскільки у домені UNIX сокети дейтаграм практично не відрізняються від сокетів потоку. Як адресу сервера можна зазначити ім’я файла ./echo.server й припустити, що клієнти знають цю адресу. Сервер зв’язує створений сокет з цією локальною адресою і в такий спосіб реєструється в системі. З цього моменту він готовий до приймання та опрацьовування повідомлень. Сервер починає нескінченний цикл, очікуючи на повідомлення від клієнтів та блокуючись на виклику recvfrom(2). При отриманні повідомлення сервер надсилає його клієнтові, за допомогою виклику sendto(2). У додатку наведено програми серверної та клієнтської сторін. Клієнт створює сокет дейтаграм та зв’язує його зі своєю унікальною адресою, що зумовлюється унікальністю імені файла. Оскільки водночас можуть працювати кілька клієнтів, виникає проблема отримання унікального імені. Для її розв’язання використовується функція mktemp(3c), яка дозволяє за заданим шаблоном /tmp/clnt.XXXX та на підставі ідентифікатора поточного процесу отримати унікальне ім’я на заміну символів ХХХХ. Зв’язування сокета дозволяє при відправлянні неявно зазначати його “адресу відправника”, тому сервер може повернути повідомлення. У додатку Б (Лістинг1 та Лістинг 2) наведено вихідні тексти програм, що вони зреалізовують взаємодію поміж процесами, яка грунтується на сокетах дейтаграм у домені UNIX.


3 Контрольні запитання


1 Які комунікаційні характеристики забезпечують сокети?

2 Які основні типи сокетів зреалізовано в BSD UNIX?

3 Який системний виклик створює сокет та який він має опис?

4 Що таке комунікаційні домени та які домени Ви знаєте?

5 Який зв’язок існує поміж комунікаційними доменами та підтримуваними ними сокетами?

6 Якими параметрами схарактеризовується кожний комунікаційний канал?

7 Які системні виклики використовуються на серверному та клієнтському боці при створенні віртуального каналу з попереднім встановленням з’єднання?

8 Які системні виклики використовуються на серверному та клієнтському боці за взаємодії, яка грунтується на дейтаграмах?

9 Яку довжину і формати мають адреси сокетів у різних доменах?

10 Яку адресу слід обирати для сервера й чому?


4 Домашнє завдання


1 Коротко відповісти на контрольні запитання у письмовому вигляді.

2 Переписати тексти клієнтської та серверної частин програми, яка зорганізовує взаємодію процесів за протоколом UDP, та коментарі до них; тексти програм наведено у додатку Б (Лістинг1 та Лістинг2).


5 Лабораторне завдання


1 Підімкніться до комп’ютера під керуванням ОС UNIX за допомогою telnet (“Пуск\Виконати\telnet ip”, де ip — адреса машини під керуванням UNIX).

2 Після підімкнення введіть ім’я (login) та пароль (password) згідно з таблицею 5.1.


Таблиця 5.1 — Імена та паролі

login	st1	st2	st3	st4	st5	st6	st7	st8	st9
password	st1	st2	st3	st4	st5	st6	st7	st8	st9
login	st11	st12	st13	st14	st15	st16	st17	st18	st19
password	st11	st12	st13	st14	st15	st16	st17	st18	st19

3 Створіть текстові файли socketserver.c та socketclient.c, вихідні тексти програм цих файлів розміщено в додатку Б (Лістинг1 та Лістинг2).

4 Відкомпілюйте програми та створіть об’єктні файли:

сс -о socketserver socketserver.c

та

сс -о socketclient soketclient.c

5 Якщо все пройшло успішно, на першому терміналі запустіть виконуваний файл ./socketserver, а на другому — ./socketclient.

6 Спостерігайте з’явлення повідомлення на клієнтському боці.

7 Змініть текст повідомлення на своє прізвище, ім’я та побатькові.

8 Знову відкомпілюйте програми та виконайте пункти 4...6 даного завдання.

9 Змоделюйте ситуацію в такий спосіб, щоби серверна частина програми видала поодинці усі повідомлення про помилки.

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

11 Поясніть, як Ви досягли результату й які причини є джерелами кожної помилки.

12 Зробіть висновки й запишіть їх до протоколу.


6 Зміст протоколу


Протокол лабораторної роботи “Взаємодія процесів в ОС UNIX за допомогою інтерфейсу сокетів” оформлюється в робочому зошиті в послідовності, котра визначається стандартом підприємства з основ лабораторного практикуму. Протокол має містити назву лабораторної роботи та її мету; результати виконання домашнього завдання згідно з вимогами пункту 1 домашнього завдання, тексти програм socketserver та socketclient з коментарями, результати виконання пунктів 6...11 лабораторного завдання, висновки.


7 Список рекомендованої літератури


1 Робачевский А. М. Операционная система UNIX. — СПб.: БХВ-Петербург, 2002.

2 Ивановский С. Операционная система UNIX. — М.: Познавательная книга плюс, 2000.

3 Дегтярев Е. К. Введение в UNIX. — М.: МП "Память", 1991.

4 ссылка скрыта

5 ссылка скрыта

6 ссылка скрыта


Лабораторна робота № 17


ПРОГРАМНА РЕАЛІЗАЦІЯ ПРОТОКОЛІВ ТСР/ІР


1 Мета роботи


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


2 Основні положення


Взаємодія поміж віддаленими процесами передбачає передавання даних по мережі, тому використовуваним комунікаційним доменом сокетів є домен АF_ІNET. Згідно зі схемою адресування протоколів ТСР/ІР комунікаційний вузол однозначно ідентифікується двома значеннями: адресою хоста (ІР-адреса) та адресою процесу (адреса порту). Це відбиває структура sockaddr_in, яка є конкретним видом загальної структури адреси сокета sockaddr. Структура sockaddr_in має вигляд

struct sockaddr_in {

short sin family; Комунікаційний домен — АF_INET

u_short sin_port; номер порту

struct in_addr sin_addr; IP-адреса хоста

char sin_sero[8];

};

Адреса порту повинна бути відома клієнтові та серверові. Транспортний протокол, використовуваний у мережі найчастіше — це ТСР, він передбачає попереднє з’єднання клієнта з сервером перед передаванням прикладних даних. Сервер зв’язується з портом, номер якого відомий клієнтам за допомогою системного виклику bind(2), та повідомлює про готовність до приймання запитань за допомогою системного виклику listen(2). При отриманні запиту він за допомогою функції accept(2) створює новий socket, який обслуговує обмін даними поміж клієнтом та сервером. Для того щоб сервер міг продовжувати опрацьовувати запити, що вони надходять, він породжує окремий процес на кожний запит, котрий надійшов. Дочірній процес, своєю чергою, приймає повідомлення від клієнта за допомогою системного виклику recv(2) та передає їх назад до клієнта за допомогою системного виклику send(2). Клієнт не виконує сполучування, тому що йому є байдуже, яку адресу матиме його комунікаційний вузол. Цю операцію виконує ОС, яка обирає вільну адресу порту та встановлену адресу хоста. Далі клієнт спрямовує запит на встановлювання з'єднання connect(2), зазначаючи ІР-адресу та номер порту клієнта. Після встановлення з’єднання (“потрійне ручкання”) клієнт передає повідомлення за допомогою send(2), приймає від серверу відповідь за допомогою recv(2) та виводить його на екран. На рис. 2.1 подано схему встановлення зв’язку та передавання даних поміж клієнтом та сервером за протоколом TCP/IP.




Рисунок 2.1 — Схема встановлення з’вязку та передавання даних

поміж клієнтом та сервером


Системний виклик АРІ-сокетів, який забезпечує встановлення з’єднання за протоколом ТСР, connet(2), має вигляд

#include

int connect (s, const struct sockaddr *peer, int peer_lеn);

У разі помилки функція повертає значення -1. Параметр s — дескриптор сокета, який повернув виклик socket(2). Параметр peer вказує на структуру, в якій зберігається адреса віддаленого хоста. Для домена AF_INET — це структура типу sockaddr_in. Параметр peer_lеn вміщує розмір структури у байтах, на яку вказує peer. Після встановлення з’єднання дані можна передавати, окрім системних викликів recv(2) та send(2), за допомогою викликів read(2) та write(2). Системні виклики recv(2) та send(2) мають вигляд

#include

int recv (s, void *buf, size_t len, int flags);

int send (s, const void *buf, size_t len, int flags);

Значення, що повертається, є кількість прийнятих чи то переданих байтів у разі успіху, або -1 —у разі помилки.

У наведених далі програмах ТСР-сервера та ТСР-клієнта використовується ще кілька АРІ-функцій, які автоматизують процес написання програми.

Функція gethostbyname(3N) транслює доменне ім’я до його ІР-адреси.

Функція getservbynamе(3N) робить обернене перетворювання. Функція htonl(3N) зводить до потрібного порядок слідування байтів у структурах даних, які можуть відрізнятись для хосту та мережі.

Функція inet_ntoa(3N) перетворює ІР-адреси та їхні складові частини на звичну форму, наприклад 127.0.0.1. Більш докладно про ці функції можна дізнатися в електронному довідникові man(1).

Зупинімось лише на таких обставинах. Якщо додаток підтримує протоколи ТСР/ІР, то така інформація, як адреса джерела та приймача, номери портів, довжина пакетів тощо — це цілі числа; необхідно, щоби клієнт та сервер інтерпретували їх однаково. Аби забезпечити взаємодію комп’ютерів, які працюють на різних мікропроцесорах з різними архітектурами, всі цілі дані, що належать до протоколів, треба передавати в мережному порядку байтів, який називається “тупокінцевим”. Він збігається з порядком адресування байтів, притаманним, приміром, мікропроцесорам фірми Motorola: старший байт у багатобайтових даних адресується молодшою адресою, а молодший — старшою (big endian). На відміну від такого порядку, мікропроцесори фірми Intel адресують багатобайтові дані у “гострокінцевому” порядку: старший байт — старшою адресою, молодший — молодшою (little endian). Системні виклики htonl(2) та htons(2) повертають ціле число в мережному порядку. Літери l та s наприкінці імен функцій означають long (довге) та short (коротке). l-функції призначено для перетворювання довгих полів у заголовках протоколу, а s-функції — коротких.

#include

uint 32_t htonl(uint 32_t host 32);

uint 16 _t htons(uint 32_t host 16);

Обидві функції повертають ціле число в мережному порядку.

Функції ntohl та ntohs виконують зворотне перетворювання:

uint 32_t ntohl (uint 32_t network 32);

uint 16_t ntohs (uint 16_t network 16);

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

При виконанні цих функцій на комп’ютерах з “тупокінцевим” порядком ці функції жодного перетворювання не здійснюють.

Функції дозволу імен gethostbyname(2) та getservbyname(2) повертають значення, подані в мережному порядку.

Наведені в додатку В тексти мережних програм повністю відповідають рис. 2.1 та підтримують протокол ТСР/ІР.


3 Контрольні запитання


1 Які особливості має програмний інтерфейс сокетів, які підтримують протоколи ТСР/ІР?

2 За яким алгоритмом встановлюється з’єднання поміж клієнтом та сервером?

3 Які функції АРІ використовуються для встановлення з’єднання та обміну даними з боку сервера?

4 Які функції АРІ використовуються для встановлення з’єднання та обміну даними з боку клієнта?

5 Як забезпечується програмно взаємодія комп’ютерів з різними архітектурами в мережі?

6 Які АРІ-функції забезпечують мережний порядок байтів при роботі на комп’ютерах з різною архітектурою в мережі?

7 Які АРІ-функції забезпечують транслювання доменного імені хоста до його ІР-адреси й назад?

8 Які АРІ-функції забезпечують перетворювання ІР-адрес та їхніх складових частин відповідно до звичної нотації?


4 Домашнє завдання


1 Коротко відповісти на контрольні запитання у письмовому вигляді.

2 Вміти коментувати фрагменти програм та окремі команди відповідно до Лістинга 1 та Лістинга 2 (додаток В), та зіставляти програми з рис. 2.1.

3 Переписати тексти програм “simpletcpserv” та “simpletcpclient” (Лістинг 1 та Лістинг 2 в додатку Г) та написати до них коментарі.


5 Лабораторне завдання


1 Підімкніться до комп’ютера під керуванням ОС UNIX за допомогою telnet (“Пуск\Виконати\telnet ip”, де ip — адреса машини під керуванням UNIX).

2 Після підімкнення введіть ім’я (login) та пароль (password) згідно з таблицею 5.1.


Таблиця 5.1 — Імена та паролі

login	st1	st2	st3	st4	st5	st6	st7	st8	st9
password	st1	st2	st3	st4	st5	st6	st7	st8	st9
login	st11	st12	st13	st14	st15	st16	st17	st18	st19
password	st11	st12	st13	st14	st15	st16	st17	st18	st19

3 Створіть текстові файли simpletcpserv.c та simpletcpclient.c, вихідні тексти цих файлів розміщено в додатку Г (Лістинг 1 та Лістинг 2).

4 Відкомпілюйте програми та створіть об’єктні файли:

cc -o simpletсpserv simpletсpserv.c

та

cc -o simрletсpсlient simрletсpсlient.c

5 Якщо все пройшло успішно, на першому терміналі запустіть виконуваний файл ./simpletсpserv, a на другому — /simpletсpсliеnt.

6 Спостерігайте з’явлення повідомлення на клієнтському боці.

7 Змініть текст повідомлення на своє прізвище, ім’я та по-батькові.

8 Знову відкомпілюйте програми та виконайте пункти 4...6.

9 Змоделюйте ситуацію в такий спосіб, щоби серверна частина програми видала послідовно усі повідомлення щодо помилок системних викликів.

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

11 Поясніть, як Ви досягли результату та які причини є джерелом кожної помилки.

12 За завданням викладача з’єднайтеся за допомогою мережних програм ТСР-клієнта та, ТСР-сервера по мережі з іншим комп’ютером та повторіть пункти 3...6.

13 Зробіть висновки та запишіть їх до протоколу.


6 Зміст протоколу


Протокол лабораторної роботи “Програмна реалізація протоколів ТСР/ІР” оформлюється у робочому зошиті в послідовності, котра визначається стандартом підприємства з основ лабораторного практикуму. Протокол має містити назву лабораторної роботи та її мету, результати виконання домашнього завдання згідно з вимогами пунктів 1 та 3 домашнього завдання; результати виконання пунктів лабораторного завдання 6...12; висновки.


7 Список рекомендованої літератури


1 Робачевский А. М. Операционная система UNIX. — СПб.: БХВ-Петербург, 2002.

2 Ивановский С. Операционная система UNIX. — М.: Познавательная книга плюс, 2000.

3 Дегтярев Е. К. Введение в UNIX. — М.: МП "Память", 1991.

4 Снейдер И. Эффективное программирование TCP/IP. — СПб.: Питер, 2002.

5 sd.org.ru

6 ntern.com/computer/freebsd/

7 rsp.ru/freebsd/