TCP/IP Архитектура, протоколы, реализация (включая IP версии 6 и IP Security)
Шрифт:
13.9.1 Сигнал синхронизации
Для некоторых функций (например, Interrupt Process) включение команды в общий поток данных не приводит к нужным результатам. Когда реальный терминал посылает сигнал прерывания, хост операционной системы получает этот сигнал сразу и быстро останавливает текущее приложение.
Однако, когда telnet работает поверх сеанса TCP, данные доставляются по мере получения. Обычно удаленный сервер telnet последовательно обрабатывает все полученные данные. Может пройти много времени, прежде чем он увидит команду прерывания в поступающем потоке данных.
Клиент хочет быстро обратить внимание сервера на эту команду и должен сообщить ему. "Отбросить все уже буферированные символы, за исключением команд". Для этого клиент посылает серверу специальный сегмент TCP, называемый
■ Такой сегмент маркирован как срочные данные (Urgent Data).
■ Сервер будет отбрасывать всю информацию от клиента, за исключением команд, пока не достигнет специального командного кода, называемого меткой данных (Data Mark — DM).
■ DM маркирует место, где сервер должен прекратить отбрасывание данных.
Когда поступает сегмент сигнала синхронизации, сервер извлекает из потока данных команды NVT, отбрасывая все остальное, пока не дойдет до Data Mark. Затем он переходит к выполнению извлеченных команд, а далее возобновляется нормальная обработка данных (стоящих после Data Mark).
13.9.2 Декодирование наиболее общих команд
В таблице 13.2 приведен список акронимов для некоторых наиболее распространенных команд (вместе с десятичными значениями их кодов). Каждой команде должен предшествовать октет 255 (X'FF), когда она пересылается по соединению telnet.
Таблица 13.2 Коды команд telnet
Акроним | Команда | Код |
---|---|---|
EOF | End of File (конец файла) | 236 |
SUSP | Suspend Current Process (приостановить текущий процесс) | 237 |
ABORT | Abort Process (аварийное завершение процесса) | 238 |
EOR | End of Record (конец записи) | 239 |
NOP | No Operation (нет операции) | 241 |
DM | Data Mark (метка данных) | 242 |
BRK | Break (прерывание) | 243 |
IP | Interrupt Process (прерывание процесса) | 244 |
AO | Abort Output (отменить вывод) | 245 |
AYT | Are You There (вы здесь?) | 246 |
EC | Erase Character (стирание символа) | 247 |
EL | Erase Line (стирание строки) | 248 |
GA | Go Ahead (продолжить) | 249 |
13.9.3 Кодирование запросов выбора вариантов
Запросы выбора вариантов кодируются тремя байтами: байтом IAC, октетом запроса и кодом варианта. Например, десятичное представление последовательности для WILL TERMINAL TYPE выглядит так:
IAC | WILL | TERMINAL TYPE |
---|---|---|
255 | 251 | 24 |
Это один из вариантов для дополнительного согласования. Далее должны следовать:
СЕРВЕР:
IAC | SB | TERMINAL TYPE | SEND | IAC | SE |
---|---|---|---|---|---|
255 | 250 | 24 | 1 | 255 | 240 |
КЛИЕНТ:
IAC | SB | TERMINAL TYPE | IS | DEC-VT220 | IAC | SE |
---|---|---|---|---|---|---|
255 | 250 | 24 | 0 | DEC-VT220 | 255 | 240 |
В таблице 13.3 показаны десятичные значения для кодов обычных и дополнительных согласований. Приведены также коды для часто используемых вариантов. Параметры дополнительного согласования и коды добавочных вариантов определены во многих RFC,
Таблица 13.3 Коды согласования и выбора вариантов
Коды согласования | |
---|---|
Запрос | Код |
WILL (будет) | 251 |
WONT (не будет) | 252 |
DO (выполнить) | 253 |
DON'T (не выполнять) | 254 |
SB (Start Subnegotiation, начало дополнительного согласования) | 250 |
SE (End Subnegotiation, конец дополнительного согласования) | 240 |
Примеры кодов вариантов | |
Command Option (вариант команды) | Код |
Transmit Binary (пересылка двоичных данных) | 0 |
Echo (эхо-печать) | 1 |
Suppress Go Ahead (подавление сообщения Go Ahead) | 3 |
Status (состояние) | 5 |
Timing Mark (метка времени) | 6 |
Output Line Width (длина выходной строки) | 8 |
Output Page Size (размер выводимой страницы) | 9 |
Extended ASCII (расширенный набор ASCII) | 17 |
Data Entry Terminal (терминал ввода данных) | 20 |
Terminal Type (тип терминала) | 24 |
End of Record (конец записи) | 25 |
Window Size (размер окна) | 31 |
Terminal Speed (скорость терминала) | 32 |
Remote Flow Control (удаленное управление потоком) | 33 |
Linemode (построчный режим) | 34 |
Authentication (аутентификация) | 37 |
Encryption (шифрование) | 38 |
Extended Options List (расширенный список вариантов) | 255 |
13.9.4 Дополнительные сведения о вариантах
Более тридцати RFC детально рассматривают различные варианты, предоставляющие специальные возможности для telnet. Среди них можно выделить:
■ Способность опрашивать партнера о текущем состоянии параметров. Запрос и ответ о состоянии партнера переносятся при дополнительном согласовании.
■ Согласование размера окна. Партнеры соглашаются, что клиент может дополнительно согласовать высоту и ширину окна, которое будет использоваться в сеансе telnet. Эта возможность особенно полезна для запуска сеанса telnet в системах с многооконным интерфейсом.
Реализациям не требуется поддерживать все или многие из определенных в стандартах вариантов. Два из них, используемые при эмуляции терминала 3270, имеют специальные возможности:
■ Transmit Binary (пересылка двоичных данных). Начало отправки 8-разрядных двоичных данных (сеансы с терминалом IBM 3270 проводятся в двоичном режиме).
■ End of Record (конец записи). После получения DO END-OF-RECORD партнер использует стандартные управляющие коды IAC 239 для маркировки конца записи в общем потоке данных.
Вспомним, что даже после перехода в двоичный режим партнеру можно послать команды telnet, удваивая esc-символы IAC.
13.10 Применение telnet
С точки зрения пользователей, желающих получить доступ к приложениям через эмуляцию терминалов ASCII или IBM, наиболее важным является способность telnet выполнять согласование и эмуляцию. Но разработчикам прикладного программного обеспечения основанный на NVT telnet предлагает достаточно бедный набор средств для реализации функций клиент/сервер, которые трудно и утомительно воспроизводить в программах. Мы уже знаем, что базовыми возможностями NVT являются: