Файл: Реализовать приложениесервер в среде MicrosoftVisualStudioна языкеVisualC#.odt

Таким образом, TripleDESвыполняет три раза алгоритмDESи длина его ключа также в три раза большеDES, то есть равна 168 битов. Для DES 64-разрядный ключ делился на 8 байтов, в каждом байте используется только 7 битов, поэтому на самом деле длина ключа равна 56 битов, а не 64, поэтому длина ключа 3DES на самом деле равна 168, а не 192 бита.

TripleDES с различными ключами имеет длину ключа равную 168 бит, но из-за атак «встреча посередине» эффективная криптостойкость составляет только 112 бит. Для успешной атаки наTriple-DES потребуется около

бит известного открытого текста,

шагов,

циклов DES-шифрования и

бит памяти.

1.3. Протокол tcp.

В качестве протокола передачи данных в сети будет использоваться TCP. Протокол реализован в контексте клиента и сервера. В отличии от других протоколов,TCPявляется надёжным благодаря следующим качествам:

сверка контрольных сумм для проверки целостности передаваемых пакетов
осуществление повторного запроса данных в случае потери данных
устранение дублирования при получении двух копий одного пакета.

Передача пакетов начинается с установления соединения (в отличии от UDP). Состояние сеанса описывается благодаря флагам.

Closed	Начальное состояние узла. Фактически фиктивное
Listen	Сервер ожидает запросов установления соединения от клиента
Syn-sent	Клиент отправил запрос серверу на установление соединения и ожидает ответа
Syn-received	Сервер получил запрос на соединение, отправил ответный запрос и ожидает подтверждения
Established	Соединение установлено, идёт передача данных
Fin-wait-1	Одна из сторон (назовём её узел-1) завершает соединение, отправив сегмент с флагом FIN
Close-wait	Другая сторона (узел-2) переходит в это состояние, отправив, в свою очередь сегмент ACK и продолжает одностороннюю передачу
Fin-wait2	Узел-1 получает ACK, продолжает чтение и ждёт получения сегмента с флагом FIN
Last-ack	Узел-2 заканчивает передачу и отправляет сегмент с флагом FIN
Time-wait	Узел-1 получил сегмент с флагом FIN, отправил сегмент с флагом ACK и ждёт 2*MSL секунд, перед окончательным закрытием соединения
Closing	Обе стороны инициировали закрытие соединения одновременно: после отправки сегмента с флагом FIN узел-1 также получает сегмент FIN, отправляет ACK и находится в ожидании сегмента ACK (подтверждения на свой запрос о разъединении)

Таблица 1. Состояния сеанса TCP.

Соединение разделяют на следующие стадии:

установка соединения
1. послание серверу сегмента с номером последовательности и флагом SYN
2. если клиент получает сегмент с флагом SYN, то он запоминает номер последовательности и посылает сегмент с флагом ACK
3. если сервер в состоянии SYN-RECEIVED получает сегмент с флагом ACK, то он переходит в состояние ESTABLISHED
передача данных
завершение соединения
1. посылка серверу от клиента флагов FIN и ACK на завершение соединения.
2. сервер посылает клиенту флаги ответа ACK, FIN, что соединение закрыто.
3. после получения этих флагов клиент закрывает соединение и в подтверждение отправляет серверу ACK, что соединение закрыто.

Из недостатков TCPотмечают уязвимость к атакамTCPResetиTCPhijacking

ГЛАВА 2. РАЗРАБОТКА ПРОГРАММНОГО ПРОДУКТА

2.1. Архитектура Библиотеки UpdateLibrary

Updatelibrary-представляет собой библиотеку классов ,которую разработчики могут подстраивать под свои проекты, легко добавлять функцию автоматического обновления в свои приложения на рабочем столе (Windows, macOS и Linux).

Рисунок1.3.Архитектура Библиотеки UpdateLibrary

Исправление ошибок и добавление новых функций является частью разработки программных приложений. Отправка обновлений приложений пользователям также является важной частью разработки приложений, особенно когда пользователь не имеет глубоких знаний о компьютерах.

