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

ЗМІСТ

ВСТУП

1. АНАЛІЗ СУЧАСНОГО СТАНУ МЕРЕЖЕВИХ ТЕХНОЛОГІЙ ПРОГРАМУВАННЯ

1.1 Еталонна модель OSI

1.2 Транспортні протоколи ТСР та UDP

1.3 Архітектура клієнт-сервер

1.4 Технології взаємодії між процесами

2. РОЗРОБКА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ

2.1 Реалізація класів передачі даних

2.2 Програма A

2.3 Програма B

2.4 Програма C

2.5 Програма D

2.6 Програма Е

3. РОЗРОБКА ТА ВИКОНАННЯ ТЕСТОВОГО ПРИКЛАДУ

4. ІНСТРУКЦІЯ КОРИСТУВАЧА

ВИСНОВКИ

СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ

ДОДАТОК



ВСТУП

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

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

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

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



1. АНАЛІЗ СУЧАСНОГО СТАНУ МЕРЕЖЕВИХ ТЕХНОЛОГІЙ ПРОГРАМУВАННЯ

1.1 Еталонна модель OSI

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

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

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

Наведемо приклад для ілюстрації процесів реальної та віртуальної взаємодії. Нехай директор однієї фірми (директорі) написав лист директорові іншої фірми (директор_2). Секретарі вкладає цей лист у конверт, пише адресу і передає на пошту. Пошта здійснює доставку за зазначеною адресою. Конверт отримує секретар_2, розкриває його і кладе лист на стіл директорові_2. Реальною в даній схемі є лише взаємодія на рівні поштового транспорту - тобто в процесі перевезення листа з однієї точки в іншу. Всі інші - віртуальні, починаючи із взаємодії поштових відділень і закінчуючи найвищим рівнем директорі <-> директор_2. В такій моделі взаємодії директора не хвилюють проблеми відправлення листа, а секретар не повинен знати про тонкощі перевезення поштової кореспонденції.

Саме такий підхід і є перевагою багаторівневої моделі взаємодії відкритих систем ISO OSI (International Standards Organization, ISO; Open System Interconnection, OSI), і саме він дозволяє встановлювати зв'язок із будь-яким комп'ютером мережі Інтернет, довільної конфігурації, і яку би ОС на ньому не було встановлено. Розглянемо детальніше зазначену модель із характеристикою рівнів

Рисунок 1.1 Еталонна модель OSI

