ЖУРНАЛ СТА 4/2011
навливается на удалённый объект, на котором большинство систем работает в автоматическом режиме без вмеша- тельства оператора. Поэтому чем проще организована работа подсистем, тем надёжнее работает вся система. Основные функции возложены на клиентское приложение. Клиентская часть устанавливает канал связи, конт- ролирует его состояние, инициирует обмен данными и реализует механизм надёжного взаимодействия. Создание и управление каналом связи зависит от типа создаваемого канала. Например, если создаётся радиоканал с использова- нием радиомодемов, то для установле- ния канала связи достаточно проверить доступность удалённого модема и каче- ство проходящих сигналов. Поскольку радиомодемы способны обеспечить «прозрачный» канал, то никаких допол- нительных действий не потребуется. Немного сложнее процесс установле- ния, например, GSM-канала. В этом случае необходимо сначала организовать «дозвон» до удалённого модема. После организации канала связи кли- ент запрашивает все данные с сервера для обеспечения начальной инициали- зации. При этом сервер фиксирует значения, отправленные клиенту, в про- межуточном журнале и далее отправляет лишь изменённые значения. Такой под- ход существенно уменьшает количество данных, передаваемых по сети. Каждый отправляемый и получае- мый пакет контролируется на целост- ность путём проверки контрольной суммы. Контрольная сумма вычис- ляется с использованием побитового применения операции XOR (исклю- чающее ИЛИ) ко всему пакету и запи- сывается в заголовок пакета. Пакет принимается к обработке лишь после успешного прохождения процедуры проверки контрольной суммы. На каждый полученный пакет дан- ных принимающая сторона отправляет подтверждение, в котором записывает- ся уникальный код принятого пакета. На основе этого подтверждения от- правленные данные считаются полу- ченными и фиксируются в журнале синхронизированных данных. Если та- кое подтверждение не получено, то данные считаются утерянными и ос- таются в буфере на отправку. Эти дан- ные будут повторно отправлены при следующей передаче вместе с новыми данными. В случае если клиент не получает под- тверждения на отправленные пакеты установленное количество раз или при наличии активного канала связи долгое время нет данных от сервера (это время устанавливается в настройках програм- мы), то автоматически включается механизм проверки наличия канала связи. Механизм проверки основан на алгоритме «тройного рукопожатия» (по аналогии с протоколом TCP). Клиент отправляет серверу контрольный пакет, в котором записан код инициализации проверки канала связи. Сервер при получении такого пакета отправляет ответный пакет, в который записывает код ответа. Клиент при получении отве- та отправляет заключительный пакет, который указывает серверу, что канал связи всё ещё активен и обмен продол- жается. В процессе обмена контроль- ными пакетами клиент отслеживает скорость прохождения пакетов и срав- нивает её с минимально допустимой скоростью передачи данных, которая задана в настройках приложения. Если эта скорость меньше минимально допу- стимой, то канал считается некаче- ственным и включается механизм смены канала связи. Если за указанное время нет ответа от сервера, также запускается механизм смены канала. При смене канала связи клиент отправляет серверу пакет, содержащий специальный код, который указывает, что необходимо прекратить обмен и освободить ресурсы используемого канала связи. В этом случае сервер пре- кращает отправку данных по сети, осво- бождает ресурсы используемого канала связи и переходит в режим прослушива- ния портов. Так как доставка этого пакета не гарантирована, клиент не ждёт ответа от сервера, он делает небольшую паузу (на случай если пакет с завершающим кодом всё-таки был доставлен и сервер освобождает ресур- сы) и после этого меняет активный канал. При этом приоритет активации каналов определяется в настройках, где зарегистрированы все возможные кана- лы связи. Там же в настройках можно указать количество попыток создания для каждого канала связи. Реализация такого протокола взаимо- действия клиента и сервера приложения позволила создать простой и надёжный механизм обмена данными в условиях большой вероятности потери данных, а также позволила управлять каналами связи между двумя объектами. При этом программа построена таким образом, что управление может быть автоматиче- ским или ручным (оператор может само- стоятельно принять решение о необхо- димости сменить канал связи и дать соответствующую команду клиентскому приложению). Отдельно стоит отметить, что все наи- более значимые параметры работы при- ложения были вынесены в конфигура- ционные файлы. Это позволяет на- страивать приложение под индивиду- альные требования к работе и к исполь- зуемым средствам связи. П РИМЕР РАБОТЫ ПРОГРАММНОГО СРЕДСТВА В УСЛОВИЯХ РЕАЛЬНОГО ПРОЕКТА После реализации всех основных возможностей программы и проведе- 64 СТА 4/2011 СИС Т ЕМНА Я ИН Т Е Г Р АЦИЯ / КОММУНАЛ Ь НОЕ ХОЗ ЯЙС Т ВО www.cta.ru Рис. 4. Копия экрана АРМ диспетчера © СТА-ПРЕСС
Made with FlippingBook
RkJQdWJsaXNoZXIy MTQ4NjUy