From: rick@ee.uwm.edu (Rick Miller)
Newsgroups: comp.os.linux
Subject: Re: SLIP and X386
Summary: Step back and take a look.
Date: 8 Sep 92 15:12:35 GMT
Article-I.D.: uwm.1992Sep8.151235.3292
Organization: University of Wisconsin, Milwaukee

In article <55pnpxd.genie@netcom.com> genie@netcom.com (The Genie) writes:
[...]
>Is it possible to use SLIP and X Windows together?
[...]

Well, let's define terms, shall we?
(Correct me if I'm wrong.  I'm doing this from memory!)

   IP - "Inter-net Protocol"
	This is just a protocol which allows Local Area Networds (LANs)
	to exchange data packets.  While the hardware protocol on a LAN
	(such as X25 on an EtherNet) will only recognize addresses on
	it's own LAN, the IP addressing scheme allows addressing outside
	of the local (hardware) net.

   TCP - "Transfer Control Protocol"
	This is *another* protocol, another 'layer', which helps
	keep track of which packets of information go together and
	what applications they're coming from and going to.
	TCP rides on top of IP, just as IP rides on top of the
	LAN's hardware (which is usually an EtherNet).

   ka9q - " .-.  .-  ----.  --.- " (that's Morse code :-)
	This is the call-sign of the Amateur Radio operator who
	developed the original 'ka9q' package.  I forget his name.
	It was originally intended to allow bare-bones TCP/IP-like
	functionality over Amateur-X25 (AX25) packet radio nets.
	It *emulates* 'telnet' and 'ftp' using its own *built-in*
	'knowledge' of TCP and IP.  Thus, it comes in real handy for
	those machines which don't have kernel TCP/IP, since it does
	all that for itself.  However, ka9q is *not* a 'service'.
	It does its own *internal* MUX/DeMUXing, and expects to have
	a *single* user.  When run, it expects to have exclusive
	control of one hard-wired I/O port, and it won't share it
	with any other process, not even another ka9q.

   kernel TCP/IP - "The Real Thing (tm)"
	This is the ability of the Operating System to manage the
	resources necessary for TCP/IP communications.  This allows
	multiple processes to access the network, ALL THROUGH THE SAME
	PHYSICAL CONNECTION, simultaneously.  This *MUST* be done by
	the kernel, since it involves multiple processes all using the
	same hardware (EtherNet card, serial port, whatever...).

   SLIP - "Standard Line Inter-net Protocol"
	This is simply a way of using IP over a regular phone line.
	Since most of us don't have the cash to lease a high-speed line
	from the local telecom company, this is probably the next-best
	thing to being there.  It's gonna be a bit slower though. :-)
	The ka9q package is especially well-adapted for SLIP, since it
	was *designed* to communicate at lower speeds through a serial
	port (and a packetizer, and a modem, and a radio transciever...)

[...]
>With packages like ka9q, is it possible to redirect all
>tcp/ip packets to the serial modem?  A true SLIP
>connection would allow things like xhosting, etc.
[...]

Like I said, ka9q was *made* to use a serial line.  However, it doesn't
provide connections for other applications.  ka9q is *not* a service.
It's an application which *mimics* the performance of telnet and ftp
(which use the TCP/IP service), but does all the protocol itself.

If you "telnet using ka9q", you're really "ka9q'ing in telnet mode".
Get it?  The 'real' telnet program (which makes TCP/IP-related system-
calls to the kernel) wasn't even used.

telnet and ftp are like automobiles, and kernel TCP/IP is like a bridge.
They can function, but not cross the net without kernel TCP/IP just as
automobiles may tool around town, but not cross rivers without a bridge.

ka9q is like a boat.  Just as a boat is no good for driving around town,
but can cross a river where there's no bridge, ka9q is no good for inter-
process communication, but it can communicate on the net without the help
of kernel TCP/IP.

The same way, 'xhost' needs kernel TCP/IP.  It cannot use the ka9q package,
because ka9q is suited only to serving a single USER, not other processes.

Rick Miller   <rick@ee.uwm.edu> | <rick@discus.mil.wi.us>