Печать и передача данных при использовании терминала PuTTY

В этой статье рассматриваются возможности
расширения функционала клиентских сессий
OpenEdge под Linux/Unix в режиме CHUI
при работе с эмулятором терминала PuTTY

Дмитрий Кайдалов

Проблема

Не секрет, что telnet или ssh доступ к общему серверу, на котором запускаются пользовательские CHUI программы, является наиболее выгодным решением при росте и развитии предприятия, в отличие от клиентских GUI программ, для которых необходимы, как графические мощные рабочие станции, которые в свою очередь тянут за собой более усиленную поддержку, так и сетевые ресурсы. Для создания одного нового рабочего места при работе с CHUI программами нет нужды приобретать дорогую технику, нет необходимости содержать очень надёжный и толстый канал связи, следить за совместимостью програмного обеспечения и настроек рабочей станции.

Однако при работе с CHUI (в дальнейшем данное сокращение будет подразумевать под собой сессии OpenEdge под Linux/Unix) очень часто встаёт вопрос и взаимодействии между программой на удалённом сервере и рабочей станцией. И для многих невозможность напечатать что-либо на принтере, открыть файл в одном из офисных приложений (MS Word, OpenOffice Writer, …), или положить файл на локальный диск без применения дополнительного программного обеспечения является тем самым барьером, из-за которого принимаются решения об отказе от платформы OpenEdge, даже несмотря на экономические и стратегические преимущества.

История

Немного истории. У нас на предприятии всё начиналось, когда рабочие станции были ещё с DOS, но уже на горизонте замаячил Windows 3.11. В те времена мы использовали DOS-telnet эмулятор терминала, в который был встроен RCP сервер. И печать со стороны CHUI выглядела, как стандартное unix rcp копирование на удалённый сервер в файл с названием PRN. Ну и соответственно, просто файлы падали туда, куда им сказала программа. При появлении Windows 3.11 не получилось просто и бесплатно достать RCP сервер, а те, что попадались, – были нестабильными, и их приходилось перезапускать. Эмулятор, который нас устраивал, нашёлся – это был NetTerm. Он нас почти устраивал, так как в нём можно было уствновить цветовую гамму, как под DOS-ом, и в нём был встроен аналог RCP сервера – Z-modem, который позволял не только передавать файлы, но и запускать другие команды (например, открыть файл в NOTEPAD). Причём все команды и сами файлы передавались с использованием уже установленного соединения telnet сессии. Но были проблемы с кодировками, вводом национальных символов, нельзя было убрать toolbar с ненужными для оператора кнопками, кривизна шрифта. На следующем этапе развития появился Windows 95. Где-то в сети обнаружился telnet, который работал в консольном окне. Он был очень похож на DOS программу шрифтами, разворачивался в полный экран, а главное – прилагались исходники. Но, к нашему сожалению, не было никакого аналога RCP или Z-modem. А позднее появился PuTTY, так же с исходниками, с нормальными шрифтами, с возможностью управлять цветами на экране и прочими наворотами, которых так не доставало. В этом эмуляторе была даже встроенная возможность печати на заранее заданный принтер. Но всё же этого не хватало. Хотелось преобразить CHUI. Хотелось, чтобы CHUI программа могла контролировать рабочее место. Хотелось сделать CHUI программу центром быстрого получения информации, и чтобы всё остальное окружение служило средством для достижения этой цели.

Требования к CHUI программам

Но прогресс не стоит на месте, и вырос список того, что требовалось от CHUI программы. А именно:

• передавать файл на локальный диск;
• забирать файл с диска;
• запускать приложение на рабочей станции;
• отправлять на матричный принтер файлы;
• отправлять на лазерный принтер файлы;
• открывать файлы автоматически по расширению;
• открывать файлы в различных программах (Adobe Acrobat Reader, MS Word, MS Excel, OpenOffice Calc, OpenOffice Writer);
• получать содержимое папок на рабочей станции;
• читать и писать в Registry;
• получать списки принтеров;
• получать списки дисков рабочей станции.

Всё это разнообразие функционала в конечном итоге свелось к трём главным операциям:

• положить файл на диск;
• забрать файл с диска;
• запустить программу с параметрами.

Практика

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

