Newsgroups: comp.windows.x.apps
Subject: Re: X via modem?
From: jim@ncd.com (Jim Fulton)
Date: 12 Sep 92 17:49:43 GMT
Distribution: comp.windows.x.apps
Organization: Network Computing Devices, Mt. View, CA  94043, USA

>   Bjorn Smith <smith@compound.se> writes:
>	What does Xremote really do ?
>	I assume some sort of compression of the X-protocol messages.

Yes.  I've enclosed a brief description of some of the various X-over-serial-
line technologies from the latest comp.windows.x FAQ.  Most of the vendors
selling any real products (as distinct from raw X over PPP, even with
VanJ header compression) in this area currently use XRemote or something
similar.


>	Why can't a modem with V.42bis data compression do the same thing ?

Three reasons:

    o	In many environments you get better performance by letting the
	end nodes do the compression instead of the modem since it reduces
	the latency (i.e. the modem can spend all of its time transmitting)
	and the serial interrupts.

    o	More importantly, having something like XRemote allows you to 
	do X-specific compression by taking advantage of the redundancies
	in the X protocol.  This can significantly improve interactivity.

    o	Eventually, the coming X Consortium standard for Low Bandwidth X (LBX)
	will do even significant amounts of caching, avoiding the serial line
	altogether.


>    David Harrison <harrison@faraday.physics.utoronto.ca> writes:
>	Xremote, which I believe NCD has donated to the X Consortium

We've donated the XRemote protocol to serve as a starting point for the
Consortium's LBX effort (which I co-chair with Chris Kantarjiev of Xerox PARC),
which we will have ready in time for R6 late next year.  LBX will add host-side
caching of commonly used information, more efficient encoding of the wire
protocol, and other techniques for reducing the amount of data that has to
travel over the serial line.


>	I get about 30% better speed under Xremote by
>	turning off the MNP and compression protocols of my modem, and have
>	never seen an error once Xremote is running

XRemote does its own end-to-end error checking.  In addition to further
reducing latency (see above), it avoids problems that might happen as the bits
flow from the XRemote software through the OS to the modem.  Otherwise, if you
ever had anything equivalent to "zs0: silo overflow", you'd be dead in the
water.


>	At present, I believe Xremote is only available on NCD X-terminals
>	and on their software that turns a PC into an X terminal.

There are other licensees, but you'd have to ask our marketing folks at
"info@ncd.com" for details.


>	I haven't done a side-by-side comparison, but would be surprised
>	if Xremote weren't much faster than slip.

It can be up to 10 times faster than SLIP for some things (particularly
typing in a text window).  


>	A local window manager which runs in the terminal, such as NCDwm or
>	equivalent, is strongly recommended

Yup.  This is the single biggest way to boost the perceived interactivity.  A
lot of us thought that it would be useful; but I think most of us were amazed
at how much of an improvement it made.


>	And in all cases performance for color graphics is slooooow.

I'm surprised that you've found this to be the case.  It depends completely on
what you are doing, but the only operations for which being on a color display
would make any difference are PutImage and GetImage.  The latter is rarely
used.  The former is most often used to send bitmaps which expanded into deep
pixmaps within the server.  But, if your application is generating client-side
images that are the depth of the display and then sending them over the wire
(as opposed to generating them on the server side, if possible), you will see
degradation.

Below is the comp.windows.x FAQ entry on X over serial lines.

							Jim

                                *  *  *  *  *



>	I've seen a reference to XREMOTE, PPP and SLIP in this month's 
>	Workstation News.  Where can I get more information on these topics?

Here's a quick summary:

SLIP - Serial Line IP; this is both a mechanism and a protocol for sending IP
packets over point-to-point serial links.  It has been around for several
years, and implementations are available for many of the major TCP/IP
implementations.  Most X Terminal vendors supply this as a checkoff item,
although nobody really ever uses it since it is horribly slow.  The TCP/IP
headers add 40 bytes per packet and the TCP/IP encoding of the X protocol is
rather verbose (rightfully so; it is optimized for packing and unpacking over
high-speed links). 

CSLIP - Compressed header SLIP; this is a variant of SLIP that compresses
the 40 bytes of TCP/IP headers down to about 5 or 6 bytes.  It still doesn't
do anything about reencoding the X protocol.  Modems that do compression
can help, but they increase packet latency (it takes time to dribble the
uncompressed data through typical serial interfaces, plus the compression
assembly time).

PPP - Point-to-Point Protocol; this is an emerging standard for point-to-point
links over serial lines that has a more complete set of option negotiation than
SLIP.  A growing number of people see the combination of PPP for the serial
line management and CSLIP for the header compression as becoming common for
running normal TCP/IP protocols over serial lines.  Running raw X over the
wire still needs compression somewhere to make it usable.

XRemote - this is the name of both a protocol and set of products originally
developed by NCD for squeezing the X protocol over serial lines.  In addition
to using a low level transport mechanism similar to PPP/CSLIP, XRemote removes
redundancies in the X protocol by sending deltas against previous packets and
using LZW to compress the entire data stream.  This work is done by either a
pseudo-X server or "proxy" running on the host or in a terminal server.  There
are several advantages to doing compression outside the modem:

   (1)	You don't *have* to have compressing modems in there if you wouldn't 
	otherwise be using them (e.g. if you were going to be directly 
	connected), and

   (2)	It reduces the i/o overhead by cutting down on the number of bytes 
	that have to cross the serial interface, and

   (3)	In addition to the effects of #2, it reduces the latency in 
	delivering packets by not requiring the modem to buffer up
	the data waiting for blocks to compress.

LBX - Low Bandwidth X; this is an X Consortium project that is working on a
standard for this area.  It is being chaired by NCD and Xerox and is using
NCD's XRemote protocol as a stepping stone in developing the new protocol.  LBX
will go beyond XRemote by adding proxy caching of commonly-used information
(e.g. connection setup data, large window properties, font metrics, keymaps,
etc.) and a more efficient encoding of the X protocol. 

The hope is to have a Standard ready for public review in the first half of
next year and a sample implementation available in R6.


						Jim Fulton
						NCD


p.s. Additional technical information about how XRemote works and a few
notes on how LBX might be different are available via anonymous ftp from
export.lcs.mit.edu:/contrib/ in the following files:

        XRemote-slides.ps               slides describing XRemote
        XRemote-LBX-diffs.ps            more slides describing some of LBX


Newsgroups: comp.windows.x.apps