home *** CD-ROM | disk | FTP | other *** search
/ ftp.wwiv.com / ftp.wwiv.com.zip / ftp.wwiv.com / pub / WW4SHARE / WW4NTECH.ZIP / WW4NTECH.DOC < prev   
Text File  |  1994-09-04  |  93KB  |  2,644 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7.  
  8.  
  9.  
  10.  
  11.  
  12.  
  13.               WWIVnet Technical Documentation
  14.  
  15.  
  16.                        version 2.0.34
  17.  
  18.  
  19.  
  20.  
  21.  
  22.  
  23.  
  24.  
  25.                              by
  26.  
  27.  
  28.  
  29.                        Wayne Heyward
  30.                   aka Midnight Tree Bandit
  31.  
  32.  
  33.  
  34.  
  35.  
  36.  
  37.  
  38.  
  39.                      (c) Copyright 1995
  40.                          Wayne Bell
  41.                    WWIV Software Services
  42.                       P.O. Box 720455
  43.                      McAllen, Tx 78504
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.                      Table of Contents
  51.  
  52.  
  53.  
  54.     I.  INTRODUCTION.................................  1
  55.  
  56.    II.  GENERAL OVERVIEW OF WWIV NETWORKING..........  4
  57.  
  58.   III.  MAKING CONNECTIONS...........................  6
  59.  
  60.    IV.  MESSAGE PACKETS.............................. 12
  61.  
  62.     V.  BBSLIST/CONNECT FILES AND MESSAGE ROUTING.... 28
  63.  
  64.    VI.  TIPS FOR WRITING WWIVNET SOFTWARE............ 37
  65.  
  66.         APPENDIX A................................... 41
  67.  
  68.  
  69.  
  70.  
  71.  
  72.  
  73.  
  74.  
  75.  
  76.  
  77.  
  78.  
  79.  
  80.  
  81.  
  82.  
  83.  
  84.  
  85.  
  86.  
  87.  
  88.  
  89.  
  90.  
  91.  
  92.  
  93.  
  94.  
  95.  
  96.  
  97.                             -i-
  98.  
  99.  
  100.  
  101. I.   INTRODUCTION
  102.  
  103.  A.   History
  104.  
  105.   Back in 1989, Wayne Bell released the first technical
  106.   documenta tion covering the technical workings of the
  107.   WWIV networking software.  While much of the information
  108.   in that document is still relevant now, much has changed
  109.   since 1989.  The Group structure has been added, support
  110.   for more message types, and support for preprocessors to
  111.   the packet tossers has been added.
  112.  
  113.   So in late 1992 or early 1993 Wayne asked for volunteers
  114.   to rewrite the WWIVnet Technical documentation.  No one
  115.   spoke up. Then in March I started providing WWIV support
  116.   on the GEnie information service, and some people started
  117.   asking about getting technical information so they could
  118.   get their non-WWIV boards to communicate with WWIV
  119.   networks.  Looking around, I found the original doc, and
  120.   asked Wayne if anyone had answered his call.  As it
  121.   turned out, I became the volunteer.  After much
  122.   procrastination and "How's the doc coming?" from Wayne,
  123.   here it is.
  124.  
  125.  B.   Purpose, Limitations, and Other Info
  126.  
  127.   The purpose for this document is to explain the WWIVnet
  128.   interface for those who wish to write software which
  129.   communicates with WWIVnet systems, either independently
  130.   or as an extra utility for the existing NETxx software.
  131.  
  132.   The documentation that you are reading now is more an
  133.   expansion and clarification of the original docs than it
  134.   is a total rewrite.  It looks a little neater too, thanks
  135.   to Word Perfect. Now that the bulk of the work is done,
  136.   the plan is to update them with each release of NETxx to
  137.   reflect new features.  The information in this document
  138.   is current with WWIVnet version 34 (NET34).
  139.  
  140.   First clarification: in the context of this document, the
  141.   term "WWIVnet" refers to the software for interfacing
  142.   WWIV-type networks and any network which uses that
  143.   software.  Though WWIVnet is also the name of the
  144.   original and largest of the dozens of WWIV networks out
  145.   there, the use of the term here is not meant to imply
  146.   that this document is specific to that network.
  147.  
  148.   This documentation assumes that the reader at least: a)
  149.  
  150.                             -1-
  151.  
  152.  
  153.  
  154.   has a good working knowledge of C and the various C data
  155.   types and data structures. b)   has a general familiarity
  156.   of how file transfer protocols work.
  157.  
  158.   Due to the proprietary nature of Wayne Bell's WWIVnet
  159.   software, we will not cover the inner workings of the
  160.   current networking programs distributed in NETxx.ZIP.  We
  161.   will only discuss the external requirements for any third
  162.   party interfaces that may be written for connecting
  163.   non-WWIV systems to WWIV networks. Likewise, we will not
  164.   discuss the NETUP software, which generates and sends out
  165.   the network node lists and connect lists.  You'll just
  166.   have to figure that out for yourself.
  167.  
  168.   This document is not a replacement for Filo's WWIVnet
  169.   Software Documentation.  This doc does not describe how
  170.   to use the network software, only how it works.  For
  171.   instructions on using the NETxx software and familiarize
  172.   yourself with how to use it, see Filo's documentation,
  173.   which can be found in the current NETxx release.
  174.  
  175.   A note on the numbering for this document.  This is
  176.   version 2.0.34.  The first number indicates that this is
  177.   a major rewrite from the original by Wayne Bell.  Unless
  178.   a major overhaul is done, this is not likely to change.
  179.   The 0 in the second part indicates that this is the first
  180.   version of this document.  If there are any major changes
  181.   or additions made, this will be incremented.  The 34
  182.   indicates that this information is current as of version
  183.   34 of the WWIVnet software (NET34).  Minor changes
  184.   reflecting small interface changes in the WWIVnet
  185.   software will cause this number to be changed.  This
  186.   number will not always be the same as the latest version
  187.   of the WWIVnet software; if there are no changes in the
  188.   external interface, this document will not be updated.
  189.  
  190.   I welcome comments about this document -- suggestions for
  191.   additional information to include, things that could be
  192.   explained more fully, and so forth.  I can be reached at
  193.   the following addresses:
  194.     WWIVnet: #2@8408
  195.    WWIVLink: #1@18411
  196.      IceNET: #1@8411
  197.       GEnie: TREE.BANDIT
  198.    Internet: tree.bandit@genie.geis.com
  199.  
  200.  C.   Relevant Copyrights and Acknowledgements
  201.  
  202.  
  203.                             -2-
  204.  
  205.  
  206.  
  207.   This document is Copyright 1994 by Wayne Heyward (aka
  208.   Midnight Tree Bandit) and WWIV Software Services (WSS).
  209.   It may be freely distributed provided it is not altered
  210.   in any way.  This is copyrighted to prevent unauthorized
  211.   (and possibly inaccurate) changes from being made to this
  212.   document by anyone other than myself or any other
  213.   appointed by WWIV Software Services (should I be unable
  214.   to continue updating this document).
  215.  
  216.   WWIV BBS and the WWIVnet software (distributed as NETxx)
  217.   are Copyright 1986-1994 by Wayne Bell and WSS.
  218.  
  219.   NETEDIT is Copyright 1994 by Black Dragon Enterprises.
  220.  
  221.   DSZ is Copyright 1994 by Omen Technology INC.
  222.  
  223.   HSLink is Copyright 1994 by Samuel H. Smith.
  224.  
  225.   The PKWare Compression Libraries are copyright 1993 by
  226.   PKWARE, Inc.
  227.  
  228.   The WWIVnet interface information and code in this
  229.   document is placed in the public domain, and may be
  230.   freely used for the purpose of interfacing with WWIV
  231.   networks and network software.
  232.  
  233.   I would like to thank Wayne Bell, not only for creating a
  234.   top- notch BBS program that is both powerful and easy to
  235.   use, but creating a networking scheme that is more
  236.   painless to set up and operate than any other out there.
  237.   He has said often that if he knew then what he does now,
  238.   things would have been different.  I cannot help thinking
  239.   that the result would have been less elegant or easy to
  240.   use.
  241.  
  242.   I would also like to thank Wayne for his patience over
  243.   the last year and a half, waiting for me to get this
  244.   document started. I've fired thousands of questions at
  245.   him the last few weeks in an effort to make this
  246.   documentation as complete as possible, and he answered
  247.   every one.
  248.  
  249.   And finally thanks to Filo, who also provided vital
  250.   information and advice without which this documentation
  251.   would be incomplete.
  252.  
  253.  
  254.  
  255.  
  256.  
  257.                             -3-
  258.  
  259.  
  260.  
  261. II.  GENERAL OVERVIEW OF WWIV NETWORKING
  262.  
  263.  A WWIV network is basically a loose confederation of WWIV
  264.  BBS systems that use the WWIVnet (or compatible) software.
  265.  
  266.  
  267.  
  268.  The software does not limit the connection structure, so
  269.  the member sysops can connect to anyone they wish (subject
  270.  to the rules of their network).  For ease of
  271.  administration, the network may be split up into Groups,
  272.  each with their own coordinator.  Node numbers are an
  273.  unsigned short int, so that nodes may be assigned a value
  274.  from 1 to 65535.
  275.  
  276.  The lists of nodes are distributed in two sets of files:
  277.  BBSLIST.xxx and CONNECT.xxx.  There are two different ways
  278.  of handling these files.  The old way has just one
  279.  BBSLIST.NET and one CONNECT.NET file. The CONNECT.NET file
  280.  assigns costs to each connection for each system. Some
  281.  smaller networks still use this setup.  The new way,
  282.  implemented in 1990, uses several BBSLIST and CONNECT
  283.  files with extensions indicating group number (e.g. Group
  284.  1's files would be BBSLIST.1 and CONNECT.1).  BBSLIST.0
  285.  contains a list of Group numbers, and CONNECT.0 contains
  286.  inter-Group connections.  It is important that any
  287.  non-WWIV systems be able to support both setups if they
  288.  wish to connect to a WWIV network.
  289.  
  290.  Like all BBS networks, the primary purpose is to exchange
  291.  private mail and public posts between BBSes.  The passing
  292.  of files in binary form, however, is not supported by the
  293.  WWIVnet software, though there are some third party
  294.  programs such as Tolkien's PACKSCAN which can handle
  295.  files.  All messages also have a maximum size limit of
  296.  32k.
  297.  
  298.  The basic WWIVnet software distributed in NETxx.ZIP by WSS
  299.  consists of four programs: NETWORK.EXE, NETWORK1.EXE,
  300.  NETWORK2.EXE and NETWORK3.EXE.  Any alternative software
  301.  for interfacing with WWIV should follow the same
  302.  structure.
  303.  
  304.  NETWORK.EXE handles connections between systems.  On the
  305.  sending end of the connection, NETWORK.EXE calls out to
  306.  another system, chosen from the CALLOUT.NET file on that
  307.  system.  The answering system activates NETWORK.EXE when
  308.  it detects a network call.  Once they're talking, they
  309.  
  310.                             -4-
  311.  
  312.  
  313.  
  314.  make any mail packet transfers needed.
  315.  
  316.  NETWORK1.EXE is the first of the two mail tossers.  This
  317.  one takes the incoming packet received by NETWORK.EXE and
  318.  distributed the messages within to their rightful places.
  319.  Local mail goes into LOCAL.NET, while mail passing through
  320.  to other systems is tossed into packet files for the next
  321.  hop.
  322.  
  323.  NETWORK2.EXE tosses the local messages in LOCAL.NET.  Most
  324.  are messages for email or local subboards, but there are
  325.  also network updates, sub REQuests, software "pings," and
  326.  other special purpose message types.  It also has the
  327.  ability to call on third-party preprocessors for special
  328.  handling of certain types of messages.
  329.  
  330.  NETWORK3.EXE processes all the network updates that come
  331.  in.  This helps determine what routing off-system mail
  332.  will take.
  333.  
  334.  Each WWIV network also has its own special encoding and
  335.  decoding programs for handling of updates and network mail
  336.  from the Network Coordinator and Group Coordinators.
  337.  These are the DEmmm.EXE files (mmm corresponding to the
  338.  message type).  The DEmmm.EXE cannot be replaced, so any
  339.  NETWORK2.EXE replacement must be able to recognize the
  340.  need for calling the appropriate DEmmm.EXE, as described
  341.  below.
  342.  
  343.  
  344.  
  345.  
  346.  
  347.  
  348.  
  349.  
  350.  
  351.  
  352.  
  353.  
  354.  
  355.  
  356.  
  357.  
  358.  
  359.  
  360.  
  361.  
  362.  
  363.                             -5-
  364.  
  365.  
  366.  
  367. III. MAKING CONNECTIONS
  368.  
  369.  A.   Establishing Contact
  370.  
  371.   Through some process, one system decides to call another.
  372.   Various techniques can be used for deciding when and who
  373.   to call; that should have no effect on the network.  Any
  374.   WWIVnet system should be able to receive a network
  375.   connection at any time (i.e., there is no network mail
  376.   hour).  For an example of a method for limiting call out
  377.   times, see the WWIVnet Software Docs.
  378.  
  379.   However the decision is made, a call is made to another
  380.   WWIVnet system.  If he connects, the connection protocol
  381.   is then begun.
  382.  
  383.   After connection, the caller waits for the string "NN:".
  384.   To get to this prompt, the caller sends the string "N "
  385.   ('N', space), every half second.  Every 7 seconds, the
  386.   caller sends a carriage return (char 13 decimal).  The
  387.   reason for sending "N " is twofold:  1) the N is to
  388.   answer any yes/no question that may occur on connection;
  389.   and 2) the space is to abort any message printed out to
  390.   callers, if the BBS allows it.  After 16.5 seconds, the
  391.   caller gives up and assumes he is at the NN: prompt.
  392.  
  393.   Since this sequence is designed specifically with WWIV
  394.   systems in mind, any BBS or front end program receiving a
  395.   call from a WWIVnet system must be at its login prompt,
  396.   or have already started the network response program
  397.   (such as NETWORK.EXE), by 16.5 seconds after the modem
  398.   connection is estabilshed.  Whether or not it can respond
  399.   to the "N " sequence does not matter as long as it is
  400.   prepared for the next step.  Likewise, any network
  401.   program calling a WWIVnet system must follow the above
  402.   sequence to ensure a proper connection.
  403.  
  404.   After the NN: prompt is reached, the caller sends the
  405.   string "\030!-@NETWORK@-!\r" (Ctrl-x, "!-@NETWORK@-!",
  406.   return), to identify that this is the network calling.
  407.   The caller then waits for the net identification string.
  408.   The "!-@NETWORK@-!" string is sent every 6 seconds.
  409.   After 20 seconds without receiving the network
  410.   identification string, the caller gives up and hangs up.
  411.  
  412.   The network identification string is sent by the
  413.   answering system after getting the "!-@NETWORK@-!"
  414.   string.  The network ident string is sent every 6
  415.  
  416.                             -6-
  417.  
  418.  
  419.  
  420.   seconds, until the network response is received.  The
  421.   answering system gives up and hangs up after 20 seconds.
  422.  
  423.   The network ident string is:
  424.  
  425.        \x1b[8mxX33211\x0c31412718\x1b[8DNETWORK!
  426.  (i.e.,
  427.  ESC "[8mxX33211" Ctrl-L "31412718" ESC "[8DNETWORK!")
  428.  
  429.   The network response string from the calling system is:
  430.  
  431.        \x1b[8mxyzzy$.@83\x0c##
  432.   (i.e. ESC "[8mxyxxy$.@83" Ctrl-L "##")
  433.  
  434.   After getting the network identification string, the
  435.   caller sends the network response string every 6 seconds.
  436.   If, after 20 seconds, the answering system does not
  437.   receive a Ctrl-B ('\002\'), the calling system gives up
  438.   the attempt and hangs up. If the Ctrl-B is received, the
  439.   caller considers the connection established.
  440.  
  441.   After getting the network response string, the answering
  442.   system sends three Ctrl-B characters ("\002\002\002"),
  443.   and considers the two systems connected.
  444.           
  445.  B.   Data Exchange
  446.  
  447.   After the two systems are connected, the caller sends an
  448.   identification block to the answering system.  The block
  449.   is 128 bytes long, and is sent in the same method as an
  450.   xmodem block of data is sent, complete with CRC.  The
  451.   caller does not wait for a NAK before beginning
  452.   transmission, but begins transmission of the block
  453.   immediately after receiving one Ctrl-B.  The block is
  454.   sent as block #0, with CRC and 128 bytes of data.  After
  455.   receiving the block, the answering system sends the usual
  456.   ACK/NAK, etc.  If after 6 tries the block is not received
  457.   correctly, both sides give up and disconnect.
  458.  
  459.   The block of data contains from seven to nine pieces of
  460.   data, each separated by a space character (char 32
  461.   decimal).  All bytes after the last piece of data have a
  462.   value of zero.  The pieces of data are:
  463.  
  464.   system number  Net node number of the sender.
  465.  
  466.   sendback
  467.  
  468.  
  469.                             -7-
  470.  
  471.  
  472.  
  473.     Whether the answering system may send a net file back
  474.     to the sender ("0" for no, or "1" for yes).  The caller
  475.     will ignore this field when the answering system sends
  476.     its ident block.  In other words, the only system that
  477.     determines whether sendback is allowed is the system
  478.     making the call.
  479.  
  480.   cost
  481.  
  482.    The cost for the call, in cents per minute, as defined
  483.    in CONNECT.NET under the old WWIVnet setup.  If
  484.    the network is using the Group setup, this
  485.    value will be zero ("0").
  486.  
  487.   features
  488.  
  489.    A long integer, sent as a literal, specifying the
  490.    features supported by that system.  Right now, five
  491.    values are possible, affecting mainly the protocol used
  492.    in transfer.  It is read as a bitmap ('fea
  493.    tures&[value]'), with the bits having the following
  494.    effects:
  495.    1 -- Zmodem available (DSZ or Visual Zmodem);
  496.    2 -- numk and netver found after password (see below);
  497.    4 -- HSLink (bidirectional protocol) available.
  498.    Current versions of the WWIVnet software start with the
  499.    2 bit set, then sets the 1 and 4 bits as  appropriate.
  500.    If neither Zmodem nor HSLink are available, transfer
  501.    defaults to internal Ymodem.
  502.  
  503.   tosendlen
  504.  
  505.    The number of bytes in the mail file that is to be
  506.    transferred, sent as literal.
  507.  
  508.   password
  509.  
  510.    The password to be used between the two systems.  If no
  511.    password has been set yet, this is set to "NONE". Usual
  512.    passwords are 15 characters long.
  513.  
  514.   numk
  515.  
  516.    Number of KB the sender is able to take, sent as a
  517.    literal.  This is calculated as free space on the data
  518.    drive divided by three.  This field will only be
  519.    present if features&2 is set.
  520.  
  521.  
  522.                             -8-
  523.  
  524.  
  525.  
  526.   net_ver
  527.  
  528.    Version of the network software, such as "34" for
  529.    NET34.  Third-party calling programs must send the
  530.    version of WWIVnet software it is compatible with.
  531.    This field will only be present if features&2 is set.
  532.  
  533.   net_name
  534.  
  535.    Name of the network the call is for.  This is used  by
  536.    the receiver to determine which data directory the
  537.    network files go into.  This is not a required field,
  538.    but to be safe it should always be included.  One case
  539.    in which it would be necessary is if a BBS is connect
  540.    ing two nodes with the same node number on different
  541.    WWIV networks (i.e., one is @3050.IceNET and the other
  542.    is @3050.WWIVnet).
  543.  
  544.   See below for examples of identification blocks sent
  545.   between systems.  To assure that the identification block
  546.   is compatible with that generated by NETWORK.EXE in
  547.   NET34, here is how it's generated and sent out by
  548.   NETWORK.EXE:
  549.  
  550.     for (i=0; i<128; i++)
  551.       b[i]=0;
  552.      /* 'b' is the net ident string */
  553.     itoa(net_sysnum,b,10);
  554.      /* net_sysnum = system's node number */
  555.     strcat(b," ");
  556.     itoa(sendback,s,10);
  557.     strcat(b,s);
  558.     strcat(b," ");
  559.     itoa((int) (cost*100.0),s,10);
  560.     strcat(b,s);
  561.     strcat(b," ");
  562.     ltoa(features,s,10);
  563.     strcat(b,s);
  564.     strcat(b," ");
  565.     ltoa(tosendlen,s,10);
  566.     strcat(b,s);
  567.     strcat(b," ");
  568.     if (password[0])
  569.       strcat(b,password);
  570.     else
  571.       strcat(b,"NONE");
  572.     if (features & 2) {
  573.       /* 'net_data' is network data dir, FREE_FACT = 3 */
  574.  
  575.                             -9-
  576.  
  577.  
  578.  
  579.       ltoa((long) (freek1(net_data) / FREE_FACT), s, 10);
  580.       strcat(b," ");
  581.       strcat(b,s);
  582.       strcat(b," ");
  583.       itoa(NET_VER,s,10);
  584.       strcat(b,s);
  585.     }
  586.     strcat(b," ");
  587.     strcat(b,net_name);
  588.  
  589.   After the caller sends the block of data to the answering
  590.   system, the answering system checks the password with the
  591.   password expected from that system.  If the password is
  592.   wrong, or calls from that system are not allowed, the
  593.   answering system discon nects.  Information on passwords
  594.   and allowable systems should be in a separate data file,
  595.   such as the CALLOUT.NET
  596.  
  597.   If the password is OK, the answering system then sends a
  598.   similar block of data back to the caller, giving its
  599.   system number, features, and bytes to send.  Also, if no
  600.   password had been set yet (the password received from the
  601.   caller is "NONE"), then the answering system randomly
  602.   picks a password and puts it in the password field.
  603.  
  604.   After both systems have sent and received the data
  605.   blocks, transfers begin.  If the caller has any data to
  606.   send, it is sent first.  If the answering has any data to
  607.   send, it is sent second if the sendback flag is set on.
  608.   It should be noted at this point that since Ymodem is the
  609.   default protocol in the absence of Zmodem or HSLink, it
  610.   must be supported internally in the WWIVnet calling
  611.   program, or at least be able to run it externally.
  612.  
  613.   The Ymodem used by the WWIVnet software (NETxx) is not
  614.   quite the true Ymodem defined by Forsberg.  There is a
  615.   block #0 which contains the filename, timestamp, and size
  616.   (in bytes), followed by the file itself, ending with an
  617.   EOT block.  There is no "end of batch" block, however.
  618.  
  619.   If the caller has no data to send, the answering system
  620.   immedi ately begins sending data (again, if sendback is
  621.   set on).  If neither has any data to send, the transfer
  622.   protocol is not started.  Once a netmail file is
  623.   completely sent, it is erased on the sending system. If
  624.   the file is not completely sent (due to excessive errors
  625.   or carrier loss), the file is not deleted, so that
  626.   another attempt can be made on a later call.
  627.  
  628.                             -10-
  629.  
  630.  
  631.  
  632.   Of course, if HSLink is enabled (both ends can use it),
  633.   both netmail files are sent at the same time, if there
  634.   are two.  If only one of the connected systems has a
  635.   netmail file, HSLink is still used.
  636.  
  637.   After transfers (if any) are done, both systems wait
  638.   0.5-1.0 second, then hang up.  The transfer of files is
  639.   then done.
  640.           
  641.  C.   Identification Block Examples
  642.  
  643.   1.   System 1 calls system 2 on WWIVnet.  System 1 has
  644.   100KB to send to system 2, supports Zmodem and can accept
  645.   400KB. System 2 has 200KB to send to system 1, does not
  646.   support Zmodem, and can accept 1200KB.  The call costs
  647.   $0.10/min (old CONNECT.NET being used).  No password has
  648.   been set yet on system 1, sendback is allowed, and NET34
  649.   is in use on both ends.
  650.  
  651.   System #1 sends:
  652.  
  653.        1 1 10 3 102400 NONE 409600 34 WWIVnet
  654.  
  655.   System #2 sends:
  656.  
  657.        2 1 10 2 204800 ARANDOMPASSWORD 1228800 34 WWIVnet
  658.  
  659.   Since Zmodem is not supported by both systems, Xmodem-1k
  660.   is used to transfer the mail.
  661.  
  662.   2.   System 10 calls system 20 in IceNET.  System 10 has
  663.   56KB to send, can accept 3485KB, and uses NET32.  System
  664.   20 has 678KB to send, can accept 10MB, and is a PCBoard
  665.   system using software compatible with NET34.  Both
  666.   support Zmodem and the selected password is
  667.   "PASSWORDPASSWOR".  Sendback is not enabled.
  668.  
  669.   System #10 sends:
  670.  
  671.        10 0 0 3 57344 PASSWORDPASSWOR 3568640 32 IceNET
  672.  
  673.   System #20 sends:
  674.  
  675.        20 0 0 3 0 PASSWORDPASSWOR 10240000 34 IceNET
  676.  
  677.   Since sendback is not allowed (the caller decides this),
  678.   system 20 won't send any data to system 10, hence the
  679.   number of bytes to send is zero.  Zmodem will be used
  680.  
  681.                             -11-
  682.  
  683.  
  684.  
  685.   since both ends support it.
  686.  
  687.   3.   System 100 calls system 200 on MTBnet.  System 10
  688.   has 125KB to send, and can accept 300KB.  System 200 has
  689.   350KB to send and can accept 500KB.  Both have HSLink
  690.   available, use NET34, and  use the password
  691.   "OURPASSWORD1234".  Sendback is enabled.
  692.  
  693.   System #100 sends:
  694.  
  695.        100 1 0 6 128000 OURPASSWORD1234 307200 34 MTBnet
  696.  
  697.   System #200 sends:
  698.  
  699.        200 1 0 6 358400 OURPASSWORD1234 512000 34 MTBnet
  700.  
  701.   Since system 100 cannot accept the 350KB system 200 has
  702.   for it, only the 125KB from system 1 is sent.  HSLink is
  703.   used for the transfer since both systems support it,
  704.   though only one system is sending a file.
  705.                
  706. IV.  MESSAGE PACKETS
  707.  
  708.  The most important component of any network is the mail
  709.  file, which contains all the public posts, email, and
  710.  network information which makes the BBS network what it
  711.  is.  WWIVnet mail files consist of a series of mail
  712.  packets, each with its own header segment describing the
  713.  type and size of the packet.
  714.  
  715.  There are two types of mail files in WWIVnet, each similar
  716.  but processed differently.  The netmail file is the file
  717.  received from another system, and contains packets
  718.  destined for that system as well as other systems in the
  719.  network (if the BBS has more than one connect).  Netmail
  720.  files may be compressed, using the PKWare compres sion
  721.  libraries.  The local mail file contains the packets from
  722.  the netmail file which are destined for the BBS only.
  723.  
  724.  A.   Message Header
  725.  
  726.   Each message sent through the network has a header.  The
  727.   header tells which user/system originated the message,
  728.   where it is to be sent to, the type of message, and other
  729.   information.  The structure of the header is:
  730.  
  731.   typedef struct {
  732.        unsigned short tosys,
  733.  
  734.                             -12-
  735.  
  736.  
  737.                       touser,
  738.                       fromsys,
  739.                       fromuser;
  740.        unsigned short main_type,
  741.                       minor_type;
  742.        unsigned short list_len;
  743.        unsigned long  daten;
  744.        unsigned long  length;
  745.        unsigned short method;
  746.   } net_header_rec;
  747.  
  748.   Each header is 24 bytes long.  The fields, in detail,
  749.   are:
  750.  
  751.   tosys, touser
  752.  
  753.    The destination of this message (system number and user
  754.    number, if applicable).  The touser field will be zero in
  755.    all cases except for email (main_type==2) and SSMs
  756.    (main_type==15).
  757.  
  758.   fromsys, fromuser
  759.  
  760.    The origin of the message (system number and user number).
  761.    This contains the user number/system number combination of
  762.    who actually wrote the message.
  763.  
  764.   main_type, minor_type
  765.  
  766.    The type of message this is.  The main type stores the
  767.    actual type (email, post), and the minor_type is used to
  768.    specify what sub-type it is.  For example, the main_type for
  769.    a post is 3.  The minor_type is then used to specify what
  770.    type of post it is, what subboard the post is to go on to.
  771.    A list of main and minor types is found in section IV(D),
  772.    below.
  773.  
  774.   daten
  775.  
  776.    The time the message was sent, stored in unix time, as the
  777.    number of seconds since Jan 1, 1970.
  778.  
  779.   length
  780.  
  781.    The length of the message.  This includes any information
  782.    between the packet header and the message itself, such as
  783.    the sender's name, message title, and so forth.  Note that
  784.    the length does not include the node list indicated by
  785.    list_len.
  786.  
  787.                             -13-
  788.  
  789.  
  790.  
  791.   method
  792.  
  793.    If the file is encrypted, compressed, or source-verified,
  794.    this describes the type of compression or encryption used.
  795.    This will tell NETWORK2 (or other local mail tosser) which
  796.    DEmmm.EXE to execute.  DEmmm.EXE is explained in more detail
  797.    in the next section, below.
  798.  
  799.   list_len
  800.  
  801.    Some messages need to go to more than one system.  For
  802.    example, networked posts may go to over 20 different
  803.    systems.  It makes no sense to have a separate copy of
  804.    the message for each destination system, so the same
  805.    copy of the header and message is used.  (This is
  806.    referred to as "stacking" the message).  The list_len
  807.    specifies the number of destination systems listed.  If
  808.    list_len is non-zero, then the touser and tosys fields
  809.    are ignored.  The list_len is not used for e-mail to a
  810.    user (main_type is 2 or 7).
  811.  
  812.    When a message has only one destination system, the
  813.    destina tion system is stored in tosys, and list_len is
  814.    zero.  If there are two or more destinations, then tosys
  815.    is 0, and list_len holds the number of destination
  816.    systems.
  817.  
  818.    When list_len is non-zero, the list of destination
  819.    systems is stored immediately after the header, but
  820.    before the actual message itself.  The length of the
  821.    list is not included in the length field in the header;
  822.    the length stored in the header is the length of the
  823.    message only.
  824.  
  825.    Each entry in the destination system list is two bytes
  826.    long, and is stored in the standard byte-reversed format
  827.    of 80x86 chips.
  828.  
  829.    For example, if a post is destined to system 1, the
  830.    tosys field will be 1, and list_len will be 0.  If the
  831.    post is destined to systems 1 and 2, tosys will be 0,
  832.    list_len will be 2, and there will be 4 bytes between
  833.    the header and message.  The bytes will be: 01 00 02 00
  834.    (remember, byte-reversed format).  The rest of the
  835.    header will be the same for both messages.
  836.  
  837.   A packet thus consists of a net header, a destination
  838.   list (if any), and the text of the message.  The length
  839.  
  840.                             -14-
  841.  
  842.  
  843.  
  844.   of a full message packet is thus: 24 + 2*list_len +
  845.   msg_length.
  846.  
  847.   The message text (the part following the header) for a
  848.   post or email begins with information intended for the
  849.   message header shown when the message is displayed.  Each
  850.   piece of information is followed by a carriage return and
  851.   line feed (cr/lf) character to separate it from the next
  852.   except for the message title, which is followed by a NUL
  853.   character.  For most posts and email, that information
  854.   is:
  855.  
  856.   Message Title
  857.  
  858.     Whatever title the user gave to the post.
  859.  
  860.   Sender name
  861.  
  862.     usually the name and number of the user who wrote
  863.     the message with the system number, in whatever
  864.     format the sending BBS uses.
  865.  
  866.   Date string
  867.  
  868.    Formatted date the post was written, in whatever
  869.    format the BBS uses.
  870.  
  871.   So the message header format for most posts and email
  872.   would be
  873.   TITLE<nul>SENDER_NAME<cr/lf>DATE_STRING<cr/lf>MESSAGE_TEXT.
  874.   Some main_types have other information, as noted in the
  875.   main_type descriptions in section IV(D).
  876.  
  877.  B.  Mail File Processing
  878.  
  879.   A WWIVnet file is simply several packets appended into
  880.   one file. Starting with NET25, the WWIVnet software
  881.   supports compression of the netmail files to help save on
  882.   connection time in long distance connections, using the
  883.   PKWare Compression Libraries. These files have a slightly
  884.   different format from uncompressed files, but the most
  885.   important issue at this point is that the first long int
  886.   of a compressed file has the value 0xFFFEFFFE.  If you
  887.   purchase the compression libraries from PKWare, details
  888.   covering compressed packets are found in Appendix A.
  889.   Otherwise, anyone using WWIVnet compatible software
  890.   should be advised to make sure their connect only sends
  891.   them uncompressed files, and the software should be able
  892.  
  893.                             -15-
  894.  
  895.  
  896.  
  897.   to detect and reject compressed packets before attempting
  898.   to process them.  Since there is nothing in the data
  899.   exchange described above to warn that an incoming packet
  900.   is compressed, there is no way to detect and prevent
  901.   transfer of a compressed mail file.
  902.  
  903.   Once it has been received and (if necessary)
  904.   uncompressed, the mail file should be processed following
  905.   these steps:
  906.  
  907.   1.   Open the file, and set the current message pointer
  908.        to the beginning of the file.
  909.  
  910.   2.   Read in the net header (24 bytes).
  911.  
  912.   3.   If list_len is non-zero, read in the list following
  913.        the header (2 * list_len bytes).
  914.  
  915.   4.   Read in the message itself (length bytes).
  916.  
  917.   5.   Process the message.
  918.  
  919.   6.   If not the end of file, go to step 2.
  920.  
  921.   To ensure the integrity of the mail file, an initial pass
  922.   over it should be done.  This pass would step through
  923.   each packet in the file, reading each header and making
  924.   sure no packets are truncated.  If the file ends in the
  925.   middle of a packet, then it is obviously corrupted and
  926.   cannot be processed properly.  At this point, either
  927.   throw away the whole file or remove the truncated packet
  928.   and process the remaining packets.
  929.  
  930.   During the packet tossing, each packet needs to be marked
  931.   as processed.  Thus, if analysis is interrupted before
  932.   completion, the packet analyzer can skip over those
  933.   packets already processed when run again.  To mark the
  934.   packet as already processed (or deleted), set the
  935.   main_type to 65535.  Any packet with a main_type of 65535
  936.   should therefore not be processed.
  937.  
  938.   The analyzer should follow these steps when processing
  939.   each packet:
  940.  
  941.   1.   If main_type is 65535 (deleted), skip the message.
  942.  
  943.   2.   If list_len is non-zero, do steps 3-6 for each entry
  944.        in the list, substituting that entry for "tosys"
  945.  
  946.                             -16-
  947.  
  948.  
  949.  
  950.  
  951.   3.   If tosys is this system, process the file locally
  952.        (in the case of NETWORK1.EXE, the message is copied
  953.        to LOCAL.NET for processing by the local packet
  954.        processor).
  955.  
  956.   4.   If tosys is an unknown system or unreachable, put
  957.        the packet in the dead mail file.
  958.  
  959.   5.   If the next system to forward the packet to ("next
  960.        hop") is the system that the message was last
  961.        received from, put the packet in the dead mail file.
  962.        This prevents messages from looping
  963.  
  964.   6.   If the tosys is okay, put the packet into the file
  965.        that is to be sent to the next hop.
  966.  
  967.   Of course, it is more complicated than that.  If list_len
  968.   is non-zero, all destination systems should be processed
  969.   before the message is stored anywhere.  This way, if the
  970.   message has 10 destinations, each of which has the same
  971.   next hop, only one copy of the message will be printed
  972.   out, that packet with 10 systems in its destination list.
  973.   Likewise, for a system with more than one connection, if
  974.   a message has 4 destination systems going through one
  975.   next hop and 3 going through another, one copy of the
  976.   message will go into each hop's file -- one with four
  977.   systems in the node list, the other with the remaining
  978.   three.
  979.  
  980.   The dead mail file is reprocessed whenever a network
  981.   update (new BBSlist or connection list) is received.
  982.  
  983.  C.   Local Mail Processing and DEmmm.EXE
  984.  
  985.   Processing of local mail packets should be similar to
  986.   processing of incoming netmail packets.  The main
  987.   difference between netmail tossing and local mail tossing
  988.   is that the main and minor types are ignored during
  989.   netmail processing, and the list_len and node list are
  990.   ignored (since there won't be a list on local mail).
  991.  
  992.   1.   Open the file, and set the current message pointer
  993.        to the beginning of the file.
  994.  
  995.   2.   Read in the net header (24 bytes).
  996.  
  997.   3.   Read in the message itself (length bytes).
  998.  
  999.                             -17-
  1000.  
  1001.  
  1002.  
  1003.  
  1004.   4.   Process the message.  This is done according to the
  1005.        main_type and (if applicable) minor_type of the
  1006.        message.
  1007.  
  1008.   5.   If not the end of file, go to step 2.
  1009.  
  1010.   A few main_types (noted below) cause return messages to
  1011.   be generated to go back out to other systems.  The local
  1012.   mail file analyzer should place these into an interim
  1013.   mail file that will be processed by the netmail file
  1014.   analyzer after local mail processing has been completed.
  1015.   The WWIVnet local mail analyzer (NETWORK2.EXE) puts these
  1016.   messages into P1.001 or P2.001.  Then NETWORK1.EXE
  1017.   analyzes this file and places them into outgoing netmail
  1018.   files for the system's connections.
  1019.  
  1020.   Some types of messages that contain network related files
  1021.   such as updates to the nodelists and connect lists and
  1022.   email to all sysops from the NC or GC.  For the sake of
  1023.   network security, these messages have a
  1024.   source-verification signature at the beginning (using,
  1025.   for example, RSA or a similar algorithm). There are
  1026.   several "methods" used to handle these messages, and each
  1027.   requires a decryption program, or DEmmm.EXE (where "mmm"
  1028.   is the encryption method, as listed in the 'method. field
  1029.   of the net header).  These DEmmm.EXE files MUST be
  1030.   supplied by the NC or GC of each network, and each
  1031.   network's DEmmm.EXE are unique to that network.  That is,
  1032.   WWIVnet's DE1.EXE will not handle method 1 messages from
  1033.   WWIVLink, nor vice versa.
  1034.  
  1035.   When a message is encountered with 'method!=0', the
  1036.   following steps are taken:
  1037.  
  1038.   1.   The local packet analyzer writes out the text of the
  1039.        message (no header or node list) to a temporary file
  1040.        (TEMPDE.XXX) in the data directory for the relevant
  1041.        network.
  1042.  
  1043.   2.   A command line for calling the appropriate DEmmm.EXE
  1044.        is created using the C command "sprintf(cmd, "de%u
  1045.        %s/tempde.xxx", nh.method, net_data);" ('nh' is a
  1046.        structure of type net_header_record, 'net_data' is
  1047.        the network data directory).  The command is then
  1048.        executed.
  1049.  
  1050.   3.   The DEmmm.EXE program is then responsible for
  1051.  
  1052.                             -18-
  1053.  
  1054.  
  1055.  
  1056.        reading the TEMPDE.XXX in from disk, deleting it,
  1057.        then attempting to decode it.  Two things can then
  1058.        happen: a.   If the TEMPDE.XXX fails decoding (bad
  1059.        CRC), DEmmm.EXE just exits (returning to the local
  1060.        packet analyzer). If the analyzer finds the
  1061.        TEMPDE.XXX file does not exist, the message is
  1062.        deleted and the program goes to the next packet. b.
  1063.        If the CRC checks out in the DEmmm.EXE program, it
  1064.        writes out the decoded text into a new TEMPDE.XXX
  1065.        file and exits.  The local packet analyzer reads in
  1066.        the data from that file and replaces the text of the
  1067.        message with that, then goes ahead and processes the
  1068.        packet as determined by main_type.
  1069.  
  1070.   Network operators who wish to write EN/DE programs for
  1071.   their own netwide messages may wish to consider using the
  1072.   RSAREF library to develop their own source-verification
  1073.   scheme.
  1074.  
  1075.  D.   Main and Minor Message Types
  1076.  
  1077.   The main and minor type of each message determines how it
  1078.   is processed (where it goes, whether it's a sub post,
  1079.   email, or network info, etc.).  The analyzer reads the
  1080.   message header in first to get the main and minor types,
  1081.   then performs the operation indicated by those fields.
  1082.  
  1083.   Here is a list of the main_ and minor_types, along with
  1084.   the WWIV BBS #define name and descriptions of the
  1085.   processing required. Encoding method is assumed to be
  1086.   zero unless otherwise noted. Note that while these
  1087.   descriptions concern analyzing local mail packets, they
  1088.   also apply to how to create outgoing netmail packets.
  1089.  
  1090.   main_type 1 (0x0001) -- main_type_net_info
  1091.  
  1092.        These messages contain various network information
  1093.        files, encoded with method 1 (requiring DE1.EXE).
  1094.        Once DE1.EXE has verified the source and returned to
  1095.        the analyzer, the file is created in the network's
  1096.        DATA directory with the filename determined by the
  1097.        minor_type (except minor_type 1).
  1098.  
  1099.         0 -- Feedback to sysop from the NC.  This is sent
  1100.        to the #1 account as source-verified email.
  1101.  
  1102.         1 -- BBSLIST.NET -- Old-style node list (non-Group
  1103.        setup).
  1104.  
  1105.                             -19-
  1106.  
  1107.  
  1108.  
  1109.  
  1110.         2 -- CONNECT.NET -- Old-style connections list
  1111.        (non-Group).
  1112.  
  1113.         3 -- SUBS.LST -- List of subboards ("subs")
  1114.        available through the network.  This has been
  1115.        replaced by main_type 9.
  1116.  
  1117.         4 -- WWIVNEWS.NET -- An electronic magazine of
  1118.        sorts distributed within some networks, usually
  1119.        monthly.
  1120.  
  1121.         5 -- FBACKHDR.NET -- a header file added to network
  1122.        update reports for the network.
  1123.  
  1124.         6 -- Additional WWIVNEWS.NET text -- appended to
  1125.        the existing WWIVNEWS.NET file.
  1126.  
  1127.         7 -- CATEG.NET -- List of sub categories.  WWIV's
  1128.        sub setup facility uses this list so the sysop can
  1129.        specify what category a netted sub falls into.  The
  1130.        network's SUBS.LST compiler uses this information
  1131.        for compiling the subs lists sent out as main_type
  1132.        9.
  1133.  
  1134.        8 -- NETWORKS.LST -- A list of all current WWIVnet
  1135.        type networks.
  1136.  
  1137.        This message type is source-verified.  That is,
  1138.        there is a digital signature at the beginning of the
  1139.        message text which is decoded by the DE1.EXE to
  1140.        verify that it has come from a "legal" source.  This
  1141.        helps make sure that the network info will only come
  1142.        from the Network Coordinator.  If the source-
  1143.        verification fails, the packet is discarded.
  1144.  
  1145.   main_type 2 (0x0002) -- main_type_email
  1146.  
  1147.        This is regular email sent to a user number at this
  1148.        system (see tosys and touser, above).  Note that
  1149.        this type of mail should only be received by systems
  1150.        that assign numbers to users (WWIV, VBBS, etc.).
  1151.        BBSes in a WWIV network that only identify users by
  1152.        name (PCBoard, RBBS, etc.) can only receive
  1153.        email-by-name (see main_type 7, below).  Email has
  1154.        no minor type, so minor_type will always be zero.
  1155.  
  1156.        Processing of the email is straightforward.  The
  1157.  
  1158.                             -20-
  1159.  
  1160.  
  1161.  
  1162.        analyzer looks for the user number indicated by the
  1163.        touser field.  If the number exists and the user has
  1164.        not been deleted from the BBS, the message is
  1165.        written into the email file, addressed to the user
  1166.        indicated.  If the number does not exist or the user
  1167.        at that number has been deleted, the packet is
  1168.        deleted without processing.   Alternatively, the
  1169.        analyzer may generate a return message (as email) to
  1170.        the sender telling him that the mail was not
  1171.        delivered and quoting the message back to him.
  1172.  
  1173.   main_type 3 (0x0003) -- main_type_post
  1174.  
  1175.        This is a post sent from the sub host's system to
  1176.        the subscriber systems, for subs that have a numeric
  1177.        sub-type (subs of alphanumeric subtypes are
  1178.        main_type 26, described below).  The minor_type will
  1179.        be the numeric subtype the post will go to.
  1180.  
  1181.        When this type is encountered, the network analyzer
  1182.        should search the BBS data files for the sub type
  1183.        given.  When the sub is found, the message is
  1184.        written into the indicated message file in whatever
  1185.        format the BBS software uses.  If the sub type is
  1186.        not found, the message packet is simply deleted.
  1187.        (There are some local mail preprocessors which will
  1188.        scan the packet for messages on subs that the system
  1189.        does not carry, and return the message to the host
  1190.        system. An alternate mail analyzer could have such a
  1191.        capability built in.)
  1192.  
  1193.   main_type 4 (0x0004) -- UNUSED
  1194.  
  1195.   main_type 5 (0x0005) -- main_type_pre_post
  1196.  
  1197.        These messages are similar to main_type_3, except
  1198.        they are posts en route from the subscribers to the
  1199.        host of a sub. Like main_type 3, the minor_type is
  1200.        the numeric subtype of the sub.  Since this is from
  1201.        subscriber to host, list_len will be zero.
  1202.  
  1203.        When this type of packet is received, the local mail
  1204.        tosser should look for the appropriate file which
  1205.        will contain the list of subscribers to the sub
  1206.        (WWIV and NETxx use N[subtype].NET)  If the file is
  1207.        found, a main_type 3 copy of the post is generated
  1208.        in an outgoing netmail file, with the node list read
  1209.        from the subscriber file inserted before the message
  1210.  
  1211.                             -21-
  1212.  
  1213.  
  1214.  
  1215.        text (and the list_len field modified reflecting the
  1216.        addition of the node list).  If the file cannot be
  1217.        found, the analyzer assumes the BBS does not host
  1218.        the sub and deletes the packet.
  1219.  
  1220.        Many WWIV sysops use a feature of the software known
  1221.        as network validation ("netval").  When a sub is set
  1222.        for netval (this is found in the SUBS.DAT record for
  1223.        the sub), the analyzer does not send the post out to
  1224.        the network.  The sysop must validate the post on
  1225.        the BBS, at which point it is sent out by the BBS.
  1226.        This also applies to pre-posts for main_type 26
  1227.        (main_type_new_post).
  1228.  
  1229.   main_type 6 (0x0006) -- main_type_external
  1230.  
  1231.        This type has largely been replaced with main_type
  1232.        27 (main_type_new_external), but essentially works
  1233.        the same way.  This will create messages that are
  1234.        read and processed by an external processor.  The
  1235.        minor_type is determined by the program expected to
  1236.        work with it.
  1237.  
  1238.        When the processor encounters this type of message,
  1239.        it searches for a file that contains the names of
  1240.        external programs, and the minor_types they accept,
  1241.        used by the BBS (EXT_LIST.NET for the WWIVnet
  1242.        software).  If found, the message is written or
  1243.        appended to EXTERNAL.NET in the network's data
  1244.        directory.  The external program, when run, should
  1245.        be able to find the file and process it, then delete
  1246.        the file (or the portion that it uses).  Note that
  1247.        when there is more than one main_type 6 message in a
  1248.        mail file, the EXTERNAL.NET will contain all
  1249.        messages of that type, so the external message
  1250.        processor needs to be able to find the relevant text
  1251.        within the file.
  1252.  
  1253.        It is encouraged that programs that use external
  1254.        messages use main_type 27 (main_type_new_external),
  1255.        which has more robust features.  Among other things,
  1256.        that type will create a separate temporary file for
  1257.        each main_type 27 message found, making processing
  1258.        of external messages simpler.
  1259.  
  1260.   main_type 7 (0x0007) -- main_type_email_name
  1261.  
  1262.        The other email type.  The touser field is zero, and
  1263.  
  1264.                             -22-
  1265.  
  1266.  
  1267.  
  1268.        the name is found at the beginning of the message
  1269.        text, followed by a NUL character.  Minor_type will
  1270.        always be zero.
  1271.  
  1272.        When this type of packet is encountered, the
  1273.        analyzer gets the name from the beginning of the
  1274.        message text and searches through the BBS's user
  1275.        list to find the specified name.  If it is found,
  1276.        the message is written into the email file for the
  1277.        BBS.  If it is not, the message will be deleted or a
  1278.        return email may be sent back to the sender,
  1279.        explaining that the message was not delivered and
  1280.        quoting the email back.
  1281.  
  1282.        The destination user's name is prepended to the
  1283.        beginning of the message text, followed by a NUL,
  1284.        then the rest of the usual message header info and
  1285.        the message text.  The message header info at the
  1286.        beginning of email-by-name messages is thus
  1287.        DEST_USER_NAME<nul>TITLE<nul>SENDER_NAME<cr/lf>
  1288.        DATE_STRING<cr/lf>MESSAGE_TEXT.
  1289.  
  1290.   main_type 8 (0x0008) -- main_type_net_edit
  1291.  
  1292.        This type is used by Black Dragon (#1@1180 WWIVnet)
  1293.        in conjunction with his program NETEDIT, a utility
  1294.        for managing the network files on a WWIV BBS.  For
  1295.        more information on this type, contact him at the
  1296.        above address.
  1297.  
  1298.   main_type 9 (0x0009) -- main_type_sub_lst
  1299.  
  1300.        Networks with large subs lists (over 32k) break them
  1301.        up into parts and send the set out under this main
  1302.        type rather than the subs.lst type under main_type
  1303.        1.  The minor_type indicates the part of the subs
  1304.        list.
  1305.  
  1306.        When the analyzer processes this type, it creates a
  1307.        file in the appropriate network directory and copies
  1308.        the message text into it.  Minor_type zero creates
  1309.        the file SUBS.LST, and all other minor_types create
  1310.        a SUBS.x file where 'x' is the minor_type.
  1311.  
  1312.   main_type 10 (0x000a) -- UNUSED
  1313.  
  1314.   main_type 11 (0x000b) -- main_type_bbslist
  1315.  
  1316.  
  1317.                             -23-
  1318.  
  1319.  
  1320.  
  1321.        This type is for the new-style BBSLIST files used in
  1322.        networks that use the Group setup.  It covers full
  1323.        and partial updates sent from the Network
  1324.        Coordinator (NC) to the entire network as well as
  1325.        update requests sent from the Group Coordinators
  1326.        (GCs) to the NC.  The encoding method is either 1
  1327.        (when coming from the NC) or calculated as
  1328.        ((minor_type % 256)+256) (when coming from the GC).
  1329.        Messages of this type are source verified by
  1330.        DE<method>.EXE, handled the same as main_type 1
  1331.        packets are.  Minor types are as follows:
  1332.  
  1333.        0..255    Full bbslist update sent from NC to the
  1334.                  network. Minor type is the Group number.
  1335.                  Creates BBSLIST.<minor_type> in the
  1336.                  network data direc tory.
  1337.  
  1338.        257..511  Full bbslist update sent from the GC to
  1339.                  the NC. Minor_type is the Group number
  1340.                  plus 256.  Creates
  1341.                  BBSLIST.A<minor-less-256-in-hex> in the
  1342.                  NC's network data directory.
  1343.  
  1344.        513..767  Partial bbslist update sent from the NC to
  1345.                  the network.  Minor type is the Group
  1346.                  number plus 512. Creates the file
  1347.                  BBSLIST.<minor-type> in the network data
  1348.                  directory.  This file will be merged with
  1349.                  the appropriate full BBSLIST file during
  1350.                  network analysis (described below).
  1351.  
  1352.        In some networks, the Group updates are sent out to
  1353.        the network by the GCs rather than the NC.
  1354.  
  1355.   main_type 12 (0x000c) -- main_type_connect
  1356.  
  1357.        This is the same as main_type 11, except it is for
  1358.        CONNECT files.  It also does not include partial
  1359.        updates, as there are none for CONNECT files.  The
  1360.        encoding method is also either 1 (from NC) or
  1361.        ((minor_type % 256)+256) (from NC) for this type.
  1362.        These packets are also source-verified, checked by
  1363.        DE<method>.EXE.  Minor types:
  1364.  
  1365.        0..255    Full CONNECT update sent from NC to the
  1366.                  network. Minor type is the Group number.
  1367.                  Creates CONNECT.<minor-type> in the
  1368.                  network data directory (after
  1369.  
  1370.                             -24-
  1371.  
  1372.  
  1373.  
  1374.                  source-verification).
  1375.  
  1376.        257..511  Full bbslist update sent from the GC to
  1377.                  the NC. Minor_type is the Group number
  1378.                  plus 256.  Creates
  1379.                  CONNECT.A<minor-less-256-in-hex> in the
  1380.                  NC's network data directory (after source
  1381.                  verifica tion).
  1382.  
  1383.        In some networks, the Group updates are sent out to
  1384.        the network by the GCs rather than the NC.
  1385.  
  1386.   main_type 13 (0x000d) -- UNUSED
  1387.  
  1388.   main_type 14 (0x000e) -- main_type_group_info
  1389.  
  1390.        For now, this type only covers email to the members
  1391.        of a particular Group by the GC, so minor type will
  1392.        always be zero.  Encoding method is the Group number
  1393.        plus 256. Processing for this is the same as for
  1394.        type 1/0 messages. They are source-verified by
  1395.        DE<method>.EXE.
  1396.  
  1397.   main_type 15 (0x000f) -- main_type_ssm
  1398.  
  1399.        WWIV BBSes also send out small messages, known as
  1400.        "SSMs", across the network.  These are little
  1401.        one-line messages generally telling users when their
  1402.        mail has been read and so forth.  Some BBSes have
  1403.        been modified to send other types of messages.  At
  1404.        any rate, main_type handles these small messages.
  1405.        Minor_type is always zero.
  1406.  
  1407.        Like email, the analyzer searches for the user
  1408.        number in the BBS's user list.  If found, the
  1409.        message is written into the SSM file for the BBS.
  1410.        Since this is a feature most non-WWIV systems do not
  1411.        support, they can be ignored.
  1412.  
  1413.   One feature of WWIV networking is the ability fpr network
  1414.   sysops to send "REQs" to the hosts of subs, enabling them
  1415.   to automati cally subscribe to and drop subs they belong
  1416.   to.  Main_types 16 through 19 handle REQs and their
  1417.   responses.
  1418.  
  1419.   main_type 16 (0x0010) -- main_type_sub_add_req
  1420.  
  1421.        This is for requests to add the sending system to a
  1422.  
  1423.                             -25-
  1424.  
  1425.  
  1426.  
  1427.        sub's subscriber list.  Minor_type will be the
  1428.        numeric sub type, or zero for alphanumeric sub
  1429.        types.  For minor_type==0, the sub type (followed by
  1430.        NUL) will be the message text. Otherwise, there
  1431.        should be no message text (if there is, ignore it).
  1432.  
  1433.        When this message type is received, the analyzer
  1434.        should search for the subtype's subscriber file
  1435.        (N[subtype].NET for WWIV systems).  If the file is
  1436.        found, the system number of the new subscriber is
  1437.        added, if it is not in there already. If the add is
  1438.        successful, it will then look for a text file in the
  1439.        data directory (SA[subtype].NET for the WWIVnet
  1440.        software) that contains information the sysop wants
  1441.        to send back to the subscriber.   A type 18 message
  1442.        is sent to the subscriber indicating status of the
  1443.        add request (see below) and including the text in
  1444.        the SA[subtype].NET file, if one is found.  If the
  1445.        add is not allowed, the analyzer looks for
  1446.        SR[subtype].NET and sends that text back to the
  1447.        requester. If the add is otherwise unsuccessful, the
  1448.        type 18 message will include the status and a short
  1449.        explanation of why the add was not succcessful.
  1450.  
  1451.   main_type 17 (0x0011) -- main_type_sub_drop_req
  1452.  
  1453.        This is the same as a main_type 16 message, except
  1454.        that it is sent by a subscriber wishing to drop a
  1455.        sub.  The minor_type is determined the same way as
  1456.        main_type 16. There should be no message text, but
  1457.        if there is any, it is ignored.
  1458.  
  1459.        Processing is similar to a type 16 message.  The
  1460.        analyzer searches for the subtype's subscriber file,
  1461.        and upon finding it removes the subscriber's system
  1462.        number from it, if it is there.  Status of the drop
  1463.        request is returned to the sender in a main_type 19
  1464.        message, with a short message appended that explains
  1465.        the status.
  1466.  
  1467.   main_type 18 (0x0012) -- main_type_sub_add_resp
  1468.  
  1469.        This carries the status response to a main_type 16
  1470.        (sub add request).  The minor_type is determined the
  1471.        same way as type 16 message.  The first byte of
  1472.        message text (after the subtype, if minor_type==0)
  1473.        is the status of the add request. Possible status
  1474.        byte values are:
  1475.  
  1476.                             -26-
  1477.  
  1478.  
  1479.  
  1480.  
  1481.        0 -- Subscriber added successfully.
  1482.  
  1483.        1 -- This system is not the host (N[subtype].NET not
  1484.        found).
  1485.  
  1486.        3 -- Not allowed to add subscribers automatically.
  1487.  
  1488.        4 -- System number already there (can't add it
  1489.        again).
  1490.  
  1491.  
  1492.        When received, the processor will send the message
  1493.        text mentioned in the main_type 16 description
  1494.        (minus the status byte) to the sysop as email.
  1495.  
  1496.   main_type 19 (0x0013)- main_type_sub_drop_resp
  1497.  
  1498.        Similar to main_type 18, this carries the response
  1499.        to a sub drop request, with the minor_type following
  1500.        the same conventions as above.  This also carries a
  1501.        status byte as the message text:
  1502.  
  1503.        0 -- Sub dropped successfully.
  1504.  
  1505.        1 -- This system is not the host.
  1506.  
  1507.        2 -- System number is not there (can't drop it).
  1508.  
  1509.        3 - not allowed to drop subscribers automatically.
  1510.  
  1511.        When received, the processor will send the message
  1512.        text mentioned in ther main_type 17 description
  1513.        (minus the status byte) to the sysop as email.
  1514.  
  1515.   main_type 20 (0x0014) -- main_type_sub_list_info
  1516.  
  1517.        In many WWIV networks, the subs list coordinator
  1518.        (SLC) occasionally sends out "pings" to all network
  1519.        members.
  1520.  
  1521.        When this message type is received from the SLC
  1522.        (minor_type 0), the analyzer checks the BBS's sub
  1523.        data file.  If there are any subs hosted by the
  1524.        receiving system which are flagged for inclusion in
  1525.        the distributed SUBS.LST, a list of them is returned
  1526.        to the SLC via another main_type 20 message with
  1527.        minor_type==1).  When the SLC recieves the reply, it
  1528.  
  1529.                             -27-
  1530.  
  1531.  
  1532.  
  1533.        is written into SUBS.INF in the network's data
  1534.        directory (appended if the file exists).
  1535.  
  1536.   main_type 26 (0x001a) -- main_type_new_post
  1537.  
  1538.        Because of the growing number of networked subs on
  1539.        WWIVnet, the number of available subtypes was
  1540.        getting scarce. Starting with WWIV version 4.22 and
  1541.        NET32, alphanumeric subtype support was added,
  1542.        greatly expanding the possible subtypes.  Alpha
  1543.        subtypes are seven characters -- the first must be a
  1544.        letter, but the rest can be any character allowed in
  1545.        a DOS filename.  This main_type covers both
  1546.        subscriber- to-host and host-to-subscriber messages.
  1547.        Minor type is always zero (since it's ignored), and
  1548.        the subtype appears as the first part of the message
  1549.        text, followed by a NUL. Thus, the message header
  1550.        info at the beginning of the message text is in the
  1551.        format SUBTYPE<nul>TITLE<nul>
  1552.        SENDER_NAME<cr/lf>DATE_STRING<cr/lf>MESSAGE_TEXT.
  1553.  
  1554.        It is assumed that a message coming into a host is a
  1555.        prepost, and it is processed similarly to main_type
  1556.        5. Likewise, it is assumed that messages coming into
  1557.        a sub scriber system are net posts, and they are
  1558.        processed similarly to main_type 3.
  1559.  
  1560.   main_type 27 (0x001b) -- main_type_new_external
  1561.  
  1562.        This is the new type of external message,
  1563.        implemented with NET33.  Like main_type 6, it
  1564.        creates an external file with the message text for
  1565.        an external program to process.  Again, the
  1566.        minor_type is determined by the external program.
  1567.  
  1568.        There is a full explanation of how these messages
  1569.        are processed in Filo's WWIVnet Software Docs.  In
  1570.        short, similar to main_type 6, the local mail
  1571.        processor searches for the minor_type in a data file
  1572.        (EPROGS.NET for NETxx), and creates an external file
  1573.        if it is found.  When the local mail processor is
  1574.        finished with the local mail file, the program
  1575.        associated with that minor_type will execute, with
  1576.        the associated filename (with path) as a parameter.
  1577.  
  1578. V.  BBSLIST/CONNECT FILES AND MESSAGE ROUTING
  1579.  
  1580. So how does the network software know where to send an
  1581.  
  1582.                             -28-
  1583.  
  1584.  
  1585.  
  1586. off-system message, especially if the BBS has more than one
  1587. connect?  FidoNet has its nodelists, and so does WWIVnet.
  1588. WWIVnet actually has two different types of node lists, as
  1589. mentioned elsewhere.  We'll take these separately, then
  1590. discuss figuring out the routing.
  1591.  
  1592.  A.  Old WWIVnet -- BBSLIST.NET & CONNECT.NET
  1593.  
  1594.  In the beginning of WWIVnet, there were only two files
  1595.  needed to keep up with the systems in the network --
  1596.  BBSLIST.NET and CONNECT.NET.  Though this is rarely used
  1597.  now, there are still some smaller networks which use these
  1598.  files, so they should be discussed.
  1599.  
  1600.  BBSLIST.NET holds a listing of what systems are in the
  1601.  network. Each system has an entry, with the systems
  1602.  usually grouped by area code.  The format for each
  1603.  system's line: system number (preceded by @), system phone
  1604.  number (preceded by *), max bps rate of the system
  1605.  (preceded by #), system flags if any, WWIV registration
  1606.  number or date of entry (enclosed in brackets), and system
  1607.  name (enclosed in "").  For example, the BBSLIST line for
  1608.  Amber in WWIVnet could be:
  1609.  
  1610.  @1     *310-798-9993  #14400 <  !$     [1]  "Amber"
  1611.  
  1612.  Most of the system flags after the modem speed indicate
  1613.  the kind of high-speed modem being used by the system.
  1614.  Currently, these flags are:
  1615.  
  1616.  | -- Telebit-compatible (PEP) modem.
  1617.  < -- USR HST 9600+bps modem.
  1618.  > -- Hayes V-Series compatible 9600+bps modem.
  1619.  Z -- Zoom V.32terbo (19.2kpbs) modem.
  1620.  / -- CompuCom 9600+bps modem.
  1621.  ! -- CCITT V.32 (9600bps) modem.
  1622.  $ -- CCITT V.32bis (14.4kbps) modem.
  1623.  ~ -- V.FAST (28.8kbps) modem.
  1624.  ? -- Fax-capable modem (not currently used)
  1625.  
  1626.  Other system flags used which are not modem designators:
  1627.  
  1628.  + -- The system is a dedicated mail server.  That is, it
  1629.       is not a true BBS, only handles the transfer of
  1630.       network mail for an area or region.
  1631.  
  1632.  \ -- Fidonet system.  Some systems in the network have
  1633.       "gateways" into Fidonet (or Fidonet compatible, such
  1634.  
  1635.                             -29-
  1636.  
  1637.  
  1638.  
  1639.       as GlobalNet).
  1640.  
  1641.  = -- PCPursuitable system.  This is actually not useful
  1642.       since PCPursuit has gone out of business (though
  1643.       there are other similar networks still operating).
  1644.  
  1645.  _ -- End node.  That is, a system with only one
  1646.       connection.
  1647.  
  1648.  There can also be one of three flags appearing before the
  1649.  phone number: ^ -- Area Code coordinator (AC). & --
  1650.  Network Coordinator (NC). % -- Group Coordinator (GC) Note
  1651.  that since there can only be one Network Coordinator, the
  1652.  "&" should only appear once in the BBSLIST.NET file. Also,
  1653.  the "%" is not likely to be seen except in the Group setup
  1654.  described below, since this setup has no Groups.
  1655.  
  1656.  The first line of the BBSLIST.NET must be a tilde (~)
  1657.  followed by the Unix timestamp (seconds since midnight,
  1658.  Jan 1, 1970) indicating the date and time the file was
  1659.  sent out by the NC or GC.
  1660.  
  1661.  CONNECT.NET lists the connection costs between systems.
  1662.  The cost listed should be the cost per minute, though for
  1663.  most networks using this system, the rule of thumb is 0.00
  1664.  for local connects, 0.01 for long distance connects, and
  1665.  more for long distance connects that one wants to route
  1666.  less mail through.
  1667.  
  1668.  Each entry in the CONNECT.NET file specifies a one-way
  1669.  connection between two systems.  The entries in the
  1670.  CONNECT.NET file do NOT need to be in any specific order.
  1671.  The format for system's connection entry is: the system
  1672.  number (preceded by "@"), first connection and cost
  1673.  (separated by "="), second connection and cost, and so
  1674.  forth.  Like BBSLIST.NET, the first line is a tilde (~)
  1675.  followed by the UNIX timestamp.
  1676.  
  1677.  Examples:
  1678.  1.   If there are two systems, numbered 1 and 2, and each
  1679.       can call each other for free, the CONNECT.NET file
  1680.       would look like:
  1681.  
  1682.       @1      2=0.00
  1683.       @2      1=0.00
  1684.  
  1685.       Note that the routing analysis software should make
  1686.       sure both ends of the connection have entries
  1687.  
  1688.                             -30-
  1689.  
  1690.  
  1691.  
  1692.       referring to each other.
  1693.  
  1694.  2.   If there are three systems, each can call the others
  1695.       for free, the CONNECT.NET file would look like:
  1696.  
  1697.       @1      2=0.00 3=0.00
  1698.       @2      1=0.00 3=0.00
  1699.       @3      1=0.00 2=0.00
  1700.  
  1701.  3.   If system 3 called the other two for $0.10, the
  1702.       CONNECT.NET file would look like:
  1703.  
  1704.       @1      2=0.00 3=0.10
  1705.       @2      1=0.00 3=0.10
  1706.       @3      1=0.10 2=0.10
  1707.  
  1708.  
  1709.  In both BBSLIST.NET and CONNECT.NET file, each entry
  1710.  begins with identifying the system number (preceded with
  1711.  @), allowing system entries to take up more than one line
  1712.  -- in larger networks a CONNECT.NET entry can fill more
  1713.  than one line.  Everything after the system number
  1714.  identifier up to the next "@", corresponds to that system.
  1715.  Thus, the CONNECT.NET files above could also be listed as:
  1716.  
  1717.  @1 2=0.00 3=0.10 @2 1=0.00 3=0.10 @3 1=0.10 2=0.10
  1718.  
  1719.  or
  1720.  
  1721.  @1
  1722.  2=0.00
  1723.  3=0.10
  1724.  @2
  1725.  1=0.00
  1726.  2=0.10
  1727.  @3
  1728.  1=0.10
  1729.  2=0.10
  1730.  
  1731.  Thus, the end-of-line indicator (EOL) should be IGNORED.
  1732.  
  1733.  Neither the BBSLIST.NET nor CONNECT.NET file need to be in
  1734.  any specific order.  There cannot, however, be multiple
  1735.  entries per system in either BBSLIST.NET or CONNECT.NET.
  1736.  
  1737.  It is possible for a system to have references in one or
  1738.  both of the .NET files, but not be reachable from any
  1739.  other system.  For example, two systems may be listed in
  1740.  
  1741.                             -31-
  1742.  
  1743.  
  1744.  
  1745.  BBSLIST.NET, and listed in CONNECT.NET, but each can only
  1746.  call the other.  No other system in the network can
  1747.  connect with them, so they don't exist, essentially.
  1748.  Also, a system can be listed in BBSLIST.NET, but not have
  1749.  any entries in CONNECT.NET.  This usually happens for
  1750.  systems just joining the network, and those systems
  1751.  essentially don't exist either.
  1752.  
  1753.  It is also possible for one system to call another, but
  1754.  the second system can't call back the first.  This is
  1755.  unusual, but valid.  Also, the cost of a connection can be
  1756.  different in one direction than it is in the other.  This
  1757.  is also valid.
  1758.  
  1759.  BBSLIST.NET is received across the network as main_type 1,
  1760.  minor_type 1 (1/1).  CONNECT.NET is received as main_type
  1761.  1, minor_type 2 (1/2).
  1762.  
  1763.  B.   New WWIVnet -- BBSLIST.x and CONNECT.x
  1764.  
  1765.   As mentioned previously, things changed in 1990.  The
  1766.   original WWIVnet network had grown so large that it was
  1767.   necessary to break the BBSLIST and CONNECT files into
  1768.   smaller segments, known as Groups.  How the Groups are
  1769.   determined is up to the Network Coordinator.  WWIVnet's
  1770.   Groups were formed based on the connec tion topology at
  1771.   the time of the conversion to the Group system. Many
  1772.   other networks use the International Time Zones to divide
  1773.   the groups.  The Groups are numbered, with the potential
  1774.   for up to 255 Groups in a network.  The BBSLIST and
  1775.   CONNECT files have the Group number ("x") as the
  1776.   extension.
  1777.  
  1778.   The BBSLIST.x file is formatted the same way as the
  1779.   BBSLIST.NET under the old WWIVnet system.  Only BBSes
  1780.   with the Group are in each Group's files.  There is an
  1781.   additional file, BBSLIST.0, which contains information
  1782.   for the routing analyzer.  The first line has the UNIX
  1783.   timestamp, as usual.  The second describes which
  1784.   CONNECT.x file to use.  If it is ":" alone, then
  1785.   CONNECT.0 contains all the connection information for the
  1786.   network, so that is all that will be used.  If the second
  1787.   line is ":A", then CONNECT.0 and the CONNECT.x files for
  1788.   all Groups are used.
  1789.  
  1790.   There can also be partial BBSLIST updates sent out,
  1791.   indicating systems to be added, changed or removed.  The
  1792.   extension on these messages is generally Group number
  1793.  
  1794.                             -32-
  1795.  
  1796.  
  1797.  
  1798.   plus 512 (e.g., a group 1 partial update would be
  1799.   BBSLIST.513).  For added or changed systems, the system
  1800.   is listed as it would appear in the BBSLIST.x it belongs
  1801.   to.  A deleted system is listed as just the system number
  1802.   with a period (.), as in "@1234 .".  These partial
  1803.   updates are incorporated into the full BBSLIST files
  1804.   during the routing analysis (see below).
  1805.  
  1806.   The BBSLIST.x files use the same indicators as the
  1807.   BBSLIST.NET file, with one addition: This should only
  1808.   appear once in each BBSLIST.x file, since each Group may
  1809.   only have one GC.
  1810.  
  1811.   CONNECT.x is not like the old CONNECT.NET.  The main
  1812.   difference is that there are no costs in the connections,
  1813.   only the node numbers each system is connected to.  So in
  1814.   the second example in the previous section, the CONNECT.x
  1815.   for systems 1, 2 and 3 would look like this:
  1816.  
  1817.   @1   2 3
  1818.   @2   1 3
  1819.   @3   1 2
  1820.  
  1821.   As noted above, the CONNECT.x files will be used as
  1822.   specified by the second line in BBSLIST.0.  When that
  1823.   line is ":", CONNECT.0 will contain all the network's
  1824.   connections.  When it is ":A", the CONNECT.x files
  1825.   contain all the connections within each Group. All
  1826.   connections between systems in different groups are
  1827.   listed in CONNECT.0.
  1828.  
  1829.   For example, say we have a network with five systems,
  1830.   numbered 1, 2, 3, 4, and 5.  Systems 1 and 2 are in Group
  1831.   1, and systems 3, 4, and 5 are in Group 2.  1 and 2
  1832.   connect to each other, and 2 connects to 4.  3 and 4
  1833.   connect to each other, and 5 connects to 1.
  1834.  
  1835.   CONNECT.1 will contain:
  1836.   @1   2
  1837.   @2   1
  1838.  
  1839.   CONNECT.2 will contain:
  1840.   @3   4
  1841.   @4   3
  1842.  
  1843.   CONNECT.0 will contain:
  1844.   @1   5
  1845.   @2   4
  1846.  
  1847.                             -33-
  1848.  
  1849.  
  1850.  
  1851.   @4   2
  1852.   @5   1
  1853.  
  1854.   Like the old WWIVnet files, the ordering of the systems
  1855.   in these files does not matter, however a node number may
  1856.   appear only once in all of the BBSLIST.x files combined.
  1857.  
  1858.   The BBSLIST.x files are received across the networks as
  1859.   main_type 11, with the minor_type being determined by the
  1860.   Group they are for.  CONNECT.x files are received as
  1861.   main_type 12, with the minor_type determined by the Group
  1862.   number.
  1863.  
  1864.  C.  Figuring the Routing
  1865.  
  1866.   There are three ways message routing could be determined:
  1867.  
  1868.   1.   Each time you need to route a message, find the
  1869.        least cost or shortest path (depending on whether
  1870.        new or old update files are being used);
  1871.  
  1872.   2.   Each time one of the network programs that has to
  1873.        route messages is run, the least-cost or shortest
  1874.        route to each system is decided; or
  1875.  
  1876.   3.   Each time an update to the .NET files is received,
  1877.        the least cost route is decided to each system.
  1878.  
  1879.   Options 1 and 2 are simply not practical.  Depending on
  1880.   network size and system speed, it can take a minute or
  1881.   more to analyze the network data files and determine the
  1882.   optimal route.  Finding the best route to a specific
  1883.   system requires the same operation as finding the best
  1884.   route to all systems, so option #1 is a waste of time
  1885.   (besides possibly requiring the BBS to have the path-
  1886.   finding code in it).  Option #2 holds no advantages over
  1887.   option #3 because it will tie up the BBS unnecessarily.
  1888.  
  1889.   Therefore, the optimal routes to all the systems in the
  1890.   network should be analyzed only when a network update is
  1891.   received. This routing analysis can be done any way, as
  1892.   long as it determines the best route.  The best way,
  1893.   however, could follow these steps:
  1894.  
  1895.   1.   System records are read into an array from
  1896.        BBSLIST.NET (for the old WWIVnet setup) or the
  1897.        BBSLIST.x files (for the Group setup).  The array is
  1898.        of struct net_system_list_rec (see below).  All
  1899.  
  1900.                             -34-
  1901.  
  1902.  
  1903.  
  1904.        fields are filled from the BBSLIST.x except numhops
  1905.        and forsys, which are set to 65535 and 0, respec
  1906.        tively.  For the Group setup, the BBSLIST.xxx
  1907.        partial updates (.513-.768) are read in next, and
  1908.        the indicated changes (existing systems replaced,
  1909.        new systems added, systems indicated with "."
  1910.        deleted) are made in the array and in the BBSLIST
  1911.        files themselves.  After processing, the partial
  1912.        updates are deleted.
  1913.  
  1914.   2.   Next, the CONNECT files are read into another array.
  1915.        Since system records may be repeated in the CONNECT
  1916.        files, make sure, when each system record is read
  1917.        in, a check is made in the array to see if there is
  1918.        already an entry for it.  If there is, add the
  1919.        connections in the new record to the existing
  1920.        record.
  1921.  
  1922.   3.   Then, the analysis starts.  The analyzer uses the
  1923.        system's callout list (CALLOUT.NET for NETxx) as a
  1924.        base, starting with the first entry and checking
  1925.        each of its connnects, spreading out from there to
  1926.        THEIR connects.  This is done for each system in the
  1927.        callout list.
  1928.  
  1929.        For each destination system checked, the number of
  1930.        hops found is compared to that entered in the
  1931.        network data array (numhops) and changed if it is
  1932.        less.  The forsys is also changed, if that is
  1933.        different.  This is for the Group setup.
  1934.  
  1935.        If the network is using the old WWIVnet setup, cost,
  1936.        rather than number of hops, is considered.  In this
  1937.        case, when figuring cost, the speed of a connection
  1938.        (highest speed two connecting systems will support)
  1939.        needs to be considered. For instance, two systems
  1940.        connecting at 14400bps at a cost of 0.10 would take
  1941.        precedence over two systems connectiung at 2400bps
  1942.        at a cost of 0.10 (assuming that they are on the
  1943.        path to the same destination system, and all other
  1944.        scosts are equal).
  1945.  
  1946.   4.   When all systems in the callout list are processed,
  1947.        analysis is complete and the network data array is
  1948.        written to disk. If specified, a piece of mail is
  1949.        then sent to the sysop giving the results of the
  1950.        analysis (for instance, how many valid systems are
  1951.        in the network, how many systems route through each
  1952.  
  1953.                             -35-
  1954.  
  1955.  
  1956.  
  1957.        of this system's connections, who the NC and GC and
  1958.        AC are, and so forth).
  1959.  
  1960.   The data structure NETxx's NETWORK3.EXE uses for the
  1961.   network data file is:
  1962.  
  1963.   typedef struct {
  1964.        unsigned short sysnum;
  1965.              /* system number */
  1966.        char           phone[13]
  1967.        ,     /* phone number of system */
  1968.                       name[40];
  1969.              /* name of system */
  1970.        unsigned char  group;
  1971.              /* group system is in */
  1972.        unsigned short speed,
  1973.              /* max bps rate of system */
  1974.                       other,
  1975.              /* other info (bit mapped) */
  1976.                       forsys;
  1977.              /* next hop from here */
  1978.        short          numhops;
  1979.              /* how far to get there */
  1980.        union {
  1981.             unsigned short rout_fact;
  1982.              /* routing factor */
  1983.             float          cost;
  1984.             /* cost factor */
  1985.             long           temp;
  1986.             /* temporary variable */
  1987.        } xx;
  1988.   } net_system_list_rec;
  1989.  
  1990.   It is encouraged that this structure be used by any
  1991.   WWIVnet compatible analyzer.  Not only is this used by
  1992.   the WWIV BBS software, but some WWIVnet add-ons also use
  1993.   this file, so supporting this structure will enhance
  1994.   compatibility with WWIVnet.
  1995.  
  1996.   The fields: sysnum, phone, name, group, and speed should
  1997.   be self-explanatory.
  1998.  
  1999.   other --  This is bitmapped, and contains the modem and
  2000.             other information shown in BBSLIST.  The bitmap
  2001.             values are (with corresponding BBSLIST flag):
  2002.  
  2003.             \    other_fido          0x0001
  2004.             |    other_Telebit_19200 0x0002
  2005.  
  2006.                             -36-
  2007.  
  2008.  
  2009.  
  2010.             <    other_USR_9600      0x0004
  2011.             >    other_Hayes_9600    0x0008
  2012.             ^    other_coordinator   0x0010
  2013.                  (area coordinator)
  2014.             !    other_V32           0x0020
  2015.             $    other_V32bis        0x0040
  2016.             =    other_PCP           0x0080
  2017.             %    other_group_coord   0x0100
  2018.             &    other_net_coord     0x0200
  2019.             /    other_compucom      0x0400
  2020.             +    other_net_server    0x0800
  2021.             ?    other_FAX           0x1000
  2022.             _    other_end_system    0x2000
  2023.             ~    other_VFAST         0x4000
  2024.  
  2025.   forsys -- Where to forward messages destined for this
  2026.             system, also known as "next hop".  For example,
  2027.             if a message going from system 1 to system 5
  2028.             passes through systems 2 and 4, then forsys==2.
  2029.             When it is determined that the system is
  2030.             unreachable (listed in BBSLIST but no
  2031.             connections listed), forsys==65535.
  2032.  
  2033.   rout_fact -- This is the routing factor, but is currently
  2034.             not used by the NETxx software.
  2035.  
  2036.   cost --   When using an old-style WWIV network setup,
  2037.             this holds the cost of the call, calculated as
  2038.             the sum of costs for each hop to the
  2039.             destination.
  2040.  
  2041.   When all systems have been processed, you should have a
  2042.   database containing all systems in the network and how
  2043.   they may be reached.  Whenever a packet that is not
  2044.   destined for the local system is processed, the data file
  2045.   is searched to find the system entry for the destination
  2046.   system.  If it is not found, then the system is unknown.
  2047.   If the system is identified as unreachable
  2048.   (forsys==65535), the system is also considered unknown.
  2049.  
  2050. VI.  TIPS FOR WRITING WWIVNET SOFTWARE
  2051.  
  2052.  That about covers all the technical details for designing
  2053.  software compatible with WWIV networks.  Now for some
  2054.  things to consider for those wishing to design a WWIVnet
  2055.  interface for a non-WWIV BBS, or add-ons to existing
  2056.  WWIVnet software.
  2057.  
  2058.  
  2059.                             -37-
  2060.  
  2061.  
  2062.  
  2063.  A.   WWIVnet Interface Software
  2064.  
  2065.   The information provided in this document is enough for
  2066.   anyone wishing to write WWIVnet interface software from
  2067.   scratch.  Unless you are writing for a BBS on a non-PC
  2068.   platform (such as Hermes for Macintosh), there is no need
  2069.   to rewrite all of the software to interface a PC-based
  2070.   BBS to a WWIV network.  Since the local mail processor
  2071.   (NETWORK2.EXE) is the only program that writes to BBS
  2072.   message bases, that is really the only one needing
  2073.   replace ment.  If any of the NETxx programs are used, it
  2074.   is essential that all of the supporting data files used
  2075.   by that software be present.  For details on those files,
  2076.   see the WWIVnet software documentation.
  2077.  
  2078.   Some additional programming may be necessary, though.
  2079.   For one, a shell would be useful for executing the
  2080.   various network programs, unless the BBS can be modified
  2081.   to make the calls itself.  A batch file could do it, but
  2082.   a program such as Jim Wire's CLOUT makes it much easier.
  2083.   Any shell or BBS modification should follow these steps
  2084.   (filenames in parentheses are programs from NET34 or
  2085.   files created/used by them):
  2086.  
  2087.   1.   Choose a system to call (or have one specified),
  2088.        then execute the network callout program
  2089.        (NETWORK.EXE).  If successful, proceed to step 2.
  2090.        If not, either try again or end processing.
  2091.  
  2092.   2.   Check for the incoming netmail file (P*.NET).  If
  2093.        there isn't one, end processing.  If there is one,
  2094.        run the netmail packet analyzer (NETWORK1.EXE).
  2095.  
  2096.   3.   Check for the local mail file packet (LOCAL.NET).
  2097.        If there is none, end processing.  If there is one,
  2098.        run the local mail packet analyzer (NETWORK2.EXE).
  2099.  
  2100.   4.   Check again for a netmail packet (outgoing messages
  2101.        result ing from local mail processing).  If there is
  2102.        one run the netmail analyzer, otherwise proceed to
  2103.        the next step.
  2104.  
  2105.   5.   Check for a BBSLIST or CONNECT update.  The most
  2106.        reliable way to do this is to compare the filedates
  2107.        of the CONNECT and BBSLIST files against the
  2108.        filedate of the database file created last time the
  2109.        routing analyzer ran.  If one or more of the files
  2110.        is new (or there is a partial BBSLIST update), run
  2111.  
  2112.                             -38-
  2113.  
  2114.  
  2115.  
  2116.        the routing analyzer (NETWORK3.EXE).
  2117.  
  2118.   If the software cannot be modified to handle these steps,
  2119.   it is probably best to use a front-end such as Front Door
  2120.   or Binkleyterm, then set up events that would run the
  2121.   shell for making the network calls and processing.
  2122.  
  2123.   The trickiest part is exporting messages from the BBS to
  2124.   a WWIV network file.  Possibly the easiest way to pack
  2125.   new messages is to have the BBS write them out to Fido
  2126.   packets (if the BBS is Fido-compatible), then when
  2127.   control returns to the front end, run an event that
  2128.   converts the Fido packet to a WWIV mail file.  When doing
  2129.   this, keep in mind that WWIV networks do not have all of
  2130.   the fields a WWIV packet does, most notably the "To:"
  2131.   field.
  2132.  
  2133.   Another method could be a program that, after the BBS
  2134.   returns control to the front end, scans the BBS's message
  2135.   bases for new messages on the WWIVnet subboards.  This
  2136.   would work best for BBS programs that cannot export Fido
  2137.   messages.  In either case, it is important that the
  2138.   netmail file processor analyze the outgoing message file
  2139.   (P*.NET) for tossing into the various connection files
  2140.   (S*.NET and Z*.NET).
  2141.  
  2142.   Of course, the optimal solution, if possible, would be to
  2143.   modify the BBS software to export the messages directly
  2144.   into a WWIVnet compatible mail file, and run the other
  2145.   network programs as needed without the shell.
  2146.  
  2147.   This is probably be a good time to discuss the naming of
  2148.   the incoming and pending netmail files, mentioned in step
  2149.   2 above. The actual name of the P*.NET can vary,
  2150.   depending on NETxx version and what program generates it.
  2151.   NETWORK.EXE in older NETxx versions (NET33 and below)
  2152.   receive the netmail file as P1.NET, while the one in
  2153.   NET34 receives the file as P1-0-1.NET. The "-0" in the
  2154.   middle indicates that NETWORK.EXE created the file (think
  2155.   of it as NETWORK0).  When other NET34 programs generate
  2156.   pending netmail files, the middle number indicates which
  2157.   program created it (NETWORK2.EXE, the local mail
  2158.   processor, would create a pending netmail file named
  2159.   P1-2-1.NET).  The main reason for this new naming system
  2160.   is so that we can tell the source of a P*.NET file being
  2161.   processed by the netmail analyzer.
  2162.  
  2163.   The WWIV BBS just creates P0.NET (network email,
  2164.  
  2165.                             -39-
  2166.  
  2167.  
  2168.  
  2169.   generally) and P1.NET (outggoing sub posts, generally).
  2170.   WWIV 4.23 also creates a PGATE.NET file, which contains
  2171.   posts for "gated" subs (that is, subs which are carried
  2172.   on more than one network).  WWIV 4.24 does not use
  2173.   PGATE.NET for gated messages.  Multi-instance WWIV 4.23
  2174.   and above setups create P*.nnn (where 'nnn' is the
  2175.   instance number, such as P*.001 for instance 1) while a
  2176.   user is online, but they are renamed to P*.NET after the
  2177.   user logs off.
  2178.  
  2179.   The NETWORK1.EXE processes all of the P*.NET files, until
  2180.   none are left, before converting any indicated
  2181.   S<sysnum>.NET files into compressed Z<sysnuum>.NET files
  2182.   (see Appendix A).  It is important that an alternate
  2183.   netmail file analyzer be able to recognize and handle any
  2184.   P*.NET file, not just Pn.NET.
  2185.  
  2186.  
  2187.  B.   WWIVnet Software Add-ons
  2188.  
  2189.   There are two possible types of add-ons supported by the
  2190.   WWIVnet software, both working with the local mail
  2191.   processor.
  2192.  
  2193.   The external message processors (or "post-processors")
  2194.   are described above in the main_type descriptions.  As
  2195.   noted above, it is recommended that any post-processor be
  2196.   written to be compatible with main_type 27, because it
  2197.   provides an easier interface for external messages.
  2198.   Again, a full description of how to use the external
  2199.   message feature is provided in the WWIVnet Software
  2200.   Documentation written by Filo.
  2201.  
  2202.   A common use for external messages is what is known as a
  2203.   "ping," used by the authors of some WWIV network
  2204.   utilities who wish to gain some information about the use
  2205.   of their software.  The author sends out a main_type 27
  2206.   message with the minor_type they are using.  If a
  2207.   receiving system is using the software and it is
  2208.   installed properly, it will execute after local mail
  2209.   processing, and process the request in the external
  2210.   message.
  2211.  
  2212.   The local mail processor also supports use of
  2213.   "pre-processors," generally used to scan the local mail
  2214.   file for certain types of messages before the local mail
  2215.   processor gets to it.  One example is JAFO's AUTOSEND,
  2216.   which looks for sub requests and sends out messages from
  2217.  
  2218.                             -40-
  2219.  
  2220.  
  2221.  
  2222.   the system's subs to new subscribers.  These, also, are
  2223.   described in the WWIVnet Software Documentation.
  2224.  
  2225.   Naturally, any external message processor or preprocessor
  2226.   that generates new outgoing network messages must put
  2227.   them into a P*.NET file so that NETWORK1.EXE can find it
  2228.   and process it.
  2229.  
  2230. APPENDIX A
  2231.  
  2232. MAIL PACKET COMPRESSION
  2233.  
  2234.  In order to write WWIVnet software that can deal with
  2235.  compressed mail packets, you must have the PKWare
  2236.  Compression Libraries, available from PKWare, Inc. for
  2237.  $300.00.  This Appendix covers the necessary details for
  2238.  handling compressed mail packets.  To make the explanation
  2239.  easier, how NETWORK1 from NET34 handles compressed files
  2240.  will be explained.
  2241.  
  2242.  When NETWORK1 analyzes the file of messages to go out on
  2243.  the network (P*.NET), they are placed in Sxxxx.NET files
  2244.  (where xxxx corresponds to the numbers of systems in the
  2245.  CALLOUT.NET).  After processing of all P*.NET files,
  2246.  NETWORK1 checks to see which connections accept compressed
  2247.  files.  For each that does, its Sxxxx.NET is compressed
  2248.  with the implode() function from the PKWare libraries.
  2249.  The compressed data is appended to the corresponding
  2250.  Zxxxx.NET file (which is created if it does not exist).
  2251.  The size of the compressed segment in Zxxxx.NET is then
  2252.  checked against the size of the Sxxxx file.  If the
  2253.  compressed segment is smaller than the original file, the
  2254.  file header and segment header (see below) are updated and
  2255.  Zxxxx.NET is closed. If the compressed file is the same
  2256.  size or larger than the uncompressed file, the
  2257.  uncompressed version is appended to the Zxxxx.NET
  2258.  (overwrit ing the compressed version), then the headers
  2259.  are updated and the file closed.  Whether the original
  2260.  Sxxxx.NET was compressed or not, it is deleted after it is
  2261.  transferred to the Zxxxx.NET.
  2262.  
  2263.  Thus, while an uncompressed netmail file is simply a
  2264.  collection of message packets with their headers, the
  2265.  compressed netmail file is a collection of segments which
  2266.  contain one or more messages, either compressed or not.
  2267.  The file has a ten byte header, and each segment within
  2268.  the file has a five byte header.
  2269.  
  2270.  
  2271.                             -41-
  2272.  
  2273.  
  2274.  
  2275.  The netmail file header has three elements: compression
  2276.  identifier -- long int (4 bytes) Always set to 0xfffefffe.
  2277.  
  2278.  extra bytes -- unsigned short int (2 bytes)
  2279.  
  2280.       Number of additional bytes in the header record,
  2281.       being the sum of the bytes in all fields following .
  2282.       This is to allow for future expansion of the header
  2283.       while maintaining compatibility with older versions
  2284.       of the NETxx software.  Currently, this should have
  2285.       the value of 4.
  2286.  
  2287.  uncompressed bytes -- long int (4 bytes)
  2288.  
  2289.       Length of the file when it is uncompressed.  This
  2290.       gets updated each time a new segment is added to the
  2291.       compressed file.
  2292.  
  2293.  The header on each segment of the compressed file has two
  2294.  elements: compression flag -- char (1 byte)
  2295.  
  2296.       Set to 0 if segment is NOT compressed, 1 if it is.
  2297.  
  2298.  segment length -- long int (4 bytes)
  2299.  
  2300.       Set to the actual length of the segment, in bytes.
  2301.  
  2302.  When a netmail file is received, NETWORK1 reads the first
  2303.  four bytes. If they are 0xfffefffe, it knows the file is
  2304.  compressed, so it decompresses it before processing the
  2305.  messages.  The first ten bytes are read in order to get
  2306.  the uncompressed length of the file.  Then for each
  2307.  segment, these steps are followed:
  2308.  
  2309.  1.   The segment header is read in, to see if the segment
  2310.       is com pressed and how long the segment is.
  2311.  
  2312.  2.   If the segment is compressed, it is decompressed into
  2313.       a temporary netmail file (which is created for the
  2314.       first segment, and appended for each additional
  2315.       segment) using PKWare's 'explode()' function.  If it
  2316.       is NOT compressed, it is written directly to the
  2317.       temporary netmail file.
  2318.  
  2319.  Once all segments have been decompressed or written to the
  2320.  temporary netmail file, the original netmail file is
  2321.  deleted and the temporary netmail file is renamed to the
  2322.  original's name.  NETWORK1 then processes message packets
  2323.  
  2324.                             -42-
  2325.  
  2326.  
  2327.  
  2328.  the new uncompressed netmail file.
  2329.  
  2330. COMPRESSION SOURCE CODE
  2331.  
  2332.  The following code is provided to help simplify the
  2333.  process of writing code for complete compatibility with
  2334.  the WWIVnet software.  It is the same as what is used by
  2335.  NETWORK1.EXE in NET34.  It covers both the compression and
  2336.  decompression of netmail packets.  Comments have been
  2337.  added by WH in order to clarify what's happening.  Some
  2338.  lines are split due to space.
  2339.  
  2340.  /* Description of global variables used here:
  2341.   *   (long) nbw --  number of bytes written
  2342.   *   (long) nbr --  number of bytes read
  2343.   *   (long) nbl --  number of bytes left (to read/write)
  2344.   *   (int) fi --    input file handle
  2345.                      (set to "S[sysnum].NET")
  2346.   *   (int) fo --    output file handle
  2347.                      (set to "Z[sysnum].NET" for
  2348.                      compression, "TEMP.NET" for
  2349.                       decompression)
  2350.   *   (char) net_data -- path to system's network data
  2351.                          directory
  2352.   * The rest should be obvious from their use.
  2353.   */
  2354.  
  2355.  
  2356.  unsigned far pascal net_read(char far *buff,
  2357.                              unsigned short int far *size)
  2358.  /* used
  2359.  {
  2360.    unsigned br=0,sz;
  2361.    unsigned pct,i;
  2362.  
  2363.    sz=*size;
  2364.    if ((long)sz>nbl)
  2365.      sz=(unsigned)nbl;
  2366.  
  2367.    br=read(fi,buff,sz);
  2368.  
  2369.    if (br<0)
  2370.      br=0;
  2371.  
  2372.    nbr += br;
  2373.    nbl -= br;
  2374.    nc_sf += br;
  2375.  
  2376.  
  2377.                             -43-
  2378.  
  2379.  
  2380.  
  2381.    return(br);
  2382.  }
  2383.  
  2384.  
  2385.  void far pascal net_write(char far *buff,
  2386.                            unsigned short int far *size)
  2387.  {
  2388.    write(fo,buff,*size);
  2389.    nbw += *size;
  2390.  }
  2391.  
  2392.  
  2393.  void net_compress(unsigned int sn)
  2394.  {
  2395.    char s[81], s1[81], fl;
  2396.    long l,l1;
  2397.    char *buf;
  2398.    unsigned short int type, dsize, xx;
  2399.  
  2400.    /* set up the input (Sxxxx.NET) and output (Zxxxx.NET)
  2401.     filenames */
  2402.  
  2403.    sprintf(s,"%sS%u.net",net_data, sn);
  2404.    sprintf(s1,"%sZ%u.net",net_data, sn);
  2405.  
  2406.    /* open the input file, if possible */
  2407.    fi=open(s,O_RDWR | O_BINARY);
  2408.    if (fi<0) {
  2409.      return;
  2410.    }
  2411.  
  2412.    buf=malloc(35256);
  2413.    if (!buf) {
  2414.      printf("\r    Not enough mem to compress    \r");
  2415.      return;
  2416.    }
  2417.  
  2418.    /* open the output file, if there is one */
  2419.    /*note the following line with CAPS in it should be
  2420.     all one line */
  2421. fo=open(s1,O_RDWR | O_BINARY | O_CREAT,
  2422.    S_IREAD | S_IWRITE);
  2423.    if (fo<0) {
  2424.      close(fi);
  2425.      free(buf);
  2426.      return;
  2427.    }
  2428.    /* write file header if file is new */
  2429.  
  2430.                             -44-
  2431.  
  2432.  
  2433.  
  2434.    if (filelength(fo)==0) {
  2435.      /* compression identifier */
  2436.      l=0xfffefffe;
  2437.      write(fo,&l,4);
  2438.      /* extra bytes in header */
  2439.      xx=4;
  2440.      write(fo,&xx,2);
  2441.      /* uncompressed bytes (initalized to 0) */
  2442.      l=0L;
  2443.      write(fo,&l,4);
  2444.    }
  2445.  
  2446.    /* prepare for new segment */
  2447.    nbw=nbr=0;
  2448.    l=filelength(fo);
  2449.    lseek(fo,l,SEEK_SET);
  2450.    l1=filelength(fi);
  2451.    nbl=l1;
  2452.    fl=1;             /* compresssion flag (compressed) */
  2453.    /* write compression flag and segment length to segment
  2454.     header */
  2455.    write(fo,&fl,1);
  2456.    write(fo,&nbw,4);
  2457.    type=CMP_ASCII;
  2458.    if (l1<1024)
  2459.      dsize=1024;
  2460.    else if (l1<2048)
  2461.      dsize=2048;
  2462.    else
  2463.      dsize=4096;
  2464.  
  2465.    /* compress the file */
  2466.    implode(net_read, net_write, buf, &type, &dsize);
  2467.  
  2468.    if (nbw>=nbr) {
  2469.      /* if it didn't compress */
  2470.      lseek(fo,l,SEEK_SET);
  2471.      lseek(fi,0L,SEEK_SET);
  2472.      fl=0;
  2473.      /* change segment header (flag off, seg length is
  2474.       input length */
  2475.      write(fo,&fl,1);
  2476.      write(fo,&nbr,4);
  2477.      /* then write input file to output file (overwrite
  2478.       compressed) */
  2479.      xx=read(fi,buf,32768);
  2480.      while (xx>0) {
  2481.        write(fo,buf,xx);
  2482.  
  2483.                             -45-
  2484.  
  2485.  
  2486.  
  2487.        xx=read(fi,buf,32768);
  2488.      }
  2489.      chsize(fo,l+5+nbr);
  2490.    } else {
  2491.      /* if compressed, write compressed seg length to
  2492.       segment header */
  2493.      lseek(fo,l+1,SEEK_SET);
  2494.      write(fo,&nbw,4);
  2495.    }
  2496.  
  2497.    /* update output file header (change uncompresssed
  2498.     bytes) */
  2499.    lseek(fo,6,SEEK_SET);
  2500.    read(fo,&l,4);
  2501.    l += nbr;
  2502.    lseek(fo,6,SEEK_SET);
  2503.    write(fo,&l,4);
  2504.  
  2505.    bytes_comp=filelength(fo);
  2506.    bytes_uncomp=l;
  2507.    /* compute percentage of compression */
  2508.    if (bytes_comp<bytes_uncomp)
  2509. xx=(unsigned) ((bytes_uncomp-bytes_comp)*100/bytes_uncomp);
  2510.    else
  2511.      xx=0;
  2512.  
  2513.    /* clean up */
  2514.    close(fi);
  2515.    close(fo);
  2516.    unlink(s);
  2517.    free(buf);
  2518.  }
  2519.  
  2520.  
  2521.  void net_uncompress(char *fn)
  2522.  /* 'fn' is the name (with path) of the P*.NET file being
  2523.   processed */
  2524.  {
  2525.    char s[81],fl;
  2526.    long l,l1;
  2527.    unsigned xx;
  2528.    char *buf;
  2529.  
  2530.    /* set up output filename (temporary netmail file) */
  2531.    sprintf(s,"%sTEMP.NET",net_data);
  2532.  
  2533.    buf=malloc(16384);
  2534.    if (!buf) {
  2535.  
  2536.                             -46-
  2537.  
  2538.  
  2539.  
  2540.      printf("\r    Not enough mem to uncompress  \r");
  2541.      return;
  2542.    }
  2543.  
  2544.    /* Zxxxx.NET, if possible */
  2545.    fi=open(fn,O_RDWR | O_BINARY);
  2546.    if (fi<0) {
  2547.      free(buf);
  2548.      return;
  2549.    }
  2550.  
  2551.    /* open output file */
  2552. fo=open(s,O_RDWR | O_BINARY | O_CREAT | O_TRUNC, S_IREAD |
  2553.            S_IWRITE);
  2554.    if (fo<0) {
  2555.      close(fi);
  2556.      free(buf);
  2557.      return;
  2558.    }
  2559.  
  2560.    /* get file header */
  2561.    lseek(fi,4,SEEK_SET);            /* compression
  2562.                                        identifier */
  2563.    read(fi,&xx,2);                  /* extra bytes */
  2564.    read(fi,&bytes_uncomp,4);        /* uncompressed
  2565.                                             bytes */
  2566.    bytes_comp=filelength(fi);
  2567.    lseek(fi,6+xx,SEEK_SET);
  2568.    l=bytes_comp-(6+xx);             /* compute
  2569.                                        compressed bytes */
  2570.  
  2571.    /* decompression pass */
  2572.    while (l>0) {
  2573.      /* get segment header */
  2574.      read(fi,&fl,1);                /* compression flag */
  2575.      read(fi,&l1,4);                /* segment length (in
  2576.                                        bytes) */
  2577.      nbr=nbw=0;
  2578.      nbl=l1;
  2579.      if (fl==0) {
  2580.  /* if segment not compressed, write directly to temporary
  2581.   * netmail file */
  2582.        if (nbl>16384)
  2583.          xx=read(fi,buf,16384);
  2584.        else
  2585.          xx=read(fi,buf,(unsigned)nbl);
  2586.        while (nbl>0) {
  2587.          write(fo,buf,xx);
  2588.  
  2589.                             -47-
  2590.  
  2591.  
  2592.  
  2593.          nbl -= (long)xx;
  2594.          if (nbl>16384)
  2595.            xx=read(fi,buf,16384);
  2596.          else
  2597.            xx=read(fi,buf,(unsigned)nbl);
  2598.        }
  2599.      } else {
  2600. /* if segment compressed, decompress to temp
  2601.  * netmail file */
  2602.        explode(net_read, net_write, buf);
  2603.      }
  2604.      l -= (l1+5);
  2605.    }
  2606.  
  2607.    /* clean up */
  2608.    close(fi);
  2609.    close(fo);
  2610.    unlink(fn);
  2611.    rename(s,fn);       /* rename temp filename to P*.NET */
  2612.    free(buf);
  2613.  }
  2614.  
  2615.  
  2616.  
  2617.  
  2618.  
  2619.  
  2620.  
  2621.  
  2622.  
  2623.  
  2624.  
  2625.  
  2626.  
  2627.  
  2628.  
  2629.  
  2630.  
  2631.  
  2632.  
  2633.  
  2634.  
  2635.  
  2636.  
  2637.  
  2638.  
  2639.  
  2640.  
  2641.  
  2642.                             -48-
  2643.  
  2644.