LTSP/BarcodeScanners
Сканеры штрих-кода
В данной статье рассматривается случай, когда пользовательские программы (например, 1C) работают на MS Terminal Server, к которому по протоколу RDP подключаются оснащённые сканерами штрих-кода рабочие станции под управлением Linux (например, тощие клиенты).
Варианты подключения сканера ШК
В настоящее время для подключения к компьютеру могут использоваться следующие интерфейсы:
- клавиатурный разъём: сканер подключается в "разрыв" клавиатурного интерфейса DIN или PS/2. При этом с точки зрения софта он ничем от этой самой клавиатуры не отличается, а следовательно, не представляет для нас никакого интереса. Клавиатура - она и в африке клавиатура.
- Bluetooth. Не сильно распространен. Не имел возможности потестировать, но думаю, с таким вариантом можно обращаться, как с последовательным устройством.
- RS-232. Обычный ком-порт.
- USB.
на двух последних вариантах остановимся поподробнее.
Подключение по RS-232.
Плюсы:
- относительная простота и безвариантность подключения - весь вывод с устройства мы сразу видим на /dev/ttyS?, никаких драйверов не надо.
- про такой вариант подключения догадываются и поддерживают его многие пользовательские программы.
Минусы:
- Сканер, последовательный порт и программы, возможно, придётся понастраивать. Скорость, четность, стоп-биты...
- Сканер потребует отдельного питания.
- никакого plug-n-play'я.
- в новых компьютерах может уже никакого ком-порта не оказаться.
Как уже было сказано, при правильной настройке сканера и последовательного порта мы сразу получим содержимое наших скан-кодов на устройстве /dev/ttyS?. ttyS0, скорее всего, вряд ли у вас больше одного ком-порта в системе. Скажем же cat /dev/ttyS0, и попищим вволю сканером. Ну, а как напищимся, подумаем, как передать эти циферки программе на Windows-сервере. Самый простой путь - использовать возможности протокола RDP по подключению локальных устройств клиента (man rdesktop).
Подключимся к Windows-серверу командой
rdesktop -r comport:COM1=/dev/ttyS0 win-server
Данное заклинание подключило наше устройство /dev/ttyS0 к COM1-порту в данной сессии пользователя на Windows-сервере. Причем, у каждой такой сессии будет свой собственный COM1-порт. На стороне Windows увидеть этот перенаправленный порт можно командой change port, а тестово полюбоваться выводом со сканера - программой HyperTerminal. Всё, теперь остаётся настроить свою пользовательскую программу на использование COM1 и наслаждаться.
Однако, жизнь более скорбная штука и не всё в ней так просто и безоблачно. То, что ваш сканер будет работать в HyperTerminal'е, вовсе не означает, что он будет работать и в вашей программе, которая может быть старая, глюкавая, странная и капризная. Существует, например, труднорешаемая ошибка, возникающая при сочетании особенности работы программы с COM-портом и особенности реализации RDP-проброса устройств в rdesktop, когда программа получает вывод от сканера только после того, как что-нибудь напечатать на клавиатуре или пошевелить мышкой. (см. раз, см. два), которая, вдобавок, может проявляться не под администратором, а под простым пользователем. В таком случае может помочь проброс ком-порта вне протокола RDP; на стороне линукса для этого можно использовать программу ser2net, которая ловит всё с последовательного порта и отдаёт это по TCP. А на стороне сервера присылаемое можно получать бесплатной утилитой Tibbo Virtual Serial Port, которая создаёт в системе новый виртуальный COM-порт. Однако, он уже не уникальный для одной сессии, и придётся как-то самим обеспечивать уникальность связки порт-клиент, кроме того, хуже ситуация с переносом сессии на другого клиента и безопасностью.
Подключение по USB.
Плюсы:
- сканер может питаться от компьютера;
- имеем некоторый plug-n-play - возможность обрабатывать события подключения/отключения сканера, если нам это надо
- никакой настройки сканера кроме типа эмулируемого устройства - воткнул и оно работает
Минусы:
- большая-большая проблема передать этот usb на сервер и пользовательской программе.
Подключение сканера по USB отличается большим количеством вариантов типов изображаемых сканером устройств. Тут и HID-устройство (USB-клавиатура, проще говоря), и эмуляция последовательного порта (если железка поддерживает), и многочисленные проприетарные устройства (типа IBM Hand-Held USB и USB OPOS Hand-Held), которые для нас неинтересны - под Виндусом всё это живёт со своими драйверами, а под Линукс их нет.
Проще всего было бы передать на сервер "сырое" USB, чтобы виндусячьи драйвера сами разбирались, что там к чему, но увы, протокол RDP такого не предусматривает. Эту функциональность могут предоставить сторонние утилиты, бесплатных из которых я пока не обнаружил. Например, Fabulatech USB for Remote Desktop. Для линукса компилится модуль ядра и патчится rdesktop, а для Виндуса ставится драйвер с программой-монитором. В тестах работает неплохо, каждая сессия получает свои собственные USB-устройства, но всё это бесполезно без толстого бюджета из-за сильной небесплатности программы. Ну что же, может быть, когда-нибудь напишут Windows-часть для распространяемой по GPL usbip.
Если сканер поддерживается любым из usbserial-модулей, (см., например), то с ним можно обращаться как при подключении по RS-232 (см. выше), сюда же можно отнести подключение сканера всякими экзотическими rs232<->usb кабелями.
Остаётся HID Keyboard Emulation. С одной стороны, оно столь же простое и малоценное, как и подключение в разрыв клавиатуры, но с другой стороны, у нас имеется чрезвычайно интересная возможность "вычленить" ввод с этой "клавиатуры". Это позволяет реализовать программа hid-barcode-scanner из одноименного пакета. Она умеет отключать указанное HID-устройство от общей консоли и перенаправлять его на свой стандартный вывод. На сервер этот вывод можно отсылать банальным netcat'ом, а там ловить вышеупомянутым TibboVSP, настроенным в режиме сервера (рекомендую UDP). Потестируйте получившийся COM-порт в HyperTerminal'е; мне для нормальной работы понадобилась конструкция вроде
hid-barcode-scanner 05e0:1200 |while read BARCODE; do echo -e "$BARCODE\r"; done |netcat -u myserver 11111
Было бы совершенно замечательно иметь доступ к разработчикам нашей пользовательской программы. Тогда можно было бы обойтись без прослойки в виде TibboVSP и виртуального ком-порта: программу можно было бы научить напрямую слушать UDP-порт, и всё полученное там трактовать, как ввод со сканера ШК. Вопросы безопасности при этом остаются нерассмотренными.
Так же за рамками статьи остались вопросы:
- проброска ввода со сканера ШК для программ в wine (в т.ч., и на терминальном сервере)