Создание модели с расширенными возможностями на базе основных коммутационных протоколов для информационной системы ТОО "Караганда Связь Плюс"

Ниже на Рисунке 2.1 представлена схема взаимосвязей между протоколами семейства TCP/IP.

Рисунок 2.1 - Структура взаимосвязей протоколов семейства TCP/IP

Стек протоколов TCP/IP является основной технологией межсетевого взаимодействия. Вторым основным протоколом, используемым комплексом, является протокол канала связи с непосредственным соединением (PPP).

Необходимость использования указанного протокола обуславливается требованием обязательного наличия функций по созданию резервного (модемного) соединения. PPP протокол позволяет асинхронное (старт/стоп) и синхронное (бит-ориентированное) формирование пакета данных, мультиплексирование протокола сети, конфигурацию канала связи, проверку качества канала связи, обнаружение ошибок. Указанные свойства протокола позволяют полностью контролировать процесс передачи данных с использованием модемного соединения.

В модели системы для передачи информации для ТОО «Караганда Связь Плюс» при необходимости инициализации PPP-соединения используется асинхронное формирование пакета данных протоколом PPP, что позволяет четко отслеживать ход подключения и при обнаружении возможных ошибок осуществлять принятие соответствующих мер.

Понятие FTP (File Transfer Protocol) возникло на заре развития всемирной Сети вместе с таким понятием, как HTTP (Hypertext Transfer Protocol). Назначением FTP, как это видно из самого названия, была передача файлов. В те времена (начало 90-х) было лишь две возможности получить файл, расположенный где-нибудь на сервере в Америке: заказать его с помощью электронной почты или использовать FTP. Практически каждая сетевая организация имела свой FTP-сервер, на котором хранились огромные объемы данных.

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

Обмен данными в FTP проходит по TCP-каналу. Построен обмен по технологии "клиент - сервер". На Рисунке 2.2 изображена модель FTP протокола.

Рисунок 2.2 - Модель FTP протокола

В FTP соединение инициируется интерпретатором протокола пользователя. Управление обменом осуществляется по каналу управления в стандарте протокола TELNET. Команды FTP генерируются интерпретатором протокола пользователя и передаются на сервер. Ответы сервера отправляются пользователю также по каналу управления. В общем случае пользователь имеет возможность установить контакт с интерпретатором протокола сервера и отличными от интерпретатора пользователя средствами.

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

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

Канал данных устанавливается для того же host'а, что и канал управления, через который ведется настройка канала данных. Канал данных может быть использован как для приема, так и для передачи данных.

Режимы обмена данными

В протоколе большое внимание уделяется различным способам обмена данными между машинами различных архитектур. Действительно, чего только нет в Internet, от персоналок и Mac'ов до суперкомпьютеров. Все они имеют различную длину слова и многие различный порядок битов в слове. Кроме этого, различные файловые системы работают с разной организацией данных, которая выражается в понятии метода доступа.

В общем случае, с точки зрения FTP, обмен может быть поточный или блоковый, с кодировкой в промежуточные форматы или без нее, текстовый или двоичный. При текстовом обмене все данные преобразуются в ASCII и в этом виде передаются по сети. Исключение составляют только данные IBM mainframe, которые по умолчанию передаются в EBCDIC, если обе взаимодействующие машины IBM. Двоичные данные передаются последовательностью битов или подвергаются определенным преобразованиям в процессе сеанса управления. Обычно, при поточной передаче данных за одну сессию передается один файл данных, а при блоковом способе за одну сессию можно передать несколько файлов.

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

Одной из причин малого числа каналов связи IP с непосредственным соединением было отсутствие стандартного протокола формирования пакета данных Internet. Протокол Point-to-Point Protocol (PPP) (протокол канала связи с непосредственным соединением) предназначался для решения этой проблемы. Помимо решения проблемы формирования стандартных пакетов данных Internet IP в каналах с непосредственным соединением, РРР также должен был решить другие проблемы, в том числе присвоение и управление адресами IP, асинхронное (старт/стоп) и синхронное бит-ориентированное формирование пакета данных, мультиплексирование протокола сети, конфигурация канала связи, проверка качества канала связи, обнаружение ошибок и согласование варианта для таких способностей, как согласование адреса сетевого уровня и согласование компрессии информации. РРР решает эти вопросы путем обеспечения расширяемого Протокола Управления Каналом и семейства Протоколов Управления Сетью (Network Control Protocols) (NCP), которые позволяют согласовывать факультативные параметры конфигурации и различные возможности. Сегодня PPP, помимо IP, обеспечивает также и другие протоколы, в том числе IPX и DECnet.

В отличие от SLIP-протокола РРР может работать через любой интерфейс DTE/DCE (например, EIA RS-232-C, EIA RS-422, EIA RS-423 и CCITT V.35). Протокол PPP достаточно неприхотлив и может работать без управляющих сигналов модемов (таких, как Request to Send, Clear to Send, Data Carrier Detect и Data Terminal Ready). Единственным абсолютным требованием, которое предъявляет РРР, является требование обеспечения дублированных схем (либо специально назначенных, либо переключаемых), которые могут работать как в синхронном, так и в асинхронном последовательном по битам режиме, прозрачном для блоков данных канального уровня РРР. РРР не предъявляет каких-либо ограничений, касающихся скорости передачи информации, кроме тех, которые определяются конкретным примененным интерфейсом DTE/DCE.

