hpk@antique.UUCP (Howard Katseff) (02/21/89)
I have seen a few articles describing X terminals; low cost terminals that run an X server and are used to access computing via the network. I would like to use one of these X terminal from home to access my Sun workstation at work over a dialup line. I have seen references to SLIP and 9600 baud modems but I am quite ignorant about such things. I would appreciate hearing an explanation of how this works, recommendations about X terminals or modems, or best of all, I would like to hear from somebody who has successfully tried to do this! -- Howard Katseff Room 4G-622, AT&T Bell Laboratories, Holmdel, NJ 07733 UUCP: att!vax135!hpk Internet: hpk@vax135.att.com 201 949-5337
dana@dino.bellcore.com (Dana A. Chee) (02/21/89)
In article <2566@antique.UUCP> hpk@antique.UUCP (Howard Katseff) writes:
I would like to use one of these X terminal from home to access my Sun
workstation at work over a dialup line.
I have seen references to SLIP and 9600 baud modems but I am quite
ignorant about such things. I would appreciate hearing an explanation
of how this works, recommendations about X terminals or modems,
or best of all, I would like to hear from somebody who has successfully
tried to do this!
--
Howard Katseff
Room 4G-622, AT&T Bell Laboratories, Holmdel, NJ 07733
UUCP: att!vax135!hpk
Internet: hpk@vax135.att.com
201 949-5337
I have a 9600 baud SLIP line from home, so I can give you a brief
summary of what to expect ... NOTHING!!. 9600 is WAY too slow to run
X over. I have tried to run clients on the office machines, while
using my home machine as the display. Its painful! The windows paint
in little bursts, which makes you think you have a 300 baud modem.
As for how it works. SLIP acts like another device (if you have Suns,
you're used to le0, ie0, ec0, etc., well SLIP is sl0). You set up
your network to use sl0 for the network, and on the office side, you
tell the machine what tty port your home machine(terminal) will come
in over, and at what speed. There is a program (slattach) which when
run from /etc/rc.local, will set things up (you also have to make
changes (i.e., add drivers) to your vmunix).
For a summary, it would be very slow going, X was designed for a high
speed network.
--
+*************************************************************************+
* Dana Chee (201) 829-4488 *
* Bellcore *
* Room 2Q-250 *
* 445 South Street ARPA: dana@bellcore.com *
* Morristown, NJ 07960-1910 UUCP: {gateways}!bellcore!dana *
+*************************************************************************+bob@tinman.cis.ohio-state.edu (Bob Sutterfield) (02/22/89)
In article <2566@antique.UUCP> hpk@antique.UUCP (Howard Katseff) writes: I would like to use one of these X terminals from home to access my Sun workstation at work over a dialup line. ... I have seen references to SLIP and 9600 baud modems but I am quite ignorant about such things. In article <DANA.89Feb21094308@dino.bellcore.com> dana@dino.bellcore.com (Dana A. Chee) writes: I have a 9600 baud SLIP line from home, so I can give you a brief summary of what to expect ... NOTHING!!. 9600 is WAY too slow to run X over... For a summary, it would be very slow going, X was designed for a high speed network. If all you want is an X terminal, you don't really want to bother with becoming a part of the Internet. SLIP is appropriate for providing IP connectivity to remote workstations, but that's not really what an X terminal is. Without the overhead of SLIP, 9600 would be more tolerable for interactive X applications. A Trailblazer would be even better, since it could try to batch and compress on the output side.
yduJ@lucid.com (Judy Anderson) (02/22/89)
In article <DANA.89Feb21094308@dino.bellcore.com> dana@dino.bellcore.com (Dana A. Chee) writes: >In article <2566@antique.UUCP> hpk@antique.UUCP (Howard Katseff) writes: >> [various questions about SLIP and X] >I have a 9600 baud SLIP line from home, so I can give you a brief >summary of what to expect ... NOTHING!!. 9600 is WAY too slow to run >X over. I have tried to run clients on the office machines, while >using my home machine as the display. Its painful! The windows paint >in little bursts, which makes you think you have a 300 baud modem. >For a summary, it would be very slow going, X was designed for a high >speed network. I find that SLIP at 9600 baud is quite acceptable, but only if you have your xterm (or whatever) running locally and use rlogin/telnet to access the remote system. I find that I need two windows up: One local xterm with a local emacs running a rlogin'd shell buffer, so that most of my shell and program interaction is done with character echoing done by the local xterm and emacs, and a second local xterm rlogin'd to the remote system, running an emacs there for remote file editting. I then use X cut and paste if I want to transfer a small amount of data from a remote file as part of a command to the remote shell (running in a local emacs) or vice-versa. The remote emacs feels like it's at 1200 to 2400 baud when nothing else is going on. For heavy editting tasks I'll transfer the file to be editted, do my changes, and transfer it back. There's always some size of file/number of changes ratio to figure out whether it's better to put up with the slow response of the remote system or wait for the file transfer. You can figure on 7500 baud for file transfers. One of my co-workers wrote some scripts which compress files, transfer them, and uncompress them, which gets you another 2.5 times effective speed. Response goes to pot when you are doing a file transfer; the remote emacs becomes completely unusable for that period. My experiences combined with Dana's above show that you really need a workstation on the other end of your SLIP connection; an X terminal just won't do the job. Maybe your company has a spare Sun-2 they could let you have :-) yduJ (Judy Anderson) ...!sun!edsel!yduJ (617)784-6114 yduJ@lucid.com ('yduJ' rhymes with 'fudge') edsel!yduJ@labrea.stanford.edu
barmar@think.COM (Barry Margolin) (02/22/89)
In article <BOB.89Feb21112937@tinman.cis.ohio-state.edu> bob@tinman.cis.ohio-state.edu (Bob Sutterfield) writes: >If all you want is an X terminal, you don't really want to bother with >becoming a part of the Internet. SLIP is appropriate for providing IP >connectivity to remote workstations, but that's not really what an X >terminal is. First of all, X requires a reliable byte stream protocol underneath it, so you usually want something like TCP running over SLIP. Some high-speed modems claim to do error correction, but you still have to worry about errors on the cable between the host and the modem or between the modem and the terminal. TCP provides the end-to-end error detection that is necessary for a really reliable connection. Second, you need to multiplex multiple streams over the connection. Each X client has at least one unique stream open to the workstation. TCP provides the multiplexing. Third, X terminals frequently DO want to become part of the network. Unless there's only one client host at the site, the X terminal is likely to want to have windows connected to different hosts (e.g. several xterm windows). IP provides this connectivity. Barry Margolin Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
vixie@decwrl.dec.com (Paul A Vixie) (02/22/89)
# If all you want is an X terminal, you don't really want to bother with # becoming a part of the Internet. SLIP is appropriate for providing IP # connectivity to remote workstations, but that's not really what an X # terminal is. Well, it is, sort of. If you want to have an X display (+keyboard +pointer) with windows open on it from several different places, you've got to find a way to name the display and a way to get data back and forth from the clients. And once you've got named entities exchanging data, you've got most of the ingredients of a network. The Internet is a popular network these days, though you can run X over tin cans and string if you really want to. (That is, X-over-DECNet is a supported product on VMS and Ultrix.) # Without the overhead of SLIP, 9600 would be more tolerable for # interactive X applications. A Trailblazer would be even better, since # it could try to batch and compress on the output side. I don't agree. You need some kind of framing, even on the Telebit where error detection/correction is done for you at the link level. The X server doesn't want to deal with a byte stream -- it wants to deal with packets. It expects those packets to be sequenced and reliable, but forget that fort a moment; the important need here is for framing. Assuming that something underneath the X server is going to provide X with datagram access to the network, why not SLIP? SLIP (and TCP) gives you not only framing, but a way to have virtual circuits open to more than one remote destination -- which is handy for X since you tend to have windows open from several hosts at the same time. How much overhead? Too much. TCP adds 20 bytes (usually) and IP adds 20 more. Framing adds one or two, plus some escapes if your data includes the framing character in it. Best case is 41 bytes of overhead per packet. That's bigger than the average X packet, right? Fortunately we're starting to compress the IP/TCP headers. If this kind of compression becomes popular, I think we'll see compression of X headers, as long as they are predictable from one packet to the next. Anyway, the point of this long ramblingness is that a raw byte stream, even if reliable and sequenced as in the Telebit, is not a good match for X. And if you don't like SLIP for your serial protocol, I'm listening: suggest a datagram-oriented alternative. -- Paul Vixie Work: vixie@decwrl.dec.com decwrl!vixie +1 415 853 6600 Play: paul@vixie.sf.ca.us vixie!paul +1 415 864 7013
bob@tinman.cis.ohio-state.edu (Bob Sutterfield) (02/23/89)
In suggesting the elimination of SLIP in favor of a pair of Telebits,
I was thinking of the GraphOn X terminal's model of the world, as
described by WOOD@SMITHKLINE.COM ("Bill Wood, Upper Merion IS X5163
L331") in <8902220455.AA27885@expo.lcs.mit.edu>. Since its server
runs on a UNIX host and simply handles its display on the terminal, IP
is unneeded, TCP for reliable streams is overkill, and in-modem
compression sometimes wins. (If it doesn't win, then at least you
break even.) Mr. Wood even reports that simple 9600bps modems are
survivable.
Certainly IP is the correct way to glue something into the internet if
it has a bit more ambitious view of its responsibilities, such as a
terminal (or certainly a workstation) running its own server locally.
In that (perhaps more common) case, IP (or some other routing and
delivery mechanism) is necessary and TCP (or some other stream
mechanism) is an appropriate layer.
In article <VIXIE.89Feb21232349@bacchus.pa.dec.com> vixie@decwrl.dec.com (Paul A Vixie) writes:
Anyway, the point of this long ramblingness is that a raw byte
stream, even if reliable and sequenced as in the Telebit, is not a
good match for X. And if you don't like SLIP for your serial
protocol, I'm listening: suggest a datagram-oriented alternative.
I spend some days evangelizing others to the benefits of
internetworking, so I am aware of the joys of full generality, but
only where it's appropriate. It seems, from the uproar over my
apparent "suggestion that TCP/IP be abandoned", that more folks think
of terminals with that latter more ambitious view than with the former
simplistic outlook. I need to pay more attention to my terms...alberto@tove.umd.edu (Jose Alberto Fernandez R) (02/23/89)
Finally I found someone interested in using X windows from HOME. From your comments looks like the hardware solutions are not practical. I'm thinking in a software solution similar in the way that `x10tox11' works. The idea is to have a server program running on the host, this program only takes all the events and transmit the information in a more suitable format throught the phone line. On the other side, a similar program read from the phone lines and creates the events for the Xserver (who is running on the Micro-computer). Actually the interpreter on the line could be the Micro-computer's Xserver itself. This approach does not need any modification in the kernel nor any other place. And using a diferent codification in the line could help with the speed problem. Well I hope some body can make some comments about if it is possible to create something like this. And that some body in the Network will try to implement something like this (I don't have any idea of how to program in X11). Please let me know your comments about it. -- Jose Alberto. / \ Jose Alberto Fernandez R | INTERNET: alberto@tove.umd.edu | o o | Dept. of Computer Sc. | | ^ | Univesity of Marylad | \ \_/ / College Park, MD 20742 |
dfh@bnrunix.UUCP (David F. Hinnant) (02/23/89)
In article <DANA.89Feb21094308@dino.bellcore.com>, dana@dino.bellcore.com (Dana A. Chee) writes: > In article <2566@antique.UUCP> hpk@antique.UUCP (Howard Katseff) writes: > ... I would like to hear from somebody who has successfully > tried to do this! > > I have a 9600 baud SLIP line from home, so I can give you a brief > summary of what to expect ... NOTHING!!. 9600 is WAY too slow to run Soon after we got our three Visual Technology X Window Stations (XDS), I called the folks at XPI who did the communications s/w for the XDS and asked them about the performance of this scenario. Indeed ordinary Sun SLIP is painfully slow I was told and that given sufficient performance, 9600 could be made bearable. Not being a SLIP person I have no idea what parametmers could be/need to be twiddled; nor do I knwo where to get SLIP for the Sun (pointers please!). I believe I remember being told that some people (at HP?) had been looking at improving the performance of SLIPs for this environment. -- David Hinnant UUCP: ...{decvax,akgua}!mcnc!rti!bnrunix!dfh Bell Northern Research (919) 991-8299
brooks@vette.llnl.gov (Eugene Brooks) (02/23/89)
In article <2566@antique.UUCP> hpk@antique.UUCP (Howard Katseff) writes: >I have seen a few articles describing X terminals; low cost terminals >that run an X server and are used to access computing via the network. > >I would like to use one of these X terminal from home to access my Sun >workstation at work over a dialup line. I understand that the Visual terminal can be set up to run SLIP on a serial line and performance is said to be "acceptible" at 19.2K baud. The latest microcom modem will provide performance somewhere between 19.2K and 38.4K baud with its class 9 MNP protocol. Is the news software incompatible with your mailer too? brooks@maddog.llnl.gov, brooks@maddog.uucp, uunet!maddog.llnl.gov!brooks
janssen@titan.sw.mcc.com (Bill Janssen) (02/24/89)
In article <20819@lll-winken.LLNL.GOV>, brooks@vette (Eugene Brooks) writes: >I understand that the Visual terminal can be set up to run SLIP on a >serial line and performance is said to be "acceptible" at 19.2K baud. Depends a bit on your clients. We tried our Visual on a hard-wired 19.2 Kbaud SLIP line, and performance was on the sluggish side of acceptable for xterm (I wouldn't use it at that speed), and completely unacceptable for more elegant clients, such as FrameMaker or Andrew `messages'. Bill
bzs@Encore.COM (Barry Shein) (02/24/89)
Re: X over SLIP
Perhaps this would be a good excuse for us all to look at the RFC for
a "Thinwire Protocol". The basic idea is to take advantage of the fact
that the source and dest addr and other info of packets over the SLIP
line are almost always the same so have some (eg) single-bit way of
saying "same as last packet", this can reduce the fixed overhead
considerably (there are calculations in the RFC.)
Other, similar extensions could be made to SLIP and an updated
Thinwire Protocol proposed (or adopted as is!), it's been a few years
and it was hardly ubiquitous so I'd suspect the community would be
open to a proposal. Personally I always thought it was a good idea
given the realities of a point-to-point connection.
-Barry Shein, ||Encore||
RFC
914 Farber, D.J.; Delp, G.; Conte, T.M. Thinwire protocol for connecting
personal computers to the Internet. 1984 September; 22 p. (58586 bytes)mike@ists.ists.ca (Mike Clarkson) (02/24/89)
In article <16083@mimsy.UUCP>, alberto@tove.umd.edu (Jose Alberto Fernandez R) writes:
The idea is to have a server program running on the host, this
program only takes all the events and transmit the information in a
more suitable format throught the phone line. On the other side, a
similar program read from the phone lines and creates the events
for the Xserver (who is running on the Micro-computer). Actually
the interpreter on the line could be the Micro-computer's Xserver
itself.
How about using PostScript :-) ?
Mike.
--
Mike Clarkson mike@ists.UUCP
Institute for Space and Terrestrial Science mike@ists.ists.ca
York University, North York, Ontario, uunet!mnetor!yunexus!ists!mike
CANADA M3J 1P3 +1 (416) 736-5611alberto@tove.umd.edu (Jose Alberto Fernandez R) (03/02/89)
The Idea of use POSTSCRIPT as the comunication Protocol is not a bad one. Actually, there is not a tool as this for NeWS?, must be very easy to implement. I like the ideas of NeWS very much (was my first window system), but the speed of the server make me change to X. I can't wait forever and ever each time I move a window. A tool as this GRAPHON terminal that you are talking about is more or less the type of things I am looking for. There is not a tool such as this but in software? (For PCs, etc) There are many students (like me) that would like to use something like that from home and can't afford a sophisticated hardware. Some ideas Xhackers? -- Jose Alberto. / \ Jose Alberto Fernandez R | INTERNET: alberto@tove.umd.edu | o o | Dept. of Computer Sc. | | ^ | Univesity of Marylad | \ \_/ / College Park, MD 20742 |
mh@wlbr.EATON.COM (Mike Hoegeman) (03/05/89)
In article <16174@mimsy.UUCP> alberto@tove.umd.edu.UUCP (Jose Alberto Fernandez R) writes: > The Idea of use POSTSCRIPT as the comunication Protocol is not a bad one. > Actually, there is not a tool as this for NeWS?, must be very easy to I think bruce schwartz made something like this for NeWS. check out the SEX tape (sun user group software exchange tape) or the NeWS stuff on tumtum.umd.edu > implement. I like the ideas of NeWS very much (was my first window > system), but the speed of the server make me change to X. I can't wait > forever and ever each time I move a window. I've found the Performance of NeWS to be just fine. What does "waiting forever and ever to paint, each time i move a window mean ?" sounds to me like you're not doing something right.