Разработка пакета прикладных программ для передачи информации с рпдп

Автоматическая обработка информации РПДП имеет целью обеспечить проверку электрических характеристик и параметров системы управления «Витязь» и вагонного оборудования в вагонах метрополитена. Автоматическая обработка РПДП позволит оперативно находить неисправности системы «Витязь» и вагонного оборудования, анализировать параметры движения поезда, а также анализировать действия машиниста.

Создание программы передачи и обработки информацииможно разделить на две части: разработку функций передачи информации по сети и разработку функций обработки переданной информации.

Организация сетевого соединения с РПДП

Для обеспечения взаимодействия по сети между двумя приложениями (вычислительными процессами) было решено использовать стандартный прикладной программный интерфейс (application programming interface (API)) Winsock. Winsock не является протоколом и является основным средством для программирования сетевых приложений для операционных систем Windows. Winsock предоставляет программный интерфейс для коммуникации процессов с помощью всех известных современных протоколов: TCP/IP версий 4 и 6, IPX/SPX, NetBIOS, ATM, Bluetooth и т. д. Основная цель разработки спецификации Winsock — создать независимый от транспортного протокола программный интерфейс [7].

Различают транспортные протоколы, требующие и не требующие установления логического соединения. Протоколы, устанавливающие соединение, поддерживают информацию о состоянии, которая позволяет следить за последовательностью пакетов. Они самостоятельно отслеживают состояние пакетов. Сохраняемая информация о состоянии позволяет протоколу обеспечить надежную доставку. Например, отправитель запоминает, когда и какие данные послал, но они еще не подтверждены. Если подтверждение не приходит в течение определенного времени, отправитель повторяет передачу. Получатель запоминает, какие данные уже принял, и отбрасывает пакеты-дубликаты. Если пакет поступает не в порядке очередности, то получатель может «придержать» его, пока не придут логически предшествующие пакеты. Как правило, в протоколах, требующих соединения, данные передаются потоком. У типичного протокола, требующего наличия соединения, есть три фазы. Сначала устанавливается соединение между двумя приложениями. Затем происходит обмен данными. И, наконец, когда оба приложения завершили обмен данными, соединение разрывается. Обычно такой протокол сравнивают с телефонным разговором, а протокол, не требующий соединения, — с отправкой почтовой открытки.

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

В связи с многочисленными недостатками протоколов, не требующих соединения, возникает закономерный вопрос: зачем вообще нужен такой вид протоколов? Часто встречаются ситуации, когда для создания приложения использование именно такого протокола оправдано. Например, протокол без соединения может легко поддерживать связь одного хоста со многими и наоборот. Между тем протоколы, устанавливающие соединение, должны обычно организовать по одному соединению между каждой парой хостов. Впрочем, установление канала связи между двумя участниками и гарантия безошибочной с правильным порядком передачи данных влечет дополнительные издержки. С другой стороны, протокол, не требующий соединения, можно использовать для быстрой передачи коротких сообщений.

Internet Protocol (IP) не требует установления соединения и не гарантирует доставку данных, поэтому для передачи данных поверх IP используются два протокола более высокого уровня TCP (Transrmssion Control Protocol — протокол управления передачей) и UDP (User Datagram Protocol пользовательский датаграммный протокол). Каждый TCP и UDP пакет инкапсулируются в поле данных IP-пакета. В стеке TCP/IP протокол UDP работает без установки соединения, передаёт данные в виде дейтаграмм и не гарантирует их безошибочную передачу в правильном порядке. UDP может осуществлять передачу данных множеству адресатов и принимать данные от множества источников. Например, данные, отправляемые клиентом на сервер, передаются немедленно, независимо от того, готов ли сервер к приему. При получении данных от клиента, сервер не подтверждает их прием. Протокол TCP работает с установкой соединения, передаёт данные в виде потока байт и гарантирует их безошибочную передачу в правильном порядке между двумя компьютерами. Когда приложения связываются по TCP, осуществляется виртуальное соединение исходного компьютера с целевым, после чего между ними возможен одновременный двунаправленный обмен данными. То есть в случае протокола TCP имеем полнодуплексную связь, как при телефонном разговоре: два связанных абонентамогут разговаривать одновременно.

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

Сетевой программный интерфейс Winsock основан на понятии сокета. Сокет — это описатель поставщика сетевого транспорта. Создание сокета позволяет приложениям осуществлять сетевое подключение и обмен данными через него. Сокеты являются своего рода представителями или конечными точками сетевого соединения как со стороны клиента, так и со стороны сервера. В Win32, в отличие от UNIX/LINUX, сокет отличается от описателя файла, а потому представлен отдельным типом — SOCKET (переопределенное беззнаковое целое).Это означает, что в отличие от UNIX/LINUX, с сокетом нельзя обмениваться информацией с помощью файловых функций ввода и вывода типа read и write. В проектируемой системе клиент (стенд обработки информации) — это «сторона» соединения, которая запрашивает определенные данные, а сервер (регистратор параметров движения поезда) отвечает в соответствии с этими запросами. В приложении сокет клиента создается следующим образом:

Листинг 3.1.1.

s = socket (AF_INET, SOCK_DGRAM, 0);

Первый параметр определяет семейство адресов протокола. Чтобы ссылаться на протокол IP версии 4 первый параметр необходимо задать как AF_INET.Второй параметр —это тип сокета для данного протокола. Он может принимать одно из следующих значений SOCK_STREAM (потоковый сокет для TCP), SOCK_DGRAM (для UDP), SOCK_RAW и т. д. Создавая UDP сокет, необходимо указать значение SOCK_DGRAM. Третий параметр указывает конкретный транспорт, если для данного семейства адресов и типа сокета существует несколько записей. Значение «0» может быть использовано для выбора протокола по умолчанию из указанного семейства адресов и типа сокета. При успешном вызове функция socket возвращает дескриптор, ссылающийся на новый сокет.

Когда сокет создается при помощи socket (), он ассоциируется с некоторым семейством адресов, но не с конкретным адресом. Такой сокет называют несвязанным.

Рисунок 3.1.1 Несвязанный сокет.

До того как сокет сможет принять входящие соединения, он должен быть связан с адресом. Необходимо указать IP-адрес сетевого интерфейса клиента и номер порта службы. В Winsock IP-адрес и порт службы задают в структуре:

Листинг 3.1.2.

struct sockaddr_in.

{.

short sin_family;

unsigned short sin_port;

struct in_addr sin_addr;

char sin_zero[8];

}.

Поле sin_family должно быть равно AF_ INET (IP версии 4). Поле sin_port задает, какой коммуникационный порт TCP или UDP будет использован. Очень важно осторожно относиться к выбору порта, поскольку некоторые доступные порты зарезервированы для использования популярными службами: такими, как File Transfer Protocol (FTP) и Hypertext Transfer Protocol (HTTP). Во избежание накладок с портами, уже занятыми системой или другим приложением, программа должна выбирать зарегистрированные порты в диапазоне 1024−49 151.

Поле sin_addr структуры sockaddr_in имеет тип:

Листинг 3.1.3.

struct in_addr.

{.

unsigned long s_addr;

}.

То есть sin_addr структуры sockaddr_in хранит IP-адрес в 4-байтном виде с типом unsigned long int с сетевым порядком байт. В зависимости от того, как это поле использовано, оно может представлять и локальный, и удаленный IP-адрес.

Далее представлена функция, заполняющая структуру sockaddr_in необходимыми адресами:

Листинг 3.1.4.

void set_address (struct sockaddr_in *sa, char *ipaddr, int port).

{.

bzero (sa, sizeof (struct sockaddr_in));

sa->sin_family = AF_INET;

sa->sin_port = htons (port);

if (ipaddr==0).

sa->sin_addr.s_addr = htonl (INADDR_ANY);

else.

sa->sin_addr.s_addr = inet_addr (ipaddr);

}.

Если номер порта и IP-адрес хранятся в памяти компьютера как многобайтные числа, они представляются в системном порядке (host-byte-order). Стандарты Интернета требуют, чтобы многобайтные значения представлялись от старшего байта к младшему (в порядке big-endian), что обычно называется сетевым порядком (network-byte order). Есть целый ряд функций для преобразования многобайтных чисел из системного порядка в сетевой и обратно. Например, вспомогательная функция inet_addr () преобразует IP-адрес из точечной нотации в 32-битное длинное целое без знака с сетевым порядком следования байт (network-byte order). А функция htons () преобразует порт из четырехбайтного числа с системным порядком следования байт в число с сетевым порядком.

Если конкретный IP-адрес не указан (ipaddr==0), существует специальный IP-адрес INADDR_ANY, позволяющий приложению вести передачу через любой сетевой интерфейс на несущем компьютере. Если на компьютере несколько сетевых адаптеров, то этот адрес позволит отдельному приложению получать отклики от нескольких интерфейсов.

После создания сокета и инициализации структуры адресов sockaddr_in, можно произвести ассоциирование сокета с оконечной точкой. В приложении для ассоциирования вызывается функция bind (). Этот вызов принимает параметры, в которых задаются дескриптор созданного сокета и адрес оконечной точки, записанный в структуру sockaddr_in, который включает IPадрес и номер порта точки.

Листинг 3.1.5.

ret = bind (s, (struct sockaddr *)sa, sizeof (struct sockaddr_in));

Функция bind () принимает три аргумента: s— дескриптор, представляющий сокет при привязке; (struct sockaddr *)sa — указатель на структуру sockaddr, представляющую адрес, к которому привязываем; sizeof (struct sockaddr_in) — поле, представляющее длину структуры sockaddr.

Таким образом, следующая функция создает UDP-клиента:

Листинг 3.1.6.

SOCKET udp_client (struct sockaddr_in *sa, char *ipaddr, int port).

{.

SOCKET s;

int ret;

set_address (sa, ipaddr, port);

s = socket (AF_INET, SOCK_DGRAM, 0);

bind (s,(struct sockaddr*)sa, sizeof (struct sockaddr_in));

if (!sock_valid (s)).

{.

return -1;

}.

return s;

}.