РРР обеспечивает метод передачи дейтаграмм через последовательные каналы связи с непосредственным соединением. Он содержит три основных компонента:

Метод формирования дейтаграмм для передачи по последовательным каналам. РРР использует протокол High-level Data Link Control (HDLC) (Протокол управления каналом передачи данных высокого уровня) в качестве базиса для формирования дейтаграмм при прохождении через каналы с непосредственным соединением.

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

Семейство протоколов NCP (Network Control Protocols) для организации и выбора конфигурации различных протоколов сетевого уровня. РРР протокол предназначен для обеспечения одновременного пользования множеством протоколов сетевого уровня.

Для того чтобы организовать связь через канал связи с непосредственным соединением, инициирующий РРР сначала отправляет пакеты LCP для выбора конфигурации и (факультативно) проверки канала передачи данных. После того, как канал установлен и пакетом LCP проведено необходимое согласование факультативных средств, инициирующий РРР отправляет пакеты NCP, чтобы выбрать и определить конфигурацию одного или более протоколов сетевого уровня. Как только конфигурация каждого выбранного протокола определена, дейтаграммы из каждого протокола сетевого уровня могут быть отправлены через данный канал. Канал сохраняет свою конфигурацию для связи до тех пор, пока явно выраженные пакеты LCP или NCP не закроют этот канал, или пока не произойдет какое-нибудь внешнее событие (например, истечет срок бездействия таймера или вмешается какой-нибудь пользователь).

Link Control Protocol (LCP) может согласовывать модификации стандартной структуры блока данных РРР. Однако модифицированные блоки данных всегда будут четко различимы от стандартных блоков данных. Алгоритм работы протокола представлен на Рисунке 2.3.



Рисунок 2.3 - Алгоритм работы PPP протокола

Фаза Dead начинает и заканчивает процесс связи. В случае появления внешнего события (например, готовность аппаратного обеспечения осуществить связь) будет инициирована фаза Establish, в которой происходит согласование различных параметров соединения (обмен пакетами LCP). В случае невозможности согласовать некоторый параметр, процесс прервется и протокол перейдет в состояние Dead. Если же все необходимые параметры согласованы, будет инициирована фаза Authenticate, в которой проводится проверка на подлинность участников сеанса (если таковая требуется). В случае неудачной аутентификации будет инициирована фаза Terminate, подготавливающая разрыв соединения. Если же фаза Authenticate прошла успешно, протокол переходит к фазе Network. В этой фазе осуществляется пересылка данных в соответствии с ранее сконфигурированными параметрами связи (в частности - типом сетевого протокола). Фаза Network начинается с того, что каждый протокол сетевого уровня (например, IP или IPX) конфигурирует различные параметры (скажем, согласует алгоритм сжатия заголовка пакета, обменивается адресной информацией) с помощью соответствующих протоколов Network Control Protocol (например, IP Control Protocol или IPX Control Protocol). Фаза Terminate (используется по окончании передачи кадров или в случае возникновения каких-либо ошибок) прерывает передачу кадров и переводит протокол РРР в состояние Dead.

Структура кадра протокола PPP.

РРР использует принципы, терминологию и структуру блока данных процедур HDLC (High Level Data Link Control) (ISO 3309-1979) Международной Организации по Стандартизации (ISO), модифицированных стандартом ISO 3309-1984/PDAD1. ISO 3309-1979 определяет структуру блока данных HLDC (Таблица 2.3) для применения в синхронных окружениях. ISO 3309-1984/PDAD1 определяет предложенные для стандарта ISO 3309-1979 модификации, которые позволяют его использование в асинхронных окружениях. Процедуры управления РРР используют дефиниции и кодирование управляющих полей, стандартизированных ISO 4335-1979 и ISO 4335-1979/Addendum 1-1979.

Таблица 2.1

Структура кадра протокола PPP

1 байт	1 байт	1 байт	2 байта	(до 1500 байтов)	2 байта	1 байт
Flag	Address	Control	Protocol	Information	CRC	Flag
(7E)	(FF)	(03)				(7Е)

Flag

Длина последовательности "флаг" равна одному байту; она указывает на начало или конец блока данных. Эта последовательность состоит из бинарной последовательности 01111110.

Address

Длина поля "адрес" равна 1 байту; оно содержит бинарную последовательность 11111111, представляющую собой стандартный широковещательный адрес. РРР не присваивает индивидуальных адресов станциям, то есть содержимое поля "адрес" никогда не изменяется.

Control

Поле "управление" составляет 1 байт и содержит бинарную последовательность 00000011, которая требует от пользователя передачи информации непоследовательным кадром. Предусмотрены услуги без установления соединения канала связи, аналогичные услугам LLC Type 1.

Protocol

Длина поля "протокол" равна 2 байтам; его значение идентифицирует протокол, заключенный в информационном поле блока данных.

Information

Длина поля "данные" - от нуля и больше; оно содержит дейтаграмму для протокола, заданного в поле протокола. Максимальная длина умолчания информационного поля равна 1500 байтам. В соответствии с априорным соглашением, разрешающие реализации РРР могут использовать другие значения максимальной длины информационного поля.

