117:
118: /* родительский процесс */
119: free(name);
120:
121: /* Обратите внимание, что настройки termios устанавливаются только
122: * для стандартного ввода; ведущая сторона pty НЕ является tty.
123: */
124: tcgetattr(STDIN_FILENO, &ot);
125: t = ot;
126: t.c_lflag &= ~(ICANON | ISIG | ECHO | ECHOCTL | ECHOE |
127: ECHOK | ECHOKE | ECHONL | ECHOPRT);
128: t.c_iflag |= IGNBRK;
129: t.c_cc[VMIN] = 1;
130: t.c_cc[VTIME] = 0;
131: tcsetattr(STDIN_FILENO, TCSANOW, &t);
132:
133: /* Этот код взят без изменений из robin.с
134: * Если дочерний процесс завершается, читающая ведущая сторона
135: * должна вернуть -1 и завершиться.
136: */
137: ufds[0].fd = STDIN_FILENO;
138: ufds[0].events = POLLIN;
139: ufds[1].fd = master;
140: ufds[1].events = POLLIN;
141:
142: do {
143: int r;
144:
145: r = poll(ufds, 2, -1);
146: if ((r < 0) && (errno != EINTR)) {
147: done = 1;
148: break;
149: }
150:
151: /* сначала проверить возможность завершения */
152: if ((ufds[0].revents | ufds[1].revents) &
153: (POLLERR | POLLHUP | POLLNVAL)) {
154: done = 1;
155: break;
156: }
157:
158: if (propagate_sigwinch) {
159: /* обработчик сигнала запросил распространение SIGWINCH */
160: if (ioctl(STDIN_FILENO, TIOCGWINSZ, &ws) < 0) {
161: perror("ptypair: не удается получить размеры окна");
162: }
163: if (ioctl(master, TIOCSWINSZ, &ws) < 0) {
164: perror("не удается восстановить размеры окна");
165: }
166:
167: /* не делать этого снова до поступления следующего SIGWINCH */
168: propagate_sigwinch = 0;
169:
170: /* опрос мог быть прерван SIGWINCH,
171: * потому повторить попытку. */
172: continue;
173: }
174:
175: if (ufds[1].revents & POLLIN) {
176: i = read (master, buf, BUFSIZE);
177: if (i >= 1) {
178: write(STDOUT_FILENO, buf, i);
179: } else {
180: done = 1;
181: }
182: }
183:
184: if (ufds[0].revents & POLLIN) {
185: i = read (STDIN_FILENO, buf, BUFSIZE);
186: if (i >= 1) {
187: write(master, buf, i);
188: } else {
189: done = 1;
190: }
191: }
192: } while (!done);
193:
194: tcsetattr(STDIN_FILENO, TCSANOW, &ot);
195: exit(0);
196: }
Вся добавленная сложность ptytest.с по сравнению с forkptytest.с связана с обработкой старого интерфейса. Все это было описано в данной главе, кроме запуска дочернего процесса, который рассматривался в главе 10.
Глава 17
Работа в сети с помощью сокетов
По мере того, как компьютерный мир все шире объединяется в единую сеть, важность сетевых приложений все больше и больше возрастает. Система Linux предлагает программный интерфейс сокетов Беркли (Беркли), который уже стал стандартным сетевым API. Мы рассмотрим основы использования сокетов Беркли и через сетевой протокол TCP/IP, и через простое межпроцессное взаимодействие (interprocess communication — IPC) с помощью сокетов домена Unix.
Мы не планировали превратить данную главу в полное руководство по программированию для сетей. Это отдельная сложная тема, и для тех программистов, которые планируют серьезную работу с сокетами, мы рекомендуем специализированные книги по программированию для сетей, например, [33]. Этой главы, однако, будет достаточно для того, чтобы вы смогли создавать несложные сетевые приложения.
17.1. Поддержка протоколов
API-интерфейс сокетов Беркли был сконструирован в виде шлюза для нескольких протоколов. Хотя это и приводит к дополнительным сложностям в интерфейсе, это все- таки гораздо легче, чем создавать (или изучать) новый интерфейс для каждого нового протокола, который встречается в работе. В Linux используется интерфейс сокетов для многих протоколов, включая TCP/IP (версии 4 и 6), AppleTalk и IPX.
Мы обсудим применение сокетов для двух протоколов, доступных через реализацию сокетов Linux. Наиболее важным протоколом, поддерживаемым системой Linux, является TCP/IP[115] (Transmission Control Protocol/Internet Protocol — протокол управления передачей/протокол Internet), поскольку именно он управляет всем Internet. Мы также обратим внимание на сокеты домена Unix — механизм IPC, ограниченный одним компьютером. Хотя они и не работают через сеть, сокеты домена Unix широко применяются для приложений, работающих на одном компьютере.
Протоколы, как правило, используются группами, или семействами протоколов. Общераспространенное семейство протоколов TCP/IP среди прочих включает в себя протоколы TCP и UDP (User Datagram Protocol — протокол передачи дейтаграмм пользователя). Для того чтобы хорошо ориентироваться в различных протоколах, потребуется овладеть некоторой терминологией.
17.1.1. Идеальная работа в сети
Большинство пользователей ожидают от сетевых протоколов обеспечения эквивалента каналов Unix между компьютерами. Если байт (или последовательность байтов) поступает в один конец соединения, он обязательно выйдет из другого конца. Причем должен быть гарантирован не просто выход байта из другого конца, а выход непосредственно после того байта, который был отправлен перед ним, и перед байтом, посланным следующим. Конечно, все байты должны быть доставлены в первозданном виде без каких-либо изменений. Никакой другой процесс не может прерывать передачу дополнительными байтами; соединение ограничивается только двумя исходными сторонами.
Хорошей визуализацией этой идеи является телефон. При разговоре предполагается, что собеседник слышит те же самые слова и в том же порядке, что вы произносите.
17.1.2. Реальная работа в сети
Хотя все это кажется достаточно базовым, основные компьютерные сети работают далеко не так. Сеты склонны быть хаотическими и случайными. Представьте себе школьников на перемене, которым не только нельзя разговаривать, но и нужно находиться на расстоянии не менее пяти метров друг от друга. При этом они должны найти способ пообщаться — хотя бы с помощью бумажных самолетиков!
Предположим, что всякий раз, когда школьники хотят кому-нибудь передать информацию, они просто записывают ее на листах бумаги, вкладывают в самолетики, подписывают снаружи имя получателя и бросают их тому, кто расположен ближе к конечному адресату. Посредник смотрит на самолетик, видит назначенную цель и передает письмо следующему лицу. В конечном счете, адресат, которому предназначено сообщение, получит (точнее, может быть, получит) самолетик, развернет его и прочтет письмо.
Хотите верьте, хотите нет, но такая схема практически точно отображает процесс функционирования компьютерных сетей[116]. Посредники здесь носят название маршрутизаторов, а самолетики называются пакетами, но в остальном все происходит именно так. Как и в жизни, некоторые из отправленных самолетиков (или пакетов) теряются. Если сообщение слишком длинное для одного пакета, его нужно распределить по нескольким пакетам (для каждого из которых есть шанс потеряться). Все школьники-посредники могут прочесть пакеты, если им захочется[117], и даже просто выбросить их вместо того, чтобы попытаться доставить их по адресу. При этом кто угодно может прервать ваш диалог, направив в него новые пакеты.
17.1.3. Как заставить реальность играть по точным правилам?
Встречаясь лицом к лицу с реальностью (миллионами бумажных самолетиков), разработчики протоколов прилагают все усилия для того, чтобы представлять сети по аналогии с телефонными линиями, а не со школьниками. Для описания сетевых протоколов установились разнообразные термины.
• Протоколы на основе логических соединений имеют две конечные точки подобно телефонным разговорам. Соединение должно быть установлено до начала передачи информации (ведь вы отвечаете на звонок словом "Алло!", а не начинаете сразу же разговаривать). Остальные пользователи не могут (и даже не должны иметь возможности) вторгаться в соединение. Протоколы, не имеющие таких характеристик, называются протоколами без установления соединения.
• Говорят, что протоколы обеспечивают упорядочение, если они гарантируют доставку данных в том же порядке, в котором они были отправлены.
• Протоколы предоставляют защиту от ошибок в том случае, если они автоматически отбрасывают поврежденные сообщения и подготавливаются к повторной передаче данных.