Рівень 0 (канал зв'язку) пов'язаний із фізичним середовищем - передавачем сигналу і містить характеристики посередників, що з'єднують кінцеві пристрої: кабелі, радіолінії і т.п. Як правило, рівень 0 не зазначається в моделі ISO OSI, проте, знання його особливостей дозволяє налагодити стабільний зв'язок з точки зору фізичних з'єднань.

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

Рівень 2 (канальний) забезпечує безпомилкову передачу пакетів через рівень 1, що може спотворювати дані (використовується завадостійке кодування). Визначає початок та кінець пакету в бітовому потоці.

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

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

s Шлюз - станція зв'язку із довільною мережею. Забезпечує зв'язок несумісних мереж, а також взаємодію несумісних компонентів у рамках однієї мережі

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

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

Рівень 6 (представлення даних) оперує синтаксисом та семантикою інформації, що передається, тобто встановлює "порозуміння" між двома комп'ютерами. Тут вирішуються задачі перекодування (всім, напевно, траплялись повідомлення у вигляді набору незрозумілих символів -наприклад, при передачі українського тексту без перетворення кодом Windows CP1251); підтримка зображень, стиск та розпакування файлів, підтримка мережних файлових систем (Network File System, NFS), тощо.

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

Рисунок 1.2 Протоколи та пристрої відповідно до рівнів моделі OSI

1.2 Транспортні протоколи ТСР та UDP

Оскільки сімейство протоколів TCP/IP є основою побудови Інтернету, розглянемо ці протоколи більш докладно.

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

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

Сімейство протоколів TCP/IP дозволяє побудувати універсальну мережу, що реалізує зазначені вище принципи. Воно містить у собі протоколи 4 рівнів комунікацій (мал. 3.2).

Прикладний рівень	WWW, FTP, Telnet E-mail та інші
Транспортний рівень	TCP, UDP
Мережевий рівень	IP, ICMP, IGMP
Канальний рівень (мережевий інтерфейс)	ARP, RARP

Рис. 1.3. Рівні стека протоколів TCP/IP

Рівень мережевого інтерфейсу відповідає за встановлення мережевого з'єднання в конкретній фізичній мережі. На цьому рівні працюють драйвер пристрою в операційній системі і відповідна мережева плата комп'ютера (Ethernet-протокол).Мережевий рівень -- основа сімейства протоколів TCP/IP. Саме на цьому рівні реалізується принцип міжмере-жевого з'єднання, зокрема маршрутизація пакетів через Інтернет. На мережевому рівні протокол реалізує ненадійну службу доставки пакетів по мережі від системи до системи без установлення з'єднання. Це означає, що буде виконане все необхідне для доставки пакетів, однак ця доставка не гарантується. Пакети можуть бути загублені, передані в неправильному порядку, продубльовані тощо. Служба, що працює без установлення з'єднання, обробляє пакети, незалежно один від одного. Але головне, що саме на цьому рівні приймається рішення про маршрутизацію пакета по міжмереже-вим з'єднанням.

Надійну передачу даних реалізує наступний рівень -- транспортний, на якому два основних протоколи, TCP (Transmission Control Protocol) i UDP (User Datagram Protocol), здійснюють зв'язок між машиною-відправником пакетів і машиною-адресатом пакетів.

Нарешті, прикладний рівень -- це прикладні програми типу клієнт-сервер, що базуються на протоколах нижніх рівнів. На відміну від протоколів інших трьох рівнів, протоколи прикладного рівня займаються деталями конкретного додатка, і для них звичайно не важливі способи передачі даних по мережі. Серед основних додатків TCP/ IP, що присутні практично в кожній його реалізації, -- протокол ему-ляції терміналу TELNET, протокол передачі файлів FTP, протокол електронної пошти SMTP (Simple Message TransferProtocol), протокол керування мережею SNMP (Simple Network Management Protocol), використовуваний у системі World Wide Web протокол передачі гіпертексту HTTP і ін.

На мал. 1.3 показано, як здійснюється взаємодія двох комп'ютерів з різних мереж з використанням стека прото-, колів TCP/IP. Програмне забезпечення IP-протоколу за допомогою маршрутизатора передає пакети з однієї мережі Ethernet в іншу. Протоколи верхніх рівнів, прикладного і транспортного, здійснюють з'єднання між комп'ютерами, клієнтом і сервером додатка, у той час як IP забезпечує зв'язок між кінцевою і проміжною системами.

Оскільки в Інтернеті деталі фізичних з'єднань приховані від прикладних програм, прикладний рівень зовсім «не піклується» про те, що клієнт і сервер прикладної програми працюють у різних мережах і що, як канальний протокол в обох мережах використовується протокол Ethernet. Між кінцевими системами може бути кілька десятків маршрути-заторів і безліч проміжних фізичних мереж різних типів. Прикладна програма у будь-якому випадку буде сприймати цей конгломерат як єдину фізичну мережу. Це обумовлює основну силу і привабливість технології Інтернету.Хоча стек протоколів і називається TCP/IP, самі протоколи TCP і IP є найважливішими, але не єдиними представниками цього сімейства. Кожен рівень комунікацій обслуговується декількома протоколами. Розглянемо їх більш докладно.TCP і UDP -- протоколи транспортного рівня, що організують потік даних між кінцевими системами для додатків верхнього рівня. Ці протоколи значно відрізняються один від одного.

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

Протокол UDP реалізує набагато більш простий алгоритм передачі, забезпечуючи, подібно протоколам мережевого рівня, ненадійну доставку даних без установлення логічного з'єднання. Він просто посилає пакети даних, дейтаграми (datagrams), з однієї машини на іншу, але не надає жодних гарантій їхньої доставки.IP -- основний протокол мережевого рівня, що дозволяє реалізовувати міжмережеві з'єднання. Він використовується обома протоколами транспортного рівня. IP визначає базову одиницю передачі даних в Інтернеті -- ІР-дейтаграму. Програмне забезпечення IP виконує функції маршрутизації, вибираючи шлях для даних. Для визначення маршруту підтримуються спеціальні таблиці; вибір здійснюється на основі адреси мережі, до якої підключений комп'ютер-адресат. Протокол IP визначає маршрут окремо для кожного пакета даних, не гарантуючи надійної доставки в потрібному порядку. Він задає безпосереднє відображення даних на фізичний рівень передачі, що лежить нижче, і тим самим реалізує високоефективну доставку пакетів.

Крім IP на мережевому рівні використовуються також протоколи ІСМР і IGMP. ІСМР (Internet ControlMessage Protocol) відповідає за обмін повідомленнями про помилки та іншу важливу інформацію з мережевого рівня на іншому хості чи маршрутизатор!. IGMP (Internet Group Management Protocol) використовується для відправлення ІР-дейтаграм множини хостів у мережі.

На самому нижньому рівні -- рівні мережевого інтерфейсу -- використовуються спеціальні протоколи визначення адрес ARP (Adress Resolution Protocol) і RARP (Reverse Adress Resolution Protocol). Ці протоколи застосовуються для перетворення адрес мережевого рівня в адреси фізичної мережі і назад.

Відкритість, масштабованість, універсальність і простота використання -- незаперечні переваги TCP/IP, але в цьому сімействі протоколів є й очевидні недоліки. Настільки приваблива простота доступу обертається для Інтернету серйознішого проблемою захисту інформації, що отримує особливу гостроту зараз, коли світова мережа усе активніше використовується для електронної комерції. Невпорядкованість передачі пакетів і неможливість відстежити маршрут їхнього просування також являють собою важливі проблеми, оскільки перешкоджають реалізації таких необхідних у сучасних комунікаціях можливостей, як переда-ча мультимедийних даних у реальному часі. Нарешті, зауважимо, що наданий IP-обсяг адресного простору, особливо в зв'язку з його неефективним використанням, уже на превелику силу дозволяє задовольняти потреби гігантської й усе більш розростаючої мережі.Багато зазначених проблем мають бути зняті реалізацією протоколу IPv6. Крім чотириразового збільшення розміру адреси, що забезпечить адресний простір обсягом близько 4 квадрильйонів адрес у порівнянні із сучасними 4 мільярдами, новий стандарт забезпечує реалізацію вбудованих функцій, захисту від несанкціонованого доступу, підтримку передачі мультимедійних даних в реальному часі і можливості автоматичного реконфігурування адрес.

Контролем використання TCP/IP, визначенням основних напрямків розвитку, розробкою і затвердженням стандартів сьогодні займається декілька організацій. Основною з них є Internet SocietyISOC) -- професійне співтовариство, що займається загальними питаннями еволюції і росту Інтернету як глобальної інфраструктури дослідницьких комунікацій.

