The LBX Mini-HOWTO <author>Paul D. Smith, <tt><htmlurl url="mailto:psmith@baynetworks.com" name="psmith@baynetworks.com"></TT> <date>v1.04, 11 December 1997 <abstract> LBX (Low Bandwidth X) 是一种在 X Protocol 上进行压缩的 X Server 延伸。 他的用意在於改善低速网路连接时，X 程式与 X Server 显示及回应的时间。 </abstract> <toc> <sect>内容 <p> X protocol 可能制造网路上的壅塞， 尤其是一些看似简单的事情，例如开新的视窗。 任何人尝试著在 28.8 或是更快的拨接网路上使用 X 开启一个 X 视窗都能造成极痛苦的等待。 LBX 基本上是为了减少两个系统的 X 讯息交换压缩极快取的专案。 <sect>LBX 目前的状况？ <p> LBX 完全延伸在 1996十二月由 X 社群释出 X11R6.3 的 X Protocol 。 以 XFree86 家族而言，她算是 XFree86 3.3.x 系列的一分子。 <sect>谁能再 LBX 上获得利益？ <p> 如果你利用拨接使用服务，LBX 将可以加速 X 程式於远端执行，而在 DISPLAY 环境变数设定的本端的 连接。此外如果 DISPLAY 设定跨越 WAN (例如跨国的) 或是其他的低速连接， LBX 都有所助益。 <sect>谁不需要 LBX？ <p> 如果你镜静止需要在本端使用X 或是你根本不使用 X，当然， LBX 不会有任何助益。 如果你在高速的 LAN 上， LBX 也不会有太大助益。 有些人也许会问"如果 LBX 能减低网路交通，那麽为什会在 高速的 LAN 上没有帮助？" 如果你的目的是在於减少网路流量 那麽它的确可能有所帮助。 但是你的目的是减少 X 的回应时间， LBX 可能不是你所需要的。 虽然它使用快取以及 压缩，但是他们也造成一些花费 ( 快取需要记忆体 压缩需要 CPU 时间 )。 如果你的连线已经很快速了 LBX 反而可能降低速度。 <sect>如何让 LBX 工作？ <p> LBX 利用在 X client 端的一个处理快取和压缩的<em/代理伺服器/工作。 X 伺服器知道远端使用这一个代理装置，并依据他而进行解压缩。 以下是 X clients的一般设定。在我们的讨论中本端 (LOCAL) 指的是在你面前的工作站，你能见到它的萤幕。而远端 (REMOTE) 指的是你远端跑程式的工作站。 <tscreen><code> REMOTE LOCAL +-----+ +-----+ | APP |-\ Network +----------+ | |\ +-----+ \--------------------------->| X SERVER |=>| || +-----+ / (X Protocol) +----------+ +-----+\ | APP |-/ /_____// +-----+ </code></tscreen> 当使用 LBX ，一个代理伺服器 ( <tt/lbxproxy/ ) 在远端被处理 ，现在本端先和代理伺服器沟通，而不是直接和程式沟通。 接著这程序处理快取以及压缩 X 的要求并传递他们。 他们看起来像是∶ <tscreen><code> REMOTE LOCAL +-----+ +-----+ +-------+ Network +----------+ | |\ | APP |->| PROXY |----------------------------->| X SERVER |=>| || +-----+ +-------+ (LBX/X Protocol) +----------+ +-----+\ +-----+ / /_____// | APP |--/ +-----+ </code></tscreen> 至於到底是什麽东西被压缩以及被快取则不是这放文件讨论的□围。 <sect>我需准备要什麽去使用 LBX？ <p> 你需要一个已经将 LBX 编译整合在本端的 X Server。 除非你在编译的时候指定不将 LBX 整合於其中， 否则 X11R6.3 会自动的使用 LBX 的特性。 所有的 XFree86 3.3 server 预设都会把 LBX 整合於其中。 你可以使用 <tt/xdpyinfo/ 这个命令检是你的 server 是否打开了 LBX 的功能。 执行 <tt/xdpyinfo/ 即可在 number of extensions 的列表下面，见到 LBX 列在其中。 下一不你需要一个在远端已经将 <tt/lbxproxy/ 这程式编译在内的系统。 这边有个陷阱。 如果远端的系统和你本端不同，那麽在本端的 <tt/lbxproxy/ 将不会作用。 很不幸的，没所所谓分离开的 <tt/lbxproxy/ ，所以 你必须 (a) 所有的远端系统都使用X11R6.3，或是 (b) 找一个针对你的本端系统预先编译好的 <tt/lbxproxy/。 当然後者是比较方便的。 <tt/lbxproxy/ 仅仅是一个单一执行档。 它没有任何的设定档或是资源档，或诸如此类的档案。 <sect>我不需要准备什麽去使用 LBX？ <p> 远端系统<bf/不需要/一个新的 X server (如同一般的状况，远端系统并不需要<em/任何/一个 X Server). 你所需的程式并<bf/不需要/指定特别版本的 X 或是特别的函式库。 我借由 LBX 使用 X11R5 的程式，也没碰到什麽问题。 你<bf/不需要/使用 root 或是特别的权限存取选端系统。 你只需要一般的权限执行 <tt/lbxproxy/。 另外你只需要在你自己的家目录下执行即可，lbxproxy 并不需要安装在特定的目录。 <sect>如何使 LBX 开始工作？ <p> OK，接下来的步骤都很简单。 将下列 LOCAL 以及 REMOTE 用你本端以及远端的主机名称取代。 ( 千万不要搞混了 )On LOCAL: <enum> <item> 启动你的 X server。 <item> 告诉你的 X server 哪些远端系统是被允许存取的。 使用 host-list 的方法，键入 <tt/xhost + REMOTE/。如果你要使用 <tt/xauth/ 你需要作更多事情；请参阅 man <em/xauth(1)/ 以获得更多的资讯。 如果你不熟悉 X 远端的存取，那麽你需要参阅 <url url="http://www.xs4all.nl/~zweije/xauth.html" name="Remote X Apps Mini-HOWTO"> 。 </enum> On REMOTE: <enum> <item> 起始 <tt/lbxproxy/ 并告诉它传送讯息到本端的 X server，如下∶ <tscreen><verb> $ lbxproxy -display LOCAL:0 :1 &ero; </verb></tscreen> 这告诉 <tt/lbxproxy/ 在远端系统使用 display <tt/:1/ ；如果系统大於 1 的 display 已经在使用。你可以使用 <tt/:2/ 之类的设定取代。 <item> 设定你的 DISPLAY 环境变数，使此环境变数和你 <tt/lbxproxy/ 所设定的相同。取代平常的 DISPLAY 设定 <tscreen><verb> $ DISPLAY=:1 $ export DISPLAY </verb></tscreen> 如果你使用 csh 之类的，以下可能是你所需要的∶ <tscreen><verb> % setenv DISPLAY :1 </verb></tscreen> <item> 如果你使用 <tt/xauth/ 你需要确定你的 cookie 正确的运作。你可以从 <url url="http://www.xs4all.nl/~zweije/xauth.html" name="Remote X Apps Mini-HOWTO"> 获的更多的资讯。 <item> 执行你的 X 程式！ </enum> 接下来就完成了；所有在 Display 环境变数为<tt/:1/ 的 X 程式都会在都会使用 LBX。当然，你没有办法起始一个 X 程式，其 Display 的环境变数是指向 <tt/LOCAL:0/ 以及在同一个时间下执行。 <sect>问题 <p> 这边有一些常见的问题∶ <descrip> <tag/Q)/ <tt/lbxproxy/ 以 access denied 的错误结束程式。 <tag/A)/ 这是代表你进端的系统不接受选端系统的连结而产生的错误。 请参阅 <url url="http://www.xs4all.nl/~zweije/xauth.html" name="Remote X Apps Mini-HOWTO"> 有更详尽的说明。 碰到这问题时，有一个简单的试验方式。请试著在远端不要透过 <tt/lbxproxy/ 执行一个简单的 X 程式， 比如说 <tt/xclock/ ∶ <tscreen><verb> $ xclock -display LOCAL:0 </verb></tscreen> 如果它不能正常的工作，那麽就表示是<tt/xhost/或是 其他一些基本的 X 问题而不是 LBX。 </descrip> <sect>Documentation <p> 在标准的 X 文件中，唯一可以参阅的文件应该是 man <em/lbxproxy(1)/。 如果你有看 X 的原始档，那麽下列有些有趣的资讯有关 LBX ∶ <itemize> <item><tt>xc/doc/specs/Xext/lbx.mif</tt> (Framemaker MIF) <item><tt>xc/doc/hardcopy/Xext/lbx.PS.Z</tt> (Compressed Postscript) <item><tt>xc/doc/hardcopy/Xext/lbxTOC.html</tt> (HTML) </itemize> LBX 更深入的演算法在下列的地方∶ <itemize> <item><tt>xc/doc/specs/Xext/lbxalg.mif</tt> (Framemaker MIF) <item><tt>xc/doc/specs/Xext/lbxalg.PS.Z</tt> (Compressed Postscript) </itemize> 如果你没有 X 的原始档，你可以由 <url url="ftp://ftp.x.org/pub/R6.3/xc/doc/" name="X 组织的 FTP 站取得">。 <sect>Alternatives <p> 如果你有某些原因不喜欢 <tt/lbxproxy/ 。例如你不喜欢他的执行效率， 它不帮你工作， 你不想麻烦的为远端建立 lbxproxy 或著你只是想是是其他的选择， 这边有一些其他的 X protocol 压缩方式。 (有没有人有其他的方案？) <sect1>dxpc - 一个极不一样的 X Protocol 压缩程式 <p> <itemize> <item>原本的作者∶ <htmlurl url="mailto:brianp@cnet.com" name="Brian Pane <brianp@cnet.com>"> <item>现下的维护者∶ <htmlurl url="mailto:lightborn@mail.utexas.edu" name="Zachary Vonler <lightborn@mail.utexas.edu>"> </itemize> <tt><url url="http://ccwf.cc.utexas.edu/~zvonler/dxpc/" name="dxpc"></tt> 和 LBX 以相同的方式运作。然而为了避免修改 X Server的原始码 以及实作一个 X Server 的扩充<tt/dxpc/ 使用 <bf/两个/ 代理伺服器∶ 一个像是 <tt/lbxproxy/ 跑在远端的系统，另一个则在本端执行。 在远端的代理伺服器负责沟通 X Client 以及本端的代理伺服器， 而本端的代理伺服器负责沟通 X Server 以及远端的代理伺服器。 所以，对於 X clients 以及 X server <em/两造/，他们都以平常的处理方式处理 X Protocol <sect2>优点 <p> <itemize> <item> 既然它是完全的独立程式而不需要动到 X 的内部， 它一定<em/非常的/ 容易编译以及安装。 <item> 它是独立的被维护著，所以你不需要 OSF 释出新的 X ，即可过的效能的增进以及错误的修正。 <item> 它提供了比 <tt/lbxproxy/ 更多的压缩资讯以及统计资讯。 </itemize> <sect2>缺点 <p> <itemize> <item> 它不是 X 的标准套件，你必须自己取得以及编译安装。 <item> 它在安装上变的比较复杂，因为它要求在本端也要有一个像是远端的代理伺服器。 </itemize> <sect2>我在哪里可以得到 dxpc？ <p> dxpc 的原始档可以自<url url="ftp://ftp.x.org/contrib/utilities/" name="ftp.x.org">取得。 这里有一个网页<url url="http://ccwf.cc.utexas.edu/~zvonler/dxpc/">有 dxpc 很多不错的资讯。包含了 dxpc 的 mailing list，原始档，以及 为多种平台预先编译好的执行档。 <sect1>Ssh (Secure Shell) <p> <htmlurl url="mailto:lbxhowto@sizone.org" name="Ken Chase <lbxhowto@sizone.org>"> notes that <tt><url url="http://www.cs.hut.fi/ssh/" name="ssh"></tt> 能被用於压缩。虽然它只要的目的是为了保密，但是它也压缩它传送的资料。 所以如果你自一个 <tt/ssh/ 连结执行 X ，你在使用间自然会压缩资料。 <sect1>谁比较好？ <p> 我不知道。 LBX 以及 <tt/dxpc/ 在纯压缩上比 <tt/ssh/ 好。当然， <tt/ssh/ 提供了在安全上的附加功能。 不过，也没有任何理由禁止你使用 <tt/ssh/ 加上另外两种之一的压缩方式，以获得良好的压缩以及安全性。 在这些选择上跑一些评量以获取统计资讯，应该不是很难的事。 但是我没有做过这件事，也没有听说过任何人做过。 </article>