| Все для программирования. |
| начало | почта | статьи | файлы | ссылки | сайты | RSS | о нас | опубликовать | оформление | авторы | друзья | реклама |
|
Каталог статей
|
Статья
часть 3: использование драйвера (вариации на тему ICQ). Написание клиентской части. Первым побуждением при написании общего проекта было создание единого проекта-приложения (в терминологии PhAB - Photon Application Builder), первая часть которого (инициализация) создавала бы менеджер ресурса, регистрирующий уникальное имя (в проекте /proc/talk), а вторая - реализовывала бы пользовательский интерфейс к аналогичным экземплярам менеджеров ресурсов, запущенных на других хостах сети. Достаточно продолжительные эксперименты показали, что этот путь - не плодотворный. "Это" - не работает в принципе, и это особенность менеджера ресурса, которая не отражена нигде в документации, и на которой следует остановиться подробнее. В документации отмечается, что менеджер ресурса регистрирует уникальное путевое имя, обращаясь к менеджеру процессов (соответствующего хоста), а последний заносит это имя в свои таблицы. Можно предположить (и это очень похоже на правду), что изменения состояния таблиц зарегистрированных имён фиксируются менеджером процессов только после завершения процесса, регистрирующего имя. Это логично, так как событиями, на которые должен реагировать менеджер процессов, являются запуск и завершение процессов в системе. Отсюда следует, что рассматриваемый проект распадается на два процесса: процесс rmta, регистрирующий имя /proc/talk, и клиентский процесс clitalk, обеспечивающий пользовательские обращения к этому имени. Как оказалось, этот подход оказался плодотворнее позже также исходя из других соображений (в смысле потенциальной простоты развития такого проекта). Полученный в результате итоговый проект, помимо использования техники написания менеджера ресурса (но, собственно, благодаря ей и архитектуре QNX), демонстрирует ещё две очень интересных особенности:
 На рис.5 показано построенное в PhAB (Photon Aplication Builder) изображение, и именования элементов клиентского приложения. Это приложение позволяет пользователю выбирать сетевые хосты (из списка доступных в сети) и порождать новые соединения (сеансы). Кратко, в мере, необходимой для понимания исходного кода, рассмотрим порядок совместной работы приложений (и подготовленного ранее менеджера ресурса, и рассматриваемого клиентского приложения), полный текст работающего PhAB проекта может быть взят на myrm.tgz :
