Системное программирование в среде Windows

Харт Джонсон М.

11.3. Усовершенствуйте сервер таким образом, чтобы имя его канала задавалось в виде аргумента в командной строке. Организуйте несколько серверных процессов с различными именами каналов, используя программу управления заданиями из главы 6. Убедитесь в том, что одновременно несколько клиентов получают доступ к этой многопроцессной серверной системе.

11.4. Запустите клиент и сервер на различных системах, чтобы проверить их работу в условиях сети. Измените программу SrvrBcst (программа 11.4) таким образом, чтобы она включала имя компьютера сервера в имя канала. Кроме того, видоизмените имя почтового ящика, используемого в программе 11.4.

11.5. Модифицируйте сервер таким образом, чтобы

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

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

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

11.8. Программа serverNP спроектирована таким образом, что она выполняется как сервер в течение неопределенного времени, давая клиентам возможность подключаться, получать услуги и разрывать соединение. Очень важно, чтобы при отключении клиента сервер освобождал все соответствующие ресурсы, например, память, дескрипторы файлов или потоков. Если это не делается, то в результате утечки ресурсов системные ресурсы, в конце концов, исчерпаются, что приведет аварийному завершению работы сервера с возможным предшествующим ухудшением показателей производительности. Тщательно проверьте код программы serverNP, чтобы убедиться в отсутствии утечки ресурсов, и в случае необходимости внесите необходимые исправления. (Просьба информировать автора обо всех обнаруженных ошибках, используя указанный в предисловии адрес электронной почты.) Примечание. Утечка ресурсов является весьма распространенным серьезным дефектом многих промышленных систем. Никакие попытки вывода изделия на уровень "промышленных стандартов" нельзя считать успешными, если указанной проблеме не было уделено должного внимания.

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

ГЛАВА 12

Сетевое программирование с помощью сокетов Windows

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

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

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

Возможность взаимодействия с другими системами обеспечивается в Windows поддержкой сокетов (sockets) Windows Sockets — совместимого и почти точного аналога сокетов Berkeley Sockets, де-факто играющих роль промышленного стандарта. В этой главе использование API Windows Sockets (или "Winsock") показано на примере модифицированной клиент-серверной системы из главы 11. Результирующая система способна функционировать в глобальных сетях, использующих протокол TCP/IP, что, например, позволяет серверу принимать запросы от клиентов UNIX или каких-либо других, отличных от Windows систем.

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

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

В данной главе указанная клиент-серверная система используется в качестве механизма демонстрации интерфейса Winsock, и в процессе того, как сервер будет модифицироваться, в него будут добавляться новые интересные возможности. В частности, нами будут впервые использованы точки входа DLL (глава 5) и внутрипроцессные серверы DLL. (Эти новые средства можно было включить уже в первоначальную версию программы в главе 11, однако это отвлекло бы ваше внимание от разработки основной архитектуры системы.) Наконец, дополнительные примеры покажут вам, как создаются безопасные реентерабельные многопоточные библиотеки.

Поскольку интерфейс Winsock должен соответствовать промышленным стандартам, принятые в нем соглашения о правилах присвоения имен и стилях программирования несколько отличаются от тех, с которыми мы сталкивались в процессе работы с описанными ранее функциями Windows. Строго говоря, Winsock API не является частью Win32/64. Кроме того, Winsock предоставляет дополнительные функции, не подчиняющиеся стандартам; эти функции используются лишь в случае крайней необходимости. Среди других преимуществ, обеспечиваемых Winsock, следует отметить улучшенную переносимость результирующих программ на другие системы.

Сокеты Windows

Winsock API разрабатывался как расширение Berkley Sockets API для среды Windows и поэтому поддерживается всеми системами Windows. К преимуществам Winsock можно отнести следующее:

• Перенос уже имеющегося кода, написанного для Berkeley Sockets API, осуществляется непосредственно.

• Системы Windows легко встраиваются в сети, использующие как версию IPv4 протокола TCP/IP, так и постепенно распространяющуюся версию IPv6. Помимо всего остального, версия IPv6 допускает использование более длинных IP-адресов, преодолевая существующий 4-байтовый адресный барьер версии IPv4.