Під керуванням ISOC діє Internet Architecture Board (ІАВ) -- організація, у веденні якої знаходиться технічний контроль і координація Інтернету. ІАВ координує напрямки досліджень і нових розробок для TCP/IP і є кінцевою інстанцією у визначенні нових стандартів для Інтернету. У ІАВ входять дві основні групи: Internet Engineering Task Force (IETF) і Internet Research Task Force (IRTF). IETF -- інженерна група, що займається рішенням найближчих технічних проблем Інтернету. IETF поділяється на дев'ять підгруп, відповідно до основних областей (додатки, маршрутизація й адресація, захист інформації і т. д.) і визначає специфікації, що потім стають стандартами Інтернету. Зокрема, протокол IPv6 є плодом зусиль IETF. У свою чергу, IRTF координує довгострокові дослідницькі проекти з протоколів TCP/ IP і технології Інтернету в цілому.

Різноманітна документація, пов'язана з Інтернетом, пропозиції зі стандартів і самі офіційні стандарти протоколів TCP/IP публікуються в серії технічних повідомлень Internet Request for Comments, чи RFC. RFCможуть бути короткими чи довгими, викладати глобальні концепції чи описувати деталі певного проекту, формулювати офіційний стандарт чи давати пропозиції з нових протоколів.

1.3 Архітектура клієнт-сервер

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

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

Повідомлення, які посилають клієнти отримали назви HTTP запити. Запити мають спеціальні методи, які говорять сервера про те, як обробляти повідомлення. А повідомлення, які посилає сервер отримали назву HTTP відповіді, вони містять крім корисної інформації ще й спеціальні коди стану, які дозволяють браузеру дізнатися те, як сервер зрозумів його запит.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1.4 Технології взаємодії між процесами

У операційній системі Windows зазвичай використовують три технології для здійснення обміну даними між процесами. Це поштові скриньки mailoslot, іменовані канали NamedPipe та сокети зі встановленням та без встановлення з'єднання [5].

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

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

