dshr@SUN.COM (David Rosenthal) (07/08/88)
I was very impressed with the X terminal prototype that XPi and Visual had at Usenix. It was directly connected to the Ethernet, but I expect to see people trying to do the same thing over the phone soon. I'm not an expert on communication protocols, but I had heard of SLIP, so I asked around to see if this was the answer. The experts I talked to were unanimous that SLIP is not the right answer; here are a selection of the reasons they gave: 1) There are a number of incompatible versions of SLIP. The RFC1055 "generic" version does not cover compression, which would be important for X terminals. 2) SLIP connections need a separate network number - this fills up the route daemon tables. 3) SLIP connections need statically assigned network and host numbers - this makes it impossible to have a pool of dial-in lines. I know that UC Davis has hacked around this, but once again this isn't RFC1055 "standard". 4) SLIP does no error checking. It depends on higher-level protocols to detect errors and do re-transmission. Doing this at the end-to-end level is very inefficient, and can mean that a very short error burst at the low level can cause a very long delay at the higher level. This would be a particular problem for any X clients that were accessed via gateways, etc. It could also be a problem for an X terminal that used NFS client code to access fonts, which would be a really good way of getting at them. 5) SLIP does not support an Ethernet-like packet type field to permit extensions (for example, extensions for compression, ISO protocols, and so on). As I understand it, an Internet Engineering Task Force has been chartered by the Internet Activities Board to attack this area. I believe they expect to have a prototype implementation in the next few months. The contact people for this effort are: Drew Daniel Perkins <ddp@andrew.cmu.edu> Russ Hobby <rdhobby@ucdavis.edu> Philip Prindeville <philipp@cs.mcgill.ca> Is anyone from the "xserial" world in touch with this effort? Since these terminals will depend on the OS they're accessing to support their brand of serial-line networking, making sure that they use whatever turns out to be the Internet standard would be pretty important. And it is probably important to get the requirements of X terminals into the design process early on. David.
devon@hcx1.SSD.HARRIS.COM (07/11/88)
I am looking for different brands of terminals which support X directly.
If anyone can give me the address or phone numbers of XPi, Visual, or
any other manufacturer of terminals with X support I would appreciate it
greatly.
--------------------------------------------------------------------
Devon Shows
devon@SSD.HARRIS.COM
...!{mit-eddie,uunet,novavax}!hcx1!devondiamant@hpfclp.SDE.HP.COM (John Diamant) (07/12/88)
> The experts I talked to were unanimous that SLIP is not the right answer; > here are a selection of the reasons they gave: Many of the points you make below are good, but there are a few corrections. It seems to me that SLIP is the best thing we have at the moment, but that we should look for better alternatives for the future. > 1) There are a number of incompatible versions of SLIP. The RFC1055 > "generic" version does not cover compression, which would be important > for X terminals. I think 4.3BSD SLIP is close to a defacto standard, though certainly there are incompatible versions, and this is a problem. Compression is definitely a problem, though it can be handled in hardware (for instance Telebit Trailblazers do hardware data compression if requested). It's not clear that compression is really that big a win during interactive use of X. It will probably only help during transfers of large bitmaps or significant other amounts of data. The handshake will slow things down in interactive response. > > 2) SLIP connections need a separate network number - this fills up > the route daemon tables. This is not true. It is implementation dependent. Cisco Systems has an implementation on their ethertip that allows all SLIP connections to be on the same network/subnet as the ethertip. > 3) SLIP connections need statically assigned network and host numbers > - this makes it impossible to have a pool of dial-in lines. I know > that UC Davis has hacked around this, but once again this isn't > RFC1055 "standard". Not impossible, just difficult. Cisco also handles this situation, by telling you which address was assigned to you upon connection. They also will work with bootp to allow a machine to ask for its own address. This isn't that big of a problem. > 4) SLIP does no error checking. Good point. > 5) SLIP does not support an Ethernet-like packet type field to permit > extensions (for example, extensions for compression, ISO protocols, > and so on). Yup. John Diamant Software Development Environments Hewlett-Packard Co. ARPA Internet: diamant@hpfclp.sde.hp.com Fort Collins, CO UUCP: {hplabs,hpfcla}!hpfclp!diamant
alan@apple.apple.COM (Alan Mimms) (07/13/88)
There's a company in Campbell, CA (area code 408) called GraphOn which is contemplating manufacturing of an X11 workstation based on its existing terminal hardware with some changes. Talk to them. They're reasonably smart people. alan Alan Mimms My opinions are generally Communications Products Group pretty worthless, but Apple Computer they *are* my own... ...it's so simple that only a child can do it! -- Tom Lehrer, "New Math"
jkh@ardent.UUCP (07/15/88)
John raised an interesting point.. Modern modems (like telebits) will indeed do compression, if requested. What's more, they'll do error checking. What's wrong with building SLIP networks that assume that the underlying hardware will take care of most of the grungyness you mentioned? Jordan
dshr@SUN.COM (David Rosenthal) (07/15/88)
> Many of the points you make below are good, but there are a few corrections. > It seems to me that SLIP is the best thing we have at the moment, but that we > should look for better alternatives for the future. The point of the mail was to show people where the "better alternatives" were coming from and what the timescale was. People interested in getting a functional defacto standard for use with X terminals need to be in touch with the IETF effort. > I think 4.3BSD SLIP is close to a defacto standard, though certainly there are > incompatible versions, and this is a problem. Compression is definitely a > problem, though it can be handled in hardware (for instance Telebit > Trailblazers do hardware data compression if requested). It's not clear that > compression is really that big a win during interactive use of X. It will > probably only help during transfers of large bitmaps or significant other > amounts of data. The handshake will slow things down in interactive response. 4.3BSD SLIP isn't a good enough defacto standard for X terminals to use, and incompatible versions are more than just "a problem" if you're shipping machines with software in ROM. The compression that matters is not Telebit-type data compression, but header compression. The headers can be many times the size of the data. To repeat, if you are planning to ship X terminals that work over the phone with generic systems, rather than just one type of proprietary box, you need to be in touch with the IETF effort. David.
jbs@fenchurch.MIT.EDU (Jeff Siegal) (07/15/88)
In article <9740039@hpfclp.SDE.HP.COM> diamant@hpfclp.SDE.HP.COM (John Diamant) writes (quoting someone else): >> 1) There are a number of incompatible versions of SLIP. The RFC1055 >> "generic" version does not cover compression, which would be important >> for X terminals. >[...]. It's not clear that compression is really that big a win >during interactive use of X. I suspect that the compression being referred to is header compression, which *is* critically important for interactive uses of SLIP, including the proposed use of X over SLIP. Header compression reduces the per-packet (and thus the per-round-trip) overhead by reducing the large and often redundant IP/TCP headers to a few bits in most cases. The Telebit TrailblazerPlus modem would probably work OK, as would any high speed modem with a reasonable turnaround time. I have used Telnet over generic SLIP (probably not much worse than X) at 2400 bps, and it was usable, but not pleasant. The TB would work even better if special support for SLIP was provided (it wasn't last I checked) like it is for UUCP, Kermit, XMODEM, etc. Jeff Siegal
bill@tahoe.unr.edu (Bill Rainey) (07/16/88)
In article <111300005@hcx1> devon@hcx1.SSD.HARRIS.COM writes: >If anyone can give me the address or phone numbers of XPi, Visual, or Here are the addresses and numbers for Xpi Inc. Wayland Square, Box 3245 Providence, RI 02906 (401) 331-8990 and Visual Technology Inc. 1703 Middlesex Street Lowell, MA 01851 (617) 459-4903 Bill Rainey Computer Science Department University of Nevada, Reno bill@tahoe.unr.edu