Если при синхронном типе связи в поле "данные" появляется байт со значением 7E (значение байта-флага), то ситуация обрабатывается на аппаратном уровне с помощью техники вставки битов (bit stuffing).

При асинхронном (стартстопном) типе связи ситуации, когда между байтами-флагами появляются байты со значениями 7E или 7D (значение символа Esc - scape) и значениями меньшими 20 (управляющие символы ASCII), обрабатываются при помощи составных последовательностей. Байт 7E передается как двухбайтовая последовательность 7D,5E; байт 7D - как последовательность 7D,5D; байты XX со значениями меньшими 20 - как XX.

CRC

Поле "проверочная последовательность блока данных" обычно составляет 16 бит (два байта). В соответствии с априорным соглашением, разрешающие реализации РРР могут использовать 32-х битовое (четырехбайтовое) поле CSC, чтобы улучшить процесс выявления ошибок.

Протокол PPP является значительно развитым инструментом для работы на последовательных линиях и имеет следующие преимущества:

- возможность одновременной работы по различным сетевым протоколам, а не только по IP;

- проверка целостности данных путем подсчета контрольной суммы;

- поддержка динамического обмена адресами IP;

- возможность сжатия заголовков IP - и TCP - пакетов, разработанных Van Jacobson (механизм похож на реализованный в протоколе CSLIP).

До недавнего времени число пользователей протокола РРР было незначительным. В основном это было связано с малым число программных продуктов, поддерживающих РРР. Однако сейчас не вызывает сомнений, что будущее за протоколом РРР. Это подтверждается массовым появлением продуктов, реализующих этот протокол.

2.3 Структурный состав модели

Модель для передачи информации состоит из пяти основных модулей и библиотеки, содержащих функции и процедуры необходимые для обеспечения стабильного функционирования комплекса в соответствии с налагаемыми на него требованиями. Каждый модуль инкапсулирует определенные механизмы по работе с потоками данных: прием/передача данных, контроль над сессиями передачи, создание туннелей передачи и пр. Часть модулей имеет графические формы, для заполнения параметров по операциям, конфигурационных настроек, а также формы отображения текущего состояния процессов.

2.3.1 Модуль формирования очереди заданий и управления сессиями передачи данных

Механизм, реализованный в данном модуле, внешне похож на механизм диспетчера процессов ОС, однако в пакетной обработке, реализованной в комплексе FTP-клиента, роль диспетчеризации значительно шире. Функции и процедуры, входящие в состав комплекса, обеспечивают непосредственный контроль над информационными потоками приема/передачи данных.

Процесс диспетчеризации в FTP-клиенте производит формирование списка заданий в соответствии с некоторой политикой, которая зависит от конкретной установки и реализуется средствами конфигурирования, например, указанием приоритета операции. Периодическое размещение заданий в списке очереди выглядит как типичная задача планирования, которую можно формализовать следующим образом:

- С операцией ассоциируется приоритет, определяющий частичный порядок в очереди. В соответствии с этим порядком производится выборка заданий и их запуск.

- Определяются правила выбора операций из числа тех, которые удовлетворяют заказу.

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

Выбор заданий из спула осуществляется непосредственно диспетчером потоков, который четко отслеживает текущее состояния каждой запущенной сессии и при ее завершении передает потоку новое задание, удаляя из списка отработанное.

В каждый момент приема или отправки блока данных поток сообщает диспетчеру о своем состоянии, обеспечивая, тем самым, необходимый уровень контроля в многопоточном приложении. При возникновении каких-либо внештатных ситуаций (например, отказ основного сетевого соединения, зависание потока) диспетчер может приостанавливать выполнение отдельных потоков на непродолжительное время, а также выполнять терминирование потока при отсутствии в течение определенного периода времени сведений о его состоянии.

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

2.3.2 Модуль определения типа соединения, реализация функции Dial on Demand

При наличии выделенных каналов связи не лишним будет иметь элементарный резерв на основе модемных соединений по коммутируемым телефонным линиям. Идеальным вариантом будет использование резервного, так называемого, "соединения по требованию" или DDR (Dial-on-Demand Routing).

ИС позволяет автоматически определить тип соединения. В случае необходимости использования модемного соединения комплекс инициирует процедуру создания РРР-сессии на основе одного из имеющихся в системе соединений. Каждый раз при запуске основного исполняемого файла определенная процедура модуля проверяет наличие собственного соединения и в случае его отсутствия создает его с использованием установок по умолчанию. Конфигурирование данного соединения представляет особое значение, поскольку при неправильных настройках параметров модемное соединение может работать нестабильно или же вовсе не позволит создать РРР-сессию.

При установке PPP-сессии модуль подключает в работу процедуру, обеспечивающую контроль за текущим состоянием соединения, позволяя определить и выявить возможные ошибки, возникающие в ходе приема/передачи данных, и принять соответствующие меры к их устранению. Список телефонных абонентов, используемых для модемного соединения, должен быть заранее сконфигурирован в основных настройках системы (Приложение Д). При инициировании РРР-сессии используются последовательно каждый абоненты заданное количество раз. Если по данному абоненту сессию установить не удалось, функция набора номера переходит к следующему.

