Валерий Борисок - Delphi. Трюки и эффекты

end;

Процедура ReleaseFileMapping, симметричная по своему назначению функции GetFileMapping, реализована так, как показано в листинге 10.24.

Листинг 10.24.

Освобождение проекции файла

procedure ReleaseFileMapping();

begin

UnmapViewOfFile(hook_info);

hook_info := nil;

CloseHandle(hFile);

hFile := 0;

end;

Функция GetFileMapping и процедура ReleaseFileMapping используют дополнительно глобальную переменную hFile (тип THandle), объявленную в модуле HookData.

Наконец пришла очередь функции-ловушки. Ее реализация приведена в листинге 10.25.

Листинг 10.25.

Функция-ловушка

function WndProcHook(code: Integer; wparam: WPARAM;

lparam: LPARAM): LRESULT stdcall;

var

hook_data: ^TCWPStruct;

begin

//Получим доступ к проекции файла

if not GetFileMapping() then

begin

//Не удалось получить доступ к проекции файла. Ценой потери

//сообщений не дадим возникнуть ошибкам доступа к памяти

WndProcHook := 0;

Exit;

end;

if code < 0 then

begin

WndProcHook := CallNextHookEx(hook_info^.hook_handle, code,

wParam, lParam);

//Освободим проекцию файла

ReleaseFileMapping();

Exit;

end;

//Можно обрабатывать сообщение

hook_data := Pointer(lParam);

//Обрабатываем только сообщения нужного окна

if hook_data^.hwnd = hook_info^.wnd then

begin

//Заполняем поля структуры в общей области памяти и посылаем

//сообщение окну-шпиону

hook_info^.mess := hook_data^.message;

hook_info^.wParam := hook_data^.wParam;

hook_info^.lParam := hook_data^.lParam;

PostMessage(hook_info^.spy_wnd, WM_SPY_NOTIFY, 0, 0);

end;

//Передаем сообщение для дальнейшей обработки

WndProcHook := CallNextHookEx(hook_info^.hook_handle, code,

wParam, lParam);

//Освободим проекцию файла

ReleaseFileMapping();

end;

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

Дело в том, что загрузка DLL в адресное пространство другого процесса отличается от штатной загрузки библиотеки, например, при помощи функции LoadLibrary: не вызывается код инициализации. Следовательно, мы не можем, например, обнулить указатель hookinf о или установить еще какой-либо признак того, была ли открыта проекция файла. Велика вероятность того, что без отсутствия ручной инициализации указатель hookinf о не будет равен нулю. Как тогда определить, связан ли этот указатель с областью памяти, куда спроецирован файл?

Можно было бы, конечно, завести 64-битную или более переменную, которой присваивалось бы «магическое» число при первой инициализации указателя hookinf о. Но в таком случае работоспособность нашей программы носила бы вероятностный характер.

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

Глава 11 Сетевое взаимодействие

• Краткое описание сетевых компонентов

• Простой обмен данными

• Слежение за компьютером по сети

• Многопользовательский разговорник

Организация надежного сетевого взаимодействия между приложениями или компонентами одного приложения зачастую является задачей довольно сложной даже для программиста со значительным опытом работы. Это правда, если пытаться самостоятельно использовать API сетевого взаимодействия, предоставляемый операционной системой (в нашем случае – Windows). Однако с использованием компонентов Delphi, в которых уже реализованы рутинные операции по созданию соединений, пересылке данных, контролю ошибок и т. д., программирование сетевых приложений становится не только простым, но и увлекательным занятием. В данной главе мы рассмотрим несколько примеров создания несложных сетевых приложений, построенных с использованием архитектуры «клиент – сервер».

11.1. Краткое описание сетевых компонентов

В Delphi 7 количество компонентов для программирования самых различных сетевых приложений просто радует глаз (см. вкладки IndyQients и IndyServers). Мы рассмотрим построение приложения на базе только IdTCPServer и IdTCPCLient (написание клиент-серверных приложений с использованием всех сетевых компонентов могло бы занять всю книгу).

