Формирование пакетов в формате выбранного нами протокола.
«Разбор» (parse) пакетов в формате выбранного протокола.
В данной статье мы сосредоточимся на первой задаче. Вообще-то, мы не собирались здесь вдаваться в детали программирования сокетов (sockets), полагая, что читатели знакомы с данным вопросом. Однако думается, что несколько слов сказать все же стоит. Тем не менее мы настоятельно (а как же :) советуем тем, кто не знаком с данным вопросом, изучить его подробнее применительно к той ОС под которой придется программировать.
(для UNIX см. например http://world.std.com/~jimf/papers/sockets/sockets.html)
мы же приведем простую реализацию, которая нам понадобится в дальнейшем. Те же, кто уже сталкивался с программированием сокетов могут запросто пропустить данную статью, обратившись, может быть, к нескольким последним абзацам.
2.2 Общие принципы.
Связь по TCP/IP устанавливается по принципу "точка-точка"; инициирующая сторона называется клиентом, принимающая -- сервером. Сервер постоянно находится в ожидании входящих соединений (как говорят, "слушает" -- listening), клиент же посылает запрос на установление связи, используя IP-номер (IP-адрес) сервера и номер порта. IP-адрес это тридцатидвухразрядное число, представляемое обычно в т. н. dotted нотации:
XXX.XXX.XXX.XXX
(байты разделены точками, кажда из групп XXX может принимать значения от 0 до 255). Номер же прота можно рассматривать как указание на конкретный сервис данного узла. Таким образом, для установки соединения клиенту необходимо знать пару чисел IP-адрес:порт (например 192.18.97.241:80 дает нам www-сервер компании Sun Microsystems :). Мы не станем здесь останавливаться на службе доменных имен (предыдущий пример можно записать проще: http://www.sun.com:80), URL и прочем, полагая, что читателю это знакомо. Заметим только, что существуют стандартные соглашения на присваивание номеров портов сервисам (в предыдущем примере использован порт 80 -- http; можно упомянуть порт 21 -- ftp, 23 -- telnet и 25 -- smpt), посему для "нестандартных" сервисов рекомендуется брать "большие" номера (мы предпочитаем номера начиная с 8100). Кстати, из вышесказанного видно, что работа с сокетами на клиентской и серверной сторонах различна. Мы начнем (сюрприз!) с серверной части.
2.2 Сервер.
Простейшая реализация TCP/IP сервера может быть представлена следующим кодом (socktest.c):
Мы постарались сделать код переносимым (по крайней мере между Windows и Linux. Для того, чтобы собрать данный пример под Windows мы должны указать компоновщику на библиотеку wsock32.lib). Как видно из предыдущего примера, "открытие порта на прослушку" -- операция достаточно простая: необходимо создать сокет (socket(2)), заполнить и связать с сокетом структуру sockaddr_in (bind(2)), после чего вызвать listen(2). В данном примере сервер начинает "слушать" по порту 8100. По приходу запроса отрабатывает функция accept(2), которая создает новый сокет, оставляя "старый" готовым к приему нового соединения. Новый сокет готов к приему-передаче данных, мы посылаем приветствие и закрываем оба сокета (тонко, правда? ;).
Обратим внимание на то, что accept является блокирующим вызовом, т. е. поток исполнения не проходит ниже этой строчки, пока не принято входящее соединение, и наша программа не может в это время делать ничего, кроме как "болтаться в accept'е". Кроме того, данный пример написан так, что принимает только одно соединение. Мы могли бы не закрывать первый сокет, а снова вызвать с ним accept для приема второго соединения, однако проблема блокировки вызовом accept все равно не была бы решена (несколько забегая вперед, заметим, что и функция приема данных из сокета recv(2) также является блокирующей). Часто данную проблему снимают организуя многопоточное (multithreaded) приложение, в котором каждое соединение обрабатывается в собственном потоке или, под UNIX, используют вызов разделения процесса fork(2) (кстати, ежели кто не понял, зачем двойки в скобках, -- это означает вторую секцию руководства). Добиться переносимости такого кода -- задача совсем нетривиальная, мы же пока не хотим привязываться к платформе, насколько это возможно, и потому воспользуемся вызовом select(2), который присутствует и в UNIX и в Windows. Функция select ожидает изменения статуса набора дескрипторов (в Windows поддерживаются только сокеты, а в UNIX -- файловые дескрипторы, коими сокеты и являются). Кроме того, нам потребуется перевести наши сокеты в неблокирующее состояние (non-blocking mode).
Все вышесказанное отражено в следующем примере, состоящем из трех файлов (по прежнему, в Windows следует подключать библиотеку wsock32.lib):
// select failing breaks the work
if (select(maxfd + 1, &readfds, NULL, &exfds, &tv) == -1) break;
// On exception in server socket also breaks immediately
if(FD_ISSET(ssocket, &exfds)) break;
// Test events on client sockets
for (ii = clients.begin(); ii != clients.end(); ++ii) {
if (FD_ISSET(*ii, &exfds)) {
if (*ii != INVALID_SOCKET) shutdown_socket(&(*ii));
if ((ii = clients.erase(ii)) == clients.end()) break;
}
if (FD_ISSET(*ii, &readfds) && ! process_data(*ii)) {
if (*ii != INVALID_SOCKET) shutdown_socket(&(*ii));
if ((ii = clients.erase(ii)) == clients.end()) break;
}
// Send data
if (*ii != INVALID_SOCKET)
if (send(*ii, "Connection is established ",
strlen("Connection is established "), 0) == SOCKET_ERROR)
if ((ii = clients.erase(ii)) == clients.end()) break;
}
}
for (ii = clients.begin(); ii != clients.end(); ++ii)
if (*ii != INVALID_SOCKET) shutdown_socket(&(*ii));
shutdown_socket(&ssocket);
return 0;
}
--------------------------------------------------------------------------------
В этом примере мы получили возможность обрабатывать несколько входящих соединений (хотя, если в канале нет данных от клиента, то select ждет 1 секунду; таким образом, мы не можем отправлять данные клиентам чаще, но этого нам в дальнейшем будет достаточно) и не останавливаться на блокирующих вызовах. Интервал в 1 секунду выбран произвольно. Мы можем испытать наш сервер, набрав команду:
telnet localhost 8200
Остановить выполнение сервера можно с помощью Ctrl-C :). Разумеется, в приведенном примере еще многое можно "подрихтовать" (например, можно проверять, доступен ли сокет для записи перед вызовом send или проверять код ошибки accept), но мы объявим серверную часть готовой и перейдем, наконец, к клиенту.
2.3 Клиент.
Программирование клиентских сокетов несколько проще, чем серверных. На клиенте достаточно создать сокет с помощью socket(2) и соединить с удаленной стороной с помощью connect(2). После этого сокет готов к приему и передаче данных. Просто приведем пример.
В этом примере мы устанавливаем соединение с нашим сервером, дожидаемся приветствия, посылаем ответное и закрываем соединение. Напомним, что recv(2) является блокирующим вызовом, что нас, вообще говоря, не устраивает. Тем не менее, мы снова можем перевести наш сокет в неблокирующее состояние и воспользоваться select. Мы так и поступим в дальнейшем, а этот пример просто показывает технику написания простейшего клиента, и мы с удовольствием обнаруживаем, что это не слишком сложно. В завершение обратим внимание на вызовы inet_addr(3) и htons(3). Первая функция дает IP-адрес по символьному его представлению, а вторая переводит short int в целое с порядком байтов, принятых в сети. Часто этот порядок совпадает с порядком байтов в машинном представлении, но может и не совпадать (имеется ввиду т. н. LSB и FSB представления). Впрочем, это уже тонкости, о которых можно почитать и в другом месте :). И наконец, можно на досуге взглянуть на функцию gethostbyname(3), которая выполняет т. н. разрешение (resolving) по имени хоста. Используя ее, мы могли бы обратиться к нашему серверу не по IP-адресу, а по его имени ("localhost").
Глава 3 Заключение.
Итак, в данной статье мы выяснили, как обращаться с сокетами. Те, кто уже имел с ними дело (и набрался терпения дочитать до этого места), наверное обратили внимание на то, что мы использовали "классическую" Берклиевскую реализацию. Она хороша тем, что в большинстве случаев переносима между платформами, однако нам бы не хотелось подталкивать разработчиков к использованию именно такого подхода, тем более, что, как мы в дальнейшем увидим, для работы с SMS-протоколами это совсем необязательно, ибо они абстрагированы от деталей установки соединения. Например, те, кто программирует под Windows, могут воспользоваться функциями из семейства WSA* (если, конечно, не уснут, читая их перечень :), а программисты, привыкшие работать с MFC, возможно найдут полезным класс CSocket (правда, если Вы собираетесь использовать его в мультипоточном приложении с CWinThread, не забудьте включить заклинание:
-------------------------------------------------------------------------------- v
#ifndef _AFXDLL
#define _AFX_SOCK_THREAD_STATE AFX_MODULE_THREAD_STATE
#define _afxSockThreadState AfxGetModuleThreadState()
_AFX_SOCK_THREAD_STATE* pState = _afxSockThreadState;
if (pState->m_pmapSocketHandle == NULL)
pState->m_pmapSocketHandle = new CMapPtrToPtr;
if (pState->m_pmapDeadSockets == NULL)
pState->m_pmapDeadSockets = new CMapPtrToPtr;
if (pState->m_plistSocketNotifications == NULL)
pState->m_plistSocketNotifications = new CPtrList;
#endif
--------------------------------------------------------------------------------
в код thread'а до самой первой сокетной операции; возможно, это сэкономит Вам выходные ;). И, в конце концов, Вы можете воспользоваться компонентами (Привет, Михаил! ;), которых достаточно много и которые достаточно "бросить" на форму, особенно это касается поклонников продуктов от Borland.
Мы же на этом закончим обсуждение вопроса, еще раз напомнив о предложении внимательно его изучить, а то что-то мы увлеклись сокетами; пора переходить к содержательной части дела. В следующей статье мы попробуем построить наше первое "настоящее" SMS-приложение и добавим функциональности нашему эмулятору. Оставайтесь с нами!