При конфигурировании ИС на использовании резервного соединения при помощи технологии WEB Ranger необходимо прописать в конфигурационных настройках значения времени ожидания эхо-повтора и количества посылаемых ping-пакетов, достаточных для создания за время ожидания ответа от удаленного сервера модемного соединения самим WEB Ranger'ом. При этом контроль за сессией и возможное исправление ошибок осуществляется непосредственно WEB Ranger'ом, а программный комплекс контролирует лишь физическое наличие канала связи. В случае обрыва связи комплекс вновь произведет инициализацию сетевой активности, ожидая ответа от удаленного сервера до тех пор, пока либо WEB Ranger не создаст сессию, либо не закончится период времени ожидания ответа.

2.3.3 Модуль криптозащиты передаваемой информации

Для обеспечения конфиденциальности передаваемой информации в состав ИС входит модуль, содержащий функции криптозащиты данных. При заведении операции в настройках системы имеется возможность указания необходимости криптования или декриптования данных. При этом если обрабатываемое задание является приемом файлов, то соответственно по принятию данных будет автоматически произведена их декриптация. Если заданием является отправка файлов, будет автоматически произведено их криптование. Функции модуля криптозащиты используют стандарт систем с открытым ключом.

В качестве функции, гарантирующей целостность принимаемой или отправляемой информации, в модуле реализована функция подсчета контрольной суммы файла (CRC), позволяющей записывать в криптованный блок данных или считывать из него битовую последовательность, являющейся контрольной суммой.

2.3.4 Модуль опциональных настроек и дополнительных сервисных возможностей

Модуль содержит интерфейс, позволяющий указывать основные конфигурационные настройки непосредственно для соединения, а также формировать список выполняемых операций. Все настройки производятся один раз при инсталляции комплекса и корректируются по мере необходимости. Настройки, используемые при создании сессий, операций приема/передачи, автоматического запуска комплекса хранятся в конфигурационном файле, создаваемом в той же директории, что и исполняемый файл.

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

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

2.3.5 Модуль функций по автоматическому управлению моделью

Для минимального участия человеческого фактора в процессе управления ИС, а также использования функций комплекса FTP-клиента, обеспечивающих прием/передачу файлов, внешними приложениями, в состав комплекса интегрирован модуль автоматического управления. Данный модуль содержит функции, реализованные с использованием технологии ОС (операционной системы) Windows генерации и обработки сообщений.

В состав модуля входят следующие функции:

- Функция широковещательного оповещения всех окон системы верхнего уровня.

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

Функция предоставления дескриптора приложения

Предназначена для терминирования комплекса FTP-клиента, используя дескриптор его процесса, в случае долговременного простоя приложения в ожидании получения или отправления файлов. Необходимость вызвана возможностью каких-либо негативных факторов (зависание программного комплекса, выдача фатальной ошибки), имевших место с момента последнего выхода FTP-клиентом на связь.

- Функция предоставления пути и имени главного исполняемого файла комплекса.

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

- Функция обработки сообщений посылаемых внешними приложениями для инициализации операции трансферта.

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

2.4 Межмодульное взаимодействие

Алгоритм, реализованный в модели для передачи информации предусматривает логический порядок выполнения функций, инкапсулированных в телах модулей. Графическое изображение схемы взаимодействия компонентов системы представлено в Приложении Б.

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

Взаимодействие с внешними приложениями осуществляется на основании механизма ОС Windows генерации и обработки сообщений. Графическое изображение схемы взаимодействия модулей представлено в Приложении В.

2.4.1 Схема взаимодействия модулей

Происходит отработка процедур и функций, инкапсулированных в модуле инициализации системы (Рисунок 2.4). На данном этапе происходит проверка структуры каталогов, используемых для основных целей (приема/передачи информации) и вспомогательных, обеспечивающих хранение логической структуры заводимых операций. Происходит резервирование идентификаторов сообщений, используемых при взаимодействии комплекса с внешними приложениями; создание объектов, необходимых для динамического хранения структур и формирования очередей потоков. Осуществляется выгрузка библиотеки, обеспечивающей установку ловушки в ОС на определенные сочетания клавиш, позволяющие вызывать основные функции комплекса без использования устройства мышь.

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

Следующим этапом работы системы является определение текущего состояния подключения, определение типа соединения, при необходимости - его создание. Инициализируются функции, осуществляющие контроль над созданием и функционированием соединения, сигнализирующие о текущем статусе соединения.

Рисунок 2.4 - Функциональная схема взаимодействия компонентов системы

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

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

2.4.2 Схема стороннего управления

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

Схема стороннего управления рассматривается с двух позиций: ручного воздействия и автоматического (Рисунок 2.5). В любом случае, все взаимодействие осуществляется через зарезервированные дескрипторы сообщений с использованием функций модуля по автоматическому управлению комплексом.

При ручном воздействии на FTP-клиента происходит широковещательное оповещение всех окон о начале передачи данных. При этом если в системе находились запущенные приложения, использующие транспортные возможности комплекса, генерировался запрос к программному комплексу о предоставлении сведений о дескрипторе главного процесса комплекса и текущего месторасположения. После получения необходимых сведений внешнее приложение инициализирует процедуру по контролю за текущим состоянием комплекса. При наступлении определенных критических условий (возникновение фатальной ошибки в комплексе), процедура внешнего приложения по контролю за состоянием комплекса передачи конфиденциальной информации, производит принудительное удаление главного процесса комплекса из системы по последнему известному дескриптору и производит новый запуск комплекса, основываясь на сведениях о пути и месторасположении главного исполняемого файла FTP-клиента.