Рисунок 3.1.2 Связанный сокет.

Таким образом, так как в разрабатываемом приложении используется UDP протокол, для клиента связывание осуществляется явным вызовом функции bind (), а для сервера привязка сокета к локальному адресу осуществляется неявно с помощью функции sendto ().

В программах с установлением логического соединения после создания TCP сокета и связывания его со своим адресом и портом вызывают функцию listen (), чтобы подготовить его для приема входящих запросов на установление соединения. Большая часть серверных программ состоит из бесконечного цикла, в котором принимается очередной входящий запрос на установление соединения, выполняется его обработка, а затем происходит возврат к выполнению операции приемаочередного входящего соединения. Для обеспечения того, чтобы не был потерян ни один запрос на установление соединения, сервер должен передать функции listen () параметр, который указывает операционной системе, что запросы на установлениесоединения, поступающие в сокет, нужно ставить в очередь. Поэтому один параметр вызова функции listen () указывает сокет, который должен быть переведен впассивный режим, а другой — размер очереди, предназначенной для этого сокета. При работе с сокетами TCP после вызова в серверной программе функций socket () (для создания сокета), bind () (для указания адреса локальной оконечной точки) и listen () (для перевода сокета в пассивный режим прослушивания) вызывается функция accept () для извлечения из очереди следующего входящего запроса на установление соединения. Параметр функции accept () указывает сокет, из очереди которого должен быть принят запрос на соединение. Функция accept () создает новый сокет для каждого нового запроса на соединение и возвращает дескриптор нового сокета в вызывающую программу. В сервере новый сокет используется только для нового соединения, а первоначальныйсокет служит для приема следующих запросов на соединение. Сразу после приема запроса на соединение сервер может передавать данные через новый сокет с помощью функций send () и recv ().

Для формирования запроса на установление соединения сокета клиента TCP с сокетом сервера используется функция connect (), в которой указывается IP-адрес и номер порта протокола сервера, на котором должен существовать пассивный сокет, привязанный к адресу и порту.

Сокеты UDP позволяют не производить соединение (connect ()), а сразу передавать и принимать данные от произвольных абонентов с помощью функций sendto () и recvfrom (). Если же функция connect () используется, то она просто определяет адрес назначения по умолчанию для дальнейшего использования для обмена данными функций send () иrecv () вместо sendto () и recfrom (). Любая дейтаграмма, полученная от адреса отличного от адреса назначения, будет отброшена.

Для приема данных от РПДП используется функция recvfrom (), она получает дейтаграмму и возвращает адрес источника. Функция имеет вид:

Листинг 3.1.7.

int recvfrom (SOCKET s, char* buf, int len, int flags, struct sockaddr* from, int* fromlen);

Параметр s задаёт связанный сокет, bufбуфер для входящих данных, lenдлину буфера в байтах, from — необязательный указатель на структуруsockaddr в которой будет возвращен адрес источника, fromlenнеобязательный указатель на размер в байтах адреса источника. Если не произошла ошибка, то функция возвращает число принятых байт, которых может быть меньше len, иначе может быть получен код ошибки SOCKET_ERROR (с помощью функции WSAGetLastError). Данные извлекаются из первого сообщения в очереди вплоть до размера указанного буфера. Если сообщение в очереди длиннее, чем буфер, то буфер заполняется начальной частью сообщения, recvfrom () генерирует сообщение WSAEMSGSIZE. Для протокола UDP оставшиеся в сообщении данные теряются. Если сообщение в очереди короче, чем буфер, то ошибок не возникает, recvfrom () забирает всё сообщение в буфер и возвращает длину сообщения. Если параметр from не равен нулю, сетевой адресотправителя данных копируется в структуру sockaddr, на которую указываетfrom. Величина на которую указывает fromlen устанавливается в размер этой структуры и при возврате изменяется, показывая истинный размер адреса, сохранённого в структуре sockaddr.

Функцияsendto () отсылает данные регистратору параметров движения поезда. Прототип определён в файле Winsock2.h. Библиотека импорта Ws2₃₂.lib. Код расположен в Ws2₃₂.dll. Функция имеет вид:

Листинг 3.1.8.

int sendto (SOCKET s, const char* buf, int len, int flags, const struct sockaddr* to, int tolen);

Парметр s определяет сокет, который может быть уже и соединён, buf — буфер, содержащий данные для передачи, len — длина буфера в байтах (для UDP сокетов параметр lenне может превосходить максимального значения, которое можно получить вызвав getsockopt с парамертом SO_MAX_MSG_SIZE, flagsв большинсве случаях устанавливают в 0, to — необязательный указатель на структуру, которая содержит адрес целевого сокета, tolen — размер адреса в байтах. Параметр to может быть любым действительным адресом, включая широковещательные. Если сокет не связан, то при вызове sendto () WinSock назначает ему локальный адрес и уникальный порт, осуществляя тем самым неявнуюпривязку сокета. Успешный вызов sendto () не означает, что данные были успешно доставлены. Обычно sendto () используется на сокетах, не ориентированныхна соединение для пересылки дейтаграмм к указанному сокету, определённому в параметре to.