Для створення поштової скриньки використовується спеціальне середовище імен «\\.\mailslot\[шлях]ім'я». Для запису інформації в мейлслот на локальному комп'ютері клієнтом використовується те ж ім'я, що використовувалось сервером для створення мейлслота. Для запису інформації в мейслот використовується форма «\\ім'я комп'ютера\mailslot\[шлях]ім'я». Для запису інформації у всі поштові скриньки домена вказується ім'я домена або зірочка, що визначає початковий домен системи: «\\ім'я домену\mailslot\[шлях]ім'я» або «\\*\mailslot\[шлях]ім'я».

Для створення мейлслотів сервером використовується спеціальна функція Windows API CreateMailslot. Для створення дескриптору поштової скриньки клієнтом, запису інформації клієнтом, читання її сервером та закриття дескриптора використовуються функції для роботи з файлами CreateFile, WriteFile, ReadFile, CloseHandle.

Найбільш важливі особливості поштових скриньок:

– поштові скриньки є однонаправленими

– з одною поштовою скринькою можуть бути пов'язані декілька програм, що записують (writers), та декілька програм, що зчитують (readers), але вони часто зв'язані між собою відношеннями «один до багатьох» в тій чи іншій формі

– клієнту не відомо достовірно, чи всі, тільки деякі чи взагалі якась одна з програм зчитування отримали повідомлення

– поштові скриньки можуть знаходитись в будь-якому місці мережі

– розмір повідомлень обмежений [6].

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

У Windows взаємодія через іменовані канали схожі до архітектури «клієнт-сервер» і працюють фактично як сокети: крім звичайних операцій читання та запису, іменовані канали підтримують «пасивний» режим для серверних додатків.

До іменованого каналу можна звертатись як до файлу. Можна використовувати функції Windows API CreateFile, CloseHandle, ReadFile, WriteFile для того, що відкривати і закривати канал, виконувати читання та запис.

Можливості іменованих каналів:

– іменовані канали орієнтовані на обмін повідомленнями, тому процес, що зчитує, може зчитувати повідомлення довільної довживи саме в тому вигляді, в якому вони були надіслані процесом, що виконує запис

– іменовані канали є двонаправленими, що дозволяє здійснювати обмін повідомленням між двома процесами через єдиний канал

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

– кожна з систем, що підключені до мережі, може звертатись до каналу, використовуючи його ім'я. Взаємодія через іменований канал здійснюється однаковим чином для процесів, що виконуються як на одній машині, так і на декількох [7].

Серверами іменованих каналів можуть бути лише системи на основі Windows NT, системи на базі Windows 9x можуть виступати лише в ролі клієнтів.

Ім'я іменованого каналу має такий формат: \\servername\pipe\[path]pipename, де «servername» вказує на розташування каналу (замість назви можна вказати «.», тоді обмін буде здійснюватись на одній локальній машині); [path]pipename - шлях та саме назва каналу.

Іменовані канали та поштові скриньки володіють недоліком, так як вони не є промисловим стандартом. Це не дозволяє їх використовувати в інших операційних системах, окрім Windows. Таким стандартом виступають сокети [8].

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

Сокет являє собою пару номерів: ІР-адресу та номер порта.

В процесу обміну використовуються два сокети - сокет відправника та сокет отримувача. Наприклад, при зверненні до сервера на НТТР порт сокет буде мати такий вигляд: 194.106.118.30:80, а відповідь буде поступати на mmmm.nnnn.pppp.aaaa: xxxx.

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

Можливість взаємодії з іншими системами в Windows здійснюється підтримкою сокетів Windows Socket (Winsock) - сумісного і майже точного аналогу сокетів Беркелея, які є фактично є промисловим стандартом [9].

Winsock API розроблявся як розширення Berkley Sockets APІ для середовища Windows і тому підтримується всіма системами Windows. До переваг Winsock належать:

– перенесення вже існуючого коду, написаного для Berkley Sockets APІ, здійснюється безпосередньо

– системи Windows легко вбудовуються в мережі, що використовують як IPv4 протоколу ТСР/ІР, так і версію IPv6. Крім того, версія ІРv6 допускає використання більш довгих ІР-адрес, що дозволяє подолати існуючий 4-байтовий адресний бар'єр версії ІРv4

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

– сокети можна розглядати як дескриптори (типу HANDLE) файлів при використанні функцій ReadFile i WriteFile і, з деякими обмеженнями, при використанні інших функцій, точно так же, як в якості дескрипторів файлів сокети використовуються в UNIX. Ця можливість виявляється зручною у тих випадках, коли потребується використання асинхронного введення/виведення і портів завершення введення/виведення

