home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / os / linux / 10178 < prev    next >
Encoding:
Internet Message Format  |  1992-09-08  |  4.1 KB
  1. Path: sparky!uunet!ogicse!uwm.edu!news
  2. From: rick@ee.uwm.edu (Rick Miller)
  3. Newsgroups: comp.os.linux
  4. Subject: Re: SLIP and X386
  5. Summary: Step back and take a look.
  6. Message-ID: <1992Sep8.151235.3292@uwm.edu>
  7. Date: 8 Sep 92 15:12:35 GMT
  8. Article-I.D.: uwm.1992Sep8.151235.3292
  9. References: <55pnpxd.genie@netcom.com>
  10. Sender: news@uwm.edu (USENET News System)
  11. Organization: University of Wisconsin, Milwaukee
  12. Lines: 81
  13.  
  14. In article <55pnpxd.genie@netcom.com> genie@netcom.com (The Genie) writes:
  15. [...]
  16. >Is it possible to use SLIP and X Windows together?
  17. [...]
  18.  
  19. Well, let's define terms, shall we?
  20. (Correct me if I'm wrong.  I'm doing this from memory!)
  21.  
  22.    IP - "Inter-net Protocol"
  23.     This is just a protocol which allows Local Area Networds (LANs)
  24.     to exchange data packets.  While the hardware protocol on a LAN
  25.     (such as X25 on an EtherNet) will only recognize addresses on
  26.     it's own LAN, the IP addressing scheme allows addressing outside
  27.     of the local (hardware) net.
  28.  
  29.    TCP - "Transfer Control Protocol"
  30.     This is *another* protocol, another 'layer', which helps
  31.     keep track of which packets of information go together and
  32.     what applications they're coming from and going to.
  33.     TCP rides on top of IP, just as IP rides on top of the
  34.     LAN's hardware (which is usually an EtherNet).
  35.  
  36.    ka9q - " .-.  .-  ----.  --.- " (that's Morse code :-)
  37.     This is the call-sign of the Amateur Radio operator who
  38.     developed the original 'ka9q' package.  I forget his name.
  39.     It was originally intended to allow bare-bones TCP/IP-like
  40.     functionality over Amateur-X25 (AX25) packet radio nets.
  41.     It *emulates* 'telnet' and 'ftp' using its own *built-in*
  42.     'knowledge' of TCP and IP.  Thus, it comes in real handy for
  43.     those machines which don't have kernel TCP/IP, since it does
  44.     all that for itself.  However, ka9q is *not* a 'service'.
  45.     It does its own *internal* MUX/DeMUXing, and expects to have
  46.     a *single* user.  When run, it expects to have exclusive
  47.     control of one hard-wired I/O port, and it won't share it
  48.     with any other process, not even another ka9q.
  49.  
  50.    kernel TCP/IP - "The Real Thing (tm)"
  51.     This is the ability of the Operating System to manage the
  52.     resources necessary for TCP/IP communications.  This allows
  53.     multiple processes to access the network, ALL THROUGH THE SAME
  54.     PHYSICAL CONNECTION, simultaneously.  This *MUST* be done by
  55.     the kernel, since it involves multiple processes all using the
  56.     same hardware (EtherNet card, serial port, whatever...).
  57.  
  58.    SLIP - "Standard Line Inter-net Protocol"
  59.     This is simply a way of using IP over a regular phone line.
  60.     Since most of us don't have the cash to lease a high-speed line
  61.     from the local telecom company, this is probably the next-best
  62.     thing to being there.  It's gonna be a bit slower though. :-)
  63.     The ka9q package is especially well-adapted for SLIP, since it
  64.     was *designed* to communicate at lower speeds through a serial
  65.     port (and a packetizer, and a modem, and a radio transciever...)
  66.  
  67. [...]
  68. >With packages like ka9q, is it possible to redirect all
  69. >tcp/ip packets to the serial modem?  A true SLIP
  70. >connection would allow things like xhosting, etc.
  71. [...]
  72.  
  73. Like I said, ka9q was *made* to use a serial line.  However, it doesn't
  74. provide connections for other applications.  ka9q is *not* a service.
  75. It's an application which *mimics* the performance of telnet and ftp
  76. (which use the TCP/IP service), but does all the protocol itself.
  77.  
  78. If you "telnet using ka9q", you're really "ka9q'ing in telnet mode".
  79. Get it?  The 'real' telnet program (which makes TCP/IP-related system-
  80. calls to the kernel) wasn't even used.
  81.  
  82. telnet and ftp are like automobiles, and kernel TCP/IP is like a bridge.
  83. They can function, but not cross the net without kernel TCP/IP just as
  84. automobiles may tool around town, but not cross rivers without a bridge.
  85.  
  86. ka9q is like a boat.  Just as a boat is no good for driving around town,
  87. but can cross a river where there's no bridge, ka9q is no good for inter-
  88. process communication, but it can communicate on the net without the help
  89. of kernel TCP/IP.
  90.  
  91. The same way, 'xhost' needs kernel TCP/IP.  It cannot use the ka9q package,
  92. because ka9q is suited only to serving a single USER, not other processes.
  93.  
  94. Rick Miller   <rick@ee.uwm.edu> | <rick@discus.mil.wi.us>
  95.