The LBX Mini-HOWTO Paul D. Smith, psmith@baynetworks.com v1.04, 11 Dec 1997 伊佐治 哲, isaji@mxu.meshnet.or.jp LBX(Low Bandwidth X：低バンド幅 X)はXプロトコルを圧縮するためのXサーバ の拡張機能です。遅いネットワーク上でやりとりされるXアプリケーションと Xサーバの、表示/応答時間を改善するのに使われます。 ______________________________________________________________________ 目次 1. イントロダクション 2. LBXについて 3. LBXが役立つケース 4. LBXが不要なケース 5. LBXはどのような動作をするか？ 6. LBXを使うために必要なもの 7. LBXを使うとき不用なもの 8. LBXはどのようにスタートされるか 9. 問題 10. ドキュメント 11. 代わりの方法 11.1 dxpc - もう一つのXプロトコル圧縮 11.1.1 利点、長所 11.1.2 欠点 11.1.3 dxpcの入手先 11.2 Ssh (Secure Shell) 11.3 どちらがよいか？ ______________________________________________________________________ 1. イントロダクション Low-Bandwidth X (LBX)は高速LANを使っていない、あるいはアプリケーション を起動しているシステムから２台以下のマシンを経由(hop)して使える場所に いる人ばかりではないというような現状に対処しようとするものです。 Xプロトコルは非常に膨大なトラフィックをつくり出すことがあります。特に 新しいウィンドウを開くといった簡単なことでもトラフィックの量はかなりあ ります。28.8モデム(あるいはそれ以上)のダイアルインモデムでXを使おうと したユーザーならわかるように、Xセッションの確立には非常に時間がかかり ます。 LBXは基本的に２つのシステム間でやりとりされるXアプリケーションのトラ フィック量を最小化するように設計された圧縮およびキャッシングの機能を 持っています。 2. LBXについて Xコンソーシアムの X11R6.3リリース(1996年12月)において、LBXはXプロトコ ルに組み込まれました。XFree86に関してはXFree86 バージョン3.3で組み込ま れています。 3. LBXが役立つケース モデムを使ってプロバイダにダイアルインしている場合は、環境変 数DISPLAYをローカルマシンに設定してリモートマシン上のXアプリケーション を起動します (逆ももちろん可能です)。LBXはこの時の接続を高速にしてくれ ます。 DISPLAY変数をWAN外部などの遅いリンク先のシステム(例えば外国な ど)に設定している場合も、LBXが役立ちます。 4. LBXが不要なケース ローカル(自マシン)でアプリケーションを起動したりXを使わない場合はLBXで はかえって不便です。 また高速LAN上でアプリケーションを使う場合もLBXは十分役立つとは言えませ ん。ある人は「もしLBXがネットワークトラフィックを少なくしてくれるな ら、高速LAN上でもLBXは便利なのでは？」と言います。もし目指すものがネッ トワークトラフィックを減らすことだけならきっとそうでしょう。しかし目指 すものが応答時間を良くすることだけなら、LBXはおそらく役に立ちませ ん。LBXはキャッシュと圧縮を導入していますが、そのために「キャッシュの 外部メモリ、非圧縮のための外部CPU」に負担をかけているのです(訳注： キャッシュに使われる余分なメモリと伸長のための余分なCPU 時間)。そのた めリンクが速いなら LBXは通信速度を結果的に下げてしまうのです。 5. LBXはどのような動作をするか？ LBXはクライアント側(訳注：REMOTE側。アプリケーションを起動するほうで す) のプロキシサーバ(キャッシュと圧縮を行うサーバ)を導入して動作させま す。 Xサーバは、クライアントがプロキシサーバを使っていることを認識し て、それに応じて展開(decompress)します。 リモートXクライアントの通常セットアップについて。ここで"LOCAL"はあなた が使っているモニターが接続されているワークステーションで、REMOTEは実際 のアプリケーションが起動されているリモートワークステーションです。 ______________________________________________________________________ LBXを使っていない状態： REMOTE LOCAL +-----+ +-----+ | APP |-\ Network +----------+ | |\ +-----+ \--------------------------->| X SERVER |=>| || +-----+ / (X Protocol) +----------+ +-----+\ | APP |-/ /_____// +-----+ ______________________________________________________________________ 一方、 LBXを起動しているとプロキシサーバ(lbxproxy)がリモート側に導入さ れ、アプリケーションは LOCALサーバと直接通信する代わりにそのプロセ ス(リモート側のプロキシ)と通信します。そしてそのプロセスがXリクエスト の圧縮と転送を行います。これらは以下の図のようになります： ______________________________________________________________________ LBXを使っている状態： REMOTE LOCAL +-----+ +-----+ +-------+ Network +----------+ | |\ | APP |->| PROXY |----------------------------->| X SERVER |=>| || +-----+ +-------+ (LBX/X Protocol) +----------+ +-----+\ +-----+ / /_____// | APP |--/ +-----+ ______________________________________________________________________ LBXが行っているキャッシングと圧縮についての詳細はこのドキュメントでは 扱いません。 6. LBXを使うために必要なもの LOCALシステム上にのXサーバがLBX拡張機能付きでコンパイルされている必要 があります。構築するときに特に指定しない限りX11R6.3のサーバでは自動的 にLBXが使えるようになっています。またXFree86 3.3サーバではデフォルトで LBXが使えます。 xdpyinfoコマンドを使ってサーバがLBXをサポートしている かどうか確認できます。xdpyinfoと実行して"number of extensions"でリスト されている項目を見れば"LBX"がのっているでしょう。 次にリモート(REMOTE)システム用のlbxproxyプログラムが必要です。これはテ クニカルなことで、もしリモートシステムがローカルシステムと同じタイプで なければ当然lbxproxy(ローカルシステム)は使えません(no good)。 lbxproxyの"broken out"ディストリビューションは残念ながらありません。そ こで (a)リモートシステム用X11R6.3を入手して構築する。 (b)あなたのシステムにあったプレコンパイルされたを参照しましょう。 REMOTE側: 1. lbxproxyをスタートさせて、以下のようにLOCAL X サーバへフォワードさ せるようにします。 $ lbxproxy -display LOCAL:0 :1 & これはlbxproxyに、REMOTEシステムの:1ディスプレイを使うように指示してい ます。もし>1ディスプレイをすでに使っているなら:2 など別のディスプレイ を指定します。 2. ノーマルディスプレイのかわりにDISPLAY変数をlbxproxyが与えているディ スプレイに設定します(訳注：bash系はこちら)。 $ DISPLAY=:1 $ export DISPLAY あるいはcsh(やcshクローン)なら % setenv DISPLAY :1 とします。 3. ここでxauthを使っている場合は、ローカルにcookieが使えるかどうか確認 する必要があります。詳しくはRemote X Apps Mini-HOWTO を参照。 4. Xアプリケーションを起動します！ こうして:1ディスプレイに表示される全てのXアプリケーションはLBXを使うよ うになります。もちろんLOCAL:0としてXアプリケーションを使うこともできま すし併用して使うこともできます。 9. 問題 ここで共通した問題があります： Q) "access denied"となってlbxproxyが終了してしまう。 A) これは LOCALシステムがREMOTEシステムかrなお接続許可をしておらず パーミッションエラーが出るためです。この問題についてはRemote X Apps Mini-HOWTO を参照 して下さい。 トラブルシューティングとして REMOTE上でxclockといったXアプリケー ションを起動してみて下さい。 lbxproxyを使わずにローカルシステム 上で表示させるには： $ xclock -display LOCAL:0 とします。もしこれで動作しないようでしたらxhostや基本的なXの問題と いうことになります。LBXのせいではありません。 10. ドキュメント Xディストリビューションで読めるドキュメントはlbxproxy(1) manページくら いでしょう。 Xソースがあるディレクトリツリーにアクセスできるなら、LBXの興味深い情報 が以下のディレクトリから入手できます。 o xc/doc/specs/Xext/lbx.mif (Framemaker MIF) o xc/doc/hardcopy/Xext/lbx.PS.Z (Compressed Postscript) o xc/doc/hardcopy/Xext/lbxTOC.html (HTML) LBXアルゴリズムについて詳しく書かれたものは： o xc/doc/specs/Xext/lbxalg.mif (Framemaker MIF) o xc/doc/specs/Xext/lbxalg.PS.Z (Compressed Postscript) などです。 X11ソースがないならthe X Consortium's FTP site からドキュメントを入手できます。 11. 代わりの方法 「パフォーマンスがよくない」、「思い通りに動作しない」、「リモートホス トで lbxproxyをスタートするのが煩わしい」、「他のオプションのほうに興 味がある」などの理由でlbxproxyを使わないならXプロトコル圧縮用のパッケ ージがもう一つあるのでご紹介します(誰かこれ以外のパッケージをご存知で すか？)。 11.1. dxpc - もう一つのXプロトコル圧縮 o オリジナル作者: Brian Pane o 現在の管理者: Zachary Vonler dxpc は基本的にLBXと同じ 方法で動作するものです。しかし X拡張機能の実装やXサーバのコードを修 正しなくて済むように、dxpcは２つのプロキシ(lbxproxyのようなREMOTEホ スト上で実行するものとLOCALホスト上で実行させるもの)を使います。 REMOTEホストのプロキシ(proxy)はXクライアントとLOCALホストのプロキシ のあいだで通信をします。またLOCALホストのプロキシはXサーバ とREMOTEホストのあいだで通信をします。 訳注： ______________________________________________________________________ REMOTE LOCALホスト +-----+ +-----+ +-------+ Network +-------+ +----------+ | |\ | APP |->| PROXY |--------------------| PROXY |->| X SERVER |=>| || +-----+ +-------+ (LBX/X Protocol) +-------+ +----------+ +-----+\ +-----+ / /_____// | APP |--/ Xサーバ +-----+ Xクライアント ______________________________________________________________________ こうしてXクライアントとXサーバの両方で通常のXプロトコルのように振る舞 います。 11.1.1. 利点、長所 o Xの内部的なものを必要としない完全に独立したアプリケーションなので コンパイル、インストールがとても容易にできます。 o Xとは別々にメンテナンスされているので、拡張/フィックスされた新し いXバージョンのリリースを待つ必要がありません。 o lbxproxyと比べて圧縮について得られる情報や統計的な量において優れて いる。 11.1.2. 欠点 o Xの標準的なパッケージには含まれていないので、Xとは別々に入手して構 築する必要があります。 o REMOTE側に加えてLOCAL側のプロキシ設定が必要で、設定が少し複雑で す。 11.1.3. dxpcの入手先 dxpcのソースは ftp.x.org で入手で きます。またすぐれた情報を満載したdxpcのホームページがあります。 dxpcメーリングリストへのポインタやソースコードの利用、いろいろなプラッ トフォーム用にプレコンパイルされたバイナリファイルなどについては以下の サイトを見てみて下さい 。 11.2. Ssh (Secure Shell) Ken Chase 氏は ssh で 圧縮プロトコルが使えることを指摘しています。sshの主な目的はセキュリ ティの強化なのですがデータを圧縮して送信することもできます。 ssh接続を経由してXを起動する場合は、自動的に圧縮されます。 11.3. どちらがよいか？ 残念ながらわかりません。LBX、dxpcどちらもsshよりは圧縮そのものは (raw compression)優れています。もちろんsshはセキュリティについて優れていま す。もっとよい圧縮とセキュリティを得るために２つ(sshと dxpc、sshのどち らか一方)を併用しない手はありません。 これらのオプションについてベンチマークを実行したり統計的にパフォーマン スの計測を行うことは難しくありません。しかしまだ試していません。またこ れを試してみたという人もまだいないようです。 [ 日本語訳：伊佐冶 哲, isaji@mxu.meshnet.or.jp 校正：吉田 英樹さん, hideki@isl.rdc.toshiba.co.jp 吉田さん、JFの方達に大変お世話いただきました。ここに感謝いたします。]