Механизм реагирования при автоматическом воздействии несколько отличается от ручного. В этом случае широковещательного сообщения о начале передачи данных не происходит, так как клиент выполняет фактически запрос внешнего приложения, которое до генерации сигнала о начале передачи данных уже содержит дескриптор основного процесса FTP-клиента и его месторасположение.

Рисунок 2.5 - Функционально-логическая схема управления

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

Механизм формирования очереди заданий внешне похож на механизм диспетчера процессов ОС, однако в пакетной обработке, реализованной в FTP-клиенте, роль диспетчеризации значительно шире.

Гарантированная доставка информации, обеспечивается специальными алгоритмами, включающими в себя проверку факта доставки данных на каждом этапе выполнения операции.

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

3. Реализация модели системы передачи информации

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

3.1 Основные интерфейсы

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

3.1.1 Опции для установки PPP-сессии. Основные модемные установки

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

В модели предусмотрена возможность конфигурирования настроек соединений, зарегистрированных в системе и используемых модели для передачи информации. Все настройки для PPP-соединения осуществляются на форме комплекса, представленной на Рисунке 3.1.

Каждая вкладка приведенной формы содержит определенные характеристики, определяемые наименование вкладки:

- «Dialing». Содержит основные данные касательно правил дозвона.

- «Logon&Device». Здесь указываются такие характеристики как: информация о номере телефона, имени пользователя и пароле доступа, выбор типа устройства набора номера и пр.

- «Protocols». Обеспечивает выбор и указание протоколов установки соединения, конфигурацию стека протоколов TCP/IP, специальные установки, такие как сжатие заголовков, отображение окна терминала и пр.

- «Security». Обеспечивает установки, отвечающие необходимой аутентификации и методам шифрования паролей при установке соединений.

- «Script». Обеспечивает просмотр и создание скрипт-файлов, используемых при инициализации модема.

- «MultiLink». Отвечает за установку мультиплексирования протокола сети.

- «W2000». Устанавливаются дополнительные атрибуты соединения, доступные лишь при использовании на платформе Windows 2000 и XP.

Рисунок 3.1 - Форма основных установок модемного соединения

3.1.2 Настройка FTP-соединения. Список выполняемых операций

Настройка FTP-соединения происходит при указании адреса FTP-сервера, а также имени пользователя и пароля доступа (Рисунок 3.2)



Рисунок 3.2 - Форма с настройками FTP-соединения и списка выполняемых операций

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

Для каждого основного сервера по маскам операций составляются сами операции. Форма для заведения операций представлена на Рисунке 3.3.

Рисунок 3.3 - Форма для заведения информации по операциям

На форме представлены основные настройки:

- «Тип операции». Предусматривает режим обмена с сервером.

- «Приоритет операции». Показывает как задание будет размещено в спуле и обработано процессом (задания с приоритетом «Высокий» обрабатываются в первую очередь)

- «Откуда/Куда». Указываются локальный и удаленный каталоги.

- «Режим отправки». Обеспечивает копирование или же перемещение информации с локального компьютера на FTP-сервер и наоборот.

- «Шифровать/Дешифровать». Задает параметр операции, определяющий необходимость шифрования/дешифрования данных при их приеме или отправке.

- «Вести логи по операциям». Указывается необходимость протоколирования данной операции и отображение ее в журнале операций приема/передачи файлов.

3.1.3 Журнал протоколирования операций

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

Журнал отображает полноценную информацию, достаточную для понимания пользователем о протекании процесса передачи данных. При необходимости предоставляется возможность вывода на бумажный носитель протокола процесса приема/передачи информации, отображаемого на форме журнала. Экранная форма журнала представлена на Рисунке 3.4

Помимо ведения лог-файла, часть которого представлена на форме журнала операций приема/передачи данных, комплекс FTP-клиента ведет еще один тип лог-файла, основанного на командах, посылаемых FTP-серверу.

3.2 Повседневное использование

Перед началом использования модели необходимо ее запустить, если установлена опция автоматического запуска комплекса FTP-клиента при старте системы, то ручной запуск не требуется. Необходимо заметить, т.к. модель является многопоточным приложением, и необходимость запуска второй копии экземпляра приложения будет не целесообразной, специальными средствами предусмотрена возможность для обнаружения ранее запущенных копий.

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

Основными пунктами меню являются:

- Операции, содержащие две команды: обычный сеанс связи и сеанс связи для приема/передачи файлов с высшим приоритетом;

- Журнал протоколирования операций;

- Опциональные настройки.

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

3.3 Необходимость защиты настроек системы

При изменении условий приема/передачи файлов, а также условий физической среды передачи необходимо произвести переконфигурирование основных параметров и настроек системы. Данная возможность предоставляется при выборе пункта «Опциональные настройки» главного меню комплекса FTP-клиента. Следует отметить, что доступ к указанному пункту меню ограничен и осуществляется только специалистами с помощью специального сочетания клавиш.

Основные настройки по операциям хранятся в табличных структурах Paradox. Данный вид таблиц предусматривает возможность установки пароля на доступ и открытие таблиц. Таким образом, при создании структур данных происходит установка пароля. Предусмотрение необходимо в целях избежания внешнего взлома табличных структур, используя любые средства просмотра и редактирования таблиц. С целью двойной гарантии безопасности при заведении настроек, связанных с указанием имен пользователей и пароля доступа к FTP-серверам и модемным пулам, в комплексе предусмотрен алгоритм специального шифрования пароля и помещения его в табличную структуру в зашифрованном виде.

