home *** CD-ROM | disk | FTP | other *** search
/ SPACE 1 / SPACE - Library 1 - Volume 1.iso / misc~1 / 123 / stcitdoc.arc / NETWORK.DOC < prev    next >
Encoding:
Text File  |  1987-10-08  |  13.8 KB  |  340 lines

  1. NETWORK.DOC
  2.  
  3.     The networking portion of Citadel grew out of a utility for
  4. Citadel, no longer supported, called CTDLNET, which, in essence,
  5. provided the integration half of a true networking system -- the
  6. sysop had to provide the communications element, and then CTDLNET
  7. would take the resulting data and attempt to integrate with the
  8. Citadel's data base.
  9.  
  10.     Highly unsatisfactory. Not to mention time consuming, and there
  11. was no convenient way to network the mail, which was of some
  12. interest to network.
  13.  
  14.     So... about 85Jun01 or so work began on integrating CTDLNET with
  15. Citadel itself.  The following details how to use the networker from
  16. the sysop's viewpoint.
  17.  
  18.     Use of the networker from the user's viewpoint is detailed in
  19. NETWORK.HLP.
  20.  
  21.     The details of the protocols, etc. involved in this mess is in
  22. NETHACK.DOC.
  23.  
  24.  
  25. ---------------------------------------------------------------------
  26.  
  27.                 SUMMARY
  28.  
  29.  
  30.     Currently (as of 86May18), the networker is fairly limited, but
  31. has been designed to be easily expanded.  Be that as it may, the
  32. networker capabilities are currently limited to:
  33.  
  34.  o Users sending mail to users on other systems.
  35.  o Sysops requesting files (name or ambiguously) from other systems.
  36.  o Sysops sending files to other systems.
  37.  o Ability to specify that certain pieces of Mail be sent to All
  38.    Local Systems.
  39.  
  40.     In order for the sysop to maintain control of what's happening,
  41. the following capabilities, detailed in Usage below, are provided:
  42.  
  43.        o Ability to view the list of systems on the network list
  44.        o Adding systems to the network list
  45.  Menu 1    o Setting the credit ratings of users for long distance mail
  46.        o Ability to turn on and off network privileges for given users
  47.        o Ability to request a file or files from another system
  48.        o Ability to send files to another system.
  49.        o Editing systems on the network list to reflect their
  50.          changing characteristics
  51.            o Change a system's baud rate(s).
  52.     Menu 2       o Change a system's id.
  53.            o Change a system's passwords.
  54.            o Take a system off the network list.
  55.            o Change a system's name.
  56.            o Change a system's Local or Long Distance status.
  57.            o Change a system's receive-only status.
  58.            o Change the nets that a system uses.
  59.            o Set long-distance polling limits.
  60.  
  61.  
  62. ----------------------------------------------------------------------
  63.  
  64.                 USAGE
  65.  
  66.  
  67.    Access to the networking elements of Citadel are through
  68. (appropriately enough) the sysop menu (obtained through CTRL-L). 
  69. The network commands are divided into two menus, one subordinate to
  70. the other.  Menu 1 options are as follows:
  71.  
  72.   **** [A]dd node to net list
  73.    This is the option to add systems to the network list.  In order
  74. for the networker to handle systems on the network, the following
  75. information will be requested of the sysop:
  76.  
  77.  o System node name: this is usually the short, mnemonic name that
  78.    messages that originate from that system have in their headers. 
  79.    To take an example from HACK.DOC, if the node name of a system is
  80.    ODD-DATA, then messages from that system will have a header like
  81.    'from Cynbe ru Taren @ODD-DATA'.  It is NOT a requirement that
  82.    you use the same one as the system in question does -- but it
  83.    WILL lessen confusion on the part of the users.
  84.  
  85.  o System id: this MUST be accurate, and takes the same form as
  86.    #nodeId did in your CTDLCNFG.SYS file: i.e., <Country abbreviation>
  87.    <area code> <phone#>.  Feel free to insert special characters to
  88.    make things more readable, Citadel will (try) to strip out what
  89.    you put in. So, for instance, 'US (612) 431-1107' would probably be
  90.    acceptable.  But be sure it is as accurate as possible, because
  91.    Citadel uses this data to call other systems in the net.
  92.  
  93.  o A code indicating the range of baud rates supported by the system
  94.    in question.  At the moment, only 300, 300/1200, 300/1200/2400, and
  95.    300/1200/2400/9600 systems have codes defined for them, these
  96.    being 0 through 3. When you are asked to input the baud code for
  97.    a system, you will be reminded as to what the codes mean.
  98.  
  99.  o Local or Long Distance: An indication of whether the system is
  100.    Local or Long Distance relative to this system.
  101.  
  102.    After Citadel gets all of the above, the system you have listed
  103. is now on your network list.
  104.  
  105.  
  106.   **** [N]et privileges for individual
  107.    Each user of a particular Citadel installation has a switch,
  108. accessible only to the sysop, determining whether they are allowed
  109. to send mail, and anything else, out on the net. When using this
  110. option, the sysop will be requested to specify the name of an
  111. account and, if found, to confirm that net privileges should be
  112. toggled.
  113.     (New accounts are not given net privileges unless you set ALLNET
  114. in your CTDLCNFG.SYS.)
  115.  
  116.  
  117.   **** [C]redit setting
  118.    In case the network ever goes long distance, we certainly don't
  119. want a sysop to go bankrupt because some abuser sends a lot of long
  120. distance mail.  Thus, before a particular user can send mail (or
  121. whatever) long distance, s/he must first obtain networking
  122. privileges from the sysop of the system, and then entice the sysop
  123. into setting his/her credit rating to something greater than 0. 
  124. While I have no experience as to how this should be handled, I would
  125. suggest that the sysop establish that each message shall cost some x
  126. cents, and then make a no-exceptions rule that before someone's
  127. credit is set to a non-zero, the user pay in advance.  However, it's
  128. your system.
  129.    NOTE: if you have LONG-HAUL set to 0 in your CTDLCNFG.SYS file,
  130. then this section was a waste of your and my time.
  131.  
  132.  
  133.   **** [R]equest a file or files
  134.    This option allows the sysop to request a file from another system.
  135. In order for this option to succeed, the Sysop needs to know
  136.  a) What room the file is in on the other system (and the room, of
  137.     course, must be a directory room), and
  138.  b) The name of the file OR be willing to use an ambiguous file
  139.     request.
  140.  
  141.    On selection of <R>, Citadel asks for
  142.  1) the node name of the system that has the file,
  143.  2) the name of the room on that system,
  144.  3) the name of the file in that directory room's directory, either
  145.     an ambiguous or unambiguous file name,
  146.  4) what directory you want the file(s) put in,
  147.  5) if the name of the file requested if unambiguous, the name of
  148.     the file to save the file under (if the request is ambiguous,
  149.     then a warning is printed to the effect that files could be
  150.     overwritten).
  151.  
  152.     At any time, if you just type an empty return, the option is
  153. aborted, except during path specification, where a '?' will abort
  154. the request.
  155.  
  156.     If you answer all the questions satisfactorily, the system will
  157. proceed to write out a file named 'x.RFL', where 'x' indicates what
  158. system to call for the file, in your #netDir.
  159.  
  160.     During networking, the system will then try to get the indicated
  161. file(s) from the other Citadel.  A number of errors are possible,
  162. such as the indicated room not existing, or the file not existing,
  163. or even, perhaps, the transfer facility not being available on that
  164. system (this facility should reside on systems that are Net version
  165. 1.1 or higher).    If it succeeds, you should find your file(s) after
  166. networking at the location you specified.  On smaller systems, you
  167. may be forced to tell Citadel to overwrite a file (especially if you
  168. are requesting updates!), so, please, be careful using this function,
  169. and make sure you have backups!
  170.  
  171.  
  172.   **** [S]end files to another system
  173.     This option allows the sysop to send files to another system.
  174. When you select this option, Citadel will ask you what system you
  175. are sending the files to, then the name of the system.
  176.    
  177.     If you answer all the questions satisfactorily, the system will
  178. proceed to write out a file named 'x.SFL', where 'x' indicates what
  179. system to call for the file, in your #netDir.
  180.  
  181.     (The [S]end file command is what the #recieptDir is for -- all
  182. files sent to your system will be placed in this directory, as long
  183. as the directory doesn't contain more than RECEIPTK Kbytes of files.)
  184.  
  185.   
  186.   **** [V]iew net list
  187.     This option allows the sysop to view the list of systems on the
  188. network list.  This lists names, ids, and receive-only status,
  189. unlike the list that can be obtained from doing a '?' at the 
  190. 'destination system:' prompt during use of the <.en> command.
  191.  
  192.  
  193.   **** e[X]it to Main Citadel menu
  194.     Takes the sysop back to the main Citadel menu.
  195.  
  196.  
  197.   **** [E]dit a node
  198.     This option allows the sysop to edit a given system on the
  199. network list. The options are detailed below in Menu 2.
  200.  
  201.  
  202.  
  203.    Menu 2 (Net editing) options are as follows:
  204.  
  205.   **** [A]ccess setting
  206.     There may be times when you need to access a system via something
  207. other than the ordinary ID (something on a alternate l-d telephone
  208. system, for example?)  If there is an access string, citadel will
  209. use it as the phone number to call when networking.
  210.  
  211.  
  212.   **** [B]aud code change
  213.     When a system in the network changes baud rates, it is necessary
  214. to tell Citadel about it.  If you don't, at a minimum, nothing will
  215. happen (if your own system is 300 only); at a maximum, if your
  216. system is 1200/300 and THINKS that another system is 1200/300 when
  217. it is only 300, the systems will most likely be unable to
  218. communicate AT ALL.  Try to keep the list up-to-date, and, personally,
  219. I think it behooves all participants in the net to not keep
  220. changes secret -- perhaps some (efficient) way can be found to
  221. broadcast all changes.
  222.  
  223.  
  224.   **** [C]- set receive-only status
  225.     There are some systems that you probably don't EVER want to call,
  226. because they may be dummy systems for a UUCP feed or a long-distance
  227. system that wants to pay all of the networking costs.  If you set
  228. receive-only status, you will never call this system.
  229.  
  230.  
  231.   ****L[D] role reversal
  232.     This allows a system to role-reverse during long-distance networking.
  233. (Normally systems don't role-reverse, so people won't be surprised
  234. by noxiously high phone bills.)  If you are doing l-d networking
  235. with a receive-only system, BOTH systems must allow l-d role reversing.
  236.  
  237.  
  238.   **** [I]d change
  239.     It is, of course, highly important to keep the ids up-to-date 
  240. see the notes on Adding a system to the net for the reason), but,
  241. fortunately, most systems don't change ids very often.  Use this
  242. option if one does.
  243.  
  244.  
  245.   **** [K]ill node from net
  246.     Naturally, nodes will leave the net as sysops move, lose interest,
  247. etc. This option allows the sysop to take systems off the network list.
  248.  
  249.  
  250.   **** [L]ocal or Long Distance System
  251.     If systems or you move, your new location may not have the same
  252. Local status relative to the systems on the net.  If they change,
  253. use this option to change the Local status of the other systems.
  254.  
  255.  
  256.   **** [N]ame change
  257.     Certainly, systems are going to change their nodeId names as
  258. sysops change mood, locations, girlfriends, boyfriends, etc.  Use
  259. this option when that occurs.
  260.  
  261.  
  262.   **** [P]assword settings.
  263.     If you've got passwords defined, your system will exchange passwords
  264. with this system when you call it or it calls you during networking.
  265. If the passwords are incorrect, the systems will not do roomsharing
  266. and will not role-reverse.  (This option is only available in C-86 V2.17
  267. and above, and in STadel 3.1a and above.)
  268.  
  269.  
  270.   **** [R]ooms shared.
  271.     This lists the rooms you are sharing with this system.
  272.  
  273.  
  274.   *** [U]se nets
  275.     This lets you change the networks that this system is available on.
  276. The system will ask for what nets to put this system in, you reply
  277. with a comma-separated list of net numbers (1-32). [e.g. '1,2,5']
  278.  
  279. When you add a net, it is put into net 1 by default.
  280.  
  281.  
  282.   **** [V]iew node configuration
  283.     This shows the current configuration of this node.
  284.  
  285.  
  286.   ****e[X]it to Main net menu
  287.     Use this option to return to the main Network menu.
  288.  
  289.  
  290.   ****[Z] - set l-d poll count
  291.     To avoid excessive long-distance bills, STadel will only call a long-
  292. distance system once a night (not counting busy signals.)  If anything
  293. goes wrong during networking and the session shuts down, STadel will not
  294. call again until the next night.  If you don't want that behavior, you
  295. can change the poll count to allow more attempts.
  296.  
  297.  
  298.  
  299. --------------------------------------------------------------------
  300.  
  301.                 OPERATION
  302.  
  303.  
  304.    The networker operates on an automatic basis.
  305.  
  306.    You define when the network is active by putting #event lines
  307. into your CTDLCNFG.SYS like so:
  308.     #event NETWORK time duration <name> <netnumber>
  309.  
  310.    In the Twin cities, networking occurs at 3:00 am for 45 minutes,
  311. every day.  Pell uses the following #events for networking:
  312.  
  313.     #event NETWORK 3:01 39 c86net   1      * this is the ordinary citanet.
  314.     #event NETWORK 4:00 10 alternet 2      * a private network.
  315.  
  316.    What days does it do this?  Every day.
  317.  
  318.  
  319. --------------------------------------------------------------------
  320.  
  321.                 SPECIAL STUFF
  322.  
  323.  
  324.    It can be quite useful to specify that a given piece of Net Mail
  325. be sent to all systems that are Local to this system; for example,
  326. picnic announcements, update announcements, etc.  Citadel can do
  327. this in a limited sort of way.
  328.  
  329.    Usage: Use Net Mail as normal.  When the "System" prompt comes up,
  330. rather than answering with a system name, answer with "&L" (sans
  331. quotes, of course). This signals Citadel to send the following piece
  332. of Mail to all Local Systems, to the user specified.  While it seems
  333. obvious that the only logical user to send such Mail to would be
  334. "sysop", this option can be used to send Mail to all systems to
  335. anyone else.  During the next networking period, your installation
  336. will attempt to send this piece of Net Mail to each Local System.
  337.  
  338.    In order for a user to use this particular Network service, the
  339. user must possess both Net privileges AND Aide privileges.
  340.