Версия 1.04, 11 декабря 1997
LBX (Low Bandwidth X) - это расширение X-сервера, которое компрессирует
X-протокол. Он используется вместе с X-приложениями и X-сервером,
разделенными медленным сетевым соединением, для того, чтобы увеличить
скорость работы.
Low-Bandwidth X X (LBX) существует для тех, кто работает с X-приложениями на
машинах, находящихся далеко от сервера.
X-протокол может иметь очень большой трафик, особенно на таких простых
вещах, как создание новых окон. Те, кто пытался запустить X поверх
телефонного соединения на скорости 28.8 или даже выше, могут подтвердить,
что открытие новых X-окон может идти ужасно долго.
LBX вообще - это схема компрессирования и кэширования, предназначенная для
уменьшения X-трафика между двумя системами.
Согласно документации X-Консорциума X11 релиз X11R6.3 (декабрь 1996), LBX
является полным зарегистрированным расширением X-протокола. Что же касается
XFree86 - это означает, что вам нужна XFree86 версии 3.3.
LBX ускорит работу соединения, если вы используете модем для работы с
провайдером, и через него запускаете Х-приложения на удаленных машинах, на
которых переменная DISPLAY указывает на вашу машину (или наоборот), LBX
также поможет, если вы работаете очень далеко от этих машин (например, в
разных странах) или на других медленных соединениях.
LBX конечно бесполезен, если вы запускаете Х на одной машине, или вообще не
используете Х.
LBX также мало поможет, если вы работаете в быстрой локальной сети.
Некоторые говорят: "если LBX уменьшает сетевой трафик, не будет ли
целесообразным использовать его и в быстрых сетях?" Возможно, если ваша
цель - уменьшить трафик в сети. Но если вам необходимо ускорение работы, то, в
этом случае, LBX вам вряд ли поможет. LBX включает в себя кэширование и
компрессирование, для этого расходуются ресурсы на обоих концах сети
(дополнительная память на кэш, дополнительное время процессора на
декомпрессирование). Применение LBX на быстром соединении может привести к
общему замедлению.
LBX работает как прокси-сервер на клиентской стороне, выполняющий
кэширование и компрессирование. X-сервер знает, что клиент использует
прокси-сервер, и также занимается компрессией.
Ниже приведена обычная настройка для удаленных Х-клиентов. В этом
тексте мы будем придерживаться следующих терминов: ЛОКАЛЬНАЯ рабочая
станция - это та, непосредственно на которой вы работаете, а УДАЛЕННАЯ -
это та машина, на которой работает приложение.
УДАЛЕННАЯ ЛОКАЛЬНАЯ
+-----+ +-----+
|Прил.|-\ Сеть +----------+ | |\
+-----+ \--------------------------->| X Сервер |=>| ||
+-----+ / (X-протокол) +----------+ +-----+\
|Прил.|-/ /_____//
+-----+
Для использования LBX на удаленной машине используется прокси-сервер
(lbxproxy), и приложения общаются с этим процессом, вместо прямой передачи
данных на ЛОКАЛЬНУЮ машину. Этот процесс затем производит кэширование и
компрессирование X-запросов, и направляет их серверу. Выглядит это примерно
так:
УДАЛЕННАЯ ЛОКАЛЬНАЯ
+-----+
+-----+ +-------+ Сеть +----------+ | |\
|Прил.|->|Прокси.|----------------------------->| X Сервер |=>| ||
+-----+ +-------+ (LBX/X-протокол) +----------+ +-----+\
+-----+ / /_____//
|Прил.|--/
+-----+
Описание конкретных протоколов и деталей кэширования и компрессирования LBX
не входят в этот документ.
На ЛОКАЛЬНОЙ машине вам понадобится X-сервер со встроенной поддержкой LBX.
В серверах X11R6.3 автоматически разрешен LBX, если только его специально
не отключили при сборке. Во всех серверах XFree86 3.3 LBX также по умолчанию
разрешен.
Вы можете узнать, встроен ли в ваш сервер LBX, при помощи команды xdpyinfo:
запустите xdpyinfo и взгляните на список прямо под надписью "number of
extensions" (количество расширений); вы должны увидеть "LBX" в этом списке.
На УДАЛЕННОЙ машине вам понадобится программа lbxproxy. Это достаточно
хитрая часть настройки - если удаленная машина использует систему, отличную
от вашей, то ваш lbxproxy ей особенно не поможет.
К сожалению, пока не существует "выковырянной" версии исходных текстов
lbxproxy, поэтому придется либо (а) найти и собрать почти полностью,
если не полностью X11R6.3 для удаленной системы, или (б) найти где-нибудь
собранную версию lbxproxy для вашей удаленной системы. Второй вариант,
естественно, значительно проще.
lbxproxy - это простая одиночная программа. Никаких конфигурационных
файлов, файлов ресурсов и т.п. к ней не прилагается.
На УДАЛЕННОЙ системе не требуется нового X-сервера (УДАЛЕННОЙ системе
вообще не требуется никакого X-сервера).
Приложение, которое вы хотите запустить, не должно быть обязательно
предназначено для вашей версии X, или для каких-то библиотек; Я без
особых трудностей использую коммерческие программы для X11R5 поверх LBX.
Вам не обязательно быть root-ом или другим привилегированным пользователем
на УДАЛЕННОЙ системе; lbxproxy запускается под любыми разрешениями. Более
того, вы можете запускать его прямо из вашего каталога: его не надо никуда
устанавливать.
Теперь перейдем к самому главному. Замените в нижеприведенных примерах
слова ЛОКАЛЬНЫЙ и УДАЛЕННЫЙ на имена соответствующих хостов (не
перепутайте!)
На ЛОКАЛЬНОЙ машине:
Запустите X-сервер.
Разрешите на своей системе доступ к X-серверу извне. Используйте метод
"список машин", наберите команду xhost +REMOTE. Если вы используете xauth,
то вам, по-видимому, придется сделать немного больше; смотрите xauth(1) для
дополнительной информации. Также вы можете прочитать Мини-HOWTO: Удаленные
приложения в X, если вы не знакомы с настройкой разрешений удаленного
доступа к X.
На УДАЛЕННОЙ машине:
Запустите lbxproxy и укажите ему перенаправление на ЛОКАЛЬНЫЙ X-сервер,
например:
$ lbxproxy -display LOCAL:0 :1
Таким образом вы заставляете lbxproxy использовать display :1 на УДАЛЕННОЙ
системе; если в системе уже больше 1 дисплея, то используйте :2,
или то, что вам необходимо.
Установите переменную окружения DISPLAY так, чтобы она указывала на
дисплей, предоставляемый lbxproxy, вместо обычного:
$ DISPLAY=:1
$ export DISPLAY
Или, если вы используете csh или нечто подобное:
% setenv DISPLAY :1
Если вы используете xauth, то вам надо убедиться, что ваш cookie доступен.
Смотрите Мини-HOWTO: Удаленные приложения в X в поисках дополнительной
информации.
Запускайте свои X-приложения!
И все; все X-приложения, запущенные с указанием на дисплей :1 будут
использовать LBX. Конечно, не существует никаких препятствий к одновременному
запуску X-приложений, работающих с LOCAL:0 и :1.
Ниже приведены различные проблемы и методы их решения:
- Вопрос
lbxproxy выходит с ошибкой "access denied" (отказано в доступе).
- Ответ
Это означает, что ЛОКАЛЬНАЯ система не разрешает соединения с УДАЛЕННОЙ
системы из-за ошибок, связанных с разрешениями. Еще раз внимательно прочтите
Мини-HOWTO: Удаленные приложения в X.
Способ проверки - попробуйте запустить простое X-приложение типа xclock на
УДАЛЕННОЙ системе с дисплеем на ЛОКАЛЬНОЙ без использования lbxproxy:
$ xclock -display LOCAL:0
Если это не сработало, то проблема в xhost, или, вообще, с
X, а не с LBX.
Единственная документация по этому вопросу в стандартной поставке X - это
man lbxproxy(1).
Если у вас есть доступ к исходным текстам X, то информация по LBX доступна
в следующих каталогах:
xc/doc/specs/Xext/lbx.mif (Framemaker MIF)
xc/doc/hardcopy/Xext/lbx.PS.Z (Compressed Postscript)
xc/doc/hardcopy/Xext/lbxTOC.html (HTML)
Более подробное объяснение специфических алгоритмов LBX можно найти в:
Если у вас нет исходных текстов X11, то этот файл можно найти на сайте
X-консорциума.
Если вам по какой-то причине не понравился lbxproxy: вас не устраивает
быстродействие, он у вас не работает, или вам просто лень возиться с
установкой lbxproxy на удаленном хосте, или просто интересно попробовать
нечто иное, то существует, как минимум, еще один пакет для компрессирования
X-протокола (у кого-нибудь есть, что-нибудь еще?)
dxpc работает почти также, как LBX. Однако, вместо включения дополнения в X
и изменения кода X-сервера, dxpc использует два прокси: один работает на
УДАЛЕННОМ хосте, а второй на ЛОКАЛЬНОМ.
Прокси на УДАЛЕННОМ хосте работает между X-клиентами и прокси ЛОКАЛЬНОГО
хоста, а прокси на ЛОКАЛЬНОМ хосте работает между X-сервером и прокси
УДАЛЕННОГО хоста.
Таким образом, и X-клиенты, и X-сервер видят друг друга, будто работают на
обычном X-протоколе.
Его значительно проще собирать и устанавливать, т.к это полностью
независимое приложение, не требующее никаких изменений внутри X.
Оно поддерживается отдельно, поэтому вам не придется ждать, пока OSF
выпустит новую версию X с дополнениями или исправлениями.
В нем присутствует значительно более полная и понятная статистическая
информации о компрессировании, в отличие от lbxproxy.
Эта программа не является стандартной частью X - вам придется находить и
устанавливать ее отдельно.
Эту систему немного сложнее настроить, так как в ней требуются 2 прокси: на
ЛОКАЛЬНОЙ и УДАЛЕННОЙ машинах.
Исходные тексты dxpc можно найти на ftp.x.org.
Также существует домашняя страница dxpc, на которой есть много интересной
информации, включая ссылки на список рассылки dxpc, доступ к исходным
текстам и несколько уже готовых вариантов для различных платформ:
http://ccwf.cc.utexas.edu/~zvonler/dxpc/
Ken Chase <[email protected]> замечает, что для компрессирования можно использовать ssh. Несмотря на то, что основной его задачей является безопасность, он к тому же компрессирует передаваемые данные.
Таким образом, вы можете запустить X поверх ssh-соединения, получив сразу
некоторое сжатие.
Я не знаю. И LBX, и dxpc значительно лучше
компрессируют, чем ssh. С другой стороны, у
ssh все значительно лучше с безопасностью. И,
конечно, ничто не мешает использовать и ssh и
один из двух первых способов, получив, таким образом, неплохое сжатие и
безопасность. Наверно не очень сложно запустить несколько тестов, проверив
быстродействие этих трех вариантов, чтобы получить и субъективное, и
статистическое измерения. Но я этого не делал и не знаю никого, кто бы
это пробовал.
Авторские права на русский перевод этого текста принадлежат © 2000 SWSoft Pte Ltd.
Все права зарезервированы.
Этот документ является частью проекта Linux HOWTO.
Авторские права на документы Linux HOWTO принадлежат их авторам, если явно
не указано иное. Документы Linux HOWTO, а также их переводы, могут
быть воспроизведены и распространены полностью или частично на любом
носителе, физическом или электронном, при условии сохранения этой заметки об
авторских правах на всех копиях. Коммерческое распространение разрешается и
поощряется; но, так или иначе, автор текста и автор перевода желали бы знать о
таких дистрибутивах.
Все переводы и производные работы, выполненные по документам Linux HOWTO,
должны сопровождаться этой заметкой об авторских правах. Это делается в
целях предотвращения случаев наложения дополнительных ограничений на
распространение документов HOWTO. Исключения могут составить случаи
получения специального разрешения у координатора Linux HOWTO, с которым
можно связаться по адресу приведенному ниже.
Мы бы хотели распространить эту информацию по всем возможным каналам. Но
при этом сохранить авторские права и быть уведомленными о всех планах
распространения HOWTO. Если у вас возникли вопросы, пожалуйста, обратитесь
к координатору проекта Linux HOWTO по электронной почте:
<[email protected]> или к координатору русского
перевода Linux HOWTO компании SWSoft Pte Ltd. по адресу
<[email protected]>
