Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ucbvax!bloom-beacon!SUN.COM!dshr From: dshr@SUN.COM (David Rosenthal) Newsgroups: comp.windows.x Subject: X Terminals & SLIP Message-ID: <8807072305.AA03109@devnull.sun.com> Date: 7 Jul 88 21:01:25 GMT Sender: daemon@bloom-beacon.MIT.EDU Organization: The Internet Lines: 50 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 PerkinsRuss Hobby Philip Prindeville 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.