home *** CD-ROM | disk | FTP | other *** search
/ ftp.wwiv.com / ftp.wwiv.com.zip / ftp.wwiv.com / pub / WW4SHARE / NET37.ZIP / NET37TEC.DOC < prev    next >
Text File  |  2000-03-06  |  93KB  |  2,634 lines

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