From: rick@ee.uwm.edu (Rick Miller) Subject: Re: SLIP and X386 Date: Tue, 8 Sep 1992 15:12:35 GMT
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>