NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/fj/maillis/xwindow/19049

Internet Message Format | 1993-01-02 | 8.3 KB

Path: sparky!uunet!stanford.edu!sun-barr!sh.wide!wnoc-tyo-news!scslwide!wsgw!wsservra!onoe
From: [e-mail] (Jim Fulton)
Newsgroups: fj.mail-lists.x-window
Subject: Re: What is Xremote? [and notice about LBX]
Message-ID: <[e-mail]>
Date: 2 Jan 93 05:41:27 GMT
Sender: [e-mail] (Atsushi Onoe)
Distribution: fj
Organization: Network Computing Devices, Mountain View, CA
Lines: 175
Approved: [e-mail]

Message-Id: <[e-mail]>
Date: Fri, 01 Jan 93 18:07:20 PST


I've also attached a copy of the Frequently Asked Questions (FAQ) posting that
goes out to comp.windows.x every month.  There is also more technical
information on XRemote available via anonymous ftp on export.lcs.mit.edu.

For people who are interested in LBX (Low Bandwidth X, the X Consortium's
standard for R6 that is being evolved from XRemote), there will be a paper at
the X Conference in Boston (the proceedings of which will be published by The X
Resource).  PostScript for the paper will also be placed on export.lcs.mit.edu
at that time.


    >I saw someone post something about a program called
    >Xremote?  It sounds interesting, what is it?  Could it
    >be a way to dial into my machine at work and set my
    >display to my 486 at home?!  Wow! That would be
    >great!  Thanks...  :)

Yup, that's the idea.


    its a product NCD developed i believe - send a note to
    [e-mail] and they'll tell you about it i imagine

Both for X terminals and PCs.


    VisionWare produces XVision  the first and still market-leading
    Windows-based PC X server. XVision was the first PC X server to support
    XRemote - the compressed protocol which allows users to connect to
    remote hosts over an RS232 line and through a modem.
    XVision also supports auto dial-up modems.

    For more information and pricing details you may care to contact our
    US office on 1-800-949-8474 or email [e-mail] .

Yup.


    -  You need then some networking protocol on your serial line.
       SLIP (Serial Line IP) is the most commonly known solution,
       PPP is another possibility.

You only need SLIP or PPP if you intend to run X over them (or want them for
some other reason.  Most of the common X-over-serial-line products don't
currently require SLIP or PPP since they still are not ubiquitously bundled
with host platforms (sigh; fortunately this is slowly changing).


    -  NCD has developed a special protocol for dealing with the
       X protocol on serial lines. It includes compression techniques,
       I believe. Of course, NCD has included this software in their
       X-terminal-software, and for the X-client-side (e.g. UNIX-server)
       you can buy the software.  I think NCD has contributed Xremote to the X
       consortium, and it might be included in X11R6. Maybe someone else
       can comment on this.

NCD has donated the XRemote protocol and is co-chairing the effort to define a
standard that is using it as a stepping stone.  I recommend that anyone who
is interested in the topic get the proceedings of the conference or ftp the
paper afterwards.


    -  I don't know how SLIP/PPP and modems with good compression techniques
       (V.42bis) relate to Xremote w.r.t. performance. Any comments?

The problem with such "raw X" approaches is that they do nothing to remove the
redundancies in the X protocol.  This means that you have to send every little
bit of data over the line each time, even if it is essentially equivalent to
something that just was sent (which is esp. common when typing text, for
example).

Also, in some environments, you actually get better performance by letting
the host and display handle the compression and decompression.  This happens
for two reasons:

    o    Serial interfaces are typically not very efficient, so reducing the
    number bytes that you have to dribble across them can be a big win.

    o    Modem compression introduces delay (frequently called "latency")
    since the modem has to wait around for enough data to arrive before
    it can start compressing.  If the data is already compressed, then
    the modem can start transmitting immediately rather than sitting
    around twiddling its electronic thumbs.

Similarly, you can often get better performance by also turning off modem error
detection.  Since you have to do this at the higher levels anyway (otherwise
any noise or errors that happen between the modem and the operating system
[e.g. "zs0: silo overflow"] will leave you dead in the water), it's not worth
the added delay to have the modem do it as well.

Another hint is to make sure that you get a product that provides a window
manager running inside the display.  Otherwise, changing focus between
windows can be annoying.  Fortunately, I think most real products provide
this these days.

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