Итак, сначала о компоненте сервера IdTCPServer. Для использования возможностей сервера этот компонент нужно поместить на форму (компонент неотображаемый). При настройке компонента полезными являются следующие его свойства:

• Active – активизирует или деактивизирует сервер (по умолчанию False);

• Bindings – настраивает серверные сокеты (присоединяет их к определенному порту компьютера, позволяет задавать диапазон IP-адресов и портов клиентов) при помощи диалогового окна Binding Editor;

• ListenQueue – численное значение, ограничивающее максимальное количество запросов на установление соединения от клиентов в очереди;

• MaxConnections – позволяет ограничить максимальное количество клиентов, присоединенных к серверу;

• MaxConnectionReply – позволяет настроить сообщение, посылаемое сервером новым клиентам, когда их количество достигает MaxConnections.

Рассмотрим несколько подробнее настройку серверных гнезд с использованием свойства Bindings. Так, на рис. 11.1 показано, как при помощи диалогового окна Binding Editor настроить сервер на обслуживание клиентов с любыми IP-адресами, при этом серверный сокет присоединяется к порту 12340.

Рис. 11.1. Использование окна Binding Editor

Для более детальной настройки каждого серверного сокета можно использовать окна Object TreeView и Object Inspector так, как показано на рис. 11.2.

На этом настройку сервера можно и завершить (хотя здесь используются далеко не все возможности компонента IdTCPServer). Основная же работа сервера при обработке запросов клиентов может реализоваться в обработчике события OnExecute. В этот обработчик передается ссылка на o6beKTTIdPeerThread – поток, ассоциированный с клиентом, присоединенным к серверу. Посредством этого объекта (а точнее, его свойства Connection) можно получать и отправлять данные, а также получать и устанавливать множество полезных параметров соединения. Первый пример использования объекта TIdPeerThread при обработке запроса клиента приведен в листинге 11.1.

Теперь рассмотрим, как сконфигурировать клиент (IdTCPQient), чтобы он был способен взаимодействовать с нашим сервером. Чтобы использовать компонент ТСР-клиента, достаточно поместить его на форму (компонент также неотображаемый).

После этого как минимум нужно настроить следующие его свойства (остальные упоминаются по мере необходимости в приведенных далее примерах):

• Host – имя или IP-адрес компьютера, на котором запущен сервер;

• Port – номер порта, к которому присоединен серверный сокет.

11.2. Простой обмен данными

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

• Клиентское приложение соединяется с сервером и отправляет ему введенную пользователем строку, ждет ответа, выводит полученный от сервера текст, отсоединяется от сервера.

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

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

Рис. 11.3. Внешний вид простого сервера

Текстовое поле (Edit) с количеством обработанных запросов имеет имя txtCount, а текстовое поле с адресом последнего обслуженного компьютера названо txtFrom. Вся работа сервера заключается в обработке события Execute для компонента IdTCPServer, помещенного на форму (присоедините этот компонент к порту 12340 и установите значение свойства Active = True) (листинг 11.1).

Листинг 11.1. Реализация простого сервера

procedure TForm1.IdTCPServer1Execute(AThread: TIdPeerThread);

var

strText: string;

begin

//Принимаем от клиента строку

strText := AThread.Connection.ReadLn;

//Отвечаем

AThread.Connection.WriteLn('Принял строку:' + strText);

//Обновим сведения на форме сервера (сервер многопоточный,

//поэтому используем синхронизацию)

section.Enter;

Inc(processed,1);

txtCount.Text := IntToStr(processed);

txtFrom.Text := AThread.Connection.Socket.Binding.PeerIP;

section.Leave;

//Закрываем соединение с пользователем

AThread.Connection.Disconnect;

end;

procedure TForm1.FormCreate(Sender: TObject);

begin

section := TCriticalSection.Create;

end;

При ответе клиенту сервер только повторяет принятую от него строку с добавлением текста Принял: в начало строки.

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