home *** CD-ROM | disk | FTP | other *** search
/ Boldly Go Collection / version40.iso / TS / 05B / TN210.ZIP / NETWORK.EXE / NET-7.TXT < prev    next >
Encoding:
Text File  |  1992-07-02  |  7.9 KB  |  124 lines
  1.                                   NET-7.TXT
  2.                                NETWORK SERVERS
  3.                                ---------------
  4.  
  5. Continuing  the  packet  conservation theme, let's look at the big power users,
  6. the  servers.  Servers include  the automated computer  services  such as BBSes
  7. and  lately,  DXPacketClusters.   The common version of TCP/IP stations are not
  8. included in this category.   Even though automated, they normally don't "serve"
  9. the  general  packet  population.    This will undoubtedly change as the TCP/IP
  10. code matures and networks improve.
  11.  
  12. BBS  software  has  made  giant  strides since its introduction.  However scant
  13. attention  has  been  paid  to  ways of practicing packet conservation with its
  14. usage.    For instance, very few users are classified as "EXPERT" on their BBS.
  15. The  advantage  of  an  "Expert"  classification  is it does away with the long
  16. alphabet  soup  prompt and gets the short ">" instead.    Spread over time on a
  17. busy  channel, EXPERT prompts can make a  significant reduction  in unnecessary
  18. packets on the frequency.
  19.  
  20. Signing onto a  BBS  for the first time, some BBSes only require a  first name,
  21. while others  go  through a lengthy registration procedure.    Indeed, some BBS
  22. software  won't allow a new user to perform ANY commands until the registration
  23. process is complete.   Perhaps it's time to take another look at this to see if
  24. anything  other than a users  name is ***REALLY***  vital to the  BBS function.
  25. After all, the  shortening of an unnecessary registration process IS practicing
  26. packet conservation.
  27.  
  28. A major load on the network is BBS to BBS forwarding.   To the extent possible,
  29. packet  conservation  can be served if SysOps insure their forwarding paths are
  30. directed  to the nearest neighbor BBS.   Also, forwarding should be coordinated
  31. among  the  BBS  community  so as to avoid forwarding to  multiple BBSes in the
  32. same general area.  This will minimize sending duplicate traffic over a portion
  33. of the network.     Note here we are referring to the sending of duplicate data
  34. over the network, not duplicate messages to a BBS.
  35.  
  36. Users  should avoid the casual  "DXing" of BBSes.  Connecting to a distant BBS,
  37. going  through the registration process, downloading the HELP file to learn the
  38. commands,  then doing the magic  "LIST"  command are NO-NO's.    The  resulting
  39. freight-car  loads of  packets will usually  break the circuit, plus dump other
  40. users.     Since the  local BBS is part of the national BBS forwarding network,
  41. messages on the distant BBS are apt to be the same as found locally.  Of course
  42. there  may be times one has a good reason to check out a distant BBS.  But this
  43. should be done with consideration of the possible fury such action will unleash
  44. on the system.  Practice packet conservation on a DX BBS by doing a "LL 5", for
  45. the last five,  instead of a standard "L" command which could result in dumping
  46. 100 or more, message headers onto the network.   If unfamiliar with the distant
  47. BBS  commands,  attempt to find  the same  type of BBS closer and down-load the
  48. help file,  rather than  torturing the network.   To this end,  all BBS  SysOps
  49. could  aid packet conservation  by including  HELP  files for the different BBS
  50. types in one of their directories.
  51.  
  52. In terms of network  efficiency  it could be questioned whether the BBS/node is
  53. generally helpfull or not.  Although not as bad as the TCP/IP end user class of
  54. nodes (which don't perform anything usefull for the general packet population),
  55. the  BBS/nodes  add to network  overhead due to their node barf (broadcasts and
  56. updates).   If the BBS SysOp allows his node to propagate to the far end of the
  57. network, then  this encourages  distant users to DX his node, thus contributing
  58. to congestion.   Most SysOps are pleased to see users on their boards, but this
  59. type of operation can be counter-productive to the SysOp.   For instance if the
  60. SysOp uses the same portion of the network for forwarding that the distant user
  61. is  on,  then  the  resulting  congestion  could  cause  the forwarding  to  be
  62. terminated for that hour.    Multiplying  this type of activity with many users
  63. and many  BBSes, it's obvious  that allowing BBS/nodes  to propagate throughout
  64. the network should  be  discouraged.    Here we are referring to the  BBS/Node,
  65. rather than the gateway node portion.
  66.  
  67. KA9NNN recently released a series of notes on  G8BPQ  node operation and made a
  68. similar case for  BBS/nodes to either be  turned  off  or set  to not propagate
  69. outside the immediate area.    Along the same lines, some NodeOps have a policy
  70. of  not allowing  BBS/nodes to network  with backbone trunked LAN nodes as this
  71. can contribute significantly to local area congestion.
  72.  
  73. As the number of VHF frequencies increase,  SysOps tend to add additional ports
  74. and radios to accomadate users.  Such expansion should be carefully considered.
  75. Throughput on adjacent channels can suffer due to receiver overload and desense
  76. occuring  when transmitters in the same band are keyed up.    This may not be a
  77. serious  problem on lightly loaded channels, but  with heavy activity, it could
  78. cause an adverse network impact.   Another caution  is that  routing  confusion
  79. may occur  when  multiple gateways exist within a small area.    There  may  be
  80. practical and  political reasons why certain channels  should not be gatewayed.
  81. ALWAYS  consult local  network  policy   before  proceeding  with  establishing
  82. gateways or any new node.
  83.  
  84. DXclusters  have  recently  become  very  popular in many parts of the country.
  85. These  operate  from a  PC based  machine and are designed to service the DXing
  86. community.    Connected  stations  can report the frequency and other pertinent
  87. information  of a DX station  they hear on HF to the cluster.  This information
  88. then goes out as a  "spot"  announcement to all other stations connected to the
  89. cluster.    The  idea  here is that the more "ears" monitoring for DX, the more
  90. successful the connected  stations will be in working the DX, if it's needed by
  91. the members.
  92.  
  93. Packet clusters  also provide  a variety of user services.   Members can obtain
  94. beam headings  to any specific DX country in the world, request WWV propagation
  95. information,  download  data bases  of DX related material,  send  and  receive
  96. messages  similar  to a  BBS, and talk, either privately or publically to other
  97. connected stations.
  98.  
  99. To  extend  their HF observer  monitoring  capability it is common practice for
  100. clusters  to link  to each other via the VHF networks.   This allows all of the
  101. features  of one cluster  to be shared with other linked clusters.   To prevent
  102. connected  stations  from being  timed out  by the network  nodes,  short "stay
  103. alive" messages  are periodically  sent in order  to  keep  each connected user
  104. from being disconnected.
  105.  
  106. Peak  cluster usage  occurs in the evenings and weekends when most of the users
  107. are home  from work.   Network  congestion  from cluster  activity can be quite
  108. intense during these periods.  Every time a cluster links to a distant cluster,
  109. configuration  and  user  info is  shared between  all of  the  clusters in the
  110. linked  system.     A large linked cluster network  can consist  of 10 or  more
  111. clusters  and  over  100  users.     Whenever  a  cluster  link  is lost,  then
  112. reestablished,  a  complete  updating  sequence  is performed over the network.
  113. When this occurs,the network impact can be quite substantial.
  114.  
  115. Because  of intense DXcluster congestion,  cluster SysOps  in some parts of the
  116. country  have  been requested  to either curtail their cluster linking activity
  117. or have been encouraged to establish their own separate cluster network.
  118.  
  119. Although  separate networks  may be one  solution,  perhaps a more satisfactory
  120. and  economical  approach  would be  for NodeOps,  TCP/IP ops,  BBS and cluster
  121. SysOps  to  coordinate their  activites  and work together toward developing an
  122. integrated network capable of handling all of the users and servers.
  123.  
  124.