Делать наворот в виде реализации протокола Z-modem посчитали ненужным и очень сложным, так как требовалось подключать дополнительные сторонние библиотеки к программе, а на стороне сервера так же поддерживать актуальность программ для работы с этим протоколом. Как показала практика, на различных платформах и версиях операционных систем эти программы ведут себя по-разному. Кто-то на экран чего-то кидает, кто-то не понимает каких-то ключей.

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

Как всё это реализованно на практике:

Протокол обмена данными выглядит достаточно просто – сперва отправляется ESC-последовательность, по которой происходит переключение режима работы PuTTY, в котором все данные уже не поступают на экран, а остаются без экранной обработки. После отправляется либо имя файла, либо команда для запуска. Далее следует тело файла. И в конце посылка завершается управляющим символом ESC.

При отправке или получении файла необходимо избегать попадания в поток непечатных символов ввиду того, что эти символы могут интерпретироваться telnet или ssh серверами как некие управляющие символы и могут не передаваться. Также не передаётся символ с кодом 0. А символ с кодом 27 является признаком конца потока, при котором PuTTY возвращается в нормальный режим работы. Для этих символов налету происходит их конвертация в HEX-формат с классическим «/» перед числом (например, «/AF»). Таким образом, объём передаваемых данных увеличивается, но потери и искажения её не происходит.

К сожалению, реализовать этот протокол полностью на OpenEdge ABL не получилось. С одной стороны, перед передачей или получением файлов их нужно было конвертировать в различные кодировки. Мы пробовали реализовать конвертацию файлов на ABL, но получалось очень медленно. И передача данных из-под ABL также получалась медленной. И такая скорость нас никак не устраивала. С другой стороны, заставить ABL просто вывести на экран один символ, например, пробел или ESC, доставляло массу неудобств. В результате у нас получился небольшой набор C-программ, которые и вызывались из ABL.

Данная связка заработала как на 32-битной платформе Linux, так и на 64-битных братьях Linux и Sparc Solaris. Так как программы не использовали каких-либо специальных функций и состояли из 30-40 строк кода, то собрать их под другими средами не было проблемой. В одном из тестов система была запущена на AIX. И даже ничего не пришлось переписывать.

Самую простую команду – запуск приложения на рабочей станции – вообще сделали скриптом на sh:

#!/bin/sh 

echo "\033%w$1\033\c"

Таким образом, явно покрываются только три функции. А как же остальные?

А делается всё так:

Получить содержимое папки – нужно запустить команду DIR DISK:\PATH\* > FILE.TMP, потом забрать файл, а после запустить команду на удаление файла.

Отправить файл на печать на матричный принтер – кладём файл на рабочую станцию, запускаем копирование на нужное устройство (PRN, LPT1, ...), удаляем файл.

Отправить файл на лазерный принтер – кладём на рабочую станцию файл с текстом и файл со шрифтами для принтера. Запускаем команду копирования шрифта в принтерный порт, после команду копирования текстового файла в порт принтера. Далее удаляем файлы.

Читать и писать в Registry, получить списки принтеров, сетевых интерфейсов, имя рабочей станции – есть замечательная программа REG.EXE. С её помощью можно как извлечь нужные данные из Registry, так и положить обратно.

Расширения протокола обмена данными

После первой реализации протокола обмена данными сразу нашлось два узких места. Первое – при больших объёмах передаваемых данных время передачи очень сильно возрастало. Второе – если во время передачи нажать клавишу, то код клавиши попадал в общий поток и портил данные, а если клавиша была управляющей типа F1, то в поток попадал символ ESC, и передача останавливалась, а на экран «валил» мусор.

Второй недостаток победили сразу – при получении условной ESC-последовательности стали блокировать не только вывод на экран, но и передачу данных, которые были не желательны в это время. В этом режиме игнорировались нажатия клавиш и вставки из буфера обмена Clipboard. Эти события обрабатывались, но посылки не осуществлялись.

С первым недостатком бороться оказалось труднее. Но спасительным кругом оказалось использование библиотеки ZLIB. Правда, пришлось передачу сделать блочной. Но, в виду того, что 95% файлов являются исключительно текстовыми, то и сжимаются они очень хорошо. После реализации сжатия потока данных скорость передачи больших файлов возросла в 50-100 раз.

Выводы

Благодаря применению данной техники теперь из основной CHUI системы мы можем удовлетворить почти все запросы наших заказчиков, которые хотели, чтобы всё работало быстро и современно. И они это получили – быстрота и эффективность CHUI плюс красота и наглядность отчётности в офисных приложениях.

Автор: Дмитрий Кайдалов