– існують також додаткові розширення і розширення, що не переносяться.

Існують дві версії Winsock: 1.1 та 2.2. Друга версія має такі можливості:

– стандартизована підтримка перекриваючого введення/виведення.

– фрагментоване введення/виведення

– можливість запитувати якість осблуговування

– можливість групової організації сокетів

– можливість суміщення прямих та зворотніх пакетів з запитами з'єднання

– створення багатоточкових з'єднань [10].



2. РОЗРОБКА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ

В даному розділі описано розробку програмного комплексу (рис. 2.1). Кожна програма має свої особливості, які будуть описані у відповідних підрозділах.

Рисунок 2.1 Конфігурація програмного комплексу

2.1 Реалізація класів передачі даних

Для реалізації функцій передачі було імплементовано ряд класів, таких як : MailSlot, NamedPipe, SocketWithConnection, SocketWithoutConnect.

MailSlot

Даний клас представляє собою реалізацію методів отримання та передачі символьних масивів за допомогою поштової скриньки. Розглянемо заголовочний файл MailSlot.h :

#pragma once

#include "winsock2.h"

#include "ws2tcpip.h"

#include "windows.h"

#include "string.h"

#include <iostream>

#include <conio.h>

#include <string>

class MailSlot

{

public:

MailSlot(

wchar_t* _mailSlotName,

HANDLE& _mailSlot,

char _name);

~MailSlot();

void sendMessage(char sendBuf[]) const;

void receiveMessage(char *receiveBuf) const;

private:

const std::wstring wMailSlotString_;

const std::wstring MailSlotString_;

const char programName_;

HANDLE& MailSlot_;

DWORD count_;

};

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

#include "MailSlot.h"

MailSlot::MailSlot(

wchar_t* _mailSlotName,

HANDLE& _MailSlot,

char _name) :

programName_(_name),

MailSlot_(_MailSlot),

count_(0),

wMailSlotString_(_mailSlotName),

MailSlotString_(wMailSlotString_.begin(), wMailSlotString_.end())

{

}

MailSlot::~MailSlot()

{

}

void MailSlot::sendMessage(char sendBuf[]) const

{

std::cout<<"\nClient of mailslot for sending message to " << programName_;

std::cout << "Wait when " << programName_ <<" creates server of mailslot...";

do

{

MailSlot_ = CreateFile(MailSlotString_.c_str(), GENERIC_READ | GENERIC_WRITE, FILE_SHARE_READ | FILE_SHARE_WRITE, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);

Sleep(100);

} while (MailSlot_ == INVALID_HANDLE_VALUE);

int kilk = NULL;

std::cout << "\nPress any key for sending message to " << programName_;

_getch();

WriteFile(MailSlot_, sendBuf, strlen(sendBuf), (LPDWORD)&kilk, NULL);

std::cout << "\nMessage was sended to " << programName_;

CloseHandle(MailSlot_);

}

void MailSlot::receiveMessage(char *receiveBuf) const

{

std::cout << "\nServer of mailslot for received message from " << programName_;

HANDLE mailslotBForC;

maillotBForC = CreateMailslot(MailSlotString_.c_str(), 1024, MAILSLOT_WAIT_FOREVER, NULL);

std::cout << "\nWait for receive message from " << programName_;

while (!ReadFile(mailslotBForC, receiveBuf, 1024, (LPDWORD)&count_, NULL))

Sleep(100);

receiveBuf[count_] = 0;

CloseHandle(mailslotBForC);

}

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

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

Метод отримання в якості параметру отримує силку на початок масиву, в який за допомогою методу ReadFile() записує отримане повідомлення довжиною count_.

NamedPipe

Даний клас представляє собою реалізацію методів отримання та передачі символьних масивів за допомогою іменованого каналу. Розглянемо заголовочний файл NamedPipe.h :

#pragma once

#pragma once

#include "winsock2.h"

#include "ws2tcpip.h"

#include "windows.h"

#include "string.h"

#include <iostream>

#include <conio.h>

#include <string>

class NamedPipe

{

public:

NamedPipe(

wchar_t* _namedPipeName,

HANDLE& _namedPipe,

char _name);

~NamedPipe();

void sendMessage(char sendBuffer[]) const;

void receiveMessage(char *receiveBuf) const;

private:

const std::wstring wNamedPipeString_;

const std::wstring namedPipeString_;

const char programName_;

HANDLE& namedPipe_;

DWORD count_;

};

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

#include "NamedPipe.h"

