home *** CD-ROM | disk | FTP | other *** search
/ Programmer 7500 / MAX_PROGRAMMERS.iso / PROGRAMS / UTILS / HAMRADIO / TCP90148.ZIP / TCP90148.TXT
Encoding:
Text File  |  1990-09-28  |  8.0 KB  |  219 lines
  1. TCP-Group Digest            Tue, 25 Sep 90       Volume 90 : Issue 148
  2.  
  3. Today's Topics:
  4.                        Anders can you hear me?
  5.                  For *real* network weenies only ... 
  6.                            FORTH under NOS
  7.                           NOS under Windows
  8.                       PPP protocol info (3 msgs)
  9.                      Servers not starting in NOS
  10.  
  11. Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>.
  12. Subscription requests to <TCP-Group-REQUEST@UCSD.Edu>.
  13. Problems you can't solve otherwise to brian@ucsd.edu.
  14.  
  15. Archives of past issues of the TCP-Group Digest are available
  16. (by FTP only) from UCSD.Edu in directory "mailarchives".
  17. ----------------------------------------------------------------------
  18.  
  19. Date: Mon, 24 Sep 90 6:41:50 PDT
  20. From: <marc@kg6kf.AMPR.ORG>
  21. Subject: Anders can you hear me?
  22. To: tcp-group@ucsd.edu
  23.  
  24. Anders,
  25. I have tried several times to send you e-mail, to klemets@sics.se.
  26. Is it not getting through?
  27. I want to discuss NOS Forth with you.  Please try me at the following:
  28.  
  29. marc@toaster.sfsu.edu
  30. mdg@postgres.berkeley.edu
  31. marc@toad.com
  32. marc@well.sf.ca.us
  33.  
  34. Thank you!
  35.  
  36. And thanks to the group for indulging this slightly inappropriate use
  37. of the bandwidth.
  38.  
  39. Marc de Groot KG6KF
  40.  
  41. ------------------------------
  42.  
  43. Date: Tue, 25 Sep 90 09:42:04 +0200
  44. From: klemets@sics.se
  45. Subject: For *real* network weenies only ... 
  46. To: collinge@uvicctr.uvic.ca
  47.  
  48. > What is your favourite network book I can look it up in?
  49.  
  50. Try "Data Networks" by D. Bertsekas and R. Gallagher, Prentice-Hall 1987. 
  51. That is a good textbook on throughput analysis, routing, etc.
  52.  
  53. Anders
  54.  
  55. ------------------------------
  56.  
  57. Date: Mon, 24 Sep 90 21:05:13 UTC
  58. From: iw0cnb@tomcat.gsfc.nasa.gov
  59. Subject: FORTH under NOS
  60. To: tcp-group@ucsd.edu
  61.  
  62. Nice to hear about new version, I tried the first one and it's great!
  63. I made the command "forth" to open a new session so I can open multiple forth
  64. interpreters. But there are memory problems, I often get "freeing garbage"
  65. with associated NOS crash...
  66.  
  67. Will it be possible to interface it with the TCP sockets so we can write NOS
  68. applications in FORTH?????
  69.  
  70. Max
  71.  
  72. iw0cnb@tomcat.gfsc.nasa.gov
  73.  
  74. ------------------------------
  75.  
  76. Date: Mon, 24 Sep 90 21:13:20 UTC
  77. From: iw0cnb@tomcat.gsfc.nasa.gov
  78. Subject: NOS under Windows
  79. To: tcp-group@ucsd.edu
  80.  
  81. For those who might care, I use the following PIF settings for NOS under
  82. Windows 3.0 in 386 mode:
  83.  
  84. Memory used: 400 kb
  85. Memory required: 640 kb
  86. Full-screen and no background (I can change them later, in the "settings" window
  87. In the advanced options, I turned off EMS usage and High memory.
  88. Since we work in text mode, I unchecked all the boxes regarding graphics.
  89. No text mode emulation and no video memory retain.
  90.  
  91. As to the background and foreground priority, it works ok with the default
  92. values of 50 and 100. I tried to give it maximum priority, and it almost works
  93. ok at 4800 while in text mode, but as soon as I virtualize the screen (put it
  94. in a window), it loses characters.
  95.  
  96. I also put in the system.ini file the line COM1BUFFER=1024, but it doesn't seem
  97. to help much. Maybe we should make NOS aware of Windows, like it is with
  98. DesqView and DoubleDos, where it doesn't lose characters. Any idea is welcome...
  99.  
  100. Max
  101.  
  102. iw0cnb@tomcat.gsfc.nasa.gov
  103.  
  104. ------------------------------
  105.  
  106. Date: Mon, 24 Sep 90 21:24:09 UTC
  107. From: iw0cnb@tomcat.gsfc.nasa.gov
  108. Subject: PPP protocol info
  109. To: tcp-group@ucsd.edu
  110.  
  111. I downloaded PA0GRI sources which include the Point to Point protocol.
  112. Since there were no doc, I tried to grasp something from the source comments.
  113. I understand that this protocol (and the associated compression routines)
  114. is intended for slip work. Is it possible to use it in a packet radio
  115. environment, possibly for SMTP compressed forwarding???
  116.  
  117. We are trying to put up a TCP/IP HF link using 1200 PSK, so data transfer
  118. time should be kept low....
  119.  
  120. Max
  121.  
  122. iw0cnb@tomcat.gsfc.nasa.gov
  123.  
  124. ------------------------------
  125.  
  126. Date: Mon, 24 Sep 90 17:32:11 PDT
  127. From: Brian Lloyd <brian@robin.telebit.COM>
  128. Subject: PPP protocol info
  129. To: tcp-group@ucsd.edu
  130.  
  131. No, PPP is not designed in such a way that it can be used over the
  132. radio.  The basic PPP frame is an HDLC frame with the address field
  133. set to ff, the control field set to 03 (UI), a two octet type field,
  134. and then the data which is usually an IP dgram.  Because of the
  135. address field, ctl field, and the two octet type field it is less
  136. efficient than SLIP (I guess that it is still more efficient than
  137. AX.25 but that is another story :-).
  138.  
  139. The one item that PPP supports that would be a win for AX.25 (and
  140. could be applied to AX.25 with little or no effort) is an option
  141. negotiation process that allows you to negotiate away just about
  142. everything (like the useless address and control fields and the first
  143. octet of the type field).  
  144.  
  145. One of the items that it does allow you to negotiate ON is Van
  146. Jacobson's TCP/IP header compression.  Basically Van's compression
  147. allows the receiver to predict what the next header will look like and
  148. thus allow the sender to send only that information that really
  149. changes from packet to packet.  The result for TELNET, FTP, and SMTP
  150. sessions is that most of the TCP+IP headers gets squashed to 5 or 6
  151. octets instead of the usual 40 octets.  This would be a big win for HF
  152. use.  You could drop your packet size way down and not take the huge
  153. throughput hit.
  154.  
  155. You don't get something for nothing though.  The first TCP+IP header
  156. must get through uncompressed: all 40 octets of it.  The sender
  157. basically sends header deltas from there.  Bottom line is that your
  158. link must be good enough to get the first packet through.
  159.  
  160. Maybe someone ought to offer up an extension to AX.25 that includes
  161. option negotiation and header prediction/compression.
  162.  
  163. 73 de Brian, WB6RQN
  164.  
  165. ------------------------------
  166.  
  167. Date: Mon, 24 Sep 90 22:20:14 -0400
  168. From: "Louis A. Mamakos" <louie@sayshell.umd.edu>
  169. Subject: PPP protocol info 
  170. To: tcp-group@ucsd.edu
  171.  
  172. An assumption made in VJ TCP header compression algorithms is that the
  173. link is somewhat reliable; at the slightest provocation, the alogrithm
  174. will revert to sending a complete, uncompressed TCP segment.  This is
  175. usually the result when the TCP retransmits.  It's not all roses.
  176.  
  177. If you were to use header compression, you'd might think about running it 
  178. over an connected mode AX.25 circuit.  Though, you would have to think about
  179. how efficient that is compared to TCP's ability to reassembly out of order
  180. segments and its generally better retransmission strategies.
  181.  
  182. Or maybe you could use the effective added bandwidth gained by header
  183. compression to include some FEC "overhead"?
  184.  
  185. louie
  186. WA3YMH
  187.  
  188. ------------------------------
  189.  
  190. Date: Mon, 24 Sep 90 11:38:00 EDT
  191. From: Marcus (M.D.) Leech <MLEECH@BNR.CA>
  192. Subject: Servers not starting in NOS
  193. To: tcp-group@ucsd.edu
  194.  
  195. We're currently having a problem with NOS0828 with the servers not
  196.   starting.  Mostly it's the TELNET server, but sometimes other
  197.   servers won't start (FINGER, ECHO, DISCARD).
  198.  
  199. When you go to start them manually, you have to "stop <servername>" even
  200.   though there's no process-table entry or socket-table entry associated
  201.   with the process. It's almost like the process gets "half-started" and
  202.   then silently dies leaving enough cruft around that you have to
  203.   stop it before you can restart it.  Has anyone else experienced this
  204.   problem?  When this problems happens, there's no obvious memory
  205.   starvation going on.  I've tried starting with the interfaces unplugged, to
  206.   avoid any possible interrupt-caused-races within the kernel--it still
  207.   happens when I do that.
  208.  
  209. --
  210. -----------------
  211. Marcus Leech, 4Y11             Bell-Northern Research  |opinions expressed
  212. mleech@bnr.ca                  P.O. Box 3511, Stn. C   |are my own, and not
  213. VE3MDL@VE3JF.ON.CAN.NA         Ottawa, ON, CANADA      |necessarily BNRs
  214.  
  215. ------------------------------
  216.  
  217. End of TCP-Group Digest
  218. ******************************
  219.