Необходимость защиты возникает с целью предотвращения злоумышленного использования сведений, относящихся к конфиденциальной информации (имена пользователя и пароля доступа к FTP серверам и модемным пулам).

информационный логический программный файловый

4. Экономика

Для определения экономического эффекта от внедрения приспособлений в производственный процесс необходимо рассчитать все затраты на его проектирование, изготовление, испытание, в том числе:

-материальные затраты;

- затраты на амортизацию оборудования, используемого при изготовлении приспособления;

- затраты на электроэнергию, потребляемую оборудованием;

- затраты на оплату труда всех участников проекта;

- накладные расходы - затраты косвенно входящие в общую сумму расходов.

Основными факторами, определяющими эффективность ИС являются:

- повышение качества управления процессом работы;

- снижение трудоёмкости и увеличения производительности труда;

- оптимизация показателей производственной деятельности;

- повышение эффективности использования оборудования;

- сокращение потерь материальных и энергетических ресурсов.

К показаниям экономичности ИС относятся затраты на создание, внедрение, освоение ИС и эксплуатационные расходы на её содержание. При оценке эффективности производства всегда необходимо сопоставлять полученный эффект от производства чего-либо с затратами на производство, то есть возникает необходимость учёта этих затрат весьма разнообразен: затраты труда, средств, материалов, услуг и т.д. Всё это разнообразие учитывается с точки зрения универсального стоимостного подхода - в денежной форме.

Существует следующая классификация затрат на производство - это расходы на:

- сырьё и основные материалы;

- вспомогательные материалы;

- электроэнергию;

- амортизацию основных средств;

- заработную плату;

- отчисления на социальное страхование;

- прочие денежные расходы.

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

Себестоимость создания системы определяется по формуле:

Ссозд = Мз+Фзп+Зэл+Актс+Зар+НР,(4.1)

где Ссозд - себестоимость системы;

Мз - материальные затраты;

Фзп - фонд заработной платы сотрудников;

Зэл - затраты на электроэнергию, отопление и освещение;

Акте - амортизационные отчисления на покупное оборудование и программное обеспечение;

Зар - затраты на арендуемое оборудование;

НР - накладные расходы. Все величины измеряются в тенге. Материальные затраты рассчитываются по формуле:

Мз = Зб+3д+3к,(4.2)

где 3б - затраты на бумагу;

Зд - затраты на диски (дискеты);

Зк - затраты на картриджи для принтера. Эти затраты рассчитываются по формуле:

Зб = Сб*Кб,

Зд = Сд*Кд,

Зк = Ск*Кк,(4.3)

где Сб - стоимость одного листа бумаги;

Кб - количество листов бумаги;

Сд - стоимость диска (дискеты);

Кд - количество дисков (дискет);

Ск - стоимость одного картриджа;

Кб - количество картриджей.

По формуле (4.3) рассчитываются затраты на материалы:

Зб=1*1000 = 1000 тг.,

Зд= 25*500 = 12500 тг.,

Зк= 200*40 = 8000тг.

Тогда общие затраты на материалы равны:

Мз = 1000+12500+8000 = 21500 тг..

Расчет трудовых затрат производится с помощью нормирования затрат рабочего времени в процессе производстве работ. Нормирование дает возможность эффективно использовать оборудование, выявлять потери рабочего временя, что в свою очередь оказывает влияние на снижение себестоимости производимой продукции (выполняемых работ).

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

Расчет фонда заработной платы определяется по формуле:

Фзп = Зп*Тз*К, (4.4)

где Зп - ежемесячная заработная плата разработчика;

Тз - время на разработку задачи;

К - количество разработчиков.

Ежемесячная заработная плата разработчика Зп включает 10% социального налога и рассчитывается по следующей формуле:

Зп = 3*10%, (4.5)

где 3 - заработная плата одного разработчика.

Работы, связанные с разработкой программного обеспечения относятся к классу сложности 2. Используя тарифную сетку можно рассчитать оплату труда. Учитывая степень сложности выполняемой работы, устанавливается 13 разряд с разрядным коэффициентом 2,05. Часовую тарифную ставку инженера - системотехника можно определить по формуле:

ЧТС = Мзп-Кр/160, (4.6)

где Мзп - минимальная заработная плата;

Кр- разрядный коэффициент.

Минимальная заработная плата для специалиста данной категории составляет 6600 тенге/час, среднее количество рабочих часов в месяц равно 190.

По формуле (5.6) рассчитывается часовая тарифная ставка:

ЧТС 6600*2,05/190=71,21 тг.

При восьмичасовом рабочем дне заработная плата составит 570 тенге.

С учетом времени на разработку задачи равным 35 дней по формуле (4.4) определяется фонд заработной платы:

Фзп = 570*35*2 = 39900тг.

Амортизационные отчисления определяются по формуле:

Актс= (Сктс/Тр) *Тз,(4.7)

где Сктс - стоимость комплекса технических средств (КТС);

Тр - нормативный срок службы КТС;

Тз - время на разработку задачи. Стоимость КТС определяется по формуле:

