home *** CD-ROM | disk | FTP | other *** search
/ Boldly Go Collection / version40.iso / TS / 05B / TN210.ZIP / NETWORK.EXE / NET-6.TXT < prev    next >
Encoding:
Text File  |  1992-07-02  |  5.2 KB  |  81 lines
  1.                                 NET-6.TXT
  2.                             OPERATING PRACTICES
  3.                             -------------------
  4.  
  5. No  matter  how  efficient  a  network  configuration  may  be,  poor operating
  6. practices  can  create  congestion.    Since simplex networks perform best when
  7. lightly  loaded, more  "mileage" can  be gained from them if the users were  to
  8. employ common sense in this regard and practice PACKET CONSERVATION.
  9.  
  10. Just  as world-wide attention  and awareness  is being focused on the fact that
  11. our  natural  resources are dwindling, we packeteers could benefit if attention
  12. were focused on the impact our actions make on the network.   Since the network
  13. is  limited,  it would be well to keep in mind  every connect  sent through the
  14. network  could adversely impact someone else either up or down the line.   This
  15. isn't to say one shouldn't use and enjoy the network.    But such use should be
  16. adjusted in terms of consideration to others.
  17.  
  18. With  the price of  IBM XT clones under the $350.00 mark, it's easy for someone
  19. to  install  a  packet  BBS  these  days.     Or they  can load  it with TCP/IP
  20. software and add a node to the network.  Unfortunately this is quite frequently
  21. done without giving any thought as to what impact it will make.  It may well be
  22. the addition  of another  BBS in an area that already has adequate BBS service,
  23. could overload the network and thus cause dissention among the users.
  24.  
  25. Frequently the operation of a TCP/IP node is harmful  to  the network function.
  26. This is true even when  the TCP/IP node is not in active session.  Remember the
  27. node barf spoken of previously?    TCP/IP nodes add to the "node chatter" found
  28. in a dynamic network.    This added overhead steals away circuit time available
  29. for other users.     Network nodes provide connectivity and routes that benefit
  30. all users.   Usually not true with TCP/IP nodes.   The majority of TCP/IP nodes
  31. are nothing more than an end terminal for its owner.   When in active  session,
  32. TCP/IP nodes  can adversely  impact  the "hidden transmitter syndrome".  In the
  33. hands  of an inexperienced  person, operation of TCP/IP through the system  can
  34. disconnect all users.  An active node can prevent other usage for hours on end.
  35.  
  36. We are not suggesting TCP/IP is bad.   TCP/IP has many features that works well
  37. when  used  in  its  intended  environment.    This  envirnoment is on a robust
  38. full-duplex  9600 baud or higher,  circuit.   Originally  intended to  overcome
  39. varying protocol compatibility problems on LL systems,  TCP/IP has higher over-
  40. head than AX.25.  As such it will never perform as efficiently.   Using it on a
  41. multi-user  simplex 1200 baud radio channel frequently causes problems to other
  42. users.
  43.  
  44. Continuing with the concept that we users can modify our operating practices to
  45. make  the  present network more efficient, lets review and expand on the points
  46. made previously.
  47.  
  48. We  know  simplex  networks  perform  best  under  light to  moderately  loaded
  49. conditions.   If we all were to practice  "packet conservation",  it  stands to
  50. reason  we will be able  to get more efficient  use out of our present systems.
  51. By packet conservation, I am referring primarily to avoiding the little verbose
  52. habits  we  tend to  have.    One  of these  (which is  covered in nearly EVERY
  53. packet primer) is beaconing.  There are exceptions to this, but in general it's
  54. better to NOT beacon.   If one really feels a specific need to beacon, than  it
  55. should be limited to  intervals of not less  than once every 15 minutes.  Along
  56. simplex networks,  user beacon transmissions  may cause collisions with network
  57. nodes,  thus QRMing  the channel  and  delaying  throughput.   On a full-duplex
  58. repeater, beacons will delay ongoing traffic through the repeater.
  59.  
  60. An  extreme  case of  beaconing was noted a few years  ago off one of the local
  61. nodes.   Several  BBSes  had converged on the channel and apparently the SysOps
  62. felt the need to compete with each other.  The result was various long beacons.
  63. Some of cartoon characters,  some of page-length announcements, and each seemed
  64. to have a repetition  rate of every  two or three minutes.   Inner-mingling the
  65. beacons was near constant BBS fwding activity.  After a time, the few remaining
  66. users were  oblivious  to the beacon activity since they filtered the offending
  67. BBS  callsigns out.    The  net  result  was the  beacons  and verbose  connect
  68. messages  were  counter-productive inasmuch  as many BBS users were driven away
  69. due  to  the  congestion.    Those  who remained weren't able to enjoy  ragchew
  70. activity and went into non-monitor status.
  71.  
  72. In  this case,  too many BBSes  sending too many beacons  on the same frequency
  73. lead  to  the  decline  of local packet activity.    It would then seem prudent
  74. that potential BBS SYSOPS make a determination whether additional BBS  services
  75. are  required on channels already occupied by BBSes.  Factors influencing  this
  76. determination  would  include network policy if any, potential  user base, lack
  77. of  specialized  BBS services, and adequacy of BBS forwarding  channels.   With
  78. the  availability  of  multi-connect BBS software, one full-time dedicated  BBS
  79. in an area per frequency should be sufficient .
  80.  
  81.