Сегодня в эпоху Интернета разработчик программного обеспечения должен упростить развертывание и обновление приложений и часто делает автоматические обновления приложений для этого.

Этот проект разработан на C # ,как библиотека с именем проекта “UpdateLibrary”. DLL “UpdateLibrary” можно использовать в приложении C # Windows (WinForm, WPF, UWP и Xamarin).

Есть определенные особенности в UpdateLibrary:

Легко внедряется и используется.
Автоматический повторный запуск приложения после проверки обновления.
Процесс обновления прозрачен для пользователя .
Чтобы избежать блокировки основного потока, используйте многопоточную загрузку.
Возможность обновления системы, а также программы автоматического обновления.
Код, который не нуждается в изменении при использовании различными системами и может быть скомпилирован в библиотеке.
Пользователю легко загружать файлы обновлений.

В программе, которую вы хотите автоматически обновить, вам просто нужно вызвать функцию AutoUpdate в Основной процедуре. Функция AutoUpdate сверит версию с версией, прочитанной из файла, расположенного на веб-сайте / FTP. Если версия программы ниже прочитанной, программа загружает программу автоматического обновления и запускает ее, а функция возвращает True, что означает, что будет запущено автоматическое обновление и текущая программа должна быть закрыта. Программа автоматического обновления получает несколько параметров от программы, подлежащей обновлению, выполняет необходимое автоматическое обновление и после этого запускает обновленную систему.

Р

исунок 1.3. Окно Процесса Обновления

#проверка региона и загрузка новой версии программы bool bHasError = ложь; IUpdateLibrary UpdateLibrary = новый UpdateLibrary(); попробуй { Автопатруль.Update(); } catch (WebException exp) { MessageBox.Показать ("Не удается найти указанный ресурс"); bHasError = true; } catch (XmlException exp) { bHasError = true; MessageBox.Показать ("Загрузить ошибку файла обновления"); } catch (NotSupportedException exp) { bHasError = true; MessageBox.Показать ("Ошибка конфигурации адреса обновления"); } catch (ArgumentException exp) { bHasError = true; MessageBox.Показать ("Загрузить ошибку файла обновления"); } catch (Exception exp) { bHasError = true; MessageBox.Показать ("Произошла ошибка в процессе обновления"); } наконец { if (bHasError == true) { попробуйте { UpdateLibrary.RollBack (); } catch (исключение) { // Запишите сообщение в свой файл или базу данных } } } #endregion

2. 2. Описание модели системы обновления по.

Пользователь делает запрос на проверку о наличии новых версий для приложения. Запрос направляется на сервер. Сервер выполняет проверку и, если новая версия доступна, отправляет клиенту сообщение о наличии новой версии, иначе отправляет сообщение о том, что новых версий нет.

Пользователь делает запрос на обновление. Запрос направляется на сервер. Сервер выбирает необходимые компоненты и передаёт их клиенту. После передачи клиентское приложение выполняет замену или добавление новых компонентов.

Администратор системы устанавливает новые версии приложении в хранилище и индексирует их в файле-перечне приложений.

Система может работать в автоматическом режиме (по расписанию). Пример: Каждые понедельник, среду, пятницу выполнять проверку о наличии новых версий и, если они доступны, обновить.

2.3. Схема и описание системы.

Рисунок 1. Схема системы относительно сервера.

Серверная часть состоит из приложения-сервера, файла-перечня приложений (Apps.xml), и хранилища. Рассмотрим каждую часть подробней:

Сервер. Сервер является TCP-сервером и выполняет функции прослушивания порта (порт назначается пользователем) и обработки входящих запросов. Запрос может быть двух типов: запрос о последней версии приложения и запрос обновления приложения.
Файл-перечень приложений хранится на компьютере сервера в том же каталоге, где находится исполняемый файл сервера. В нём хранится информация о хранимых приложениях, их названиях и версиях. Для удобства чтения файла и возможности стороннего его редактирования информация представлена в виде XML-документа.
Хранилище представляет из себя запоминающее устройство, на котором хранятся приложения. Выбор файловой системы хранилища и принципа хранения остаётся за администратором системы.