home *** CD-ROM | disk | FTP | other *** search
/ ftp.wwiv.com / ftp.wwiv.com.zip / ftp.wwiv.com / pub / MISC / LN2V110.ZIP / TECHNOTE.TXT < prev   
Text File  |  2000-01-09  |  22KB  |  408 lines
  1.  
  2.  
  3.  
  4. ┌───────────────────────────────────────────────────────────────────── ┌┬┐┌┬┬┐┌┐
  5. │░ LNET-II v1.10 TECHNICAL NOTES ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ │├┤│├┤│││
  6. └───────────────────────────────────────────────────────────────────── └┴┘└┘└┘└┘
  7.  
  8. ╔════════════════╗ LNET-II is written in Microsoft PDS [Professional Development
  9. ║ PROGRAM SOURCE ║ System] v7.1, a high-powered variant of QuickBASIC.  The ANSI
  10. ╚════════════════╝ decoder is a heavily modified version of Tom Hanlin's ANSI-
  11. print() routine from the BASWIZ library.  LNET-II's GUI screens were designed in
  12. TheDraw and QEdit and are displayed using a method created by CMI Software.  All
  13. user interface code was written by CMI Software; no "user interface toolboxes"
  14. were used in the creation of this program.
  15.  
  16. The source code is 15,217 working lines [non-blank, non-comment] in 23 files
  17. occupying 554.9K.  Development of v1.00 was started on 09/27/1996.  Some core
  18. portions, such as the packet pre-scan and item validation algorithms, were
  19. borrowed from the Dead-Fix v2.30 [unreleased] source code.
  20.  
  21. ╔═════════════════════╗ LNET-II is compiled and linked with 16 of its 22 .BAS
  22. ║ MEMORY REQUIREMENTS ║ modules in overlays.  While this increases the size of
  23. ╚═════════════════════╝ the .EXE file, it also significantly reduces the pro-
  24. gram's conventional memory requirements - the basic RAM requirement is only
  25. about 260K before the program allocates its data space.  If you have EMS/XMS,
  26. the overlays [and certain data] will be loaded into high RAM and called as
  27. needed.  If you have only 640K RAM, or no EMS/XMS driver loaded, overlays will
  28. be swapped in and out of conventional RAM from disk.  Please note, though, that
  29. this will slow the program down somewhat, so EMS/XMS is highly recommended.
  30.  
  31. LNET-II reads header data for only one item at a time, so even the largest
  32. packets can be handled with very little memory overhead.  Items' locations
  33. within the packet are stored in a temporary index file, eliminating the need to
  34. index the entire packet in memory.  By creating an index, LNET-II is able to
  35. perform extremely fast access of individual items within a packet.  This does,
  36. however, require some temporary HD space overhead - 15 bytes per item are used
  37. to create the index.  A packet's index file is deleted when the packet is
  38. closed.  Index files are named *.LN2 [i.e. DEAD.NET -> DEAD.LN2].  These files
  39. are written in the current BBS instance's TEMP directory.
  40.  
  41. Occasionally, the text of a message might be too large to display.  The PDS
  42. language limits individual strings to 32767 bytes.  LNET-II will never attempt
  43. to display messages larger than 32767 bytes; however, some processes internal to
  44. LNET-II may overrun the program's allocated string space.  [Unlike C, the PDS
  45. language doesn't have the low-level memory control functions necessary to
  46. dynamically allocate string space, although it can do so for array space.  This
  47. limitation is probably one of the few leftovers from the older versions of MS
  48. BASIC.]  When an item is too large to display, LNET-II recovers from the error
  49. by aborting the text display process.  An error message will indicate that the
  50. item cannot be displayed.
  51.  
  52. When an item's text is being displayed, LNET-II first closes the packet [which
  53. is opened in BINARY mode], reopens it in INPUT mode, counts the number of lines
  54. in the item's text, reads and displays the item one line at a time [using the
  55. BASIC 'LINE INPUT' function], then closes the packet and reopens it in BINARY
  56. mode.  Although this may sound unnecessarily complicated, it actually makes it
  57. easier to handle the item, because it eliminates the need to read the entire
  58.  
  59. ───────────────────┤ LNET-II v1.10 Technical Notes - Page 1 ├───────────────────
  60.  
  61.  
  62.  
  63. message into memory as one big block [which can EASILY overrun the available
  64. string space].  Reading one line at a time makes it far less likely that the
  65. program's string space will be overrun, but there still may be cases when an
  66. individual line of text is too long to handle.  This is most likely to happen
  67. when trying to view binary data, such as DE* encrypted items, and when viewing
  68. extremely long lines of ANSI data.
  69.  
  70. The /LOMEM option reduces LNET-II's memory requirements by causing the program
  71. not to load certain data.  However, LNET-II may still occasionally exhibit
  72. unusual behavior if the amount of available memory is extremely low.  If you
  73. have limited memory and LNET-II operates improperly even with /LOMEM active, try
  74. to make more memory available, then run the program again.
  75.  
  76. Because the PDS language limits arrays to no more than 32,767 subscripts [indi-
  77. vidual elements of an array's rows or columns], LNET-II cannot handle networks
  78. with more than 32,767 nodes.  However, this is EXTREMELY unlikely to occur at
  79. any time - as we all know, many nets are shrinking in the face of Internet
  80. competition, and those few nets which are growing are not doing so at a rate
  81. which will ever give them this many systems.  LNET-II will recognize node
  82. numbers up to @65535, but it cannot handle more than 32,767 total nodes in a
  83. network.  In the unlikely event that LNET-II needs to handle a network with more
  84. than 32,767 individual nodes, please contact the author [see page 58 of the user
  85. manual LN2V110.DOC] - although it would be somewhat difficult, a patch could
  86. probably be made to allow up to 65,535 nodes in a network.
  87.  
  88. ╔══════════════╗ The largest packet readable by LNET-II is 2,147,483,647 bytes
  89. ║ PACKET SIZES ║ [(2^31)-1].  This is because the PDS language uses SIGNED LONG
  90. ╚══════════════╝ values for file access.  Since the smallest possible single
  91. WWIV network item is 24 bytes - the length of the network header structure -
  92. this packet could contain up to 89,478,485 items.  The largest possible valid
  93. non-deleted item is 24 + 8192 + 32767 bytes [40,983 total], so this packet could
  94. contain no less than 52,399 non-deleted items.  [See LN2V110.DOC for item
  95. validation specifications.]  A single deleted item can occupy the entire length
  96. of a packet, regardless of the packet's size; these items are not subject to the
  97. WWIV 32K limit.
  98.  
  99. ╔══════════════╗ LNET-II is compiled as a DOS real-mode application.  At this
  100. ║ FILE LOCKING ║ time, it has been successfully tested under MS-DOS 6.22,
  101. ╚══════════════╝ Windows 3.11, Windows 95 / MS-DOS 7.00, Windows 98, Novell Net-
  102. Ware Lite, and OS/2 Warp.  The program includes routines which help make it
  103. compatible with multi-instance BBS systems by locking write access [and, in some
  104. cases, read access] of currently open files.  Locks are released when LNET-II
  105. closes files.  The availability of file locking is automatically detected via a
  106. call to DOS interrupt service 2Fh.  The packet currently being read is held open
  107. and locked.  The same applies to the packet's temporary index file.  Because of
  108. this, the same packet cannot be opened simultaneously by two instances of
  109. LNET-II, and no other process will be able to read/write the open packet until
  110. LNET-II closes it and releases its locks.
  111.  
  112.  
  113.  
  114.  
  115.  
  116.  
  117. ───────────────────┤ LNET-II v1.10 Technical Notes - Page 2 ├───────────────────
  118.  
  119.  
  120.  
  121. Files are never held open when they are not needed.  With the exception of the
  122. currently loaded packet and its index file, most files will be open and locked
  123. only for a fraction of a second while they are being read or written.  LNET-II's
  124. file locking is designed to prevent interference with other processes as much as
  125. possible.
  126.  
  127. When running LNET-II under multi-tasking operating systems with their own
  128. internal file locking services, it is not necessary to have SHARE.EXE loaded.
  129. SHARE.EXE is usually not needed if your BBS is being run as a single-node system
  130. under DOS; it is used mostly for DOS-based LAN environments.  [Note: If you use
  131. WWIV's /I# parameter when loading the BBS, and you are NOT in a multi-tasking
  132. environment, you will need to have SHARE.EXE loaded.  WWIV will insist on it.]
  133.  
  134. ╔══════════════════╗ During development and beta testing, one of the testers
  135. ║ THE /NOHI SWITCH ║ reported that his system was locking up immediately after
  136. ╚══════════════════╝ LNET-II had displayed the opening logo.  I examined the
  137. source code for a possible cause, and on a hunch, I added the /NOHI command line
  138. switch to disable all detection and use of high-resolution text modes.  [This
  139. tester had also mentioned something about not being able to use high-resolution
  140. text modes in LNET-II.  He is running Windows 95.]  For some reason, which I am
  141. completely at a loss to explain, the video mode detection process caused the
  142. beta tester's system to lock up after it had displayed the opening logo.  By
  143. disabling the video mode detection process and forcing 25-line displays with the
  144. /NOHI switch, his lockups were eliminated.  None of the other beta testers ever
  145. encountered this problem, and I have not encountered it since I installed Win95
  146. on my system either.  Go figure.
  147.  
  148. LNET-II detects high-resolution text modes by attempting to switch the display
  149. into those modes, then checking to see whether an internal error code is gene-
  150. rated.  If there is no error after a mode is tried, LNET-II considers that mode
  151. to be available.  The video mode detection process may cause a very brief period
  152. of visible display blinking just before the opening CMI Software logo is shown
  153. [after the initial loading messages are printed to the DOS screen].  This is a
  154. normal side-effect of switching from one display mode to another; on a VGA
  155. display, up to three different modes may be accessed.
  156.  
  157. See the user manual LN2V110.DOC for further details on the /NOHI switch.
  158.  
  159. ╔═══════════════════╗ LNET-II properly recognizes the full range of possible
  160. ║ HIGH NODE NUMBERS ║ WWIV node numbers, from @1 to @65535.  It has been brought
  161. ╚═══════════════════╝ to my attention that some packet readers do not properly
  162. display node numbers over @32767, probably because they are treating node num-
  163. bers as signed integers.  LNET-II does not have this problem; all node numbers
  164. are treated as UNSIGNED values when they are being displayed.
  165.  
  166. Networks using my 65-region node numbering system might have problems with high
  167. node numbers when using other packet readers or network utilities.  [E-mail me
  168. for details on my node numbering system.  It is currently in use on DigiNet and
  169. will also be used eventually on USLink if I ever decide to put myself through
  170. the torture of renumbering the network.]
  171.  
  172.  
  173.  
  174.  
  175. ───────────────────┤ LNET-II v1.10 Technical Notes - Page 3 ├───────────────────
  176.  
  177.  
  178.  
  179. ╔═════════════════════════════╗ Development of LNET-II was assisted by the
  180. ║ WWIV NETWORK TECHNICAL DATA ║ WW4NTECH technical manual for WWIV networking,
  181. ╚═════════════════════════════╝ written by Midnight Tree Bandit.  This file is
  182. widely available; Midnight Tree Bandit's system is The Many Titled Board at
  183. 804-288-8630.  WW4NTECH contains far more detail than is necessary for this
  184. document - I recommend reading WW4NTECH if you really want to get into the nuts-
  185. and-bolts of WWIV networking and packet layout.
  186.  
  187. I would also like to thank Wayne Bell, Dean Nash, JAFO, Deltigar, Oderus
  188. Urungus, and Tom Lake for supplying other information used in the development of
  189. LNET-II.
  190.  
  191. ╔═════════════╗
  192. ║ TERMINOLOGY ║ The LNET-II documentation uses various terms to refer to packets
  193. ╚═════════════╝ and their contents.  Basically, they are:
  194.  
  195. PACKET: A collection of individual messages, or items, formatted into a single
  196. file.  Some packets may be compressed by NETWORK1.EXE, using a subset of the
  197. PKWARE compression library; however, they are not .ZIP files.  [WW4NTECH con-
  198. tains technical data and source code in C for calling PKWARE library functions
  199. in a WWIV packet handler.]  If a packet is compressed, the first item in the
  200. packet will have TOSYS and TOUSER values of 65534 [or -2 if you are reading the
  201. numbers as signed integers].  If the first four bytes of the packet are FE FF FE
  202. FF in hex, the packet is considered to be compressed.  Compressed packets are
  203. usually named Z*.NET.
  204.  
  205. ITEM: A single message within a packet.  This includes the item's HEADER, its
  206. DESTINATION LIST [if any], and its TEXT SEGMENT [if any].  Every item must have
  207. a HEADER.  Destination lists are optional on most items and prohibited on a few
  208. items [such as e-mails].  Some items do not need a text segment.
  209.  
  210. HEADER: 24 bytes of data at the start of every item, indicating what kind of
  211. message it is, where it's from, where it's going, when it was created, how large
  212. it is, and whether it is encrypted.  The header contains the following data:
  213.  
  214.     TOSYS: The destination system of the message.  This will be zero if the item
  215.     has multiple destinations; in this case, the HEADER is immediately followed
  216.     by the DESTINATION LIST [a series of two-byte integer values representing
  217.     node numbers] and the LISTLEN field contains a count of the number of nodes
  218.     which are to receive copies of the message.
  219.  
  220.     TOUSER: The WWIV user number of the person who is to receive the message.
  221.     Generally relevant only for e-mails and SSM's.
  222.  
  223.     FROMSYS: The system which originated the message.  In gated e-mails, this
  224.     will be the number of the node which gated the mail into the current
  225.     network.
  226.  
  227.     FROMUSER: The WWIV user number of the person who wrote the message.  Some-
  228.     times this is #0 to indicate a message from the net software - or from
  229.     another utility - to the sysop, or to indicate a type 7 e-mail-by-name.
  230.  
  231.  
  232.  
  233. ───────────────────┤ LNET-II v1.10 Technical Notes - Page 4 ├───────────────────
  234.  
  235.  
  236.  
  237.     MAIN TYPE: Each item has a number [currently in the range 1 to 28] indi-
  238.     cating the purpose of the item.  For instance, MAIN TYPE 2 is a standard
  239.     e-mail from one user to another on the current network.  The main type is
  240.     set to 65535 when an item has been deleted from a packet.  See LN2V110.DOC
  241.     for a detailed listing of allocated main and minor types.
  242.  
  243.     MINOR TYPE: Further identifies the purpose of an item.  For instance, MAIN
  244.     TYPE 3 is a post from a sub's host system to its subscribers, and MINOR TYPE
  245.     12345 would indicate that the post belongs to sub type 12345.  Main and
  246.     minor types are often shown together - for instance, 5/10 would be main type
  247.     5, minor type 10.  Minor types are rarely or never displayed alone.
  248.  
  249.     LISTLEN: Indicates how many nodes, if any, are in the item's DESTINATION
  250.     LIST.  When ListLen is non-zero, ToSys is should be zero.  Some items cannot
  251.     have multiple destinations; their ListLen values must be zero.
  252.  
  253.     DATEN: A four-byte value which indicates the date and time of an item's
  254.     origin.  It is calculated in seconds since midnight on 01/01/1970.  The
  255.     daten format originated on UNIX systems.
  256.  
  257.     LENGTH: A four-byte value indicating the size of an item's TEXT SEGMENT.  It
  258.     does not include the size of the DESTINATION LIST.  A deleted item [main
  259.     type 65535] may occupy the entire length of a packet; non-deleted items are
  260.     currently limited per WWIV network specifications to 32,767 bytes of text.
  261.  
  262.     METHOD: Some items are encrypted and/or require a call to an external
  263.     program in order to handle them.  EN*.EXE - where '*' represents the method
  264.     number - is used to encode an item, and DE*.EXE is used to decode it.  For
  265.     instance, an item with method 123 would be encoded by EN123.EXE and decoded
  266.     by DE123.EXE.  All items may be Method<>0; some require Method<>0.  The
  267.     encoder is called by NETWORK1.EXE when an item having Method<>0 is being
  268.     analyzed and prepared to go out from the originating system.  The decoder is
  269.     called by NETWORK2.EXE while the LOCAL.NET packet is being unpacked.
  270.  
  271. DESTINATION LIST: If an item is going to more than one node, the HEADER will be
  272. followed by a series of data - two bytes per node - listing all of the nodes
  273. which are to receive copies of the item.  This is also referred to as "stacking"
  274. an item.  When an item is stacked, TOSYS should be 0 and LISTLEN will indicate
  275. the number of nodes in the destination list.
  276.  
  277. SUBHEADER: Additional data about certain items, used by third-party network
  278. utilities.  These follow the DESTINATION LIST and are seen by the net software
  279. [and by other programs which do not specifically recognize them] as simply the
  280. first 'x' bytes of the TEXT SEGMENT.
  281.  
  282. TEXT SEGMENT: The actual text of the message itself.  This follows the header,
  283. and is preceded by the DESTINATION LIST if the item is going to more than one
  284. node.  Certain types of items do not need text segments, since all data needed
  285. to process them is in the header.  The type 20/0 SUBS.INF 'ping' is a good
  286. example of this.
  287.  
  288.  
  289.  
  290.  
  291. ───────────────────┤ LNET-II v1.10 Technical Notes - Page 5 ├───────────────────
  292.  
  293.  
  294.  
  295. OPTIONAL LINES: Some messages contain lines which may or may not be shown to the
  296. person reading the message.  These lines will begin with a ^D [ASCII 4] charac-
  297. ter, followed by a digit from 0 to 9.  If the reader's "optional line" setting
  298. is equal to, or less than, the digit in the optional line's prefix, then that
  299. line will be shown to the reader.  [The BBS uses a value of 10 when a user does
  300. not want to see any optional lines; it never displays lines having a prefix of
  301. ^D0.  LNET-II can display all optional lines.]  If the reader has "optional
  302. lines" set to 5, then only those optional lines having prefixes of ^D5 through
  303. ^D9 will be displayed.  The routing stamps added to posts and e-mails [starting
  304. with NET33] have a prefix of ^D0.  Some mail utilities also use the ^D0 prefix
  305. to write a FIDO-style 'TO:' field.  Some editors write user signatures as
  306. optional lines with ^D9 prefixes, and write the BBS tags starting with ^D8 and
  307. working downward.
  308.  
  309. DELETED ITEMS: LNET-II usually regards an item as "deleted" when it originally
  310. had main type 65535 OR when it has been marked for deletion with the ALT+D,
  311. CTRL+D, or ALT+T commands.  When items are marked to be deleted by LNET-II, they
  312. do NOT have their main types changed to 65535; rather, LNET-II simply places a
  313. flag in the packet's index file, indicating that the item is to be deleted when
  314. the packet is rewritten.  The search features consider an item to be deleted
  315. only if it is main type 65535 - items marked for deletion are, technically, not
  316. yet deleted.  Items having main type 65535 cannot be undeleted by LNET-II.
  317.  
  318. NONEXISTENT NODES: LNET-II considers a node to be "nonexistent" when no data for
  319. it is found in the network's BBSDATA.NET file.  It is important to note that
  320. such nodes MIGHT actually exist but that the updates containing their data
  321. simply haven't reached your system yet.  LNET-II can display only the numbers of
  322. nonexistent nodes; it cannot display any BBS details for them.
  323.  
  324. ╔════════════════════════╗ WWIV Software Services has extensively reworked the
  325. ║ NEW NET37 SYSTEM FLAGS ║ BBSLIST.* system identifier flags and bitmaps for
  326. ╚════════════════════════╝ NET37.  Some of these identifiers keep the same flag
  327. characters [i.e. '&' to indicate the NC], but many obsolete identifiers have
  328. been reassigned for new purposes.  Essentially, all of the old flags indicating
  329. modem connection protocols [v.32, v.32bis, v.34, etc.] were deemed obsolete and
  330. reassigned for NET37.
  331.  
  332. Network analysis by NETWORK3.EXE uses these identifiers to set bitmaps in the
  333. networks' BBSDATA.NET files.  The constants used for these bitmaps have also
  334. been reworked.  Any utility which reads these bitmaps will need to be updated
  335. with new code to handle the NET37 flags.  This is why LNET-II must use two
  336. distinct BBS detail screens - virtually all of the bitmaps are different, old
  337. identifiers have been purged, and new identifiers have been added.  Only the
  338. '!' exclamation point and '~' tilde retain their original bitmap values in
  339. NET37, although they now serve new purposes.
  340.  
  341. The following page contains a chart of the system identifier characters, their
  342. purposes in NET36/prior and NET37, and the bitmap constants assigned to them.
  343.  
  344.  
  345.  
  346.  
  347.  
  348.  
  349. ───────────────────┤ LNET-II v1.10 Technical Notes - Page 6 ├───────────────────
  350.  
  351.  
  352.  
  353.                       ■ BBSLIST.* System Flags / Bitmaps ■
  354.  
  355.               ╔════════════════════════╤════════════════════════╗
  356.               ║       NET36/PRIOR      │          NET37         ║
  357.               ╟────────────────────────┼────────────────────────╢
  358.               ║ Flag  Purpose   Bitmap │ Flag  Purpose   Bitmap ║
  359.               ╟────────────────────────┼────────────────────────╢
  360.               ║ \     FIDO          1h │ $     Internet      1h ║
  361.               ║ |     Telebit       2h │ \     FIDO          2h ║
  362.               ║ <     USR           4h │ |     Telnet        4h ║
  363.               ║ >     HayesVS       8h │ <     NoLinks       8h ║
  364.               ║ ^     AC           10h │ >     FTS          10h ║
  365.               ║ !     v.32         20h │ !     Direct       20h ║
  366.               ║ $     v.32bis      40h │ /     Unreg        40h ║
  367.               ║ =     PCPursuit    80h │ ?     Fax          80h ║
  368.               ║ %     GC          100h │ _     EndNode     100h ║
  369.               ║ &     NC          200h │ +     Server      200h ║
  370.               ║ /     Compucom    400h │       Unused      400h ║
  371.               ║ +     Server      800h │ &     NC          800h ║
  372.               ║ ?     Fax        1000h │ %     GC         1000h ║
  373.               ║ _     EndNode    2000h │ ^     AC         2000h ║
  374.               ║ ~     v.34       4000h │ ~     SLC        4000h ║
  375.               ║       Unused     8000h │       Unused     8000h ║
  376.               ╚════════════════════════╧════════════════════════╝
  377.  
  378.  
  379.  
  380.  
  381.  
  382.  
  383.  
  384.  
  385.  
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394.  
  395.  
  396.  
  397.  
  398.  
  399.  
  400.  
  401.  
  402.  
  403.  
  404.  
  405.  
  406.  
  407. ───────────────────┤ LNET-II v1.10 Technical Notes - Page 7 ├───────────────────
  408.