NamedPipe::NamedPipe(

wchar_t* _namedPipeName,

HANDLE& _namedPipe,

char _name) :

programName_(_name),

namedPipe_(_namedPipe),

count_(0),

wNamedPipeString_(_namedPipeName),

namedPipeString_(wNamedPipeString_.begin(), wNamedPipeString_.end())

{

}

NamedPipe::~NamedPipe()

{

}

void NamedPipe::sendMessage(char sendBuffer_[]) const

{

std::cout << "\nServer of named pipe for sending message to " << programName_;

std::cout << "\nWait when " << programName_ << " connects...";

namedPipe_ = CreateNamedPipe(namedPipeString_.c_str(), PIPE_ACCESS_OUTBOUND, PIPE_TYPE_BYTE, 1, 256, 0, 1000, NULL);

while (namedPipe_ != INVALID_HANDLE_VALUE)

{

if (ConnectNamedPipe(namedPipe_, NULL) != FALSE) // wait for someone to connect to the pipe

{

puts("B was connected.");

break;

}

}

std::cout << "\nPress any key for send message to " << programName_;

_getch();

WriteFile(namedPipe_, sendBuffer_, 1024, (LPDWORD)&count_, NULL);

puts("\nMessage was sended to " + programName_);

DisconnectNamedPipe(namedPipe_);

CloseHandle(namedPipe_);

}

void NamedPipe::receiveMessage(char* outStr) const

{

std::cout << "\nClient of named pipe for receiving message from " << programName_;

std::cout << "\nWait for creating server of named pipe P1 on " << programName_ << "...";

while (!WaitNamedPipe(namedPipeString_.c_str(), NMPWAIT_WAIT_FOREVER))

Sleep(100);

if (namedPipe_ != INVALID_HANDLE_VALUE)

{

namedPipe_ = CreateFile(namedPipeString_.c_str(), GENERIC_READ, 0, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);

puts("\nConnected.");

}

puts("\nWait for receive message...");

ReadFile(namedPipe_, outStr, 1024, (LPDWORD)&count_, NULL);

outStr[count_] = 0;

CloseHandle(namedPipe_);

}

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

Метод відправки приймає в якості параметра масив символів допомогою CreateNamedPipe() створює сервер і очікує і в циклі підключення за допомогою функції ConnectNamedPipe (), як тільки це йому вдається метод відправляє масив.

Метод отримання в якості параметру отримує силку на початок масиву, в який за допомогою методу ReadFile() записує отримане повідомлення довжиною count_.

SocketWithoutConnection

Даний клас представляє собою реалізацію методів отримання та передачі символьних масивів за допомогою сокета без встановленя зв'язку. Розглянемо заголовочний файл WebSocketWithoutConnect.h :

#pragma once

#include "winsock2.h"

#include "ws2tcpip.h"

#include "windows.h"

#include "string.h"

#include <iostream>

#include <conio.h>

#include <string>

#pragma comment(lib, "Ws2_32.lib")

class WebSocketWithoutConnect

{

public:

WebSocketWithoutConnect(

sockaddr_in& _sockaddress,

SOCKET& _socket,

unsigned short _port,

char _name);

~WebSocketWithoutConnect();

void sendMessage(char sendBuf[]) const;

void receiveMessage(char* receiveBuf) const;

private:

const char programName_;

const unsigned short port_;

SOCKET& socket_;

sockaddr_in& sockaddress_;

};

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

#include "WebSocketWithoutConnect.h"

WebSocketWithoutConnect::WebSocketWithoutConnect(

sockaddr_in& _sockaddress,

SOCKET& _socket,

unsigned short _port,

char _name) :

programName_(_name),

port_(_port),

socket_(_socket),

sockaddress_(_sockaddress)

{

}

WebSocketWithoutConnect::~WebSocketWithoutConnect()

{

}

void WebSocketWithoutConnect::sendMessage(char sendBuf[]) const

