Лабораторна робота №1
тема: MFC-сокети.
Теоретичні відомості
У бібліотеці MFCдля використання сокетів створено два класи: CSocket і CAsynchSocket. Клас CSocket підтримує сокети на вищому рівні абстракції ніж клас CAsyncSocket. CSocket використовує версію протоколу перетворення MFC в послідовну форму, щоб передати дані до об’єкту сокета і від нього через об’єкт MFC-класу CArchive. CSocket передбачає блокування і надає доступ до CАrchive, який управляє багатьма аспектами зв’язку, що потрібно було б робити вручну за допомогою АРІ функцій або класу CAsyncSocket.
Використання класу cArchiveзCSocketFile
Звичайно, можна використовувати клас CSocket як більш зручну версію CAsyncSocket, але ще більш зручним підходом є використання CSocket з об’єктом CArchive. Використання об’єкта CSocket включає створення та з’єднання разом декількох об’єктів класу MFC.
Об'єкт CArchive керує буфером. Коли буфер архіву, що зберігається, заповнюється, зв'язаний з ним об'єкт CFile, зберігає його вміст. Очищення буфера архіву, приєднаного до сокета, еквівалентно посилці повідомлення. Коли буфер архіву, що завантажується, заповнюється, об'єкт CFile припиняє зчитування, поки буфер знову не стане доступним.
Клас CSocketFile успадкований від CFile, але не підтримує такі функції CFile як позиціювання (Seek, GetLength, SetLength, і так далі), блокування (LockRange, UnlockRange), або функцію GetPosition. Весь об'єкт CSocketFile повинен записувати або зчитувати послідовності байт, користуючись як зв'язаним джерелом об'єктом CSocket. Оскільки фізично такий файл не існує, операції типу Seek і GetPosition не мають змісту. CSocketFile успадкований з CFile, тому вони все-таки присутні в ньому. Щоб запобігти помилковому виклику, функції, що не підтримуються CFile, заблоковані в CSocketFile, а при їхньому виклику генерується виключення CNotSupportedException.
Об'єкт CSocketFile викликає функції зв'язаного об'єкта CSocket для посилання або отримання даних.
Наступний рисунок показує відношення між цими об'єктами в обох напрямках зв'язку.
Призначення подібної архітектури полягає в тому, щоб відгородити програміста від потреби керування деталями з'єднання сокетів самостійно. Програміст створює сокет, файл, і архів, а потім починає посилати або одержувати дані, додаючи їх в архів, або беручи їх звідти. CArchive, CSocketFile, і CSocket керують всім іншим прозоро для програміста.
Об'єкт CSocket - фактично є бістабільним: він може бути асинхронним (звичайний стан) і синхронним. У асинхронному стані сокет може одержувати асинхронні повідомлення. Однак, протягом операцій таких як одержання і посилка даних сокет стає синхронним. Це означає, що сокет не одержить ніякі подальші асинхронні повідомлення, поки синхронна операція не завершиться.
CSocketFile може також використовуватися як "обмежений" файл без об'єкта CArchive. За замовчуванням, у конструктора CSocketFile параметр bArchiveCompatible істинний. Це означає, що об'єкт файлу використовується з архівом. Для використання об'єкта файлу без архіву, потрібно передати FALSE у параметр bArchiveCompatible. У "архівно-сумісному" режимі, об'єкт CSocketFile забезпечує краще виконання і зменшує небезпеку "зависання". Зависання відбувається, коли і посилаючі і одержуючі сокети очікують повідомлення один від одного, або очікують загального ресурсу. Ця ситуація може відбутися, якщо об'єкт CArchive зв’язується з CSocketFile через об’єкт CFile. У такій конфігурації архів може припустити, що, якщо він одержав меншу кількість байт ніж потрібно, то був досягнутий кінець файлу. А у випадку зв’язування CArchive з CSocketFile це нонсенс: буфер може містити безліч повідомлень, і одержання меншої кількості байт, ніж зазначено, не означає кінець файлу. Програма не блокується в цьому випадку, як це могло б відбутися з CFile, і може продовжувати зчитувати повідомлення з буфера, поки він не спорожніє. Функція IsBufferEmpty у CArchive використовується для контролю стану буфера архіву в такому випадку.