Заметно, что Windows-клиент (как от Windows 95, так и от Windows 2000) не поддерживает всех опций, предлагаемых ему сервером.

Протокол rlogin происходит из Berkley UNIX. Впервые он появился в 4.2BSD и предназначался для захода удаленным терминалом на UNIX-машины, но спустя какое-то время оказался перенесен и на другие платформы. Это прикладной протокол, реализуемый поверх транспортного протокола TCP.

В сравнении с telnet, rlogin гораздо проще и не поддерживает согласования параметров, поэтому, его реализации гораздо компактнее и, как правило, устойчивее в работе. Его подробное описание вместе с исходными текстами rlogin-сервера и rlogin-клиента можно найти в RFC-1282.

После установки соединения с rlogin-сервером, rlogin-клиент посылает серверу четыре строки (все строки должны заканчиваться нулем):

· Пустую строку (нулевой байт)

· Имя пользователя, под которым он зарегистрирован на клиенте

· Имя пользователя, под которым он зарегистрирован на сервере

· Тип терминала в формате «тип терминала» «знак слеш “/”» «скорость терминала»

Сервер отвечает нулевым байтом и пытается аутентифицировать пользователя. В первую очередь анализируется файл.rhosts, содержащий список доверенных узлов и пользователей. Если адрес клиента совпадает с одним из адресов, перечисленных в этом файле, для входа на сервер вводить пароль не потребуется. В противном случае клиент должен передать серверу незашифрованную строку пароля (впрочем, последние реализации rlogin из 4.4BSD используют Kerberos для шифровки паролей, посылаемых по сети).

Протокол rlogin поддерживает единственный режим общения с сервером - символьный. Для улучшения производительности и предотвращения перегрузки сети огромным числом тиниграмм используется алгоритм Нагла.

Если rlogin-серверу требуется передать служебную команду клиенту, он входит в режим срочности TCP и отправляет команду в последнем байте срочных данных. Клиент, получив уведомление о режиме срочности, должен читать и сохранять данные до тех пор, пока не получит командный байт (последний байт срочных данных). В зависимости от команды, сохраненные данные могут быть выведены на терминал или проигнорированы. Ниже описываются четыре командных байта.

– Байт Назначение

– Десятичное Шестнадцатеричное

– 2 0х2 Прекращение вывода. Получив такую команду, клиент должен отбросить все данные, принятые им до получения командного байта.

– 16 0х10 Прекращение контроля потока данных

– 32 0х20 Возобновление контроля потока данных

– 128 0х80 Получив эту команду, клиент должен сообщить серверу размер окна своего терминала и обязывается уведомлять сервер всякий раз, когда размер окна изменится.

Передача команд от клиента к серверу происходит следующим образом: клиент посылает два байта, равные 0xFF, за которыми следуют два командных байта (еще их называемых флаговыми).

В настоящее время определена всего одна команда - уведомление клиентом изменения размеров окна. В этом случае два командных байта равны 0x73 0x73, за ними идут два 16-битные значения (в порядке сетевых байтов), выражающие количество символов в строке, количество символов в столбце, количество пикселей по горизонтали и количество пикселей по вертикали. Обычно два последние значения равны нулю, поскольку большинство приложений определяют размер экрана в пикселах, но не символах.

Протокол rlogin не позволяет передать символ 0xFF 0xFF в потоке данных, поскольку они используются для служебных целей, но в отличие от telnet, не существует специальной команды для снятия такого ограничения.

Помимо командных байтов, пересылаемых с последним байтом срочных данных, в распоряжении сервера есть и другие способы управления работой клиента. Для этого клиенту передается специальный знак «~» (тильда) в первой позиции строки, за которым следует один из четырех специальных символов:

– Символ Назначение

–. (точка) Прекращение работы клиента

– Ctrl-D

– Ctrl-Z Приостановление работу клиента

– Ctrl-Y Задерживание ввода клиента

Легко видеть, в отличие от протекла telnet, rlogin плохо и даже небрежно продуман, и очень ограничен в своих возможностях. В настоящее время он практически вышел из употребления и используется очень редко.

Оба протокола работают с сетевыми виртуальными терминалами NVT, представляющими собой мнимое устройство для ввода вывода 7-битных USASCII [188] символов. Однако это не означает невозможность передачи 8-битных символов, с использованием национальной кодировки.

Но NVT не обеспечивает согласования принятых сервером и клиентом кодировок и не гарантирует правильность отображения национальных символов. Поддержка расширений зависит от конкретных реализаций, но, как правило, практически все telnet-клиенты и сервера такие расширения поддерживают.

Символы с кодами от 0 до 31 и 127 называются управляющими и имеют специальное назначение, описанное в приведенной ниже таблице:

???? Название Сокращение Код символа Назначение

???? NULL NUL 0 Нет операции

???? BELL BEL 7 Дзын-Дзын

???? Back Space BS 8 Удаление последнего веденного символа

???? Horizontal Tab HT 9 Горизонтальная табуляция

???? Line Feed LF 10 Перенос курсора на следующую строку с сохранением текущей позиции

???? Vertical Tab VT 11 Вертикальная табуляция

???? From Feed FF 12 Перевод курсора на следующую страницу с сохранением горизонтальной позиции

???? Carriage Return CR 13 Перевод курсора в начало текущей строки

Все остальные управляющие коды по стандарту должны игнорироваться и не влиять на работу NVT терминала. Однако множество реализаций поддерживают собственные расширения.

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

Поддержка протоколом telnet виртуальных терминалов, позволяет приложениями взаимодействовать с удаленным клиентом точно так, как с локальным терминалом, который имеет ширину и высоту. Поэтому, протокол telnet часто используют для удаленного выполнения программ на сервере. Для этого, виртуальный терминал необходимо связать с командной оболочкой (shell), которая сможет работать с удаленным клиентом точно так, как если бы он был физически подсоединен к машине.

На самом деле, возможности telnet протокола не ограничиваются удаленным выполнением программ, и он может успешно применяться и для других целей. Однако в настоящее время эти дополнительные возможности практически не используются, поскольку вытеснены другими специализированными протоколами.

Дополнение. Обзор telnet клиентов

Существует огромное множество telnet-клиентов, но большинство из них не поддерживают всех спецификаций RFC-854, а, тем более, новомодных расширений. Грубо говоря, - практически все, что умет большинство клиентов - устанавливать TCP соединение, посылать и отправлять данные на сервер (шутка). К таким, например, принадлежит telnet-клиент, входящий в поставку Windows 95 (Windows 98).

Значительно более функционален telnet-клиент, распространяемый вместе с Windows 2000, а наиболее полно современным спецификациям соответствует клиент, входящий в состав 4.4BSD UNIX. Клиенты от Sun OS 4.1, Solaris 2.2, SVR4, AIX 3.2, поддерживают не все режимы, например, они не поддерживают режим line mode.

Впрочем, в большинстве случаев это совершенно несущественно. Так, для всех экспериментов, описанных в этой книге, подойдет любой из перечисленных выше telnet-клиентов. Ниже будет рассказано, как правильно подготовить к работе два самых популярных из них.

Клиент из поставки Windows 95 (Windows 98) конфигурируется с помощью диалога «Параметры терминала» путем установки (сброса) галочек в нужных местах. Как и любое приложение с графическим интерфейсом, он никаких вопросов не вызывает. При работе с telnet-сервером флажок «отображение ввода» (то есть эхо-отображение) должен быть сброшен, в остальных случаях его обычно устанавливают, чтобы контролировать процесс ввода символов с клавиатуры. О других опциях подробно рассказано в главе «Удаленное выполнение программ».