Проблема 1: автоматически закрывается соединение с БД после уничтожения одного из дочерних процессов.

Данная проблема возникает из-за того, что Perl автоматически уничтожает переменные, ссылок на которые больше нет. Решение данной проблемы можно найти в описании модуля DBI в архиве CPAN. В частности, смотрите описание атрибута InactiveDestroy.

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

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

my $dbh = DBD::SomeDriver->new();
$dbh->{InactiveDestroy} = undef; # Разрешаем автоматическое закрытие соединения
. . .
my $child = fork();
unless ($child) {
  $dbh->{InactiveDestroy} = 1; # Запрещаем автоматическое закрытие соединения в дочернем процессе
  . . .
}
. . .

Проблема 2: возникают ошибки типа ‘Statement is already prepared‘ в дочерних процессах

Данные ошибки возникают при использовании метода prepare() для подготовки SQL-запросов. Один из вариантов, которым я пользуюсь, является клонирование дескриптора БД.

Дополняя предыдущий пример, можно прийти к такому алгоритму.

my $dbh = DBD::SomeDriver->new();
$dbh->{InactiveDestroy} = undef; # Разрешаем автоматическое закрытие соединения
. . .
my $child = fork();
unless ($child) {
  $dbh->clone(); # Создаем копию дескриптора БД
  $dbh->{InactiveDestroy} = 1; # Запрещаем автоматическое закрытие соединения в дочернем процессе
  . . .
}
. . .

Помедитировав над проектом какое-то время, я нашел достаточно простое решение, которое прекрасно работает в моей XP.

Итак, все что необходимо сделать, это пометить USER32.DLL, как отложенно загружаемую. Если конкретнее, то открываем свойства проекта, переходим в Свойства конфигурации\Компоновщик\Ввод и в значение параметра Отложенно загружаемые DLL дописываем USER32.DLL.

• DisplayKit можно найти здесь;
• Официальный сайт MochaUI;
• Официальный сайт MochiKit;
• Пример разработки расширения здесь.

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

Первое, главными и необходимыми файлами модуля расширения являются следующие:

• Dispatcher.xml – здесь размещается описание расширения, а также страница (ScriptPage), на которой будет возможность открывать окно расширения, и файл JavaScript (ScriptFile), который создаст окно расширения.
• DispatcherPackage.xml используется для предоставления информации активатору/установщику расширений в SiteAdmin. В Description тект, который отобразиться в списке Script Plugins в  SiteAdmin, в module имя файла с описанием модуля расширения.
• DispatcherModule.xml – здесь задается ссылка на модуль ASP.NET и его зависимости.
• Dispatcher.js является конструктором окон расширения, создаваемых на базе MochaUI.
• DispatcherContent.aspx – собственно страница, которая отображается в окне расширения и реализует необходимую логику.

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

В Dispatcher.js должно быть реализовано, как минимум, следующее:

• Конструктор окна Franson.DispatcherWindow, который создает окно и задает все его необходимые параметры и атрибуты;
• А также необходимо подписаться на получение сообщения инициализации пользовательского интерфейса с помощью вызова метода Franson.Event.subscribe.

Сама логика расширения реализуется обычным для ASP.NET способом.

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

• Поместить файлы в папку %HOME_DIR%\IIS\Resources\ScriptPlugins\%SITE%\%NAME%, где %HOME_DIR% – папка, куда установлен GpsGate Server, %SITE% – название вашего сайта или фирмы или еще что-то (например, com.mysite), %NAME% – название вашего расширения.
• Зайти в SiteAdmin и перейти на закладку Script Plugins.
• Надавить кнопку Refresh Script Plugins.
• Выбрать в списке рядом с кнопкой расширение.
• Поставить галочку рядом с расширением ниже и надавить кнопку Save.

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

1. Прописать путь к директории содержащей библиотеку libpq.so в /etc/ld.so.conf
2. Запустить /sbin/ldconfig

А вот выдержка из самого readme. Кстати, в последних версиях модуля в readme я уже не нашел данного текста.

DBD::Pg uses the libpq library that comes with Postgres. If the shared libpq
library is not available, DBD::Pg will error with a message that
usually mentions a file names libpq.so, like this:

    Can’t load ‘./blib/arch/auto/DBD/Pg/Pg.so’ for module DBD::Pg: libpq.so.5: cannot open
    shared object file: No such file or directory at …/DynaLoader.pm line 230.

This means that the libraries are not installed in a place where the system
can find them when it tries to load the Pg.so file. On some systems, you
can run /sbin/ldconfig -v to see a list of shared modules, or just search
the system for the file with «locate libpq.so». If it exists but is not being
loaded, you may need to add the directory it is in to /etc/ld.so.conf file
and run the ldconfig command. Otherwise, you may need to add the path to
the environment variable LD_LIBRARY_PATH.

Для сохранения всех этих данных достаточно вызвать один метод ToGpsGate, которая является членом класса Protocol. Для передачи значений используются два параметра типа TrackPoint и Dictionary<string, object> – навигационные данные и статусы соответственно. Стоит заметить, что есть перегруженные версии этого метода, но данный вариант наиболее удобен на мой взгляд.

Приведу пример добавления навигационных данных и статусов SOS, FuelLevel.

TrackPoint point = new TrackPoint(
new Position(m_longitude, m_latitude, m_altitude),
new Velocity(m_speed, m_headingCourse),
m_timestamp);