{

int result_;

std::cout << "\nSocket without connection for sending message to " << programName_;

WSADATA wsaData_;

result_ = WSAStartup(0x0202, &wsaData_);

if (result_ != NO_ERROR)

{

wprintf(L"WSAStartup failed with error: %d\n", result_);

}

socket_ = socket(AF_INET, SOCK_DGRAM, 0);

if (socket_ == INVALID_SOCKET) {

wprintf(L"socket failed with error: %ld\n", WSAGetLastError());

WSACleanup();

}

sockaddress_.sin_family = AF_INET;

sockaddress_.sin_port = htons(port_);

long adr1;

inet_pton(AF_INET, "127.0.0.1", &adr1);

sockaddress_.sin_addr.S_un.S_addr = adr1;

std::cout << "\nIf " << programName_ << " is waiting for receiving, press any key for send message";

_getch();

result_ = sendto(socket_, sendBuf, strlen(sendBuf), 0, (sockaddr*)&sockaddress_, sizeof(sockaddress_));

if (result_ == SOCKET_ERROR) {

wprintf(L"sendto failed with error: %d\n", WSAGetLastError());

closesocket(socket_);

WSACleanup();

}

std::cout << "\nMessage was sended to " << programName_;

closesocket(socket_);

}

void WebSocketWithoutConnect::receiveMessage(char* receiveBuf) const

{

WSADATA wsaData;

int count;

int isrecive = WSAStartup(0x0202, &wsaData);

if (isrecive != NO_ERROR)

{

wprintf(L"WSAStartup failed with error: %d\n", isrecive);

}

std::cout << "\nSocket without connection for receive message from " << programName_;

sockaddress_.sin_port = htons(port_);

sockaddress_.sin_family = AF_INET;

sockaddress_.sin_addr.S_un.S_addr = htonl(INADDR_LOOPBACK);

socket_ = socket(AF_INET, SOCK_DGRAM, NULL);

if (socket_ == INVALID_SOCKET)

{

wprintf(L"socket failed with error: %ld\n", WSAGetLastError());

WSACleanup();

}

bind(socket_, (sockaddr*)&sockaddress_, sizeof(sockaddress_));

count = recv(socket_, receiveBuf, 1024, 0);

receiveBuf[count] = 0;

}

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

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

WSADATA WsaData;

WSAStartup(0x0202, &WsaData);

Далі в функцію InitSocket() передаються параметри, а саме сокет і також структура типу sockaddr_in, які в подальшому ініціалізуються. Для ініціалізації сокета використовується функція socket(AF_INET, SOCK_STREAM,0), параметри цієї функції вказують на сімейство адрес( AF_INET - це інтернет ip-адреси), тип передачы повідомлення, в нашому випадку це дейтаграми, а також протокол транспортного рівня мережі за допомогою якого буде здійснюватись передача, для дейтаграм по замовчуванню це UDP-протокол. За ініціалізацію структури addr, відповідає код:

addr.sin_family = AF_INET;

addr.sin_port = htons(port);

long adr1;

inet_pton(AF_INET,"127.0.0.1",&adr1);

addr.sin_addr.S_un.S_addr = adr1;

Після цього відбувається безпосередня відправка повідомлення функцією sendto(), параметрами якої виступають:

· Сокет для передачі даних;

· Буфер з даними;

· Довжина повідомлення;

· Флаг;

· Адресна структура;

· Довжина адресної структури;

Метод отримання в якості параметру отримує силку на початок масиву, в який за допомогою методу recv() записує отримане повідомлення довжиною count_.

SocketWithConnection

Даний клас представляє собою реалізацію методів отримання та передачі символьних масивів за допомогою сокета без встановленя зв'язку. Розглянемо заголовочний файл WebSocketWithConnection.h :

#pragma once

#include "winsock2.h"

#include "ws2tcpip.h"

#include "windows.h"

#include "string.h"

#include <iostream>

#include <conio.h>

#include <string>

#pragma comment(lib, "Ws2_32.lib")

class WebSocketWithConnection

{

public:

WebSocketWithConnection(

sockaddr_in& _sockaddress,

SOCKET& _socket,

unsigned short _port,

char _name);

~WebSocketWithConnection();

void sendMessage(char sendBuf[]) const;

void receiveMessage(char* receiveBuf) const;

private:

const char programName_;

const unsigned short port_;

SOCKET& socket_;

sockaddr_in& sockaddress_;

};

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

#include "WebSocketWithConnection.h"

WebSocketWithConnection::WebSocketWithConnection(

sockaddr_in& _sockaddress,

SOCKET& _socket,

unsigned short _port,

char _name) :

programName_(_name),

port_(_port),

socket_(_socket),

sockaddress_(_sockaddress)

{

}

WebSocketWithConnection::~WebSocketWithConnection()

{

}

void WebSocketWithConnection::sendMessage(char sendBuf[]) const