Сктс = Ск+Сп,(4.8)

где Ск - стоимость компьютера;

Сп - стоимость принтера.

Стоимость компьютера и принтера составляет 130000 и 10000 тенге соответственно. Нормативный срок службы равен три года (795 рабочих дней).

По формуле (4.7) определяются амортизационные отчисления:

Актс = (140000/795)*35 = 6163,5 тг.

Затраты на электроэнергию, освещение, отопление определяются по следующей формуле:

Зэл = Сэл+Сос+Сот, (4.9)

где Сэл - затраты на электроэнергию;

Соc - затраты на освещение;

Сот - затраты на отопление.

Затраты на электроэнергию рассчитываются по формуле:

Сэл = (Мк*Тк+Мп*Тп) *Тз*С,(4.10)

где Мк - потребляемая мощность компьютера;

Тк - время работы компьютера;

Мп - потребляемая мощность принтера;

Тп - время работы принтера;

Тз - количество рабочих дней, затраченных на создание системы;

С - стоимость 1 кВт/час, тенге.

По формуле (4.10) рассчитываются затраты на электроэнергию:

Сэл = (0,35*8+0,27*0,005)*35*4,16 =409,64г.

Затраты на освещение составляют:

Сос = Сл*Т*С*Тз,(4.11)

где Сл - мощность светоустановки;

Т - количество часов освещения в день;

С - стоимость 1 кВт/час, тенге;

Тз - количество рабочих дней, затраченных на создание системы. По формуле (4.11) определяются затраты на освещение:

Сос=0,8*4*35*4,16 = 465,92тг.

Затраты на отопление составляют:

Сот = Цот*Пл*Мот,(4.12)

где Цот - цена отопления за 1кв.м.;

Пл - площадь рабочего помещения;

Мот - количество отопительных месяцев совпадающих с проведением работ.

Площадь рабочего помещения составляет 86 м. Тогда по формуле (4.12):

Сот = 86*6.62*0 = 0 тг.

По формуле (4.9) затраты на электроэнергию, освещение, отопление составляют:

Зэл =409,64 + 465,92 + 0 тг = 875,56 тг.

Накладные расходы рассчитываются по формуле:

НР = Кз*Сктс,(4.13)

где Кз = 0,05 - коэффициент затрат на содержание в год от стоимости комплекса технических средств; Сктс - стоимость КТС.

Тогда НР = 0,05 *140000 = 7000тг.

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

По формуле (4.1) себестоимость создания системы составляет:

Ссозд = 21500+39900+875,56 +6163,5 +0+7000 = 75439,06 тенге.

Договорная стоимость на продажу программного комплекса определяется по формуле:

Цд = Ссозд*(1+Нр/100),(4.14)

где Ссозд - себестоимость создания системы;

Нр - нормативная рентабельность, проценты.

Основываясь на величине полезности работы (ее результативности) для программного обеспечения нормативная рентабельность составляет 25%. Тогда по формуле (4.14):

Цд = 75439,06 * (1+25/100) = 94298,82 тг.

Чистая прибыль определяется по формуле:

Пч = Цд - (НДС+Нп+Нс),(4.15)

где Цд - договорная стоимость на продажу системы; НДС - налог на добавленную стоимость;

Нп - налог на прибыль;

Нc - социальный налог.

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

НДС составляет 12% от стоимости системы.

НДС = 94298,825 *0,12 =11315,85 тг.

Данный показатель необходимо включить в стоимость продажи системы. Тогда договорная стоимость на продажу системы, включая НДС равна:

Цд =94298,82 +11315,85 =105614,6 тг.

Налог на прибыль составляет 30% от стоимости продажи:

Нп =105614,6*0,3 = 31684,4 тг.

Социальный налог составляет 11% заработной платы:

Нc =570 *35*0,11 = 2194,5 тг.

По формуле (4.15) чистая прибыль от продажи программного продукта равна:

Пч =-105614,6 - (11315,85 +31684,4+2194,5 ) = 60419,9 тенге.

Таким образом, чистая прибыль от разработанного программного обеспечения составляет 60419,9 тенге.

Срок окупаемости программного продукта считается по формуле:

Расчетный коэффициент эффективности (Ер) это величина, обратная сроку окупаемости, который равен 0,5. Расчетный коэффициент эффективности Ер сравнивается с нормативным коэффициентом эффективности Ен, равным 0,28 - 0,57. Если Ер больше либо равен Ен, то создание информационной подсистемы эффективно. В случае разрабатываемой модели:

Ер > Ен, (4.17)

Рааработку следует признать экономически эффективной.

Годовой экономический эффект от разработки и внедрения ЭИС (Э) оп- ределяется как разность между годовой экономией (или годовым приростом прибыли) и нормативной прибылью:

Э = П - К * Ен (4.18.)

где П - годовая экономия (годовой прирост прибыли) тыс.тг.;

К - единовременные затраты, тыс.тг.;

Ен- нормативный коэффициент эффективности капитальных вложений.

Произведение К*Ен в данном случае следует рассматривать как норма- тивную прибыль, которая должна быть получена от внедрения системы. Ен принимается равным 0,15 для всех отраслей народного хозяйства. Ен представляет собой минимальную норму эффективности капитальных вложений, ниже которых они нецелесообразны. Полученное в данном случае значение показателя Э служит для сопоставления экономических результатов автоматизации обработки данных с результативностью капитальных вложений в другие направления совершенствования производства и управления.

