ого відносно низькою продуктивністю не надто добре підходить для локальних мереж, воно чудово працює в глобальних системах, для яких ненадійність є "вродженим" властивістю сполук. Так, практично всі прикладні протоколи Інтернету засновані на надійних з'єднаннях по протоколу TCP/IP. У цих випадках щоразу, коли клієнт запитує службу, до посилки запиту серверу він повинен встановити з ним з'єднання. Сервер зазвичай використовує для посилки повідомлення-відповідь, те ж саме з'єднання, після чого воно розривається. Проблема полягає в тому, що установка і розрив з'єднання в сенсі витрачається часу і ресурсів відносно дорогі, особливо якщо повідомлення із запитом і відповіддю невеликі. Ми обговоримо альтернативні рішення, в яких управління з'єднанням об'єднується з передачею даних, в наступному розділі. p align="justify"> Виходячи з вищесказаного, можна виділити переваги та недоліки такої архітектури.
Переваги: ​​
? Відсутність дублювання коду програми-сервера програмами-клієнтами.
? Так як всі обчислення виконуються на сервері, то вимоги до комп'ютерів, на яких встановлений клієнт, знижуються.
? Всі дані зберігаються на сервері, який, як правило, приховується набагато краще більшості клієнтів. На сервері простіше забезпечити контроль повноважень, щоб вирішувати доступ до даних тільки клієнтам з відповідними правами доступу.
? Дозволяє об'єднати різні клієнти. Використовувати ресурси одного сервера часто можуть клієнти з різними апаратними платформами, операційними системами і т.п.
? Дозволяє розвантажити мережі за рахунок того, що між сервером і клієнтом передаються невеликі порції даних.
Недоліки:
? Непрацездатність сервера може зробити непрацездатною всю обчислювальну мережу. Непрацездатним сервером слід вважати сервер, продуктивності якого не вистачає на обслуговування всіх клієнтів, а також сервер, що знаходиться на ремонті, профілактиці і т.п.
? Підтримка роботи даної системи вимагає окремого фахівця - системного адміністратора.
? Висока вартість обладнання.
Наша система невелика за своїм масштабом, підтримка системного адміністратора не є необхідною, тому що при збої в роботі програми нам достатньо лише перезапустити програму і продовжити роботу. Щоб уникнути проблем з недостатньою продуктивністю сервера, передбачимо одночасний доступом до серверу тільки одного клієнта. Виходячи з вищесказаного, приймемо запропоновану архітектуру задовільною для нашої задачі. [4,5]