{

int result_;

WSADATA wsaData_;

result_ = WSAStartup(0x0202, &wsaData_);

if (result_ != NO_ERROR)

{

wprintf(L"WSAStartup failed with error: %d\n", result_);

}

socket_ = socket(AF_INET, SOCK_DGRAM, 0);

sockaddress_.sin_family = AF_INET;

sockaddress_.sin_port = htons(port_);

long adr1;

inet_pton(AF_INET, "127.0.0.1", &adr1);

sockaddress_.sin_addr.S_un.S_addr = adr1;

std::cout << "\nClient of sockets with connection for sending message to " << programName_;

socket_ = socket(AF_INET, SOCK_STREAM, 0);

if (socket_ == INVALID_SOCKET)

{

wprintf(L"socket failed with error: %ld\n", WSAGetLastError());

WSACleanup();

}

std::cout << "\nWait for connecting to " << programName_ << "....";

while (connect(socket_, (sockaddr*)&sockaddress_, sizeof(sockaddress_)) == SOCKET_ERROR)

Sleep(100);

std::cout << "\nConnected to " << programName_;

std::cout << "\nPress any key for send message to " << programName_;

_getch();

send(socket_, sendBuf, strlen(sendBuf), 0);

std::cout << "\nMessage was sended to " << programName_;

closesocket(socket_);

}

void WebSocketWithConnection::receiveMessage(char* receiveBuf) const

{

std::cout << "\nServer of socket with connection for receiving message from " << programName_;

WSADATA WsaData;

SOCKET localSock;

sockaddr_in localAddr;

int count;

int res = WSAStartup(0x0202, &WsaData);

if (res != NO_ERROR)

{

wprintf(L"WSAStartup failed with error: %d\n", res);

}

localSock = socket(AF_INET, SOCK_STREAM, 0);

localAddr.sin_family = AF_INET;

localAddr.sin_port = htons(port_);

localAddr.sin_addr.S_un.S_addr = htonl(INADDR_ANY);

bind(localSock, (sockaddr*)&localAddr, sizeof(localAddr));

sockaddress_.sin_family = AF_INET;

sockaddress_.sin_port = htons(port_);

sockaddress_.sin_addr.S_un.S_addr = htonl(INADDR_LOOPBACK);

listen(localSock, 8);

int addrLen = sizeof(sockaddress_);

puts("\nWait for accept...");

std::cout << "\nWait for accept " << programName_ << ".....";

socket_ = accept(localSock, (sockaddr*)&sockaddress_, &addrLen);

std::cout << "\nAccepted " << programName_ << ".";

std::cout << "\nWait for receive message from " << programName_ << ".....";

count = recv(socket_, receiveBuf, 1024, 0);

receiveBuf[count] = 0;

std::cout << "\nMessage from " << programName_ << " was received!";

shutdown(socket_, SD_BOTH);

closesocket(socket_);

}

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

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

WSADATA WsaData;

WSAStartup(0x0202, &WsaData);

Далі в функцію InitSocket() передаються параметри, а саме сокет і також структура типу sockaddr_in, які в подальшому ініціалізуються. Для ініціалізації сокета використовується функція socket(AF_INET, SOCK_STREAM,0), параметри цієї функції вказують на сімейство адрес( AF_INET - це інтернет ip-адреси), тип передачы повідомлення, в нашому випадку це дейтаграми, а також протокол транспортного рівня мережі за допомогою якого буде здійснюватись передача, для дейтаграм по замовчуванню це UDP-протокол. За ініціалізацію структури addr, відповідає код: мережевий еталонний транспортний сервер

addr.sin_family = AF_INET;

addr.sin_port = htons(port);

long adr1;

inet_pton(AF_INET,"127.0.0.1",&adr1);

addr.sin_addr.S_un.S_addr = adr1;

Після цього за допомогою accept() відбувається з'єднання клієнта та сервера і відбувається безпосередня відправка повідомлення функцією sendto(), параметрами якої виступають:

· Сокет для передачі даних;

· Буфер з даними;

· Довжина повідомлення;

· Флаг;

· Адресна структура;

· Довжина адресної структури;

Метод отримання в якості параметру отримує силку на початок масиву, в який за допомогою методу recv() записує отримане повідомлення довжиною count_.

2.2 Програма A

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

В головному .срр файлі програми підключаються необхідні файли, .h, в яких описані необхідні класи. Також необхідно реалізувати дані класи. Лістинг даних класів наведено в додатку А. При створенні програми А, ми будемо використовувати клас SocketWithoutConnect. Необхідно підключити його використовуючи наступний код:

...