Э=60419,9-75439,06*0,15=49104,1тенге

Срок окупаемости капитальных затрат покупателя Т_ок на приобретение и внедрение проекта рассчитывается по формуле (4.19).

(4.19),

где: Клвс - капитальные затраты на приобретение и внедрение проекта;

Рэк - годовая экономия на текущих расходах.

Капитальные затраты покупателя на приобретение и внедрение системы определяются по формуле 4.20.

Клвс = Цсозд+Ккрм+Ктех+Кпр (4.20),

где: Цлвс - рыночная цена ситемы (равна Цр);

Ккрм - капитальные вложения на создание рабочих мест для пользователей;

Ктех - капитальные вложения на техническое оснащение рабочего места пользователя;

Кпр - прочие капитальные вложения, связанные с внедрением (5% от Цлвс).

Капитальные вложения на создание рабочего места пользователя системы определяются по формуле 4.21.

Ккрм = S * Цпл + Змеб (4.21),

где: S - размер площади, занимаемой компьютером (4-5 кв.м.);

Цпл - рыночная цена 1 кв.м. площади (550000 тг.);

Змеб - затраты на приобретение мебели (20% от Цком).

Капитальные вложения на техническое оснащение рабочего места пользователя определяются по формуле (4.22).

Ктех = (Цком + Цтех) * (1 + Ктр) * (1 - Киз) (4.22),

где: Цком - цена одного компьютера (130000 тг.);

Цтех - цена дополнительного технического оснащения компьютера (50% от Цком);

Ктр - коэффициент, учитывающий затраты на транспортные издержки и отладку рабочих станций после установки (можно принять в размере 0,05);

Киз - коэффициент, учитывающий степень износа действующих ПК (так как ПК новые, то Киз = 0).

Исходя из цены компьютера в130000 тг. произведем расчеты.

Ккрм = S * Цпл + Змеб = 4*55000+0,2*130000= 246000 тг.

Ктех = (Цком + Цтех) * (1 + Ктр) * (1 - Киз) =

= (130000+0,5*130000)*(1+0,05)*1= 204750 тг.

Кпр = 0,05 * Цсозд = 0,05*75439,06 = 3771,953тг

Клвс = Цсозд. + Ккрм + Ктех +Кпр = 75439,06 +246000+204750 +

+3771,953 = 529961,013. тг.

Годовая экономию на текущих расходах Рэк, которую может получить фирма от использования ЛВС, определяется по формуле (4.23).

Рэк = Зр - Зтех (4.23),

где: Зтех - годовые текущие затраты покупателя, связанные с применением системы, рассчитываются по формуле;

Зр - затраты на решение задач без применения системы, которые определяются по формуле (4.24).

Зр = Тм * См (4.24),

где: Тм - величина затрачиваемого машинного времени на решение задач при использовании системы;

См - стоимость одного часа эксплуатации компьютера.

Стоимость одного часа эксплуатации компьютера можно определить укрупнено по формуле (27).

(4.25),

где: Тс - месячная тарифная ставка 13-го разряда (13107 тг.);

Тк - тарифный коэффициент (Тк 13 разряда составляет 4);

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

тг./час

Величина затрачиваемого машинного времени на решение задач при использовании системы определятся по формуле (4.26).

Тм = nз*tm (4.26),

где: nз - количество задач определенного вида, которые решаются с помощью системы в течение года; tm - машинное время, затрачиваемое на решение ПК одной задачи определенного вида.

Tm = 1/60 = 0,0167часа;

Nз = N*21*12 = 600*21*12 = 151200;

Тм = 0,0167*8*151200 = 20200 часа.

тг.

Таким образом годовые текущие затраты покупателя, связанные с применением системы будут составлять 2216888 тенге.

Зр = Тм * См = 20200 * 327 = 6605400 тг.

Рэк = Зр - Зтех = 6605400 -2216888= 4388512тг.

Проект оказался эффективным по сколько срок окупаемости оправдался и составил менее года.

5. Охрана труда

5.1 Режим труда

Режим труда и отдыха при работе с ВДТ (видеодисплейный терминал), ПЭВМ и ПК должен организовываться в зависимости от вида и категории трудовой деятельности. Виды трудовой деятельности разделяются на 3 категории тяжести и напряженности, каждая из которых подразделяется на 3 группы:

- группа А - работа по считыванию информации с экрана ВДТ или ПЭВМ с предварительным запросом;

- группа Б - работа по вводу информации;

-группа В - творческая работа в режиме диалога с ЭВМ.

При выполнении в течение рабочей смены работ, относящихся к разным видам трудовой деятельности, за основную работу с ВДТ или ПЭВМ следует принимать ту, которая занимает не менее 50 % времени в течение рабочей смены или рабочего дня. Продолжительность обеденного перерыва определяется действующим законодательством о труде и Правилами внутреннего трудового распорядка предприятия (организации, учреждения). Для обеспечения оптимальной работоспособности и сохранения здоровья профессиональных пользователей, на протяжении рабочей смены должны устанавливаться регламентированные перерывы. Продолжительность и количество регламентированных перерывов в течение рабочей смены следует устанавливать в зависимости от продолжительности смены, вида и категории трудовой деятельности.

...