ToGpsGate((point, statuses);

Ничего сложного.

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

protected override void OnStart()
{
// Install the protocol
MyProtocol proto = new MyProtocol(null);
proto.InstallProtocol();
. . .
}

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

Установка

Первая установка плагина в систему не вызывается, каких-либо затруднений, так как GpsGate Server еще не загрузил его и не заблокировал к нему доступ. Чтобы выполнить обновление плагина, необходимо выполнить следующие действия:

1. Зайти в SiteAdmin;
2. Остановить сервис Nmea Service – кнопка «Stop» на вкладке «NMEA Service»;
3. Завершить работу с SiteAdmin;
4. Выполнить команду iisreset /stop в консоли (Win+R);
5. Скопировать плагин (dll) в папку «%APP_ROOT%\Franson NMEA Service»;
6. Скопировать плагин (dll) в папку «%APP_ROOT%\IIS\bin»;
7. Выполнить команду iisreset /start в консоли;
8. Зайти в SiteAdmin;
9. Запустить сервис Nmea Service – кнопка «Start» на вкладке «NMEA Service»;
10. Обновить страницу, чтобы получить список загруженных плагинов.

В данном случае %APP_ROOT% обозначает папку, в которую был установлен сервер GpsGate Server. По умолчанию это папка C:\Inetpub\wwwroot\GpsGateServer.

Версии

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

Так, если у в плагине версии 1.0.0.0 было только одно поле «SOS», а в последствии добавили еще одно поле «Battery Low», то это поле добавится в БД и, соответственно, в приложения (например, VehicleTracker) только, если версия плагина сменится на более старшую (например, на 1.0.0.1).

Класс-наследник GpsGate.Online.Directory.DeviceDefinition нужен для описания базовых свойств и характеристик устройства. Для этого переопределяются следующие методы и свойства:

• Свойство Name возвращает название устройства.
• Свойство Description возвращает полное описание устройства.
• Свойство NamespaceName возвращает имя пространства имен, в котором размещены остальные классы плагина.
• Метод InstallMessageFields должен вернуть список названий полей, которые поддерживает устройство.
• Метод InstallDefaultMapperEntryFor позволяет задать привязку полей устройства к полям сервера. Например, если в устройстве есть поле SOS, то его можно связать с одноименным полем SOS на сервере.
• Метод RegisterCommad возвращает набор команд, которые могут быть отправлены устройству. Да-да, именно Commad, видимо, разработчики допустили небольшую ошибочку но исправлять уже поздно.

Класс-наследник GpsGate.Online.Net.Protocol реализует протокол устройства. В частности это реализуется парой методов TranslateFromDevice, которые получают данные, поступающие с устройства, и обрабатывают их. Также в данном классе необходимо переопределить свойство StringID, чтобы оно возвращало символьное название протокола.

Классы-наследники GpsGate.Online.Net.*Listener и GpsGate.Online.Net.*Connection предназначены для реализации связи с устройством. Например, если устройство общается с сервером по протоколу UDP, то создаются два класса наследника от UdpNmeaListener и UdpNmeaConnection.

Класс-наследник *Listener выступает в качестве слушателя порта и т.п., т.е. он устанавливает соединения с устройством. В данном классе необходимо переопределить по необходимости методы OnStart, OnStop, Install и метод CreateUdpConnection, который создаст соединение с использованием вашего класса-наследника от UdpNmeaConnection. Также в данном классе необходимо переопределить свойство ProtocolID, чтобы оно возвращало символьное название протокола.

Крайне важно, чтобы свойства StringID класса-наследника GpsGate.Online.Net.Protocol свойство ProtocolID класса-наследника GpsGate.Online.Net.*Listener возвращали одинаковые значения, иначе Вы не увидите ваш плагин в VehicleTracker. Обратите на это внимание, потому что, я при разработке плагина потратил очень много времени, чтобы разобраться с этой проблемой. Решение было найдено при переписке со службой техподдержки и на данный момент об этом нигде в документации не сказано.

Класс-наследник *Connection реализует соединение с устройством и должен переопределить метод CreateProtocol, который должен создавать для обработки данных ваш класс-наследник GpsGate.Online.Net.Protocol.

В плагине может быть реализовано несколько различных соединений, например, по SMS и TCP/IP.

Также в плагине доступен глобальный объект NLog для логгирования. Его Вы можете получить с помощью такой конструкции:

private static Logger m_nlog = LogManager.GetCurrentClassLogger();

• Реализовать протокол GpsGate Protocol в самом устройстве. Данный вариант достаточно сложный и подразумевает реализацию протокола в самом устройстве. Также, данный вариант привязывает устройство к GpsGate Server, если только не реализовать в самом устройстве поддержку нескольких протоколов. В общем, не подходит.
• Реализовать proxy-сервер, который будет получать данные от устройства и преобразовывать их в совместимые с протоколом GpsGate Server и наоброт – от сервера к устройству. Этот вариант, также слишком громоздкий и хорош в том случае, когда нет доступа к устройству.
• Реализовать плагин для GpsGate Server, который будет отвечать за получени данных от устройства и передачу данных и команд устройству, т.е., по сути, плагин реализует протокол устройства. Этот вариант наиболее предпочтительный

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

Также на форуме можно найти ссылки на несколько примеров проектов плагинов на C#, например, MyDevice – базовый пример, Axxon, TrendTek. Примеры, опять же к сожалению, тоже не блещут многословием и достаточной описательностью, но суть плагина понять можно.

Еще несколько полезных ссылок про разработку и отладку плагинов – Какие логи сервера и где читать, Терминал, Отладка плагина в Visual Studio.

Думаю, этого для начало разработки достаточно.

Так, когда мы посылаем запрос Tomcat, он его обрабатывает и возвращает ответ, в котором присутствует заголовок типа Set-Cookie: Path=/; JSESSIONID=xxx, где xxx - идентификатор сессии.

Чтобы все последующие запросы относились к данной сессии, необходимо передавать полученный идентификатор сессии в заголовке запроса. Сделать это можно с помощью заголовка Cookie. К запросу добавляется пара заголовков Cookie: Path=/ и Cookie: JSESSIONID=xxx.

Т.е. алгоритм поддержки сессий следующий:

• При получении ответа от сервера, проверяем, есть ли там идентификатор сессии?
• Сохраняем идентификатор сессии, например, в переменной $_SESSION['SERVER_SESSION_ID'].
• При выполнении последующих запросов к этому серверу, добавляем заголовок с идентификатором сессии.

Легко и просто.