Сокеты беркли c. Как программировать с использованием сокетов? Пример: подключение клиента к серверу
Именованные каналы пригодны для организации межпроцессного взаимодействия как в случае процессов, выполняющихся на одной и той же системе, так и в случае процессов, выполняющихся на компьютерах, связанных друг с другом локальной или глобальной сетью. Эти возможности были продемонстрированы на примере клиент-серверной системы, разработанной в главе 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.
Сокеты могут использоваться совместно с перекрывающимся вводом/выводом Windows (глава 14), что, помимо всего прочего, обеспечивает возможность масштабирования серверов при увеличении количества активных клиентов.
Сокеты можно рассматривать как дескрипторы (типа HANDLE) файлов при использовании функций ReadFile и WriteFile и, с некоторыми ограничениями, при использовании других функций, точно так же, как в качестве дескрипторов файлов сокеты применяются в UNIX. Эта возможность оказывается удобной в тех случаях, когда требуется использование асинхронного ввода/вывода и портов завершения ввода/вывода.
Существуют также дополнительные, непереносимые расширения.
Инициализация Winsock
Winsock API поддерживается библиотекой DLL (WS2_32.DLL), для получения доступа к которой следует подключить к программе библиотеку WS_232.LIB. Эту DLL следует инициализировать с помощью нестандартной, специфической для Winsock функции WSAStartup, которая должна быть первой из функций Winsock, вызываемых программой. Когда необходимость в использовании функциональных возможностей Winsock отпадает, следует вызывать функцию WSACleanup. Примечание. Префикс WSA означает "Windows Sockets asynchronous …" ("Асинхронный Windows Sockets …"). Средства асинхронного режима Winsock нами здесь не используются, поскольку при возникновении необходимости в выполнении асинхронных операций мы можем и будем использовать потоки.
Хотя функции WSAStartup и WSACleanup необходимо вызывать в обязательном порядке, вполне возможно, что они будут единственными нестандартными функциями, с которыми вам придется иметь дело. Распространенной практикой является применение директив препроцессора #ifdef для проверки значения символической константы _WIN32 (обычно определяется Visual C++ на стадии компиляции), в результате чего функции WSA будут вызываться только тогда, когда вы работаете в Windows). Разумеется, такой подход предполагает, что остальная часть кода не зависит от платформы.
Параметрыint WSAStartup(WORD wVersionRequired, LPWSADATA ipWSAData);
wVersionRequired - указывает старший номер версии библиотеки DLL, который вам требуется и который вы можете использовать. Как правило, версии 1.1 вполне достаточно для того, чтобы обеспечить любое взаимодействие с другими системами, в котором у вас может возникнуть необходимость. Тем не менее, во всех системах Windows, включая Windows 9x, доступна версия Winsock 2.0, которая и используется в приведенных ниже примерах. Версия 1.1 считается устаревшей и постепенно выходит из употребления.
Функция возвращает ненулевое значение, если запрошенная вами версия данной DLL не поддерживается.
Младший байт параметра wVersionRequired указывает основной номер версии, а старший байт - дополнительный. Обычно используют макрос MAKEWORD; таким образом, выражение MAKEWORD (2,0) представляет версию 2.0.
ipWSAData - указатель на структуру WSADATA, которая возвращает информацию о конфигурации DLL, включая старший доступный номер версии. О том, как интерпретировать ее содержимое, вы можете прочитать в материалах оперативной справки Visual Studio.
Чтобы получить более подробную информацию об ошибках, можно воспользоваться функцией WSAGetLastError, но для этой цели подходит также функция GetLastError, а также функция ReportError, разработанная в главе 2.
По окончании работы программы, а также в тех случаях, когда необходимости в использовании сокетов больше нет, следует вызывать функцию WSACleanup, чтобы библиотека WS_32.DLL, обслуживающая сокеты, могла освободить ресурсы, распределенные для этого процесса.
Создание сокета
Инициализировав Winsock DLL, вы можете использовать стандартные (Berkeley Sockets) функции для создания сокетов и соединений, обеспечивающих взаимодействие серверов с клиентами или взаимодействие равноправных узлов сети между собой.
Используемый в Winsock тип данных SOCKET аналогичен типу данных HANDLE в Windows, и его даже можно применять совместно с функцией ReadFile и другими функциями Windows, требующими использования дескрипторов типа HANDLE. Для создания (или открытия) сокета служит функция socket.
ПараметрыSOCKET socket(int af, int type, int protocol);
Тип данных SOCKET фактически определяется как тип данных int, потому код UNIX остается переносимым, не требуя привлечения типов данных Windows.
af - обозначает семейство адресов, или протокол; для указания протокола IP (компонент протокола TCP/IP, отвечающий за протокол Internet) следует использовать значение PF_INET (или AF_INET, которое имеет то же самое числовое значение, но обычно используется при вызове функции bind).
type - указывает тип взаимодействия: ориентированное на установку соединения (connection-oriented communication), или потоковое (SOCK_STREAM), и дейтаграммное (datagram communication) (SOCK_DGRAM), что в определенной степени сопоставимо соответственно с именованными каналами и почтовыми ящиками.
protocol - является излишним, если параметр af установлен равным AF_INET; используйте значение 0.
В случае неудачного завершения функция socket возвращает значение INVALID_SOCKET.
Winsock можно использовать совместно с протоколами, отличными от TCP/IP, указывая различные значения параметра protocol; мы же будем использовать только протокол TCP/IP.
Как и в случае всех остальных стандартных функций, имя функции socket не должно содержать прописных букв. Это является отходом от соглашений, принятых в Windows, и продиктовано необходимостью соблюдения промышленных стандартов.
Серверные функции сокета
В нижеследующем обсуждении под сервером будет пониматься процесс, который принимает запросы на образование соединения через заданный порт. Несмотря на то что сокеты, подобно именованным каналам, могут использоваться для создания соединений между равноправными узлами сети, введение указанного различия между узлами является весьма удобным и отражает различия в способах, используемых обеими системами для соединения друг с другом.
Если не оговорено иное, типом сокетов в наших примерах всегда будет SOCK_STREAM. Сокеты типа SOCK_DGRAM рассматривается далее в этой главе.
Связывание сокета
Следующий шаг заключается в привязке сокета к его адресу и конечной точке (endpoint) (направление канала связи от приложения к службе). Вызов socket, за которым следует вызов bind, аналогичен созданию именованного канала. Однако не существует имен, используя которые можно было бы различать сокеты данного компьютера. Вместо этого в качестве конечной точки службы используется номер порта (port number). Любой заданный сервер может иметь несколько конечных точек. Прототип функции bind приводится ниже.
Параметрыint bind(SOCKET s, const struct sockaddr *saddr, int namelen);
s - несвязанный сокет, возвращенный функцией socket.
saddr - заполняется перед вызовом и задает протокол и специфическую для протокола информацию, как описано ниже. Кроме всего прочего, в этой структуре содержится номер порта.
namelen - присвойте значение sizeof (sockaddr).
В случае успешного выполнения функция возвращает значение 0, иначе SOCKET_ERROR. Структура sockaddr определяется следующим образом:
typedef struct sockaddr SOCKADDR, *PSOCKADDR;
Первый член этой структуры, sa_family, обозначает протокол. Второй член, sa_data, зависит от протокола. Internet-версией структуры sa_data является структура sockaddr_in:
short sin_family; /* AF_INET */struct in_addr sin_addr; /* 4-байтовый IP-адрес */typedef struct sockaddr_in SOCKADDR_IN, *PSOCKADDR IN;
Обратите внимание на использование типа данных short integer для номера порта. Кроме того, номер порта и иная информация должны храниться с соблюдением подходящего порядка следования байтов, при котором старший байт помещается в крайней позиции справа (big-endian), чтобы обеспечивалась двоичная совместимость с другими системами. В структуре sin_addr содержится подструктура s_addr, заполняемая уже знакомым нам 4-байтовым IP-адресом, например 127.0.0.1, указывающим систему, чей запрос на образование соединения должен быть принят. Обычно удовлетворяются запросы любых систем, в связи с чем следует использовать значение INADDR_ANY, хотя этот символический параметр должен быть преобразован к корректному формату, как показано в приведенном ниже фрагменте кода.
Для преобразования текстовой строки с IP-адресом к требуемому формату можно использовать функцию inet_addr, поэтому член sin_addr.s_addr переменной sockaddr_in инициализируется следующим образом:
sa.sin_addr.s_addr = inet_addr("192 .13.12.1");
О связанном сокете, для которого определены протокол, номер порта и IP-адрес, иногда говорят как об именованном сокете (named socket).
Перевод связанного сокета в состояние прослушивания
Функция listen делает сервер доступным для образования соединения с клиентом. Аналогичной функции для именованных каналов не существует.
int listen(SOCKET s, int nQueueSize);
Параметр nQueueSize указывает число запросов на соединение, которые вы намерены помещать в очередь сокета. В версии Winsock 2.0 значение этого параметра не имеет ограничения сверху, но в версии 1.1 оно ограничено предельным значением SOMAXCON (равным 5).
Прием клиентских запросов соединения
Наконец, сервер может ожидать соединения с клиентом, используя функцию accept, возвращающую новый подключенный сокет, который будет использоваться в операциях ввода/вывода. Заметьте, что исходный сокет, который теперь находится в состоянии прослушивания (listening state), используется исключительно в качестве параметра функции accept, а не для непосредственного участия в операциях ввода/вывода.
Функция accept блокируется до тех пор, пока от клиента не поступит запрос соединения, после чего она возвращает новый сокет ввода/вывода. Хотя рассмотрение этого и выходит за рамки данной книги, возможно создание неблокирующихся сокетов, а в сервере (программа 12.2) для приема запроса используется отдельный поток, что позволяет создавать также неблокирующиеся серверы.
ПараметрыSOCKET accept(SOCKET s, LPSOCKADDR lpAddr, LPINT lpAddrLen);
s - прослушивающий сокет. Чтобы перевести сокет в состояние прослушивания, необходимо предварительно вызвать функции socket, bind и listen.
lpAddr - указатель на структуру sockaddr_in, предоставляющую адрес клиентской системы.
lpAddrLen - указатель на переменную, которая будет содержать размер возвращенной структуры sockaddr_in. Перед вызовом функции accept эта переменная должна быть инициализирована значением sizeof(struct sockaddr_in).
Отключение и закрытие сокетов
Для отключения сокетов применяется функция shutdown(s, how). Аргумент how может принимать одно из двух значений: 1, указывающее на то, что соединение может быть разорвано только для посылки сообщений, и 2, соответствующее разрыву соединения как для посылки, так и для приема сообщений. Функция shutdown не освобождает ресурсы, связанные с сокетом, но гарантирует завершение посылки и приема всех данных до закрытия сокета. Тем не менее, после вызова функции shutdown приложение уже не должно использовать этот сокет.
Когда работа с сокетом закончена, его следует закрыть, вызвав функцию closesocket(SOCKET s). Сначала сервер закрывает сокет, созданный функцией accept, а не прослушивающий сокет, созданный с помощью функции socket. Сервер должен закрывать прослушивающий сокет только тогда, когда завершает работу или прекращает принимать клиентские запросы соединения. Даже если вы работаете с сокетом как с дескриптором типа HANDLE и используете функции ReadFile и WriteFile, уничтожить сокет одним только вызовом функции CloseHandle вам не удастся; для этого следует использовать функцию closesocket.
Пример: подготовка и получение клиентских запросов соединения
Ниже приводится фрагмент кода, показывающий, как создать сокет и организовать прием клиентских запросов соединения.
В этом примере используются две стандартные функции: htons ("host to network short" - "ближняя связь") и htonl ("host to network long" - "дальняя связь"), которые преобразуют целые числа к форме с обратным порядком байтов, требуемой протоколом IP.
Номером порта сервера может быть любое число из диапазона, допустимого для целых чисел типа short integer, но для определенных пользователем служб обычно используются числа в диапазоне 1025-5000. Порты с меньшими номерами зарезервированы для таких известных служб, как telnet или ftp, в то время как порты с большими номерами предполагаются для использования других стандартных служб.
struct sockaddr_in SrvSAddr; /* Адресная структура сервера. */
struct sockaddr_in ConnectAddr;
AddrLen = sizeof(ConnectAddr);
sockio = accept(SrvSock, (struct sockaddr *) &ConnectAddr, &AddrLen);
… Получение запросов и отправка ответов …
Клиентские функции сокета
Клиентская станция, которая желает установить соединение с сервером, также должна создать сокет, вызвав функцию socket. Следующий шаг заключается в установке соединения сервером, а, кроме того, необходимо указать номер порта, адрес хоста и другую информацию. Имеется только одна дополнительная функция – connect.
Установление клиентского соединения с сервером
Если имеется сервер с сокетом в режиме прослушивания, клиент может соединиться с ним при помощи функции connect.
Параметрыint connect(SOCKET s, LPSOCKADDR lpName, int nNameLen);
s - сокет, созданный с использованием функции socket.
lpName - указатель на структуру sockaddr_in, инициализированную значениями номера порта и IP-адреса системы с сокетом, связанным с указанным портом, который находится в состоянии прослушивания.
Инициализируйте nNameLen значением sizeof (struct sockaddr_in).
Возвращаемое значение 0 указывает на успешное завершение функции, тогда как значение SOCKET_ERROR указывает на ошибку, которая, в частности, может быть обусловлена отсутствием прослушивающего сокета по указанному адресу.
Сокет s не обязательно должен быть связанным с портом до вызова функции connect, хотя это и может иметь место. При необходимости система распределяет порт и определяет протокол.
Пример: подключение клиента к серверу
Показанный ниже фрагмент кода обеспечивает соединение клиента с сервером. Для этого нужны только два вызова функций, но адресная структура должна быть инициализирована до вызова функции connect. Проверка возможных ошибок здесь отсутствует, но в реальные программы она должна включаться. В примере предполагается, что IP-адрес (текстовая строка наподобие "192.76.33.4") задается в аргументе argv командной строки.
ClientSAddr.sin_addr.s_addr = inet_addr(argv);
ConVal = connect(ClientSock, (struct sockaddr *)&ClientSAddr, sizeof(ClientSAddr));
Отправка и получение данных
Программы, использующие сокеты, обмениваются данными с помощью функций send и recv, прототипы которых почти совпадают (перед указателем буфера функции send помещается модификатор const). Ниже представлен только прототип функции send.
int send(SOCKET s, const char * lpBuffer, int nBufferLen, int nFlags);
Возвращаемым значением является число фактически переданных байтов. Значение SOCKET_ERROR указывает на ошибку.
nFlags - может использоваться для обозначения степени срочности сообщений (например, экстренных сообщений), а значение MSG_PEEK позволяет просматривать получаемые данные без их считывания.
Самое главное, что вы должны запомнить - это то, что функции send и recv не являются атомарными (atomic), и поэтому нет никакой гарантии, что затребованные данные будут действительно отправлены или получены. Передача "коротких" сообщений ("short sends") встречается крайне редко, хотя и возможна, что справедливо и по отношению к приему "коротких" сообщений ("short receives"). Понятие сообщения в том смысле, который оно имело в случае именованных каналов, здесь отсутствует, и поэтому вы должны проверять возвращаемое значение и повторно отправлять или принимать данные до тех пор, пока все они не будут переданы.
С сокетами могут использоваться также функции ReadFile и WriteFile, только в этом случае при вызове функции необходимо привести сокет к типу HANDLE.
Сравнение именованных каналов и сокетов
Именованные каналы, описанные в главе 11, очень похожи на сокеты, но в способах их использования имеются значительные различия.
Именованные каналы могут быть ориентированными на работу с сообщениями, что значительно упрощает программы.
Именованные каналы требуют использования функций ReadFile и WriteFile, в то время как сокеты могут обращаться также к функциям send и recv.
В отличие от именованных каналов сокеты настолько гибки, что предоставляют пользователям возможность выбрать протокол для использования с сокетом, например, TCP или UDP. Кроме того, пользователь имеет возможность выбирать протокол на основании характера предоставляемой услуги или иных факторов.
Сокеты основаны на промышленном стандарте, что обеспечивает их совместимость с системами, отличными от Windows.
Имеются также различия в моделях программирования сервера и клиента.
Сравнение серверов именованных каналов и сокетов
Установка соединения с несколькими клиентами при использовании сокетов требует выполнения повторных вызовов функции accept. Каждый из вызовов возвращает очередной подключенный сокет. По сравнению с именованными каналами имеются следующие отличия:
В случае именованных каналов требуется, чтобы каждый экземпляр именованного канала и дескриптор типа HANDLE создавались с помощью функции CreateNamedPipe, тогда как для создания экземпляров сокетов применяется функция accept.
Допустимое количество клиентских сокетов ничем не ограничено (функция listen ограничивает лишь количество клиентов, помещаемых в очередь), в то время как количество экземпляров именованных каналов, в зависимости от того, что было указано при первом вызове функции CreateNamedPipe, может быть ограниченным.
Не существует вспомогательных функций для работы с сокетами, аналогичных функции TransactNamedPipe.
Именованные каналы не имеют портов с явно заданными номерами и различаются по именам.
В случае сервера именованных каналов получение пригодного для работы дескриптора типа HANDLE требует вызова двух функций (CreateNamedPipe и ConnectNamedPipe), тогда как сервер сокета требует вызова четырех функций (socket, bind, listen и accept).
Сравнение клиентов именованных каналов и сокетов
В случае именованных каналов необходимо последовательно вызывать функции WaitNamedPipe и CreateFile. Если же используются сокеты, этот порядок вызовов обращается, поскольку можно считать, что функция socket создает сокет, а функция connect - блокирует.
Дополнительное отличие состоит в том, что функция connect является функцией клиента сокета, в то время как функция ConnectNamedPipe используется сервером именованного канала.
Пример: функция приема сообщений в случае сокета
Часто оказывается удобным отправлять и получать сообщения в виде единых блоков. Как было показано в главе 11, каналы позволяют это сделать. Однако в случае сокетов требуется создание заголовка, содержащего размер сообщения, за которым следует само сообщение. Для приема таких сообщений предназначена функция ReceiveMessage, которая будет использоваться в примерах. То же самое можно сказать и о функции SendMessage, предназначенной для передачи сообщений.
Обратите внимание, что сообщение принимается в виде двух частей: заголовка и содержимого. Ниже мы предполагаем, что пользовательскому типу MESSAGE соответствует 4-байтовый заголовок. Но даже для 4-байтового заголовка требуются повторные вызовы функции recv, чтобы гарантировать его полное считывание, поскольку функция recv не является атомарной.
Примечание, относящееся к Win64
В качестве типа переменных, используемых для хранения размера сообщения, выбран тип данных фиксированной точности LONG32, которого будет вполне достаточно для размещения значений параметра размера, включаемого в сообщения при взаимодействии с системами, отличными от Windows, и который годится для возможной последующей перекомпиляции программы для ее использования на платформе Win64 (см. главу 16).
DWORD ReceiveMessage (MESSAGE *pMsg, SOCKET sd) {
/* Сообщение состоит из 4-байтового поля размера сообщения, за которым следует собственно содержимое. */
/* Считать сообщение. */
/* Сначала считывается заголовок, а затем содержимое. */
nRemainRecv = 4; /* Размер поля заголовка. */
pBuffer = (LPBYTE)pMsg; /* recv может не передать все запрошенные байты. */
while (nRemainRecv > 0 && !Disconnect) {
/* Считать содержимое сообщения. */
while (nRemainRecv > 0 && !Disconnect) {
nXfer = recv(sd, pBuffer, nRemainRecv, 0);
Пример: клиент на основе сокета
Программа 12.1 представляет собой переработанный вариант клиентской программы clientNP (программа 11.2), которая использовалась в случае именованных каналов. Преобразование программы осуществляется самым непосредственным образом и требует лишь некоторых пояснений.
Вместо обнаружения сервера с помощью почтовых ящиков пользователь вводит IP-адрес сервера в командной строке. Если IP-адрес не указан, используется заданный по умолчанию адрес 127.0.0.1, соответствующий локальной системе.
Для отправки и приема сообщений применяются функции, например, ReceiveMessage, которые здесь не представлены.
Номер порта, SERVER_PORT, определен в заголовочном файле ClntSrvr.h.
Хотя код написан для выполнения под управлением Windows, единственная зависимость от Windows связана с использованием вызовов функций, имеющих префикс WSA.
Программа 12.1. clientSK: клиент на основе сокетов/* Глава 12. clientSK.с */
/* Однопоточный клиент командной строки. */
/* ВЕРСИЯ НА ОСНОВЕ WINDOWS SOCKETS. */
/* Считывает последовательность команд для пересылки серверному процессу*/
/* через соединение с сокетом. Дожидается ответа и отображает его. */
#define _NOEXCLUSIONS /* Требуется для включения определений сокета. */
#include "ClntSrvr.h" /* Определяет структуры записей запроса и ответа. */
/* Функции сообщения для обслуживания запросов и ответов. */
/* Кроме того, ReceiveResponseMessage отображает полученные сообщения. */
static DWORD SendRequestMessage(REQUEST *, SOCKET);
static DWORD ReceiveResponseMessage(RESPONSE *, SOCKET);
struct sockaddr_in ClientSAddr; /* Адрес сокета клиента. */
int _tmain(DWORD argc, LPTSTR argv) {
SOCKET ClientSock = INVALID_SOCKET;
REQUEST Request; /* См. ClntSrvr.h. */
RESPONSE Response; /* См. ClntSrvr.h. */
TCHAR PromptMsg = _T("\nВведите команду> ");
TCHAR QuitMsg = _T("$Quit");
/* Запрос: завершить работу клиента. */
TCHAR ShutMsg = _T("$ShutDownServer"); /* Остановить все потоки. */
CHAR DefaultIPAddr = "127.0.0.1"; /* Локальная система. */
/* Подключиться к серверу. */
/* Следовать стандартной процедуре вызова последовательности функций socket/connect клиентом. */
ClientSock = socket(AF_INET, SOCK_STREAM, 0);
memset(&ClientSAddr, 0, sizeof(ClientSAddr));
ClientSAddr.sin_family = AF_INET;
if (argc >= 2) ClientSAddr.sin_addr.s_addr = inet_addr(argv );
else ClientSAddr.sin_addr.s_addr = inet_addr(DefaultIPAddr);
ClientSAddr.sin_port = htons(SERVER_PORT);
/* Номер порта определен равным 1070. */
connect(ClientSock, (struct sockaddr *)&ClientSAddr, sizeof(ClientSAddr));
/* Основной цикл для вывода приглашения на ввод команд, посылки запроса и получения ответа. */
_tprintf(_T("%s"), PromptMsg);
/* Ввод в формате обобщенных строк, но команда серверу должна указываться в формате ASCII. */
_fgetts(Req, MAX_RQRS_LEN-1, stdin);
for (j = 0; j <= _tcslen(Req) Request.Record[j] = Req[j];
/* Избавиться от символа новой строки в конце строки. */
Request.Record = "\0";
if (strcmp(Request.Record, QuitMsg) == 0 || strcmp(Request.Record, ShutMsg) == 0) Quit = TRUE;
SendRequestMessage(&Request, ClientSock);
ReceiveResponseMessage(&Response, ClientSock);
shutdown(ClientSock, 2); /* Запретить посылку и прием сообщений. */
_tprintf(_T("\n****Выход из клиентской программы\n"));
Пример: усовершенствованный сервер на основе сокетов
Программа serverSK (программа 12.2) аналогична программе serverNP (программа 11.3), являясь ее видоизмененным и усовершенствованным вариантом.
В усовершенствованном варианте программы серверные потоки создаются по требованию (on demand), а не в виде пула потоков фиксированного размера. Каждый раз, когда сервер принимает запрос клиента на соединение, создается серверный рабочий поток, и когда клиент прекращает работу, выполнение потока завершается.
Сервер создает отдельный поток приема (accept thread), что позволяет основному потоку опрашивать глобальный флаг завершения работы, пока вызов accept остается блокированным. Хотя сокеты и могут определяться как неблокирующиеся, потоки обеспечивают удобное универсальное решение. Следует отметить, что значительная часть расширенных функциональных возможностей Winsock призвана поддерживать асинхронные операции, тогда как потоки Windows дают возможность воспользоваться более простой и близкой к стандартам функциональностью синхронного режима работы сокетов.
За счет некоторого усложнения программы усовершенствовано управление потоками, что позволило обеспечить поддержку состояний каждого потока.
Данный сервер поддерживает также внутрипроцессные серверы (in-process servers), что достигается путем загрузки библиотеки DLL во время инициализации. Имя библиотеки DLL задается в командной строке, и серверный поток сначала пытается определить точку входа этой DLL. В случае успеха серверный поток вызывает точку входа DLL; в противном случае сервер создает процесс аналогично тому, как это делалось в программе serverNP. Пример DLL приведен в программе 12.3. Поскольку генерация исключений библиотекой DLL будет приводить к уничтожению всего серверного процесса, вызов функции DLL защищен простым обработчиком исключений.
При желании можно включить внутрипроцессные серверы и в программу serverNP. Самым большим преимуществом внутрипроцессных серверов является то, что они не требуют никакого контекстного переключения на другие процессы, в результате чего производительность может заметно улучшиться.
Поскольку в коде сервера использованы специфические для Windows возможности, в частности, возможности управления потоками и некоторые другие, он, в отличие от кода клиента, оказывается привязанным к Windows.
Программа 12.2. serverSK: сервер на основе сокета с внутрипроцессными серверами/* Глава 12. Клиент-серверная система. ПРОГРАММА СЕРВЕРА. ВЕРСИЯ НА ОСНОВЕ СОКЕТА. */
/* Выполняет указанную в запросе команду и возвращает ответ. */
/* Если удается обнаружить точку входа разделяемой библиотеки, команды */
/* выполняются внутри процесса, в противном случае – вне процесса. */
/* ДОПОЛНИТЕЛЬНАЯ ВОЗМОЖНОСТЬ: argv может содержать имя библиотеки */
/* DLL, поддерживающей внутрипроцессные серверы. */
#include "ClntSrvr.h" /* Определяет структуру записей запроса и ответа. */
/* Адресная структура сокета сервера. */
struct sockaddr_in ConnectSAddr; /* Подключенный сокет. */
WSADATA WSStartData; /* Структура данных библиотеки сокета. */
typedef struct SERVER_ARG_TAG { /* Аргументы серверного потока. */
/* Пояснения содержатся в комментариях к основному потоку. */
HINSTANCE dlhandle; /* Дескриптор разделяемой библиотеки. */
volatile static ShutFlag = FALSE;
static SOCKET SrvSock, ConnectSock;
int _tmain(DWORD argc, LPCTSTR argv) {
/* Прослушивающий и подключенный сокеты сервера. */
SERVER_ARG srv_arg;
/* Инициализировать библиотеку WSA; задана версия 2.0, но будет работать и версия 1.1. */
WSAStartup(MAKEWORD(2, 0), &WSStartData);
/* Открыть динамическую библиотеку команд, если ее имя указано в командной строке. */
if (argc > 1) hDll = LoadLibrary(argv);
/* Инициализировать массив arg потока. */
for (ith = 0; ith < MAXCLIENTS; ith++) {
srv_arg.dlhandle = hDll;
/* Следовать стандартной процедуре вызова последовательности функций socket/bind/listen/accept клиентом. */
SrvSock = socket(AF_INET, SOCK_STREAM, 0);
SrvSAddr.sin_family = AF_INET;
SrvSAddr.sin_addr.s_addr = htonl(INADDR_ANY);
SrvSAddr.sin_port = htons(SERVER_PORT);
bind(SrvSock, (struct sockaddr *)&SrvSAddr, sizeof SrvSAddr);
listen(SrvSock, MAX_CLIENTS);
/* Основной поток становится потоком прослушивания/соединения/контроля.*/
/* Найти пустую ячейку в массиве arg потока сервера. */
/* параметр состояния: 0 – ячейка свободна; 1 – поток остановлен; 2 - поток выполняется; 3 – остановлена вся система. */
for (ith = 0; ith < MAX_CLIENTS && !ShutFlag;) {
if (srv_arg.status==1 || srv_arg.status==3) { /* Выполнение потока завершено либо обычным способом, либо по запросу останова. */
WaitForSingleObject(srv_arg.srv_thd INFINITE);
CloseHandle(srv_arg.srv_tnd);
if (srv_arg.status == 3) ShutFlag = TRUE;
else srv_arg.status = 0;
/* Освободить ячейку данного потока. */
if (srv_arg.status == 0 || ShutFlag) break;
ith = (ith + 1) % MAXCLIENTS;
/* Прервать цикл опроса. */
/* Альтернативный вариант: использовать событие для генерации сигнала, указывающего на освобождение ячейки. */
/* Ожидать попытки соединения через данный сокет. */
/* Отдельный поток для опроса флага завершения ShutFlag. */
hAcceptTh = (HANDLE)_beginthreadex(NULL, 0, AcceptTh, &srv_arg, 0, &ThId);
tstatus = WaitForSingleObject(hAcceptTh, CS_TIMEOUT);
if (tstatus == WAIT_OBJECT_0) break; /* Соединение установлено. */
hAcceptTh = NULL; /* Подготовиться к следующему соединению. */
_tprintf(_T("Остановка сервера. Ожидание завершения всех потоков сервера\n"));
/* Завершить принимающий поток, если он все еще выполняется. */
/* Более подробная информация об используемой логике завершения */
/* работы приведена на Web-сайте книги. */
if (hDll != NULL) FreeLibrary(hDll);
if (hAcceptTh != NULL) TerminateThread(hAcceptTh, 0);
/* Ожидать завершения всех активных потоков сервера. */
for (ith = 0; ith < MAXCLIENTS; ith++) if (srv_arg .status != 0) {
WaitForSingleObject(srv_arg.srv_thd, INFINITE);
CloseHandle(srv_arg.srv_thd);
static DWORD WINAPI AcceptTh(SERVER_ARG * pThArg) {
/* Принимающий поток, который предоставляет основному потоку возможность опроса флага завершения. Кроме того, этот поток создает серверный поток. */
AddrLen = sizeof(ConnectSAddr);
pThArg->sock = accept(SrvSock, /* Это блокирующий вызов. */
(struct sockaddr *)&ConnectSAddr, &AddrLen);
/* Новое соединение. Создать серверный поток. */
pThArg->srv_thd = (HANDLE)_beginthreadex (NULL, 0, Server, pThArg, 0, &ThId);
return 0; /* Серверный поток продолжает выполняться. */
static DWORD WINAPI Server(SERVER_ARG * pThArg)
/* Функция серверного потока. Поток создается по требованию. */
/* Каждый поток поддерживает в стеке собственные структуры данных запроса, ответа и регистрационных записей. */
/* … Стандартные объявления из serverNP опущены … */
int (*dl_addr)(char *, char *);
char *ws = " \0\t\n"; /* Пробелы. */
GetStartupInfo(&StartInfoCh);
/* Создать имя временного файла. */
sprintf(TempFile, "%s%d%s", "ServerTemp", pThArg->number, ".tmp");
while (!Done && !ShutFlag) { /* Основной командный цикл. */
Disconnect = ReceiveRequestMessage(&Request, ConnectSock);
Done = Disconnect || (strcmp(Request.Record, "$Quit") == 0) || (strcmp(Request.Record, "$ShutDownServer") == 0);
/* Остановить этот поток по получении команды "$Quit" или "$ShutDownServer". */
hTrapFile = CreateFile(TempFile, GENERIC_READ | GENERIC_WRITE, FILE_SHARE_READ | FILE_SHARE_WRITE, &TempSA, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);
/* Проверка наличия этой команды в DLL. Для упрощения команды */
/* разделяемой библиотеки имеют более высокий приоритет по сравнению */
/* с командами процесса. Прежде всего, необходимо извлечь имя команды.*/
i = strcspn(Request.Record, ws); /* Размер лексемы. */
memcpy(sys_command, Request.Record, i) ;
dl_addr = NULL; /* Будет установлен в случае успешного выполнения функции GetProcAddress. */
if (pThArg->dlhandle != NULL) {/* Проверка поддержки "внутрипроцессного" сервера. */
dl_addr = (int (*)(char *, char *))GetProcAddress(pThArg->dlhandle, sys_command);
/* Защитить серверный процесс от исключений, возникающих в DLL*/
(*dl_addr)(Request.Record, TempFile);
} __except (EXCEPTION_EXECUTE_HANDLER) {
ReportError(_T("Исключение в DLL"), 0, FALSE);
if (dl_addr == NULL) { /* Поддержка внутрипроцессного сервера отсутствует. */
/* Создать процесс для выполнения команды. */
/* … То же, что в serverNP … */
} /* Конец основного командного цикла. Получить следующую команду. */
/* Конец командного цикла. Освободить ресурсы; выйти из потока. */
_tprintf(_T("Завершение работы сервера# %d\n"), pThArg->number);
if (strcmp(Request.Record, "$ShutDownServer") == 0) {
Замечания по поводу безопасности
В том виде, как она здесь представлена, данная клиент-серверная система не является безопасной. Если на вашей системе выполняется сервер и кому-то известен номер порта, через который вы работаете, и имя компьютера, то он может атаковать вашу систему. Другой пользователь, запустив клиентскую программу на своем компьютере, сможет выполнить на вашей системе команды, позволяющие, например, удалить или изменить файлы.
Полное обсуждение методов построения безопасных систем выходит за рамки данной книги. Тем не менее, в главе 15 показано, как обезопасить объекты Windows, а в упражнении 12.14 предлагается воспользоваться протоколом SSL.
Внутрипроцессные серверы
Как ранее уже отмечалось, основное усовершенствование программы serverSK связано с включением в нее внутрипроцессных серверов. В программе 12.3 показано, как написать библиотеку DLL, обеспечивающую услуги подобного рода. В программе представлены две уже известные вам функции - функция, осуществляющая подсчет слов, и функция toupper.
В соответствии с принятым соглашением первым параметром является командная строка, а вторым - имя выходного файла. Кроме того, следует всегда помнить о том, что функция будет выполняться в том же потоке, что и сервер, и это диктует необходимость соблюдения жестких требований относительно безопасности потоков, включая, но не ограничиваясь только этим, следующее:
Функции никоим образом не должны изменять окружение процесса. Например, если одна из функций изменит рабочий каталог, то это окажет воздействие на весь процесс.
Аналогично, функции не должны перенаправлять стандартный ввод и вывод.
Такие ошибки программирования, как выход индекса или указателя за пределы отведенного диапазона или переполнение стека, могут приводить к порче памяти, относящейся к другому потоку или самому процессу.
Утечка ресурсов, возникшая, например, в результате того, что системе не была своевременно возвращена освободившаяся память или не были закрыты дескрипторы, в конечном счете, окажет отрицательное воздействие на работу всей серверной системы.
Столь жесткие требования не предъявляются к процессам по той причине, что один процесс, как правило, не может нанести ущерб другим процессу, а после того, как процесс завершает свое выполнение, занимаемые им ресурсы автоматически освобождаются. В связи с этим служба, как правило, разрабатывается и отлаживается как поток, и лишь после того, как появится уверенность в надежности ее работы, она преобразуется в DLL.
В программе 12.3 представлена небольшая библиотека DLL, включающая две функции.
Программа 12.3. command: пример внутри процессных серверов/* Глава 12. commands.с. */
/* Команды внутрипроцессного сервера для использования в serverSK и так далее. */
/* Имеется несколько команд, реализованных в виде библиотек DLLs. */
/* Функция каждой команды принимает два параметра и обеспечивает */
/* безопасное выполнение в многопоточном режиме. Первым параметром */
/* является строка: команда arg1 arg2 … argn */
/* (то есть обычная командная строка), а вторым – имя выходного файла. … */
static void extract_token(int, char *, char *);
int wcip(char * command, char * output_file)
/* Счетчик слов; внутрипроцессный. */
/* ПРИМЕЧАНИЕ: упрощенная версия; результаты могут отличаться от тех, которые обеспечивает утилита wc. */
while ((c = fgetc(fin)) != EOF) {
/* … Стандартный код - для данного примера не является существенным … */
/* Записать результаты. */
fprintf(fout, " %9d %9d %9d %s\n", nl, nw, nc, input_file);
int toupperip(char * command, char * output_file)
/* Преобразует входные данные к верхнему регистру; выполняется внутри процесса. */
/* Вторая лексема задает входной файл (первая лексема – "toupperip"). */
extract_token(1, command, input_file);
fin = fopen(input_file, "r");
fout = fopen(output_file, "w");
while ((c = fgetc (fin)) != EOF) {
if (isalpha(c)) с = toupper(c);
static void extract_token(int it, char * command, char * token) {
/* Извлекает из "команды" лексему номер "it" (номером первой лексемы */
/* является "0"). Результат переходит в "лексему" (token) */
/* В качестве разделителей лексем используются пробелы. … */
Ориентированные на строки сообщения, точкив хода DLL и TLS
Программы serverSK и clientSK взаимодействуют между собой, обмениваясь сообщениями, каждое из которых состоит из 4-байтового заголовка, содержащего размер сообщения, и собственно содержимого. Обычной альтернативой такому подходу служат сообщения, отделяемые друг от друга символами конца строки (или перевода строки).
Трудность работы с такими сообщениями заключается в том, что длина сообщения заранее не известна, в связи с чем приходится проверять каждый поступающий символ. Однако получение по одному символу за один раз крайне неэффективно, и поэтому символы сохраняются в буфере, содержимое которого может включать один или несколько символов конца строки и составные части одного или нескольких сообщений. При этом в промежутках между вызовами функции получения сообщений необходимо поддерживать неизменным содержимое и состояние буфера. В однопоточной среде для этой цели могут быть использованы ячейки статической памяти, но совместное использование несколькими потоками одной и той же статической переменной невозможно.
В более общей формулировке, мы сталкиваемся здесь с проблемой сохранения долговременных состояний в многопоточной среде (multithreaded persistent state problem). Эта проблема возникает всякий раз, когда безопасная в отношении многопоточного выполнения функция должна поддерживать сохранение некоторой информации от одного вызова функции к другому. Такая же проблема возникает при работе с функцией strtook, входящей в стандартную библиотеку С, которая предназначена для просмотра строки для последовательного нахождения экземпляров определенной лексемы.
Решение проблемы долговременных состояний в многопоточной среде
В искомом решении сочетаются несколько компонентов:
Библиотека DLL, в которой содержатся функции, обеспечивающие отправку и прием сообщений.
Функция, представляющая точку входа в DLL.
Локальная область хранения потока (TLS, глава 7). Подключение процесса к библиотеке сопровождается созданием индекса DLL, а отключение - уничтожением. Значение индекса хранится в статическом хранилище, доступ к которому имеют все потоки.
Структура, в которой хранится буфер и его текущее состояние. Структура распределяется всякий раз, когда к библиотеке подключается новый поток, и его адрес сохраняется в записи TLS для данного потока. При отсоединении потока от библиотеки память, занимаемая его структурой, освобождается.
Таким образом, TLS играет роль статического хранилища, и у каждого потока имеется собственная уникальная копия этого хранилища.
Пример: безопасная многопоточная DLL для обмена сообщениями через сокет
Программа 12.4 представляет собой DLL, содержащую две функции для обработки символьных строк (в именах которых в данном случае присутствует "CS", от character string - строка символов), или потоковые функции сокета (socket streaming functions): SendCSMessage и ReceiveCSMessage, а также точку входа DllMain (см. главу 5). Указанные две функции играют ту же роль, что и функция ReceiveMessage, а также функции, использованные в программах 12.1 и 12.2, и фактически заменяют их.
Функция DllMain служит характерным примером решения проблемы долговременных состояний в многопоточной среде и объединяет TLS и библиотеки DLL.
Освобождать ресурсы при отсоединении потоков (случай DLL_THREAD_DETACH) особенно важно в случае серверной среды; если этого не делать, то ресурсы сервера, в конечном счете, исчерпаются, что может привести к сбоям в его работе или снижению производительности или к тому и другому одновременно.
Программа 12.4. SendReceiveSKST: безопасная многопоточная DLLПримечание
Некоторые из иллюстрируемых ниже концепций прямого отношения к сокетам не имеют, но, тем не менее, рассматриваются именно здесь, а не в предыдущих главах, поскольку данный пример предоставляет удобную возможность для иллюстрации методов создания безопасных многопоточных DLL в реалистических условиях.
Использующие эту DLL коды клиента и сервера, незначительно измененные по сравнению с программами 12.1 и 12.2, доступны на Web-сайте книги.
/* SendReceiveSKST.с - DLL многопоточного потокового сокета. */
/* В качестве разделителей сообщений используются символы конца */
/* строки ("\0"), так что размер сообщения заранее не известен. */
/* Поступающие данные буферизуются и сохраняются в промежутках между */
/* вызовами функций. */
/* Для этой цели используются локальные области хранения потоков */
/* (Thread Local Storage, TLS), обеспечивающие каждый из потоков */
/* собственным закрытым "статическим хранилищем". */
#include "ClntSrvr.h" /* Определяет записи запроса и ответа. */
/* "static_buf" содержит "static_buf_len" байтов остаточных данных. */
/* Символы конца строки (нулевые символы) могут присутствовать, а могут */
/* и не присутствовать. */
char static_buf ;
static DWORD TlsIx = 0; /* Индекс TLS – ДЛЯ КАЖДОГО ПРОЦЕССА СВОЙ ИНДЕКС.*/
/* Для однопоточной библиотеки использовались бы следующие определения:
static char static_buf ;
static LONG32 static_buf_len; */
/* Основная функция DLL. */
BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved) {
/* Для основного потока подключение отсутствует, поэтому во время подключения процесса необходимо выполнить также операции по подключению потока. */
/* Указать, что память не была распределена. */
return TRUE; /* В действительности это значение игнорируется. */
/* Отсоединить также основной поток. */
BOOL ReceiveCSMessage(REQUEST *pRequest, SOCKET sd) {
/* Возвращаемое значение TRUE указывает на ошибку или отсоединение. */
LONG32 nRemainRecv = 0, nXfer, k; /* Должны быть целыми со знаком. */
CHAR TempBuf;
p = (STATIC_BUF *)TlsGetValue(TlsIx);
if (p == NULL) { /* Инициализация при первом вызове. */
/* Распределять это хранилище будут только те потоки, которым оно */
/* необходимо. Другие типы потоков могут использовать TLS для иных целей. */
р = malloc(sizeof(STATIC_BUF));
if (p == NULL) return TRUE; /* Ошибка. */
p->static_buf_len = 0; /* Инициализировать состояние. */
/* Считать до символа новой строки, оставляя остаточные данные в статическом буфере. */
for (k = 0; k < p->static_buf_len && p->static_buf[k] != "\0"; k++) {
message[k] = p->static_buf[k];
} /* k – количество переданных символов. */
if (k < p->static_buf_len) { /* В статическом буфере обнаружен нулевой символ. */
p->static_buf_len –= (k + 1); /* Скорректировать состояние статического буфера. */
memcpy(p->static_buf, &(p->static_buf), p->static_buf_len);
return FALSE; /* Входные данные сокета не требуются. */
/* Передан весь статический буфер. Признак конца строки не обнаружен.*/
nRemainRecv = sizeof(TempBuf) – 1 – p->static_buf_len;
pBuffer = message + p->static_buf_len;
while (nRemainRecv > 0 && !Disconnect) {
nXfer = recv(sd, TempBuf, nRemainRecv, 0);
/* Передать в целевое сообщение все символы вплоть до нулевого, если таковой имеется. */
for (k =0; k < nXfer && TempBuf[k] != "\0"; k++) {
if (k >= nXfer) { /*Признак конца строки не обнаружен, читать дальше*/
} else { /* Обнаружен признак конца строки. */
memcpy(p->static_buf, &TempBuf, nXfer – k – 1);
p->static_buf_len = nXfer – k – 1;
BOOL SendCSMessage(RESPONSE *pResponse, SOCKET sd) {
/* Послать запрос серверу в сокет sd. */
nRemainSend = strlen(pBuffer) + 1;
while (nRemainSend > 0 && !Disconnect) {
/* Отправка еще не гарантирует, что будет отослано все сообщение. */
nXfer = send(sd, pBuffer, nRemainSend, 0);
fprintf(stderr, "\nОтключение сервера до посылки запроса завершения");
Создание сокета
Системный вызов socket создает сокет и возвращает дескриптор, который может применяться для доступа к сокету:
#include
#include
int socket(int domain, int type, int protocol);
Созданный сокет - это одна конечная точка линии передачи. Параметр domain задает семейство адресов, параметр type определяет тип используемого с этим сокетом обмена данными, a protocol - применяемый протокол.
В табл. 15.1 приведены имена доменов.
Таблица 15.1
К наиболее популярным доменам сокетов относятся AF_UNIX , применяемый для локальных сокетов, реализуемых средствами файловых систем UNIX и Linux, и AF_INET , используемый для сетевых сокетов UNIX. Сокеты домена AF_INET могут применяться программами, взаимодействующими в сетях на базе протоколов TCP/IP, включая Интернет. Интерфейс ОС Windows Winsock также предоставляет доступ к этому домену сокетов.
Параметр сокета type задает характеристики обмена данными, применяемые для нового сокета. Возможными значениями могут быть SOCK_STREAM и SOCK_DGRAM .
SOCK_STREAM - это упорядоченный, надежный, основанный на соединении, двунаправленный поток байтов. В случае домена сокетов AF_INET этот тип обмена данными по умолчанию обеспечивается TCP-соединением, которое устанавливается между двумя конечными точками потоковых сокетов при подключении. Данные могут передаваться в двух направлениях по линии связи сокетов. Протоколы TCP включают в себя средства фрагментации и последующей повторной сборки сообщений больших объемов и повторной передачи любых их частей, которые могли быть потеряны в сети.
SOCK_DGRAM - дейтаграммный сервис. Вы можете использовать такой сокет для отправки сообщений с фиксированным (обычно небольшим) максимальным объемом, но при этом нет гарантии, что сообщение будет доставлено или что сообщения не будут переупорядочены в сети. В случае сокетов домена AF_INET этот тип передачи данных обеспечивается дейтаграммами UDP (User Datagram Protocol, пользовательский протокол дейтаграмм).
Протокол, применяемый для обмена данными, обычно определяется типом сокета и доменом. Как правило, выбора нет. Параметр protocol применяется в тех случаях, когда выбор все же предоставляется. Задание 0 позволяет выбрать стандартный протокол, используемый во всех примерах данной главы.
Системный вызов socket возвращает дескриптор, во многом похожий на низкоуровневый файловый дескриптор. Когда сокет подключен к концевой точке другого сокета, для отправки и получения данных с помощью сокетов можно применять системные вызовы read и write с дескриптором сокета. Системный вызов close используется для удаления сокетного соединения.
В этой главе вы познакомитесь с еще одним способом взаимодействия процессов, существенно отличающимся от тех, которые мы обсуждали в главах 13 и 14. До настоящего момента все рассматриваемые нами средства основывались на совместно используемых ресурсах одного компьютера. Ресурсы могли быть разными: областью файловой системы, сегментами совместно используемой памяти или очередями сообщений, но использовать их могли только процессы, выполняющиеся на одной машине.
В версию ОС Berkeley UNIX было включено новое средство коммуникации - интерфейс сокетов, - являющееся расширением концепции канала, обсуждавшейся в главе 13. В системах Linux также есть интерфейсы сокетов.
Вы можете применять сокеты во многом так же, как каналы, но они поддерживают взаимодействие в пределах компьютерной сети. Процесс на одной машине может использовать сокеты для взаимосвязи с процессом на другом компьютере, что делает возможным существование клиент-серверных систем, распределенных в сети. Процессы, выполняющиеся на одной машине, также могут применять сокеты.
Кроме того, интерфейс сокетов стал доступен в ОС Windows благодаря общедоступной спецификации Windows Sockets или WinSock. Сервисы сокетов в ОС Windows предоставляются системным файлом Winsock.dll. Стало быть, программы под управлением Windows могут взаимодействовать по сети с компьютерами под управлением Linux и UNIX и наоборот, реализуя, таким образом, клиент-серверные системы. Несмотря на то, что программный интерфейс для WinSock не совпадает полностью с интерфейсом сокетов в UNIX, в основе его лежат те же сокеты.
В одной-единственной главе мы не сможем дать исчерпывающее описание всех многообразных сетевых возможностей Linux, поэтому вы найдете здесь лишь основные программные сетевые интерфейсы, которые позволят вам писать собственные программы, работающие в сети.
Более подробно мы рассмотрим следующие темы:
□ как действует соединение с помощью сокетов;
□ атрибуты сокетов, адреса и обмен информацией;
□ сетевая информация и интернет-демон (inetd/xinetd);
□ клиенты и серверы.
Что такое сокет?
Сокет - это средство связи, позволяющее разрабатывать клиент-серверные системы для локального, на одной машине, или сетевого использования. Функции ОС Linux, такие как вывод, подключение к базам данных и обслуживание Web-страниц, равно как и сетевые утилиты, например
, предназначенная для удаленной регистрации, и , применяемая для передачи файлов, обычно используют сокеты для обмена данными.Сокеты создаются и используются не так, как каналы, потому что они подчеркивают явное отличие между клиентом и сервером. Механизм сокетов позволяет создавать множество клиентов, присоединенных к единственному серверу.
Соединения на базе сокетов
Соединения на базе сокетов можно рассматривать как телефонные звонки в учреждение. Телефонный звонок поступает в организацию, и на него отвечает секретарь приемной, направляющий вызов в соответствующий отдел (серверный процесс) и оттуда к нужному сотруднику (сокет сервера). Каждый входящий телефонный звонок (клиент) направляется к соответствующей конечной точке, и промежуточные операторы могут заниматься последующими телефонными звонками. Прежде чем рассматривать установку соединений с помощью сокетов в системах Linux, нужно понять, как они ведут себя в приложениях сокетов, поддерживающих соединения.
Сначала серверное приложение создает сокет, который как файловый дескриптор представляет собой ресурс, присваиваемый единственному серверному процессу. Сервер создает его с помощью системного вызова
, и этот сокет не может использоваться совместно с другими процессами.Далее сервер присваивает сокету имя. Локальные сокеты с заданными именами файлов в файловой системе Linux часто размещаются в каталоге /tmp или /usr/tmp. У сетевых сокетов имя файла будет идентификатором сервиса (номер порта/точка доступа), относящегося к конкретной сети, к которой могут подключаться клиенты. Этот идентификатор, задавая определенный номер порта, соответствующий корректному серверному процессу, позволяет Linux направлять входящие подключения по определенному маршруту. Например, Web-сервер обычно создает сокет для порта 80, идентификатор, зарезервированный для этой цели. Web-обозреватели знают о необходимости применять порт 80 для своих HTTP-подключений к Web- сайтам, которые пользователь хочет читать. Именуется сокет с помощью системного вызова
. Далее серверный процесс ждет подключения клиента к именованному сокету. Системный вызов формирует очередь входящих подключений. Сервер может принять их с помощью системного вызова .Когда сервер вызывает
, создается новый сокет, отличающийся от именованного сокета. Этот новый сокет применяется только для взаимодействия с данным конкретным клиентом. Именованный сокет сохраняется для дальнейших подключений других клиентов. Если сервер написан корректно, он может извлечь выгоду из многочисленных подключений. Web-сервер добивается этого за счет одновременного предоставления страниц многих клиентам. В случае простого сервера все последующие клиенты ждут в очереди до тех пор, пока сервер не будет готов снова.Клиентская сторона системы с применением сокетов гораздо проще. Клиент создает неименованный сокет с помощью вызова
. Затем он вызывает для подключения к серверу, используя в качестве адреса именованный сокет сервера.Будучи установлены, сокеты могут применяться как низкоуровневые файловые дескрипторы, обеспечивая двунаправленный обмен данными.
Выполните упражнения 15.1 и 15.2.
Упражнение 15.1. Простой локальный клиент . Системный вызов мы подробно рассмотрим чуть позже, когда будем обсуждать некоторые проблемы адресации.1. Включите нужные заголовочные файлы и задайте переменные:
2. Создайте сокет для клиента:
sockfd = socket(AF_UNIX, SOCK_STREAM, 0);
3. Назовите сокет по согласованию с сервером:
address.sun_family = AF_UNIX;
strcpy(address.sun_path, "server_socket");
4. Соедините ваш сокет с сокетом сервера:
:printf("char from server = %c\n", ch);
Эта программа завершится аварийно, если вы попытаетесь выполнить ее, потому что еще не создан именованный сокет сервера, (Точное сообщение об ошибке может отличаться в разных системах.)
oops: client1: No such file or directoryУпражнение 15.2. Простой локальный сервер
Далее приведена программа простого сервера server1.с, которая принимает запрос на соединение от клиента. Она создает сокет сервера, присваивает ему имя, создает очередь ожидания и принимает запросы на соединения.
1. Включите необходимые заголовочные файлы и задайте переменные:
struct sockaddr_un server_address;
struct sockaddr_un client_address;
2. Удалите все старые сокеты и создайте неименованный сокет для сервера:
server_sockfd = socket(AF_UNIX, SOCK_STREAM, 0);
3. Присвойте имя сокету:
server_address.sun_family = AF_UNIX;
strcpy(server_address.sun_path, "server_socket");
4. Создайте очередь запросов на соединение и ждите запроса клиента:
5. Примите запрос на соединение:
(struct sockaddr *)&client_address, &client_len);
6. Читайте и записывайте данные клиента с помощью
:Как это работает
В этом примере серверная программа в каждый момент времени может обслуживать только одного клиента. Она просто читает символ, поступивший от клиента, увеличивает его и записывает обратно. В более сложных системах, где сервер должен выполнять больше работы по поручению клиента, такой подход будет неприемлемым, потому что другие клиенты не смогут подключиться до тех пор, пока сервер не завершит работу. Позже вы увидите пару методов, позволяющих подключаться многочисленным клиентам.
Когда вы выполняете серверную программу, она создает сокет и ждет запросов на соединение. Если вы запустите ее в фоновом режиме, т.е. она будет выполняться независимо, вы сможете затем запускать клиентов как высокоприоритетные задачи.
Ожидая запросы на соединения, сервер выводит сообщение. В приведенном примере сервер ждет запрос с сокета файловой системы, и вы сможете увидеть его с помощью обычной команды
.Хорошо взять за правило удалять сокет после окончания работы с ним, даже в случае аварийного завершения программы из-за получения сигнала. Это убережет файловую систему от загромождения неиспользуемыми файлами.
$ ls -lF server socket
srwxr-xr-x 1 neil users 0 2007-06-23 11:41 server_socket=
Здесь тип устройства - сокет, на что указывает символ
перед правами доступа и символ в конце имени. Сокет был создан как обычный файл с правами доступа, модифицированными текущей . Если применить команду , то можно увидеть сервер, выполняющийся в фоновом режиме. Он показан спящим (параметр равен ) и, следовательно, не потребляющим ресурсы ЦП.F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME COMMAND
0 1000 23385 10689 17 0 1424 312 361800 S pts/1 0:00 ./server1
Теперь, когда вы запустите программу, то успешно подключитесь к серверу. Поскольку сокет сервера существует, вы можете соединиться с ним и обмениваться данными.
server waiting char from server = В
На терминале вывод сервера и клиента перемешаны, но можно увидеть, что сервер получил символ от клиента, увеличил его и вернул. Далее сервер продолжает выполняться и ждет следующего клиента. Если вы запустите несколько клиентов вместе, они будут обслуживаться по очереди, хотя полученный вывод может оказаться еще более перемешанным.
$ ./client1 & ./client1 & ./client1 &
Атрибуты сокета
Для того чтобы до конца понять системные вызовы, применявшиеся в рассмотренном примере, необходимо узнать кое-что об организации сети в системах UNIX.
Сокеты характеризуются тремя атрибутами: доменом, типом и протоколом. У них также есть адрес, используемый как имя сокета. Форматы адресов меняются в зависимости от домена, также называемого семейством протоколов (protocol family). Каждое семейство протоколов может применять одно или несколько семейств адресов, определяющих формат адреса.
Домены сокетовДомены задают сетевую рабочую среду, которую будет использовать соединение сокетов. Самый популярный домен сокетов -
, ссылающийся на сеть Интернет и применяемый во многих локальных сетях Linux и, конечно, в самом Интернете. Низкоуровневый протокол Internet Protocol (IP), у которого только одно адресное семейство, накладывает определенный способ задания компьютеров, входящих в сеть. Он называется IP-адресом.ПримечаниеДля преодоления некоторых проблем стандартного протокола IP существенно ограниченного количества доступных адресов был разработан интернет-протокол нового поколения IPv6. Он использует другой домен сокетов
и иной формат адресов. Ожидается, что со временем IPv6 заменит IP, но для этого потребуется много лет. Несмотря на то, что уже есть реализации IPv6 для Linux, их обсуждение выходит за рамки этой книги.
Несмотря на то, что у машин в Интернете почти всегда есть имена, их преобразуют в IP-адреса. Пример IP-адреса - 192.168.1.99. Все IP-адреса представлены четырьмя числами, каждое из которых меньше 256, и образуют так называемые четверки с точками. Когда клиент подключается по сети с помощью сокетов, ему нужен IP- адрес компьютера сервера.
На компьютере сервера может быть доступно несколько сервисов. Клиент может обратиться к конкретному сервису на компьютере, включенном в сеть, с помощью IP-порта. Внутри системы порт идентифицируется уникальным 16-разрядным целым числом, а за пределами системы - комбинацией IP-адреса и номера порта. Сокеты - это коммуникационные конечные точки, которые должны быть связаны с портами, прежде чем передача данных станет возможна.
Серверы ожидают запросов на соединения от определенных клиентов. У хорошо известных сервисов есть выделенные номера портов, которые используются всеми машинами под управлением ОС Linux и UNIX. Обычно, но не всегда, эти номера меньше 1024. Примерами могут служить буфер печати принтера (515),
(513), (21) и (80). Последний из названных - стандартный порт для Web-серверов. Обычно номера портов, меньшие 1024, зарезервированы для системных сервисов и могут обслуживаться процессами с правами суперпользователя. Стандарт X/Open определяет в заголовочном файле netdb.h константу для указания наибольшего номера зарезервированных портов.Поскольку для стандартных сервисов есть стандартный набор номеров портов, компьютеры могут легко соединяться друг с другом, не угадывая правильный номер порта. Локальный сервисы могут применять адреса нестандартных портов.
Домен в первом упражнении,
, - это домен файловой системы UNIX, который может использоваться сокетами, находящимися на единственном компьютере, возможно, даже не входящем в сеть. Если это так, то низкоуровневый протокол - это файловый ввод/вывод, а адреса - имена файлов. Для сокета сервера применялся адрес , который, как вы видели, появлялся в текущем каталоге, когда вы выполняли серверное приложение.Кроме того, могут применяться и другие домены:
для сетей на основе стандартных протоколов ISO и для Xerox Network System (сетевая система Xerox). В этой книге мы их не будем обсуждать. Типы сокетовУ домена сокетов может быть несколько способов обмена данными, у каждого из которых могут быть разные характеристики. В случае сокетов домена
проблемы не возникают, т.к, они обеспечивают надежный двунаправленный обмен данными. В сетевых доменах необходимо знать характеристики базовой сети и их влияние на различные механизмы передачи данных.Интернет-протоколы предоставляют два механизма передачи данных с разными уровнями обслуживания: потоки и дейтаграммы.
Потоковые сокетыПотоковые сокеты (в чем-то подобные стандартным потокам ввода/вывода) обеспечивают соединение, представляющее собой последовательный и надежный двунаправленный поток байтов. Следовательно, гарантируется, что без указания возникшей ошибки данные не будут потеряны, продублированы или переупорядочены. Сообщения большого объема фрагментируются, передаются и снова собираются воедино. Это напоминает файловый поток, который принимает большие объемы данных и делит их на меньшие блоки для записи на физический диск. У потоковых сокетов предсказуемое поведение.
Потоковые сокеты, описываемые типом
, реализованы в домене соединениями на базе протоколов TCP/IP. Кроме того, это обычный тип сокетов и в домене . В этой главе мы сосредоточимся на сокетах типа , поскольку они чаще всего применяются при программировании сетевых приложений.ПримечаниеДейтаграммные сокетыTCP/IP - сокращение для протоколов Transmission Control Protocol/Internet Protocol. Протокол IP - низкоуровневый протокол передачи пакетов, обеспечивающий выбор маршрута при пересылке данных в сети от одного компьютера к другому. Протокол TCP обеспечивает упорядочивание, управление потоком и ретрансляцию, гарантирующие полную и корректную передачу больших объемов данных или же сообщение о соответствующей ошибочной ситуации.
В отличие от потоковых дейтаграммные сокеты, описываемые типом
, не устанавливают и не поддерживают соединение. Кроме того, существует ограничение для размера дейтаграммы, которая может отправляться. Она передается как единое сетевое сообщение, которое может быть потеряно, продублировано или прибыть несвоевременно, т.е. перед дейтаграммами, посланными после нее.Дейтаграммные сокеты реализованы в домене
с помощью соединений UDP/IP и предоставляют неупорядоченный ненадежный сервис. (UDP сокращенное название протокола User Datagram Protocol.) Однако они относительно экономичны с точки зрения расходования ресурсов, поскольку не нуждаются в поддержке сетевых соединений. Они быстры, т.к. не тратится время на установку сетевого соединения.Дейтаграммы полезны для однократных запросов к информационным сервисам, для предоставления обычных сведений о состоянии или для выполнения низкоприоритетной регистрации данных. Их преимущество в том, что остановка сервера не причинит чрезмерных неудобств клиенту и не потребует перезапуска клиента. Поскольку серверы на базе дейтаграмм обычно сохраняют данные без соединения, их можно останавливать и запускать снова, не мешая их клиентам.
На этом мы закончим обсуждение дейтаграмм, дополнительную информацию см. в разд. "Дейтаграммы" в конце данной главы.
Протоколы сокетовЕсли низкоуровневый механизм передачи данных позволяет применять несколько протоколов, предоставляющих сокет требуемого типа, можно выбрать конкретный протокол или сокет. В этой главе мы сосредоточимся на сокетах сети UNIX и ее файловой системы, которые не требуют от вас выбора протокола, отличного от заданного по умолчанию.
Создание сокета
Системный вызов socket создает сокет и возвращает дескриптор, который может применяться для доступа к сокету:
#include
#include
int socket(int domain, int type, int protocol);
Созданный сокет - это одна конечная точка линии передачи. Параметр
задает семейство адресов, параметр определяет тип используемого с этим сокетом обмена данными, a - применяемый протокол.В табл. 15.1 приведены имена доменов.
Таблица 15.1
К наиболее популярным доменам сокетов относятся
, применяемый для локальных сокетов, реализуемых средствами файловых систем UNIX и Linux, и , используемый для сетевых сокетов UNIX. Сокеты домена могут применяться программами, взаимодействующими в сетях на базе протоколов TCP/IP, включая Интернет. Интерфейс ОС Windows Winsock также предоставляет доступ к этому домену сокетов.Параметр сокета type задает характеристики обмена данными, применяемые для нового сокета. Возможными значениями могут быть
и . - это упорядоченный, надежный, основанный на соединении, двунаправленный поток байтов. В случае домена сокетов этот тип обмена данными по умолчанию обеспечивается TCP-соединением, которое устанавливается между двумя конечными точками потоковых сокетов при подключении. Данные могут передаваться в двух направлениях по линии связи сокетов. Протоколы TCP включают в себя средства фрагментации и последующей повторной сборки сообщений больших объемов и повторной передачи любых их частей, которые могли быть потеряны в сети. - дейтаграммный сервис. Вы можете использовать такой сокет для отправки сообщений с фиксированным (обычно небольшим) максимальным объемом, но при этом нет гарантии, что сообщение будет доставлено или что сообщения не будут переупорядочены в сети. В случае сокетов домена этот тип передачи данных обеспечивается дейтаграммами UDP (User Datagram Protocol, пользовательский протокол дейтаграмм).Протокол, применяемый для обмена данными, обычно определяется типом сокета и доменом. Как правило, выбора нет. Параметр
применяется в тех случаях, когда выбор все же предоставляется. Задание 0 позволяет выбрать стандартный протокол, используемый во всех примерах данной главы.Системный вызов
возвращает дескриптор, во многом похожий на низкоуровневый файловый дескриптор. Когда сокет подключен к концевой точке другого сокета, для отправки и получения данных с помощью сокетов можно применять системные вызовы и с дескриптором сокета. Системный вызов используется для удаления сокетного соединения.Адреса сокетов
Каждый домен сокетов требует своего формата адресов. В домене
адрес описывается структурой , объявленной в заголовочном файле sys/un.h:sa_family_t sun_family; /* AF_UNIX */
char sun_path; /* Путь к файлу */
Для того чтобы адреса разных типов могли передаваться в системные вызовы для обработки сокетов, все адресные форматы описываются похожей структурой, которая начинается с поля (в данном случае
), задающего тип адреса (домен сокета). В домене адрес задается именем файла в поле структуры .В современных системах Linux тип
, описанный в стандарте X/Open как объявляемый в заголовочном файле sys/un.h, интерпретируется как тип . Кроме того, размер , задаваемого в поле , ограничен (в Linux указывается 108 символов; в других системах может применяться именованная константа, например, ). Поскольку размер адресной структуры может меняться, многие системные вызовы сокетов требуют или предоставляют на выходе длину, которая будет использоваться для копирования конкретной адресной структуры. адрес задается с помощью структуры с именем , определенной в файле netinet/in.h, которая содержит как минимум следующие элементы:short int sin_family; /* AF_INET */
unsigned short int sin_port; /* Номер порта */
struct in_addr sin_addr; /* Интернет-адрес */
Структура IP-адреса типа in_addr определена следующим образом:
unsigned long int s_addr;
Четыре байта IP-адреса образуют одно 32-разрядное значение. Сокет домена
полностью описывается IP-адресом и номером порта. С точки зрения приложения все сокеты действуют как файловые дескрипторы, и их адреса задаются уникальными целочисленными значениями.Именование сокета
Для того чтобы сделать сокет (созданный с помощью вызова
) доступным для других процессов, серверная программа должна присвоить сокету имя. Сокеты домена связаны с полным именем файла в файловой системе, как вы видели в программе-примере server1. Сокеты домена связаны с номером IP-порта.#include
int bind(int socket, const struct sockaddr *address, size_t address len);
Системный вызов
присваивает адрес, заданный в параметре , неименованному сокету, связанному с дескриптором сокета . Длина адресной структуры передается в параметре :Длина и формат адреса зависят от адресного семейства. В системном вызове
указатель конкретной адресной структуры должен быть приведен к обобщенному адресному типу .В случае успешного завершения
возвращает 0. Если он завершается аварийно, возвращается -1, и переменной присваивается одно из значений, перечисленных в табл. 15.2.Таблица 15.2
Создание очереди сокетов
Для приема запросов на входящие соединения на базе сокетов серверная программа должна создать очередь для хранения ждущих обработки запросов. Формируется она с помощью системного вызова
.#include
int listen(int socket, int backlog);
Система Linux может ограничить количество ждущих обработки соединений, которые могут храниться в очереди. В соответствии с этим максимумом вызов
задает длину очереди, равной . Входящие соединения, не превышающие максимальной длины очереди, сохраняются в ожидании сокета; последующим запросам на соединение будет отказано, и клиентская попытка соединения завершится аварийно. Этот механизм реализуется вызовом для того, чтобы можно было сохранить ждущие соединения запросы, пока серверная программа занята обработкой запроса предыдущего клиента. Очень часто параметр равен 5. вернет 0 в случае успешного завершения и -1 в случае ошибки. Как и для системного вызова , ошибки могут обозначаться константами , И .Прием запросов на соединение
После создания и именования сокета серверная программа может ждать запросы на выполнение соединения с сокетом с помощью системного вызова
:#include
int accept(int socket, struct sockaddr *address, size_t *address_len);
Системный вызов
возвращает управление, когда клиентская программа пытается подключиться к сокету, заданному в параметре . Этот клиент - первый из ждущих соединения в очереди данного сокета. Функция создает новый сокет для обмена данными с клиентом и возвращает его дескриптор. У нового сокета будет тот же тип, что и у сокета сервера, ждущего запросы на соединения.Предварительно сокету должно быть присвоено имя с помощью системного вызова
и у него должна быть очередь запросов на соединение, место для которой выделил системный вызов . Адрес вызывающего клиента будет помещен в структуру , на которую указывает параметр . Если адрес клиента не представляет интереса, в этом параметре может задать пустой указатель.Параметр
задает длину адресной структуры клиента. Если адрес клиента длиннее, чем это значение, он будет урезан. Перед вызовом в параметре должна быть задана ожидаемая длина адреса. По возвращении из вызова в будет установлена реальная длина адресной структуры запрашивающего соединение клиента.Если нет запросов на соединение, ждущих в очереди сокета, вызов accept будет заблокирован (так что программа не сможет продолжить выполнение) до тех пор, пока клиент не сделает запрос на соединение. Вы можете изменить это поведение, применив флаг
в файловом дескрипторе сокета с помощью вызова в вашей программе следующим образом:int flags = fcntl(socket, F_GETFL, 0);
fcntl(socket, F_SETFL, O_NONBLOCK | flags);возвращает файловый дескриптор нового сокета, если есть запрос клиента, ожидающего соединения, и -1 в случае ошибки. Возможные значения ошибок такие же, как у вызовов и плюс дополнительная константа в случае, когда задан флаг и нет ждущих запросов на соединение. Ошибка возникнет, если процесс прерван во время блокировки в функции .
Запросы соединений
Клиентские программы подключаются к серверам, устанавливая соединение между неименованным сокетом и сокетом сервера, ждущим подключений. Делают они это с помощью вызова
:#include
int connect(int socket, const struct sockaddr *address, size_t address_len);
Сокет, заданный в параметре
, соединяется с сокетом сервера, заданным в параметре , длина которого равна . Сокет должен задаваться корректным файловым дескриптором, полученным из системного вызова .Если функция
завершается успешно, она возвращает 0, в случае ошибки вернется -1. Возможные ошибки на этот раз включают значения, перечисленные в табл. 15.3.Таблица 15.3
Если соединение не может быть установлено немедленно, вызов
будет заблокирован на неопределенный период ожидания. Когда допустимое время ожидания будет превышено, соединение разорвется и вызов завершится аварийно. Однако, если вызов прерван сигналом, который обрабатывается, connect завершится аварийно (со значением errno, равным ), но попытка соединения не будет прервана - соединение будет установлено асинхронно и программа должна будет позже проверить, успешно ли оно установлено.Как и в случае вызова
, возможность блокировки в вызове можно исключить установкой в файловом дескрипторе флага . В этом случае, если соединение не может быть установлено немедленно, вызов завершится аварийно с переменной , равной , и соединение будет выполнено асинхронно.Хотя асинхронные соединения трудно обрабатывать, вы можете применить вызов
к файловому дескриптору сокета, чтобы убедиться в том, что сокет готов к записи. Мы обсудим вызов чуть позже в этой главе.Закрытие сокета
Вы можете разорвать сокетное соединение в серверной или клиентской программах, вызвав функцию
, так же как в случае низкоуровневых файловых дескрипторов. Сокеты следует закрывать на обоих концах. На сервере это нужно делать, когда вернет ноль. Имейте в виду, что вызов может быть заблокирован, если сокет, у которого есть непереданные данные, обладает типом, ориентированным на соединение, и установленным параметром . Дополнительную информацию об установке параметров сокета вы узнаете позже в этой главе.Обмен данными с помощью сокетов
Теперь, когда мы описали основные системные вызовы, связанные с сокетами, давайте повнимательнее рассмотрим программы-примеры. Вы попытаетесь переработать их, заменив сокет файловой системы сетевым сокетом. Недостаток сокета файловой системы состоит в том, что если автор не использует полное имя файла, он создается в текущем каталоге серверной программы. Для того чтобы сделать его полезным в большинстве случаев, следует создать сокет в общедоступном каталоге (например, /tmp), подходящем для сервера и его клиентов. В случае сетевых серверов достаточно выбрать неиспользуемый номер порта.
Для примера выберите номер порта 9734. Это произвольный выбор, позволяющий избежать использования портов стандартных сервисов (вы не должны применять номера портов, меньшие 1024, поскольку они зарезервированы для системного использования). Другие номера портов с обеспечиваемыми ими сервисами часто приводятся в системном файле /etc/services. При написании программ, использующих сокеты, всегда выбирайте номер порта, которого нет в этом файле конфигурации.
ПримечаниеВам следует знать, что в программах client2.c и server2.c умышленно допущена ошибка, которую вы устраните в программах client3.c и server3.c. Пожалуйста, не используйте текст примеров client2.c и server2.c в собственных программах.
Вы будете выполнять ваши серверную и клиентскую программы в локальной сети, но сетевые сокеты полезны не только в локальной сети, любая машина с подключением к Интернету (даже по модемной линии связи) может применять сетевые сокеты для обмена данными с другими компьютерами. Программу, основанную на сетевых подключениях, можно применять даже на изолированном компьютере с ОС UNIX, т. к. такой компьютер обычно настроен на использование виртуальной сети или внутренней петли (loopback network), включающей только его самого. Для демонстрационных целей данный пример использует виртуальную сеть, которая может быть также полезна для отладки сетевых приложений, поскольку она устраняет любые внешние сетевые проблемы.
Виртуальная сеть состоит из единственного компьютера, традиционно именуемого
, со стандартным IP-адресом 127.0.0.1. Это локальная машина. Ее адрес вы сможете найти в файле сетевых узлов etc/hosts наряду с именами и адресами других узлов, входящих в совместно используемые сети.У каждой сети, с которой компьютер обменивается данными, есть связанный с ней аппаратный интерфейс. У компьютера в каждой сети может быть свое имя и конечно будут разные IP-адреса. Например, у машины Нейла с именем tilde три сетевых интерфейса и, следовательно, три адреса. Они записаны в файле /etc/hosts следующим образом.
127.0.0.1 localhost # Петля
192.168.1.1 tilde.localnet # Локальная частная сеть Ethernet
158.152.X.X tilde.demon.co.uk # Модемная линия связи
Первая строка - пример виртуальной сети, ко второй сети доступ осуществляется с помощью адаптера Ethernet, а третья - модемная линия связи с провайдером интернет-сервисов. Вы можете написать программу, применяющую сетевые сокеты, для связи с серверами с помощью любого из приведенных интерфейсов без каких-либо корректировок.
Выполните упражнения 15.3 и 15.4.
Упражнение 15.3. Сетевой клиентДалее приведена измененная программа-клиент client2.c, предназначенная для использования сетевого соединения на базе сокета в виртуальной сети. Она содержит незначительную ошибку, связанную с аппаратной зависимостью, но мы обсудим ее чуть позже в этой главе.
1. Включите необходимые директивы
и задайте переменные:#include
#include
struct sockaddr_in address;
2. Создайте сокет клиента:
3. Присвойте имя сокету по согласованию с сервером:
address.sin_addr.s_addr = inet_addr("127.0.0.1");
address.sin_port = 9734;
Оставшаяся часть программы такая же, как в приведенном ранее в этой главе примере. Когда вы выполните эту версию, она завершится аварийно, потому что на данном компьютере нет сервера, выполняющегося на порте 9734.
oops: client2: Connection refused
Как это работает
Клиентская программа использует структуру
из заголовочного файла netinet/in.h для задания адреса . Она пытается подключиться к серверу, размещенному на узле с IP-адресом 127.0.0.1. Программа применяет функцию для преобразования текстового представления IP-адреса в форму, подходящую для адресации сокетов. На страницах интерактивного справочного руководства для inet вы найдете дополнительную информацию о других функциях, преобразующих адреса. Упражнение 15.4. Сетевой серверВам также нужно модифицировать серверную программу, ждущую подключений на выбранном вами номере порта. Далее приведена откорректированная программа сервера server2.c.
1. Вставьте необходимые заголовочные файлы и задайте переменные:
#include
#include
int server_sockfd, client_sockfd;
2. Создайте неименованный сокет для сервера:
3. Дайте имя сокету:
server_address.sin_port.s_addr = inet_addr("127.0.0.1");
server_address.sin_port = 9734;
server_len = sizeof(server_address);
bind(server_sockfd, (struct sockaddr *)&server_address, server_len);
Как это работает
Серверная программа создает сокет домена
и выполняет необходимые действия для приема запросов на подключение к нему. Сокет связывается с выбранным вами портом. Заданный адрес определяет, каким машинам разрешено подсоединяться. Задавая такой же адрес виртуальной сети, как в клиентской программе, вы ограничиваете соединения только локальной машиной.Если вы хотите разрешить серверу устанавливать соединения с удаленными клиентами, необходимо задать набор IP-адресов, которые разрешены. Можно применить специальное значение
для того, чтобы показать, что будете принимать запросы на подключение от всех интерфейсов, имеющихся на вашем компьютере. Если необходимо, вы можете разграничить интерфейсы разных сетей, чтобы отделить соединения локальной сети от соединений глобальной сети. Константа - 32-разрядное целое число, которое можно использовать в поле адресной структуры. Но прежде вам нужно решить проблему.Порядок байтов на компьютере и в сети
Если запустить приведенные версии серверной и клиентской программ на машине на базе процессора Intel под управлением Linux, то с помощью команды
можно увидеть сетевые соединения. Эта команда есть в большинство систем UNIX, настроенных на работу в сети. Она отображает клиент-серверное соединение, ожидающее закрытия. Соединение закрывается после небольшой задержки. (Повторяем, что вывод в разных версиях Linux может отличаться.)$ ./server2 & ./client2
Active Internet connections (w/o servers)
tcp 1 0 localhost:1574 localhost:1174 TIME_WAIT root
ПримечаниеПрежде чем испытывать последующие примеры этой главы, убедитесь в том, что завершено выполнение серверных программ-примеров, поскольку они будут конкурировать при приеме соединений клиентов, и вы увидите вводящие в заблуждение результаты. Удалить их все (включая те, что будут приведены позже в этой главе) можно с помощью следующей команды:
killall server1 server2 server3 server4 server5
Вы сможете увидеть номера портов, присвоенные соединению сервера с клиентом. Локальный адрес отображает сервер, а внешний адрес - удаленного клиента. (Даже если клиент размещен на той же машине, он все равно подключается через сеть.) Для четкого разделения всех сокетов порты клиентов обычно отличаются от сокета сервера, ожидающего запросы на соединения, и уникальны в пределах компьютера.
Отображается локальный адрес (сокет сервера) 1574 (или может выводиться имя сервиса
) и выбранный в примере порт 9734. Почему они отличаются? Дело в том, что номера портов и адреса передаются через интерфейсы сокета как двоичные числа. В разных компьютерах применяется различный порядок байтов для представления целых чисел. Например, процессор Intel хранит 32-разрядное целое в виде четырех последовательных байтов памяти в следующем порядке 1-2-3-4, где 1-й байт - самый старший. Процессоры IBM PowerPC будут хранить целое со следующим порядком следования байтов: 4-3-2-1. Если используемую для хранения целых память просто побайтно копировать, два компьютера не придут к согласию относительно целочисленных значений.Для того чтобы компьютеры разных типов могли согласовать значения многобайтовых целых чисел, передаваемых по сети, необходимо определить сетевой порядок передачи байтов. Перед передачей данных клиентские и серверные программы должны преобразовать собственное внутреннее представление целых чисел в соответствии с принятым в сети порядком следования байтов. Делается это с помощью функций, определенных в заголовочном файле netinet/in.h. К ним относятся следующие:
#include
unsigned long int htonl(unsigned long int hostlong);
unsigned short int htons(unsigned short int hostshort);
unsigned long int ntohl(unsigned long int netlong);
unsigned short int ntohs(unsigned short int netshort);
Эти функции преобразуют 16- и 32-разрядные целые из внутреннего формата в сетевой порядок следования байтов и обратно. Их имена соответствуют сокращенному названию выполняемых преобразований, например "host to network, long" (htonl, компьютерный в сетевой, длинные целые) и "host to network, short" (htons, компьютерный в сетевой, короткие целые). Компьютерам, у которых порядок следования байтов соответствует сетевому, эти функции предоставляют пустые операции.
Для обеспечения корректного порядка следования при передаче 16-разрядного целого числа ваши сервер и клиент должны применить эти функции к адресу порта. В программу server3.c следует внести следующие изменения:
server_address.sin_addr_s_addr = htonl(INADDR_ANY);
Результат, возвращаемый функцией
, преобразовывать не нужно, потому что в соответствии со своим определением она возвращает результат с сетевым порядком следования байтов. В программу client3.c необходимо внести следующее изменение:address.sin_port = htons(9734);
В сервер, благодаря применению константы
, внесено изменение, позволяющее принимать запросы на соединение от любых IP-адресов.Теперь, выполнив программы server3 и client3, вы увидите корректный номер порта, используемый для локального соединения:
Proto Recv-Q Send-Q Local Address Foreign Address (State) User
tcp 1 0 localhost:9734 localhost:1175 TIME_WAIT root
ПримечаниеЕсли вы пользуетесь компьютером, у которого собственный формат представления целых совпадает с сетевым порядком следования байтов, вы не увидите никакой разницы. Но для обеспечения корректного взаимодействия клиентов и серверов с разной архитектурой важно всегда применять функции преобразования.
Сетевая информация
До сих пор у клиентских и серверных программ были адреса и номера портов, компилируемые в них. В более универсальных серверных и клиентских программах для определения применяемых адресов и портов вы можете использовать данные сети.
Если у вас есть на это право, можно добавить свой сервер к списку известных сервисов в файл /etc/services, который назначает имена номерам портов, так что клиенты могут использовать вместо номеров символические имена сервисов.
Точно так же зная имя компьютера, можно определить IP-адрес, вызвав функции базы данных сетевых узлов (host database), которые найдут эти адреса. Делают они это, обращаясь за справкой к конфигурационным файлам, например, etc/hosts или к сетевым информационным сервисам, таким как NIS (Network Information Services (сервисы сетевой информации), ранее известным как Yellow Pages (желтые страницы)) и DNS (Domain Name Service, служба доменных имен).
Функции базы данных сетевых узлов или хостов (Host database) объявлены в заголовочном файле интерфейса netdb.h:
struct hostent *gethostbyaddr(const void* addr, size_t len, int type);
struct hostent* gethostbyname(const char* name);
Структура, возвращаемая этими функциями, должна как минимум содержать следующие элементы.
char *h_name; /* Имя узла */
char **h_aliases; /* Перечень псевдонимов (nicknames) */
int h_addrtype; /* Тип адреса */
int h_length; /* Длина адреса в байтах */
char **h_addr_list /* Перечень адреса (сетевой порядок байтов) */
Если в базе данных нет элемента, соответствующего заданному узлу или адресу, информационные функции вернут пустой указатель.
Аналогично информацию, касающуюся сервисов и связанных номеров портов, можно получить с помощью информационных функций сервисов:
struct servent *getservbyname(const char *name, const char *proto);
struct servent *getservbyport(int port, const char *proto);
Параметр
задает протокол, который будет применяться для подключения к сервису, либо "tcp" для TCP-соединений типа , либо "udp" для UDP-дейтаграмм типа .Структура
содержит как минимум следующие элементы:char *s_name; /* Имя сервиса */
char **s_aliases; /* Список псевдонимов (дополнительных имен) */
int s_port; /* Номер IP-порта */
char *s_proto; /* Тип сервиса, обычно "tcp" или "udp" */
Вы можете собрать воедино информацию о компьютере из базы данных сетевых узлов, вызвав функцию
и выведя ее результаты. Учтите, что адрес необходимо преобразовать в соответствующий тип и перейти от сетевого упорядочивания к пригодной для вывода строке с помощью преобразования , определенного следующим образом:#include
char *inet_ntoa(struct in_addr in);
Функция преобразует адрес интернет-узла в строку формата четверки чисел с точками. В случае ошибки она возвращает -1, но в стандарте POSIX не определены конкретные ошибки. Еще одна новая функция, которую вы примените, -
:int gethostname(char *name, int name length);
Эта функция записывает имя текущего узла в строку, заданную параметром
. Имя узла будет нуль-терминированной строкой. Аргумент содержит длину строкового имени и, если возвращаемое имя узла превысит эту длину, оно будет обрезано. Функция возвращает 0 в случае успешного завершения и -1 в случае ошибки. И снова ошибки в стандарте POSIX не определены.Выполните упражнение 15.5.
Упражнение 15.5. Сетевая информацияДанная программа getname.c получает сведения о компьютере.
1. Как обычно, вставьте соответствующие заголовочные файлы и объявите переменные:
char *host, **names, **addrs;
2. Присвойте переменной
значение аргумента, предоставляемого при вызове программы , или по умолчанию имя машины пользователя:3. Вызовите функцию gethostbyname и сообщите об ошибке, если никакая информация не найдена:
fprintf(stderr, "cannot get info for host: %s\n", host);
4. Отобразите имя узла и любые псевдонимы, которые у него могут быть:
printf("results for host %s:\n", host);
printf("Name: %s\n", hostinfo->h_name);
printf(" %s", *names); names++;
5. Если запрашиваемый узел не является IP-узлом, сообщите об этом и завершите выполнение:
if (hostinfo->h_addrtype != AF_INET) {
fprintf(stderr, "not an IP host!\n");
6. В противном случае выведите IP-адрес (адреса):
addrs = hostinfo->h_addr_list;
printf(" %s", inet_ntoa(*(struct in_addr*)*addrs));
Для определения узла по заданному IP-адресу можно применить функцию
. Вы можете использовать ее на сервере для того, чтобы выяснить, откуда клиент запрашивает соединение.Как это работает
Программа getname вызывает функцию gethostbyname для извлечения сведений об узле из базы данных сетевых узлов. Она выводит имя компьютера, его псевдонимы (другие имена, под которыми известен компьютер) и IP-адреса, которые он использует в своих сетевых интерфейсах. На одной из машин авторов выполнение примера и указание в качестве аргумента имени tilde привело к выводу двух интерфейсов: сети Ethernet и модемной линии связи.
Когда используется имя узла
, задается виртуальная сеть:Теперь вы можете изменить свою программу-клиента для соединения с любым именованным узлом сети. Вместо подключения к серверу из вашего примера, вы соединитесь со стандартным сервисом и сможете извлечь номер порта.
Большинство систем UNIX и некоторые ОС Linux делают доступными свои системные время и дату в виде стандартного сервиса с именем
. Клиенты могут подключаться к этому сервису для выяснения мнения сервера о текущих времени и дате. В упражнении 15:6 приведена программа-клиент getdate.c, именно это и делающая. Упражнение 15.6. Подключение к стандартному сервису1. Начните с обычных директив
и объявлений:int main(int argc, char *argv) {
2. Найдите адрес узла и сообщите об ошибке, если адрес не найден:
hostinfo = gethostbyname(host);
3. Убедитесь, что на компьютере есть сервис
:servinfo = getservbyname("daytime", "tcp");
printf("daytime port is %d\n", ntohs(servinfo->s_port));
4. Создайте сокет:
sockfd = socket(AF_INET, SOCK_STREAM, 0);
5. Сформируйте адрес для соединения:
address.sin_family = AF_INET;
address.sin_port = servinfo->s_port;
address.sin_addr = *(struct in_addr *)*hostinfo->h_addr_list;
6. Затем подключитесь и получите информацию:
result = connect(sockfd, (struct sockaddr *)&address, len);
result = read(sockfd, buffer, sizeof(buffer));
Вы можете применять программу
для получения времени суток с любого известного узла сети.read 26 bytes: 24 JUN 2007 06:03:03 BST
Если вы получаете сообщение об ошибке, такое как
oops: getdate: Connection refused
oops: getdate: No such file or directory
причина может быть в том, что на компьютере, к которому вы подключаетесь, не включен сервис
. Такое поведение стало стандартным для большинства современных систем Linux. В следующем разделе вы увидите, как включать этот и другие сервисы.Как это работает
При выполнении данной программы можно задать узел, к которому следует подключиться. Номер порта сервиса
определяется функцией сетевой базы данных , которая возвращает сведения о сетевых сервисах таким же способом, как и при получении информации об узле сети. Программа пытается соединиться с адресом, который указан первым в списке дополнительных адресов заданного узла. Если соединение успешно, программа считывает сведения, возвращаемые сервисом daytime, символьную строку, содержащую системные дату и время.Интернет-демон (xinetd/inetd)
Системы UNIX, предоставляющие ряд сетевых сервисов, зачастую делают это с помощью суперсервера. Эта программа (интернет-демон xinetd или inetd) ожидает одновременно запросы на соединения с множеством адресов портов. Когда клиент подключается к сервису, программа-демон запускает соответствующий сервер. При таком подходе серверам не нужно работать постоянно, они могут запускаться по требованию.
ПримечаниеВ современных системах Linux роль интернет-демона исполняет программа xinetd. Она заменила оригинальную UNIX-программу inetd, которую вы все еще можете встретить в более ранних системах Linux и других UNIX-подобных системах.
Программа xinetd обычно настраивается с помощью пользовательского графического интерфейса для управления сетевыми сервисами, но вы можете изменять и непосредственно файлы конфигурации программы. К ним относятся файл /etc/xinetd.conf и файлы в каталоге /etc/xinetd.d.
У каждого сервиса, предоставляемого программой xinetd, есть файл конфигурации в каталоге /etc/xinetd.d. Программа xinetd считает все эти файлы конфигурации во время запуска и повторно при получении соответствующей команды.
.# По умолчанию: отключен
# Описание: сервер daytime. Это версия tcp.
Следующий файл конфигурации предназначен для сервиса передачи файлов.
# По умолчанию: отключен
# FTP-сервер vsftpd обслуживает FTP-соединения. Он использует
# для аутентификации обычные, незашифрованные имена пользователей и
# пароли, vsftpd спроектирован для безопасной работы.
# Примечание: этот файл содержит конфигурацию запуска vsftpd для xinetd.
# Файл конфигурации самой программы vsftpd находится в
# log_on_success += DURATION USERID, к которому подключается программа , обычно обрабатывается самой программой xinetd (он помечен как внутренний) и может включаться с помощью как сокетов типа (tcp), так и сокетов типа (udp).
Сервис передачи файлов
подключается только сокетами типа и предоставляется внешней программой, в данном случае vsftpd. Демон будет запускать эту внешнюю программу, когда клиент подключится к порту .Для активизации конфигурационных изменений сервиса можно отредактировать конфигурацию xinetd и отправить сигнал отбоя (hang-up) процессу-демону, но мы рекомендуем использовать более дружелюбный способ настройки сервисов. Для того чтобы разрешить вашему клиенту подключаться к сервису
, включите этот сервис с помощью средств, предоставляемых системой Linux. В системах SUSE и openSUSE сервисы можно настраивать из SUSE Control Center (Центр управления SUSE), как показано на рис. 15.1. У версий Red Hat (и Enterprise Linux, и Fedora) есть похожий интерфейс настройки. В нем сервис включается для TCP- и UDP-запросов.Рис. 15.1
Для систем, применяющих программу inetd вместо xinetd, далее приведено эквивалентное извлечение из файла конфигурации inetd, /etc/inetd.conf, которое программа inetd использует для принятия решения о запуске серверов:
#
# Echo, discard, daytime и chargen используются в основном для
daytime stream tcp nowait root internal
daytime dgram udp wait root internal
# Это стандартные сервисы.
ftp stream tcp-nowait root /usr/sbin/tcpd /usr/sbin/wu.ftpd
telnet stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.telnetd
# Конец файла inetd.conf.
Обратите внимание на то, что в нашем примере сервис ftp предоставляется внешней программой wu.ftpd. Если в вашей системе выполняется демон inetd, вы можете изменить набор предоставляемых сервисов, отредактировав файл /etc/inetd.conf (знак # в начале строки указывает на то, что это строка комментария) и перезапустив процесс inetd. Сделать это можно, отправив сигнал отбоя (hang-up) с помощью команды
. Для облегчения этого процесса некоторые системы настроены так, что программа inetd записывает свой ID в файл. В противном случае можно применить команду :Параметры сокета
Существует много параметров, которые можно применять для управления поведением соединений на базе сокетов - слишком много для подробного описания в этой главе. Для манипулирования параметрами используют функцию
:#include
int setsockopt(int socket, int level, int option_name,
const void *option value, size_t option len);
Задавать параметры можно на разных уровнях иерархии протоколов. Для установки параметров на уровне сокета вы должны задать
равным . Для задания параметров на более низком уровне протоколов (TCP, UDP и т.д.) приравняйте параметр level номеру протокола (полученному либо из заголовочного файла netinet/in.h, либо из функции ).В аргументе
указывается имя задаваемого параметра, аргумент содержит произвольное значение длиной байтов, передаваемое без изменений обработчику низкоуровневого протокола.Параметры уровня сокета определены в заголовочном файле sys/socket.h и включают приведенные в табл. 15.4 значения.
Таблица 15.5
Параметры
и принимают целое значение для установки или включения (1) и сброса или выключения (0). Для параметра нужна структура типа , определенная в файле sys/socket.h и задающая состояние параметра и величину интервала задержки. возвращает 0 в случае успеха и -1 в противном случае. На страницах интерактивного справочного руководства описаны дополнительные параметры и ошибки.Множественные клиенты
До сих пор в этой главе вы видели, как применяются сокеты для реализации клиент-серверных систем, как локальных, так действующих, в сети. После установки соединения на базе сокетов они ведут себя как низкоуровневые открытые файловые дескрипторы и во многом как двунаправленные каналы.
Теперь необходимо рассмотреть случай множественных клиентов, одновременно подключающихся к серверу. Вы видели, что, когда серверная программа принимает от клиента запрос на соединение, создается новый сокет, а исходный сокет, ожидающий запросы на соединение, остается доступен для последующих запросов. Если сервер не сможет немедленно принять поступившие позже запросы на соединения, они сохранятся в очереди ожидания.
Тот факт, что исходный сокет все еще доступен, и что сокеты ведут себя как файловые дескрипторы, дает нам метод одновременного обслуживания многих клиентов. Если сервер вызовет функцию
для создания своей второй копии, открытый сокет будет унаследован новым дочерним процессом. Далее он сможет обмениваться данными с подключившимся клиентом, в то время как основной сервер продолжит прием последующих запросов на соединение. В действительности в вашу программу сервера нужно внести очень простое изменение, показанное в упражнении 15.7.Поскольку вы создаете дочерние процессы, но не ждете их завершения, следует сделать так, чтобы сервер игнорировал сигналы
, препятствуя возникновению процессов-зомби. Упражнение 15.7. Сервер для многочисленных клиентов1. Программа server4.c начинается так же, как последний рассмотренный сервер с важным добавлением директивы
для заголовочного файла signal.h. Переменные и процедуры создания и именования сокета остались прежними:int server_sockfd, client_sockfd;
struct sockaddr_in server_address;
struct sockaddr_in client_address;
server_sockfd = socket(AF_INET, SOCK_STREAM, 0);
server_address.sin_family = AF_INET;
server_address.sin_port = htons(9734);
server_len = sizeof(server_address);
bind(server_sockfd, (struct sockaddr *)&server_address, server_len);
2. Создайте очередь соединений, игнорируйте подробности завершения дочернего процесса и ждите запросов клиентов:
listen(server_sockfd, 5);
signal(SIGCHLD, SIG_IGN);
printf("server waiting\n");
3. Примите запрос на соединение:
client_len = sizeof(client_address);
client_sockfd = accept(server_sockfd,
(struct_sockaddr*)&client_address, &client_len);
4. Вызовите
с целью создания процесса для данного клиента и выполните проверку, чтобы определить, родитель вы или потомок: . Пятисекундная задержка нужна для того, чтобы это продемонстрировать:read(client_sockfd, &ch, 1);
write(client_sockfd, &ch, 1);
close(client_sockfd);
6. В противном случае вы должны быть родителем и ваша работа с данным клиентом закончена:
close(client_socket);
Код включает пятисекундную задержку при обработке запроса клиента для имитации вычислений сервера или обращения к базе данных. Если бы вы проделали это в предыдущем сервере, каждое выполнение программы client3 заняло бы пять секунд. С новым сервером вы сможете обрабатывать множественные клиентские программы client3 параллельно с общим затраченным временем, чуть превышающим пять секунд.
$ ./client3 & ./client3 & ./client3 & ps x
Как это работает
Теперь серверная программа создает новый дочерний процесс для обработки каждого клиента, поэтому вы можете видеть несколько сообщений об ожидании сервера, поскольку основная программа продолжает ждать новые запросы на подключения. В выводе команды
(отредактированном) показан главный процесс server4 с PID, равным 26 566, который ожидает новых клиентов, в то время, как три клиентских процесса client3 обслуживаются тремя потомками сервера. После пятисекундной паузы все клиенты получают свои результаты и завершаются. Дочерние серверные процессы тоже завершаются, оставляя только один главный серверный процесс.Серверная программа применяет вызов
для обработки множественных клиентов. В приложении для работы с базой данных это может быть не самым удачным решением, т.к. серверная программа может быть довольно большой, и, кроме того, существует проблема координации обращений к базе данных множественных копий сервера. На самом деле, все, что вам нужно, - это способ обработки множественных клиентов единственным сервером без блокировки и ожидания доставки клиентских запросов. Решение этой задачи включает одновременную обработку множественных открытых файловых дескрипторов и не ограничено только приложениями с применением сокетов. Рассмотрим функцию .select
Очень часто при разработке приложений Linux вам может понадобиться проверка состояния ряда вводов для того, чтобы определить следующее предпринимаемое действие. Например, программа обмена данными, такая как эмулятор терминала, нуждается в эффективном способе одновременного чтения с клавиатуры и с последовательного порта. В однопользовательской системе подойдет цикл "активного ожидания", многократно просматривающий ввод в поиске данных и читающий их, как только они появятся. Такое поведение очень расточительно в отношении времени ЦП.
Системный вызов
позволяет программе ждать прибытия данных (или завершения вывода) одновременно на нескольких низкоуровневых файловых дескрипторах. Это означает, что программа эмулятора терминала может блокироваться до тех пор, пока у нее не появится работа. Аналогичным образом сервер может иметь дело с многочисленными клиентами, ожидая запросы одновременно на многих открытых сокетах. оперирует структурами данных , представляющими собой множества открытых файловых дескрипторов. Для обработки этих множеств определен набор макросов:#include#include
void FD_ZERO(fd_set *fdset);
void FD_CLR(int fd, fd_set *fdset);
void FD_SET(int fd, fd_set *fdset);
int FD_ISSET(int fd, fd_set *fdset);
Как и предполагается в соответствии с их именами, макрос
инициализирует структуру пустым множеством, и задают и очищают элементы множества, соответствующего файловому дескриптору, переданному как параметр , а макрос возвращает ненулевое значение, если файловый дескриптор, на который ссылается , является элементом структуры , на которую указывает параметр . Максимальное количество файловых дескрипторов в структуре типа задается константой . может также использовать значение для времени ожидания, чтобы помешать бесконечной блокировке. Это значение задается с помощью структуры . Она определена в файле sys/time.h и содержит следующие элементы:time_t tv_sec; /* Секунды */
long tv_usec; /* Микросекунды */, определенный в файле sys/types.h, - целочисленный. Системный вызов объявляется следующим образом:
#include
int select(int nfds, fd_set *readfds, fd_set *writefds,
fd_set *errorfds, struct timeval *timeout);
Вызов . Если параметр - пустой указатель и нет активности на сокетах, вызов может быть заблокирован на неопределенное время. возвращает управление программе, множества дескрипторов будут модифицированы для того, чтобы указать на готовые к чтению или записи или имеющие ошибки дескрипторы. Для их проверки следует использовать макрос , позволяющий определить, какие дескрипторы требуют внимания. Можно изменить значение timeout для того, чтобы показать время, остающееся до следующего превышения времени ожидания, но такое поведение не задано стандартом X/Open. При превышении времени ожидания все множества дескрипторов будут очищены.
Вызов select возвращает общее количество дескрипторов в модифицированных множествах. В случае сбоя он вернет -1 и установит значение переменной
, описывающее ошибку. Возможные ошибки - Выполните упражнение 15.8. Упражнение 15.8. ФункцияДалее для демонстрации применения функции select приведена программа select.c. Более сложный пример вы увидите чуть позже. Программа читает данные с клавиатуры (стандартный ввод - дескриптор 0) со временем ожидания 2,5 секунды. Данные читаются только тогда, когда ввод готов. Естественно расширить программу, включив в зависимости от характера приложения другие дескрипторы, такие как последовательные каналы (serial lines) и сокеты.
1. Начните как обычно с директив
и объявлений, а затем инициализируйте для обработки ввода с клавиатуры:2. Подождите ввод из файла stdin в течение максимум 2,5 секунд:
result = select(FD_SETSIZE, &testfds, (fd_set *)NULL,
3. Спустя это время проверьте
. Если ввода не было, программа выполнит цикл еще раз. Если в нем возникла ошибка, программа завершается:4. Если во время ожидания у вас наблюдаются некоторые действия, связанные с файловым дескриптором, читайте ввод из stdin и выводите его при каждом получении символа EOL (конец строки), до нажатой комбинации клавиш
$ Сервер может применять функцию
одновременно к сокету, ожидающему запросы на подключение, и к сокетам клиентских соединений. Как только активность зафиксирована, можно использовать макрос для проверки в цикле всех возможных файловых дескрипторов и выявления активных среди них.Если сокет, ожидающий запросов на подключение, готов к вводу, это означает, что клиент пытается подсоединиться, и вы можете вызывать функцию
без риска блокировки. Если клиентский дескриптор указывает на готовность, это означает, что есть запрос клиента, ждущий, что вы сможете прочесть и обработать его. Чтение 0 байтов означает, что клиентский процесс завершился, и вы можете закрыть сокет и удалить его из множества своих дескрипторов.Выполните упражнение 15.9.
Упражнение 15.9. Улучшенное клиент-серверное приложение1. В финальный пример программы server5.с вы включите заголовочные файлы sys/time.h и sys/ioctl.h вместо signal.h, использованного в предыдущей программе, и объявите несколько дополнительных переменных для работы с вызовом
:int server_sockfd, client_sockfd;
struct sockaddr_in server_address;
struct sockaddr_in client_address;
2. Создайте сокет для сервера и присвойте ему имя:
server_sockfd = socket(AF_INET, SOCK_STREAM, 0);
server_address.sin_family = AF_INET;
server_address.sin_addr.s_addr = htonl(INADDR_ANY);
server_address.sin_port = htons(9734);
server_len = sizeof(server_address);
bind(serversockfd, (struct sockaddr *)&server_address, server_len);
3. Создайте очередь запросов на соединение и инициализируйте множество
для обработки ввода с сокетаserver_sockfd6. Если зафиксирована активность на
, это может быть запрос на новое соединение, и вы добавляете в множество дескрипторов соответствующий :client_len = sizeof(client_address);client_sockfd = accept(server_sockfd,(struct sockaddr*)&client_address, &client_len);FD_SET(client_sockfd, &readfds);printf("adding client on fd %d\n", client_sockfd);Если активен не сервер, значит, активность проявляет клиент. Если получен
, клиент исчезает, и можно удалить его из множества дескрипторов. В противном случае вы "обслуживаете" клиента, как и в предыдущих примерах.printf("removing client on fd %d\n", fd);
Для полноты аналогии, упомянутой в начале главы, в табл. 15.5 приведены параллели между соединениями на базе сокетов и телефонными переговорами.
Таблица 15.5
Дейтаграммы
В этой главе мы сосредоточились на программировании приложений, поддерживающих связь со своими клиентами с помощью TCP-соединений на базе сокетов. Существуют ситуации, в которых затраты на установку и поддержку соединения с помощью сокетов излишни.
Хорошим примером может служить сервис
, использованный ранее в программе getdate.c. Вы создаете сокет, выполняете соединение, читаете единственный ответ и разрываете соединение. Столько операций для простого получения даты! так же доступен с помощью UDP-соединений, применяющих дейтаграммы. Для того чтобы воспользоваться им, просто пошлите сервису одну дейтаграмму и получите в ответ единственную дейтаграмму, содержащую дату и время. Все просто.Сервисы, предоставляемые по UDP-протоколу, применяются в тех случаях, когда клиенту нужно создать короткий запрос к серверу, и он ожидает единственный короткий ответ. Если стоимость времени процессора достаточно низкая, сервер способен обеспечить такой сервис, обрабатывая запросы клиентов по одному и разрешая операционной системе хранить очередь входящих запросов. Такой подход упрощает программирование сервера.
Поскольку UDP - не дающий гарантий сервис, вы можете столкнуться с потерей вашей дейтаграммы или ответа сервера. Если данные важны для вас, возможно, придется тщательно программировать ваших UDP-клиентов, проверяя ошибки и при необходимости повторяя попытки. На практике в локальных сетях UDP-дейтаграммы очень надежны.
Для доступа к сервису, обеспечиваемому UDP-протоколом, вам следует применять системные вызовы
и , но вместо использования вызовов и для сокета вы применяете два системных вызова, характерных для дейтаграмм: и ./* Начните с обычных include и объявлений. */
int main(int argc, char *argv) {
if (argc == 1) host = "localhost";
/* Ищет адрес хоста и сообщает об ошибке, если не находит. */
hostinfo = gethostbyname(host);
fprintf(stderr, "no host: %s\n", host);
/* Проверяет наличие на компьютере сервиса daytime. */
servinfo = getservbyname("daytime", "udp");
fprintf(stderr, "no daytime service\n");
printf("daytime port is %d\n", ntohs(servinfo->s_port));
/* Создает UDP-сокет. */
sockfd = socket(AF_INEТ, SOCK_DGRAM, 0);
/* Формирует адрес для использования в вызовах sendto/recvfrom... */
address.sin_family = AF_INET;
address.sin_port = servinfo->s_port;
address.sin_addr = *(struct in_addr*)*hostinfo->h_addr_list;
result = sendto(sockfd, buffer, 1, 0, (struct sockaddr *)&address, len);
result = recvfrom(sockfd, buffer, sizeof(buffer), 0,
(struct sockaddr *)&address, &len);
printf("read %d bytes: %s", result, buffer);
Как видите, необходимы лишь незначительные изменения. Как и раньше, вы ищете сервис
с помощью вызова , но задаете дейтаграммный сервис, запрашивая UDP-протокол. Дейтаграммный сокет создается с помощью вызова с параметром . Адрес назначения задается, как и раньше, но теперь вместо чтения из сокета вы должны послать дейтаграмму.Поскольку вы не устанавливаете явное соединение с сервисами на базе UDP, у вас должен быть способ оповещения сервера о том, что вы хотите получить ответ. В данном случае вы посылаете дейтаграмму (в нашем примере вы отправляете один байт из буфера, в который вы хотите получить ответ) сервису и он посылает в ответ дату и время.
Системный вызов
отправляет дейтаграмму из буфера на сокет, используя адрес сокета и длину адреса. У этого вызова фактически следующий прототип:int sendto(int sockfd, void *buffer, size_t len, int flags,
struct sockaddr *to, socklen_t tolen);
В случае обычного применения параметр
можно оставлять нулевым.Системный вызов recvfrom ожидает дейтаграмму в соединении сокета с заданным адресом и помещает ее в буфер. У этого вызова следующий прототип:
В этой главе мы предложили еще один способ взаимодействия процессов - сокеты. Они позволяют разрабатывать по-настоящему распределенные клиент-серверные приложения, которые выполняются в сетевой среде. Было дано краткое описание некоторых информационных функций базы данных сетевых узлов и способы обработки в системе Linux стандартных системных сервисов с помощью интернет-демонов. Вы проработали ряд примеров клиент-серверных программ, демонстрирующих обработку и сетевую организацию множественных клиентов. В заключение вы познакомились с системным вызовомint recvfrom(int sockfd, void *buffer, size_t len, int flags,
и времени ожидания, позволяющих определить, поступили ли данные, так же, как в случае серверов с устанавливаемыми соединениями. В противном случае можно применить сигнал тревоги для прерывания операции получения данных (см. главу 11).
Резюме
При создании сокета необходимо точно специфицировать его тип. Эта спецификация производится с помощью трех параметров вызова socket() . Первый параметр указывает, к какому семейству протоколов относится создаваемый сокет , а второй и третий параметры определяют конкретный протокол внутри данного семейства.
Второй параметр служит для задания вида интерфейса работы с сокетом – будет это потоковый сокет , сокет для работы с датаграммами или какой-либо иной. Третий параметр указывает протокол для заданного типа интерфейса. В стеке протоколов TCP/IP существует только один протокол для потоковых сокетов – TCP и только один протокол для датаграммных сокетов – UDP , поэтому для транспортных протоколов TCP/IP третий параметр игнорируется.
В других стеках протоколов может быть несколько протоколов с одинаковым видом интерфейса, например, датаграммных, различающихся по степени надежности.
Для транспортных протоколов TCP/IP мы всегда в качестве первого параметра будем указывать предопределенную константу AF_INET (Address family – Internet ) или ее синоним PF_INET ( Protocol family – Internet ).
Второй параметр будет принимать предопределенные значения SOCK_STREAM для потоковых сокетов и SOCK_DGRAM – для датаграммных.
Поскольку третий параметр в нашем случае не учитывается, в него мы будем подставлять значение 0 .
Ссылка на информацию о созданном сокете помещается в таблицу открытых файлов процесса подобно тому, как это делалось для pip ’ов и FIFO (см. семинар 5). Системный вызов возвращает пользователю файловый дескриптор , соответствующий заполненному элементу таблицы, который далее мы будем называть дескриптором сокета . Такой способ хранения информации о сокете позволяет, во-первых, процессам-детям наследовать ее от процессов-родителей, а, во-вторых, использовать для сокетов часть системных вызовов, которые уже знакомы нам по работе с pip ’ами и FIFO : close() , read() , write() .
|
Системный вызов для создания сокета Прототип системного вызова #include Описание системного вызова Системный вызов socket служит для создания виртуального коммуникационного узла в операционной системе. Данное описание не является полным описанием системного вызова, а предназначено только для использования в нашем курсе. За полной информацией обращайтесь к UNIX Manual. Параметр domain определяет семейство протоколов, в рамках которого будет осуществляться передача информации. Мы рассмотрим только два таких семейства из нескольких существующих. Для них имеются предопределенные значения параметра:
Параметр type определяет семантику обмена информацией: будет ли осуществляться связь через сообщения (datagrams), с помощью установления виртуального соединения или еще каким-либо способом. Мы будем пользоваться только двумя способами обмена информацией с предопределенными значениями для параметра type :
Параметр protocol специфицирует конкретный протокол для выбранного семейства протоколов и способа обмена информацией. Он имеет значение только в том случае, когда таких протоколов существует несколько. В нашем случае семейство протоколов и тип обмена информацией определяют протокол однозначно. Поэтому данный параметр мы будем полагать равным 0 . Возвращаемое значение В случае успешного завершения системный вызов возвращает файловый дескриптор (значение большее или равное 0 ), который будет использоваться как ссылка на созданный коммуникационный узел при всех дальнейших сетевых вызовах. При возникновении какой-либо ошибки возвращается отрицательное значение. |
Адреса сокетов. Настройка адреса сокета. Системный вызов bind()
Когда сокет создан, необходимо настроить его адрес . Для этого используется системный вызов bind() . Первый параметр вызова должен содержать дескриптор сокета , для которого производится настройка адреса. Второй и третий параметры задают этот адрес .
Во втором параметре должен быть указатель на структуру struct sockaddr , содержащую удаленную и локальные части полного адреса.
Указатели типа struct sockaddr
* встречаются во многих сетевых системных вызовах; они используются для передачи информации о том, к какому адресу привязан или должен быть привязан сокет
. Рассмотрим этот тип данных
подробнее. Структура struct sockaddr
описана в файле
struct sockaddr { short sa_family; char sa_data; };
Такой состав структуры обусловлен тем, что сетевые системные вызовы могут применяться для различных семейств протоколов, которые по -разному определяют адресные пространства для удаленных и локальных адресов сокета . По сути дела, этот тип данных представляет собой лишь общий шаблон для передачи системным вызовам структур данных, специфических для каждого семейства протоколов. Общим элементом этих структур остается только поле short sa_family (которое в разных структурах, естественно, может иметь разные имена, важно лишь, чтобы все они были одного типа и были первыми элементами своих структур) для описания семейства протоколов. Содержимое этого поля системный вызов анализирует для точного определения состава поступившей информации.
Для работы с семейством протоколов TCP/IP
мы будем использовать адрес сокета
следующего вида, описанного в файле
struct sockaddr _in{ short sin_family; /* Избранное семейство протоколов – всегда AF_INET */ unsigned short sin_port; /* 16-битовый номер порта в сетевом порядке байт */ struct in_addr sin_addr; /* Адрес сетевого интерфейса */ char sin_zero; /* Это поле не используется, но должно всегда быть заполнено нулями */ };
Первый элемент структуры – sin_family задает семейство протоколов . В него мы будем заносить уже известную нам предопределенную константу AF_INET (см. предыдущий раздел).
Удаленная часть полного адреса – IP-адрес – содержится в структуре типа struct in_addr , с которой мы встречались в разделе "Функции преобразования IP-адресов inet_ntoa() , inet_aton() " .
Для указания номера порта предназначен элемент структуры sin_port , в котором номер порта должен храниться в сетевом порядке байт . Существует два варианта задания номера порта : фиксированный порт по желанию пользователя и порт , который произвольно назначает операционная система . Первый вариант требует указания в качестве номера порта положительного заранее известного числа и для протокола UDP обычно используется при настройке адресов сокетов и при передаче информации с помощью системного вызова sendto() (см. следующий раздел). Второй вариант требует указания в качестве номера порта значения 0. В этом случае операционная система сама привязывает сокет к свободному номеру порта . Этот способ обычно используется при настройке сокетов программ клиентов, когда заранее точно знать номер порта программисту необязательно.
Какой номер порта может задействовать пользователь при фиксированной настройке? Номера портов с 1 по 1023 могут назначать сокетам только процессы, работающие с привилегиями системного администратора. Как правило, эти номера закреплены за системными сетевыми службами независимо от вида используемой операционной системы, для того чтобы пользовательские клиентские программы могли запрашивать обслуживание всегда по одним и тем же локальным адресам. Существует также ряд широко применяемых сетевых программ, которые запускают процессы с полномочиями обычных пользователей (например, X-Windows). Для таких программ корпорацией Internet по присвоению имен и номеров (
Мне очень нравится весь цикл статей, плюс всегда хотелось попробовать себя в качестве переводчика. Возможно, опытным разработчикам статья покажется слишком очевидной, но, как мне кажется, польза от нее в любом случае будет.
Первая статья - http://habrahabr.ru/post/209144/
Прием и передача пакетов данных
Введение
Привет, меня зовут Гленн Фидлер и я приветствую вас в своей второй статье из цикла “Сетевое программирование для разработчиков игр”.В предыдущей статье мы обсудили различные способы передачи данных между компьютерами по сети, и в конце решили использовать протокол UDP, а не TCP. UDP мы решили использовать для того, чтобы иметь возможность пересылать данные без задержек, связанных с ожиданием повторной пересылки пакетов.
А сейчас я собираюсь рассказать вам, как на практике использовать UDP для отправки и приема пакетов.
BSD сокеты
В большинстве современных ОС имеется какая-нибудь реализация сокетов, основанная на BSD сокетах (сокетах Беркли).Сокеты BSD оперируют простыми функциями, такими, как “socket”, “bind”, “sendto” и “recvfrom”. Конечно, вы можете обращаться к этим функциями напрямую, но в таком случае ваш код будет зависим от платформы, так как их реализации в разных ОС могут немного отличаться.
Поэтому, хоть я далее и приведу первый простой пример взаимодействия с BSD сокетами, в дальнейшем мы не будем использовать их напрямую. Вместо этого, после освоения базового функционала, мы напишем несколько классов, которые абстрагируют всю работу с сокетами, чтобы в дальнейшем наш код был платформонезависимым.
Особенности разных ОС
Для начала напишем код, который будет определять текущую ОС, чтобы мы могли учесть различия в работе сокетов: // platform detection
#define PLATFORM_WINDOWS 1
#define PLATFORM_MAC 2
#define PLATFORM_UNIX 3
#if defined(_WIN32)
#define PLATFORM PLATFORM_WINDOWS
#elif defined(__APPLE__)
#define PLATFORM PLATFORM_MAC
#else
#define PLATFORM PLATFORM_UNIX
#endif
Теперь подключим заголовочные файлы, нужные для работы с сокетами. Так как набор необходимых заголовочных файлов зависит от текущей ОС, здесь мы используем код #define, написанный выше, чтобы определить, какие файлы нужно подключать.
#if PLATFORM == PLATFORM_WINDOWS
#include
В UNIX системах функции работы с сокетами входят в стандартные системные библиотеки, поэтому никакие сторонние библиотеки нам в этом случае не нужны. Однако в Windows для этих целей нам нужно подключить библиотеку winsock.
Вот небольшая хитрость, как можно это сделать без изменения проекта или makefile’а:
#if PLATFORM == PLATFORM_WINDOWS
#pragma comment(lib, "wsock32.lib")
#endif
Мне нравится этот прием потому, что я ленивый. Вы, конечно, можете подключить библиотеку в проект или в makefile.
Инициализация сокетов
В большинстве unix-like операционных систем (включая macosx) не требуется никаких особых действий для инициализации функционала работы с сокетами, но в Windows нужно сначала сделать пару па - нужно вызвать функцию “WSAStartup” перед использованием любых функций работы с сокетами, а после окончания работы - вызвать “WSACleanup”.Давайте добавим две новые функции:
Inline bool InitializeSockets()
{
#if PLATFORM == PLATFORM_WINDOWS
WSADATA WsaData;
return WSAStartup(MAKEWORD(2,2), &WsaData) == NO_ERROR;
#else
return true;
#endif
}
inline void ShutdownSockets()
{
#if PLATFORM == PLATFORM_WINDOWS
WSACleanup();
#endif
}
Теперь мы имеем независимый от платформы код инициализации и завершения работы с сокетами. На платформах, которые не требуют инициализации, данный код просто не делает ничего.
Создаем сокет
Теперь мы можем создать UDP сокет. Это делается так:Int handle = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP);
if (handle <= 0)
{
printf("failed to create socket\n");
return false;
}
Далее мы должны привязать сокет к определенному номеру порта (к примеру, 30000). У каждого сокета должен быть свой уникальный порт, так как, когда приходит новый пакет, номер порта определяет, какому сокету его передать. Не используйте номера портов меньшие, чем 1024 - они зарезервированы системой.
Если вам все равно, какой номер порта использовать для сокета, вы можете просто передать в функцию “0”, и тогда система сама выделит вам какой-нибудь незанятый порт.
Sockaddr_in address;
address.sin_family = AF_INET;
address.sin_addr.s_addr = INADDR_ANY;
address.sin_port = htons((unsigned short) port);
if (bind(handle, (const sockaddr*) &address, sizeof(sockaddr_in)) < 0)
{
printf("failed to bind socket\n");
return false;
}
Теперь наш сокет готов для передачи и приема пакетов данных.
Но что это за таинственная функция “htons” вызывается в коде? Это просто небольшая вспомогательная функция, которая переводит порядок следования байтов в 16-битном целом числе - из текущего (little- или big-endian) в big-endian, который используется при сетевом взаимодействии. Ее нужно вызывать каждый раз, когда вы используете целые числа при работе с сокетами напрямую.
Вы встретите функцию “htons” и ее 32-битного двойника - “htonl” в этой статье еще несколько раз, так что будьте внимательны.
Перевод сокета в неблокирующий режим
По умолчанию сокеты находится в так называемом “блокирующем режиме”. Это означает, что если вы попытаетесь прочитать из него данные с помощью “recvfrom”, функция не вернет значение, пока не сокет не получит пакет с данными, которые можно прочитать. Такое поведение нам совсем не подходит. Игры - это приложения, работающие в реальном времени, со скоростью от 30 до 60 кадров в секунду, и игра не может просто остановиться и ждать, пока не придет пакет с данными!Решить эту проблему можно переведя сокет в “неблокирующий режим” после его создания. В этом режиме функция “recvfrom”, если отсутствуют данные для чтения из сокета, сразу возвращает определенное значение, показывающее, что нужно будет вызвать ее еще раз, когда в сокете появятся данные.
Перевести сокет в неблокирующий режим можно следующим образом:
#if PLATFORM == PLATFORM_MAC || PLATFORM == PLATFORM_UNIX
int nonBlocking = 1;
if (fcntl(handle, F_SETFL, O_NONBLOCK, nonBlocking) == -1)
{
printf("failed to set non-blocking socket\n");
return false;
}
#elif PLATFORM == PLATFORM_WINDOWS
DWORD nonBlocking = 1;
if (ioctlsocket(handle, FIONBIO, &nonBlocking) != 0)
{
printf("failed to set non-blocking socket\n");
return false;
}
#endif
Как вы можете видеть, в Windows нет функции “fcntl”, поэтому вместе нее мы используем “ioctlsocket”.
Отправка пакетов
UDP - это протокол без поддержки соединений, поэтому при каждой отправке пакета нам нужно указывать адрес получателя. Можно использовать один и тот же UDP сокет для отправки пакетов на разные IP адреса - на другом конце сокета не обязательно должен быть один компьютер.Переслать пакет на определенный адрес можно следующим образом:
Int sent_bytes = sendto(handle, (const char*)packet_data, packet_size,
0, (sockaddr*)&address, sizeof(sockaddr_in));
if (sent_bytes != packet_size)
{
printf("failed to send packet: return value = %d\n", sent_bytes);
return false;
}
Обратите внимание - возвращаемое функцией “sendto” значение показывает только, был ли пакет успешно отправлен с локального компьютера. Но оно не показывает, был ли пакет принят адресатом! В UDP нет средств для определения, дошел ли пакет по назначению или нет.
В коде, приведенном выше, мы передаем структуру “sockaddr_in” в качестве адреса назначения. Как нам получить эту структуру?
Допустим, мы хотим отправить пакет по адресу 207.45.186.98:30000.
Запишем адрес в следующей форме:
Unsigned int a = 207;
unsigned int b = 45;
unsigned int c = 186;
unsigned int d = 98;
unsigned short port = 30000;
И нужно сделать еще пару преобразований, чтобы привести его к форме, которую понимает “sendto”:
Unsigned int destination_address = (a << 24) | (b << 16) | (c << 8) | d;
unsigned short destination_port = port;
sockaddr_in address;
address.sin_family = AF_INET;
address.sin_addr.s_addr = htonl(destination_address);
address.sin_port = htons(destination_port);
Как видно, сначала мы объединяем числа a, b, c, d (которые лежат в диапазоне ) в одно целое число, в котором каждый байт - это одно из исходных чисел. Затем мы инициализируем структуру “sockaddr_in” нашими адресом назначения и портом, при этом не забыв конвертировать порядок байтов с помощью функций “htonl” и “htons”.
Отдельно стоит выделить случай, когда нужно передать пакет самому себе: при этом не нужно выяснять IP адрес локальной машины, а можно просто использовать 127.0.0.1 в качестве адреса (адрес локальной петли), и пакет будет отправлен на локальный компьютер.
Прием пакетов
После того, как мы привязали UDP сокет к порту, все UDP пакеты, приходящие на IP адрес и порт нашего сокета, будут ставиться в очередь. Поэтому для приема пакетов мы просто в цикле вызываем “recvfrom”, пока он не выдаст ошибку, означающую, что пакетов для чтения в очерели не осталось.Так как протокол UDP не поддерживает соединения, пакеты могут приходить с множества различных компьютеров сети. Каждый раз, когда мы принимаем пакет, функция “recvfrom” выдает нам IP адрес и порт отправителя, и поэтому мы знаем, кто отправил этот пакет.
Код приема пакетов в цикле:
While (true)
{
unsigned char packet_data;
unsigned int maximum_packet_size = sizeof(packet_data);
#if PLATFORM == PLATFORM_WINDOWS
typedef int socklen_t;
#endif
sockaddr_in from;
socklen_t fromLength = sizeof(from);
int received_bytes = recvfrom(socket, (char*)packet_data, maximum_packet_size,
0, (sockaddr*)&from, &fromLength);
if (received_bytes <= 0)
break;
unsigned int from_address = ntohl(from.sin_addr.s_addr);
unsigned int from_port = ntohs(from.sin_port);
// process received packet
}
Пакеты, размер которых больше, чем размер буфера приема, будут просто втихую удалены из очереди. Так что, если вы используете буфер размером 256 байтов, как в примере выше, и кто-то присылает вам пакет в 300 байт, он будет отброшен. Вы не получите просто первые 256 байтов из пакета.
Но, поскольку мы пишем свой собственный протокол, для нас это не станет проблемой. Просто всегда будьте внимательны и проверяете, чтобы размер буфера приема был достаточно большим, и мог вместить самый большой пакет, который вам могут прислать.
Закрытие сокета
На большинстве unix-like систем, сокеты представляют собой файловые дескрипторы, поэтому для того, чтобы закрыть сокеты после использования, можно использовать стандартную функцию “close”. Однако, Windows, как всегда, выделяется, и в ней нам нужно использовать “closesocket”. #if PLATFORM == PLATFORM_MAC || PLATFORM == PLATFORM_UNIX
close(socket);
#elif PLATFORM == PLATFORM_WINDOWS
closesocket(socket);
#endif
Так держать, Windows!
Класс сокета
Итак, мы разобрались со всеми основными операциями: создание сокета, привязка его к порту, перевод в неблокирующий режим, отправка и прием пакетов, и, в конце, закрытие сокета.Но, как вы могли заметить, все эти операции немного отличаются от платформы к платформе, и, конечно, трудно каждый раз при работе с сокетами вспоминать особенности разных платформ и писать все эти #ifdef.
Поэтому мы сделаем класс-обертку “Socket” для всех этих операций. Также мы создадим класс “Address”, чтобы было проще работать с IP адресами. Он позволит не проводить все манипуляции с “sockaddr_in” каждый раз, когда мы захотим отправить или принять пакет.
Итак, наш класс Socket:
Class Socket
{
public:
Socket();
~Socket();
bool Open(unsigned short port);
void Close();
bool IsOpen() const;
bool Send(const Address & destination, const void * data, int size);
int Receive(Address & sender, void * data, int size);
private:
int handle;
};
И класс Address:
Class Address
{
public:
Address();
Address(unsigned char a, unsigned char b, unsigned char c, unsigned char d, unsigned short port);
Address(unsigned int address, unsigned short port);
unsigned int GetAddress() const;
unsigned char GetA() const;
unsigned char GetB() const;
unsigned char GetC() const;
unsigned char GetD() const;
unsigned short GetPort() const;
bool operator == (const Address & other) const;
bool operator != (const Address & other) const;
private:
unsigned int address;
unsigned short port;
};
Использовать их для приема и передачи нужно следующим образом:
// create socket
const int port = 30000;
Socket socket;
if (!socket.Open(port))
{
printf("failed to create socket!\n");
return false;
}
// send a packet
const char data = "hello world!";
socket.Send(Address(127,0,0,1,port), data, sizeof(data));
// receive packets
while (true)
{
Address sender;
unsigned char buffer;
int bytes_read = socket.Receive(sender, buffer, sizeof(buffer));
if (!bytes_read)
break;
// process packet
}
Как видите, это намного проще, чем работать с BSD сокетами напрямую. И также этот код будет одинаков для всех ОС, потому весь платформозависимый функционал находится внутри классов Socket и Address.
Заключение
Теперь у нас есть независимый от платформы инструмент для отправки и према UDP пакетов.UDP не поддерживает соединения, и мне хотелось сделать пример, который бы четко это показал. Поэтому я написал небольшую программу , которая считывает список IP адресов из текстового файла и рассылает им пакеты, по одному в секунду. Каждый раз, когда программа принимает пакет, она выводит в консоль адрес и порт компьютера-отправителя и размер принятого пакета.
Вы можете легко настроить программу так, чтобы даже на локальной машине получить несколько узлов, обменивающихся пакетами друг с другом. Для этого просто разным экземплярам программы задайте разные порты, например:
> Node 30000
> Node 30001
> Node 30002
И т.д…
Каждый из узлов будет пересылать пакеты всем остальным узлам, образуя нечто вроде мини peer-to-peer системы.
Я разрабатывал эту программу на MacOSX, но она должна компилироваться на любой unix-like ОС и на Windows, однако если вам для этого потребуется делать какие-либо доработки, сообщите мне.
Теги: Добавить метки
Поиск
Мы можем оповещать вас о новых статьях,