Код: (C++) // Фактический старт приложеня - выполняется по открытию главного окна int OnBaseWindow( PtWidget_t *widget, ApInfo_t *apinfo, PtCallbackInfo_t *cbinfo ) { char sTitle[ 80 ]; strcpy( sTitle, "QNET talk-connector, " ); strcat( sTitle, sVers ); PtSetResource( ABW_base, Pt_ARG_WINDOW_TITLE, sTitle, 0 ); // создание списка QNET-хостов if( CreateNetList() <= 0 ) FatalExit( "QNET not found" ); PtListSelectPos( ABW_base_host, 1 ); ShowSelectedHost( 1 ); return( Pt_CONTINUE ); };
Код: (C++) // заполнение списка (панели) доступных QNET-хостов // ( имён хостов в локальном каталоге /net/... ), // возвращаемое значение - число хостов, // видимых в QNET сети ( <=0 - недоступно! ). static int CreateNetList( void ) { DIR *dir; struct dirent *dent; char* newname = new char[ NAME_MAX + 1 ]; int n = 0; PtListDeleteAllItems( ABW_base_host ); if( ( dir = opendir( "/net" ) ) == NULL ) return( -1 ); for( n = 0; dent = readdir( dir ); n++ ) { sprintf( newname, "%s", dent->d_name ); PtListAddItems( ABW_base_host, (const char**)&newname, 1, 0 ); }; delete newname; closedir( dir ); return n; }; //-------------------------------------------------------------------------- // имя выбранного хоста: static char *sHost = new char[ PATH_MAX + 1 ]; //-------------------------------------------------------------------------- // копирование имени выбранного хоста в отдельную позицию на экране static void ShowSelectedHost( int n ) { PtArg_t args[ 1 ]; short *num; char **items = NULL; PtSetArg( &args[ 0 ], Pt_ARG_ITEMS, &items, &num ); PtGetResources( ABW_base_host, 1, args ); strcpy( sHost, items[ --n ] ); PtSetResource( ABW_base_select, Pt_ARG_TEXT_STRING, sHost, 0 ); };
Код: (C++) // создание канала к выбранному хосту int OnConnect( PtWidget_t *link_instance, ApInfo_t *apinfo, PtCallbackInfo_t *cbinfo ) { if( !CreateLine( sHost ) ) FatalExit( "Невозможно установить соединение", false ); return( Pt_CONTINUE ); }; Конструктор Line запрашивает по open() двух менеджеров ресурсов (локальный и удалённый), которые создают для него 2 диалоговых окна обмена (возможно, на разных компьютерах). Получив от менеджеров ресурсов два файловых дескриптора (в ответ на open()), конструктор Line запускает отдельный поток (функция Exchanger() файла Line.cpp) взаимного обмена (синхронизации) окон c интервалом в 1 сек. Код: (C++) // Обновление списка доступных хостов по таймеру int OnTick( PtWidget_t *widget, ApInfo_t *apinfo, PtCallbackInfo_t *cbinfo ) { CreateNetList(); int n = PtListItemPos( ABW_base_host, sHost ); if( n == 0 ) n = 1; PtListSelectPos( ABW_base_host, n ); ShowSelectedHost( n ); return( Pt_CONTINUE ); }; //-------------------------------------------------------------------------- // фиксация и отображение выбранного в диалоге хоста int OnSelectHost( PtWidget_t *widget, ApInfo_t *apinfo, PtCallbackInfo_t *cbinfo ) { ShowSelectedHost( ( (PtListCallback_t*)cbinfo->cbdata )->item_pos ); return( Pt_CONTINUE ); }; Клиент при этом выполняет только группу POSIX операций read() -> write().
Код: (C++) static void* Exchanger( void* ); //-------------------------------------------------------------------------- class Line { private: static const int nbuf = 1024; int df, dt, hdf, hdt, tid; public: Line( char* ); ~Line( void ); bool OK( void ) { return ( ( hdf > 0 ) && ( hdt > 0 ) ); }; int Dscr( bool bDir ) { return bDir ? hdf : hdt; }; bool Exchange( void ); }; //-------------------------------------------------------------------------- // Поток обновления (инициирующий передачу по каналу) static void* Exchanger( void* p ) { Line *L = (Line*)p; while( true ) { if( ! L->Exchange() ) break; sleep( 1 ); // выдержка интервала взаимо обмена }; delete L; return NULL; }; //-------------------------------------------------------------------------- Line::Line( char *sH ) { char sRem[ PATH_MAX + NAME_MAX + 1 ]; strcpy( sRem, sResName ); int df = open( sRem, O_RDWR ); hdf = df; strcpy( sRem, "/net/" ); strcat( sRem, sH ); strcat( sRem, "/" ); strcat( sRem, sResName ); int dt = open( sRem, O_RDWR ); hdt = dt; tid = -1; int ph[ 2 ] = { hdf, hdt }; tid = ThreadCreate( 0, &Exchanger, (void*)this, NULL ); }; //-------------------------------------------------------------------------- Line::~Line( void ) { int h; close( h = hdf ); close( h = hdt ); }; //-------------------------------------------------------------------------- bool Line::Exchange( void ) { int h, n; char buf[ nbuf ]; n = read( h = hdf, buf, sizeof( buf ) ); if( strcmp( buf, sEof ) == 0 ) return false; if( strlen( buf ) != 0 ) write( h = hdt, buf, strlen( buf ) + 1 ); n = read( h = hdt, buf, sizeof( buf ) ); if( strcmp( buf, sEof ) == 0 ) return false; if( strlen( buf ) != 0 ) write( h = hdf, buf, strlen( buf ) + 1 ); return true; }; //-------------------------------------------------------------------------- // Создание новой линии связи от локального хоста к хосту sHost bool CreateLine( char* sHost ) { Line* pL = new Line( sHost ); if( !pL->OK() ) delete pL; return pL->OK(); }; Обратите внимание, что "внаружу" этого файла реализации видна только одна функция - CreateLine, которая всего лишь и объявлена в Line.h, и используется клиентом для создания коммуникационного канала. Вся остальная работа выполняется менеджером ресурса (драйвером), причём для любого числа клиентских сеансов (каждому сеансу соответствует одна пара однозначно связанных клиентских окон). Примечания к исходным кодам: в исходных кодах есть 2 места, которые могут внести невнятицу в картину происходящего. Они оставлены ввиду своей малой значимости и недостатка времени (AS IS). Ниже они объясняются детально:
Выводы и направления развития. Самый интересный вывод из проделанной работы состоит в том, что написание даже самых традиционных и не "подходящих" приложений в технике менеджера ресурса по своей трудоёмкости в несколько раз ниже традиционного ручного программирования. Обладая ранее некоторым опытом создания подобных приложений для Win32 и Linux, я предполагаю, что "ручная" реализация приложения, аналогичного описанному, была бы в 5-8 раз объёмнее приведенной. (Правда, в приведенном тексте каждый оператор "плотнее" и критичнее к ошибкам). Можно предложить и некоторые последующие улучшения предложенной схемы взаимодействия: в текущей реализации синхронизация содержимого окон сделана по таймеру. Это решение оставлено в какой то мере сознательно - при изучении работы проекта очень наглядно видеть моменты синхронизации. Более развитое решение должно предполагать асинхронную реализацию операции read() в менеджере ресурса (текущая реализация - синхронная, но в технике менеджеров ресурса ничто не препятствует реализации асинхронных операций). При этом из класса Line будет исключена необходимость отдельного потока синхронизации окон. Источники дополнительной информации: [1] - "Writing Resource Manager" в HELP подсистеме операционной системы QNX RTP 6.1. [2] - Олег Цилюрик, "Визуальные инкапсулированные компоненты в Photon QNX", журнал "Программист", М.:, 5, 2002. |
| начало | почта | статьи | файлы | ссылки | сайты | RSS | о нас | опубликовать | оформление | авторы | друзья | реклама |