Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!decwrl!vixie From: vixie@decwrl.dec.com (Paul A Vixie) Newsgroups: comp.windows.x Subject: Re: X Terminals for Sun hosts over dial up phone lines Message-ID: Date: 22 Feb 89 07:23:49 GMT References: <2566@antique.UUCP> Sender: vixie@decwrl.dec.com Followup-To: comp.windows.x Organization: DEC Western Research Lab Lines: 44 In-reply-to: bob@tinman.cis.ohio-state.edu's message of 21 Feb 89 16:29:37 GMT # 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