Уильям Стивенс - UNIX: разработка сетевых приложений

В листинге 21.7 показано несколько типичных примеров результата выполнения нашей программы.

Листинг 21.7. Типичный анонс SAP/SDP

freebsd % mysdr

From 128.223.83.33:1028 hash 0x0000 v=0

o=- 60345 0 IN IP4 128.223.214.198

s=UO Broadcast - NASA Videos - 25 Years of Progress

i=25 Years of Progress, parts 1-13. Broadcast with Cisco System's

IP/TV using MPEG1 codec (6 hours 5 Minutes; repeats) More information

about IP/TV and the client needed to view this program is available

from http://videolab.uoregon.edu/download.html

u=http://videolab.uoregon.edu/

e=Hans Kuhn

p=Hans Kuhn <541/346-1758>

b=AS:1000

t=0 0

a=type:broadcast

a=tool:IP/TV Content Manager 3.2.24

a=x-iptv-file:1 name y:25yop1234567890123.mpg

m=video 63096 RTP/AVP 32 31 96

c=IN IP4 224.2.245.25/127

a=framerate:30

a=rtpmap:96 WBIH/90000

a=x-iptv-svr:video blaster2.uoregon.edu file 1 loop

m=audio 31954 RTP/AVP 14 96 0 3 5 97 98 99 100 101 102 10 11 103 104 105 106

c=IN IP4 224.2.216.85/127

a=rtpmap:96 X-WAVE/8000

a=rtpmap:97 L8/8000/2

a=rtpmap:98 L8/8000

a=rtpmap:99 L8/22050/2

a=rtpmap:100 L8/22050

a=rtpmap:101 L8/11025/2

a=rtpmap:102 L8/11025

a=rtpmap:103 L16/22050/2

a=rtpmap:104 L16/22050

a=rtpmap:105 L16/11025/2

a=rtpmap:106 L16/11025

a=x-iptv-svr:audio blaster2.uoregon.edu file 1 loop

Этот анонс описывает рассылки, посвященные истории NASA (National Aeronautics and Space Administration — НАСА, государственная организация США, занимающаяся исследованием космоса). Описание сеанса SDP состоит из множества строк следующего формата:

type=value

где typeвсегда является одним символом, значение которого зависит от регистра, a value— это структурированная текстовая строка, зависящая от значения type. Пробелы справа и слева от знака равенства недопустимы. v=0(в нашем случае) обозначает версию (version).

■ o=обозначает источник (origin). В данном случае имя пользователя не указано, 60345 — идентификатор сеанса, 0 — номер версии этого сеанса, IN— тип сети, IР4 — тип адреса, 128.223.214.198— адрес. В результате объединения этих пяти элементов — имя пользователя, идентификатор сеанса, тип сети, тип адреса и адрес — образуется глобально уникальный идентификатор сеанса.

■ s=задает имя сеанса (session name), а i=— это информация о сеансе (information). u=указывает URI (Uniform Resource Identifier — уникальный идентификатор ресурса), по которому можно найти более подробную информацию по тематике данного сеанса, а р=и e=задают номер телефона (phone number) и адрес электронной почты (e-mail) ответственного за данную конференцию.

■ b=позволяет оценить пропускную способность, необходимую для приема данного сеанса.

■ t=задает время начала и время окончания сеанса в единицах NTP (Network Time Protocol — синхронизирующий сетевой протокол), то есть число секунд, прошедшее с 1 января 1900 года, измеренное в соответствии с UTC (Universal Time Coordinated — универсальное скоординированное время). Данный сеанс является постоянным и не имеет конкретных моментов начала и окончания, поэтому соответствующие времена полагаются нулевыми.

■ Строки a=представляют собой атрибуты, либо сеанса, если они помещены до первой строки m=, либо мультимедиа, если они помещены после первой строки m=.

■ Строки m=— это анонсы мультимедиа. Первая строка говорит нам о том, что видео передается на порт 63 096 в формате RTP с использованием профиля аудио и видео (Audio/Video Profile, AVP) с возможными типами данных 32, 31 и 96 (то есть MPEG, H.261 и WBIH соответственно). Строка c=сообщает о соединении. В данном случае используется протокол IPv4 с групповым адресом 224.2.245.25 и TTL = 127. Хотя между этими числами стоит символ «косая черта», как в формате CIDR, они ни в коем случае не должны трактоваться как префикс и маска.

Следующая строка m=говорит, что аудиопоток передается на порт 31 954 и может иметь один из типов RTP/AVP, некоторые из которых являются стандартными, в то время как другие указаны ниже в виде атрибутов a=rtpmap:. Строка с=сообщает нам сведения об аудиосоединении: IPv4 с групповым адресом 224.2.216.85 и TTL = 127.

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

В листинге 21.8 показана функция mainнашей программы.

Листинг 21.8. Создание сокетов, вызов функции fork и запуск отправителя и получателя

//mcast/main.c

1 #include "unp.h"

2 void recv_all(int, socklen_t);

3 void send_all(int. SA *, socklen_t);

4 int

5 main(int argc, char **argv)

6 {

7 int sendfd, recvfd;

8 const int on = 1;

9 socklen_t salen;

10 struct sockaddr *sasend, *sarecv;

11 if (argc != 3)

12 err_quit("usage: sendrecv ");

13 sendfd = Udp_client(argv[1], argv[2], (void**)&sasend, &salen);

14 recvfd = Socket(sasend->sa_family, SOCK_DGRAM, 0);

15 Setsockopt(recvfd, SOL_SOCKET, SO_REUSEADDR, &on, sizeof(on));

16 sarecv = Malloc(salen);

17 memcpy(sarecv, sasend, salen);

18 Bind(recvfd, sarecv, salen);

19 Mcast_join(recvfd, sasend, salen, NULL, 0);

20 Mcast_set_loop(sendfd, 0);

21 if (Fork() == 0)

22 recv_all(recvfd, salen); /* дочерний процесс -> получение */

23 send_all(sendfd, sasend, salen); /* родитель -> отправка */

24 }

Мы создаем два сокета, один для отправки и один для получения. Нам нужно, чтобы принимающий сокет связался при помощи функции bindс группой и портом, допустим 239.255.1.2, порт 8888. (Вспомните, что мы могли просто связать универсальный IP-адрес и порт 8888, но связывание с определенным адресом многоадресной передачи предотвращает получение сокетом других дейтаграмм, которые могут прийти на порт получателя 8888.) Далее, нам нужно, чтобы принимающий сокет присоединился к группе. Отправляющий сокет будет отправлять дейтаграммы на этот же адрес многоадресной передачи и этот же порт, то есть на 239.255.1.2, порт 8888. Но если мы попытаемся использовать один сокет и для отправки, и для получения, то адресом отправителя для функции bindбудет 239.255.1.2.8888 (здесь используется нотация netstat), а адресом получателя для функции sendto— также 239.255.1.2.8888. Но адрес отправителя, связанный с сокетом, становится IP-адресом отправителя дейтаграммы UDP, a RFC 1122 [10] запрещает дейтаграмме IP иметь IP-адрес отправителя, являющийся адресом многоадресной или широковещательной передачи. (См. также упражнение 21.2.) Следовательно, мы создаем два сокета: один для отправки, другой для получения.