|
|
 |
|
|
|
Мини-HOWTO: LBX| Аннотация | 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 или нечто подобное:
Если вы используете 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 <lbxhowto@sizone.org> замечает, что для компрессирования можно использовать ssh. Несмотря на то, что основной его задачей является безопасность, он к тому же компрессирует передаваемые данные. Таким образом, вы можете запустить X поверх ssh-соединения, получив сразу
некоторое сжатие.
Я не знаю. И LBX, и dxpc значительно лучше
компрессируют, чем ssh. С другой стороны, у
ssh все значительно лучше с безопасностью. И,
конечно, ничто не мешает использовать и ssh и
один из двух первых способов, получив, таким образом, неплохое сжатие и
безопасность. Наверно не очень сложно запустить несколько тестов, проверив
быстродействие этих трех вариантов, чтобы получить и субъективное, и
статистическое измерения. Но я этого не делал и не знаю никого, кто бы
это пробовал.
Авторские права на русский перевод этого текста принадлежат © 2000 ASPLinux
Все права зарезервированы. Этот документ является частью проекта Linux HOWTO. Авторские права на документы Linux HOWTO принадлежат их авторам, если явно
не указано иное. Документы Linux HOWTO, а также их переводы, могут
быть воспроизведены и распространены полностью или частично на любом
носителе, физическом или электронном, при условии сохранения этой заметки об
авторских правах на всех копиях. Коммерческое распространение разрешается и
поощряется; но, так или иначе, автор текста и автор перевода желали бы знать о
таких дистрибутивах. Все переводы и производные работы, выполненные по документам Linux HOWTO,
должны сопровождаться этой заметкой об авторских правах. Это делается в
целях предотвращения случаев наложения дополнительных ограничений на
распространение документов HOWTO. Исключения могут составить случаи
получения специального разрешения у координатора Linux HOWTO, с которым
можно связаться по адресу приведенному ниже. Мы бы хотели распространить эту информацию по всем возможным каналам. Но
при этом сохранить авторские права и быть уведомленными о всех планах
распространения HOWTO. Если у вас возникли вопросы, пожалуйста, обратитесь
к координатору проекта Linux HOWTO по электронной почте:
<linux-howto@metalab.unc.edu> или к координатору русского
перевода Linux HOWTO компании ASPLinux по адресу
<linux-howto@asplinux.ru> |
|
|
Партнёры и спонсоры проекта:
|
|
