home *** CD-ROM | disk | FTP | other *** search
/ ProfitPress Mega CDROM2 …eeware (MSDOS)(1992)(Eng) / ProfitPress-MegaCDROM2.B6I / BBS / NETMAIL / FTSC_ALL.ZIP / FSC-0047.001 < prev    next >
Encoding:
Text File  |  1990-05-28  |  8.7 KB  |  232 lines
  1. Document: FSC-0047
  2. Version:  001
  3. Date:     28-May-90
  4.  
  5.  
  6.  
  7.  
  8.          The ^ASPLIT Kludge Line For Splitting Large Messages
  9.  
  10.                              Pat Terry
  11.                             5:494/4.101
  12.                pat.Terry@p101.f4.n494.z5.fidonet.org
  13.                        pterry@m2xenix.psg.org
  14.    
  15.  
  16.  
  17.  
  18. Status of this document:
  19.  
  20.      This FSC suggests a proposed protocol for the FidoNet(r) community,
  21.      and requests discussion and suggestions for improvements.
  22.      Distribution of this document is unlimited.
  23.  
  24.      Fido and FidoNet are registered marks of Tom Jennings and Fido
  25.      Software.
  26.  
  27.  
  28.  
  29.  
  30.  
  31. Objectives
  32. ===========
  33.  
  34. Several packers place a limit on the size of message that can be
  35. transmitted.  This is often of the order of 14K which, while
  36. sufficient for most purposes, is inadequate for several
  37. applications, and in particular for long messages gated to and
  38. from UUCP land.
  39.  
  40. A SPLIT/UNSPLIT suite of two programs has been developed, intended
  41. to handle this problem.  SPLIT will split long .MSG format
  42. messages into smaller packets.  After transmission to a remote
  43. site, the packets may be merged by UNSPLIT to recreate the
  44. original message, as closely as possible.  The only differences
  45. are the addition of a kludge line and, possibly, a few line
  46. breaks.
  47.  
  48. The system ensures that each large message, when split, generates
  49. a collection of small messages, each of which is still valid in
  50. its own right.  If recombination is not effected, the messages
  51. will still be usefully received, and, in particular, split
  52. messages to UUCP should still all get to their destinations,
  53. albeit in parts.
  54.  
  55. After some weeks of testing, the system seems to be sufficiently
  56. stable and useful to justify making an FSC proposal.
  57.  
  58.  
  59.  
  60. The ^A SPLIT kludge line
  61. ========================
  62.  
  63. Messages split and joined by this system make use of an ^A kludge
  64. line, which has the form below.  It is proposed in this note that
  65. this become the basis for a "standard".
  66.  
  67. One of these lines is added to the list of kludges preceding each
  68. part of a split message.  When recombined, a line of this form
  69. remains, for reasons which will appear later.
  70.  
  71. Generically the lines look like this, in fixed columns:
  72.  
  73. ^ASPLIT: date      time     @net/node    nnnnn pp/xx +++++++++++
  74.  
  75. where
  76.       nnnnn gives the original message number from which the
  77.             components have been derived (cols 41 - 45)
  78.       pp    gives the part number (cols 47 and 48)
  79.       xx    gives the total number of parts (cols 50 and 51)
  80.  
  81. For example
  82.  
  83. ^ASPLIT: 30 Mar 90 11:12:34 @494/4       123   02/03 +++++++++++
  84.             |      |        |  |          |     |  |  |
  85.             |      |        @  |          |     |  |  |
  86.             Date   Time        Node       MSG   |  |  Eye catcher
  87.             (when split)  (of origin) (at time  |  Total parts
  88.                                       of split) Part number
  89.  
  90.  
  91. Thus a large file (existing as 123.MSG when the splitter was run)
  92. originating from 494/4 might be split into 3 parts with the split
  93. lines
  94.  
  95. ^ASPLIT: 30 Mar 90 11:12:34 @494/4       123   01/03 ++++++++++++
  96. ^ASPLIT: 30 Mar 90 11:12:34 @494/4       123   02/03 ++++++++++++
  97. ^ASPLIT: 30 Mar 90 11:12:34 @494/4       123   03/03 ++++++++++++
  98.  
  99. Columns 9 through 45 are really a "uniquefier".  The nnnnn
  100. message number is just the one the message had when it was split,
  101. and is of no other significance.  Similarly, the system does not
  102. use 4-d addressing for the node/net component, because this is of
  103. no real interest to this application, and requires parsing a file
  104. like BINKLEY.CFG, or similar extra work, to determine the other
  105. components.
  106.  
  107. This is, admittedly, verbose, but if recombination fails for any
  108. reason (like all the packets not arriving at once) one can still
  109. recombine or examine the relevant pieces manually.  Note also
  110. that the lines are added to messages that are themselves "long",
  111. and the *relative* increase in length is actually very small.
  112. Further justification will be found below.
  113.  
  114.  
  115. Splitting large messages
  116. ========================
  117.  
  118. When splitting large messages, the following happens:
  119.  
  120. The message base is scanned for large messages.
  121.  
  122. For each of the (few) large messages found that qualify, the
  123. large message is split into parts.  The original FTSC header is
  124. placed in each component part, save that the FileAttach bit (if
  125. any) is removed from the 2nd, 3rd ... parts.  No attempt is made
  126. to modify the To:, or From: fields.  The Subject: field for the
  127. 2nd, 3rd ... parts is modified to include a leading part number.
  128.  
  129. The original kludge lines are retained in the first part. Most
  130. other "leading" kludges, like ^AFMPT, ^ATOPT, ^AINTL are retained
  131. in these parts.  However, ^AEID and ^AMSGID lines, if any, are
  132. removed from the 2nd, 3rd ... parts.  This is potentially
  133. awkward, but is to avoid "dupe detectors" discarding the 2nd, 3rd
  134.  ... parts, and in practice should cause no real problems. Large
  135. echomail messages originating on a system will presumably have
  136. their ^AEID lines added to the constituent parts at
  137. scanning/packing time on that system (ie AFTER splitting), and
  138. other large messages should probably not reach this stage - they
  139. should have been split or discarded earlier.
  140.  
  141. A ^ASPLIT line is added to each part to allow for possible later
  142. recombination.
  143.  
  144. If the message is addressed "TO UUCP: in the FTSC header, the To:
  145. lines at the start of the message text are copied to all parts.
  146.  
  147. The "body" of the message is then split between the various
  148. parts.  An attempt is made to split at the end of a line in each
  149. case.
  150.  
  151. The trailing tear line, ^AVia ^APath etc lines are added to all
  152. parts.
  153.  
  154.  
  155. Joining ("unsplitting") messages
  156. ================================
  157.  
  158. When reconstituting large messages, the following happens:
  159.  
  160. The message base is scanned for messages with ^ASPLIT lines.
  161. A list is made of messages to be unsplit, with each message
  162. having a list of its component parts. If a duplicate component
  163. part is found, it is discarded (thus partially getting around the
  164. problem of any discarded ^AEID lines in the components).
  165. Messages marked "in transit" or "sent" are not eligible for
  166. recombination.  Nor are messages with a split component number of
  167. 00, as these will only exist as the result of an earlier
  168. recombination.
  169.  
  170. For each set of components of messages to be recombined the
  171. following happens:
  172.  
  173. The first component is examined so as to extract the Kludge
  174. lines, and any UUCP "To: " lines. These, and the FTSC header, are
  175. written out to a new file, with the ^ASPLIT line modified to have
  176. a component number of 00, so as to prevent further splitting
  177. should the splitter program be reapplied to the recombined
  178. message.  If this is not done, large messages can get into a
  179. tedious split-unsplit- split-unsplit... cycle each time the
  180. system is run.
  181.  
  182. The text portions of the first and subsequent parts are then
  183. merged (discarding extra copies of kludges, UUCP "To:" lines and
  184. the like).
  185.  
  186. Any tearline, Origin, ^APATH, ^AVia lines etc are appended.
  187.  
  188. Normally the component files are then automatically deleted.
  189.  
  190.  
  191. Justification for "human readable" uniquifier.
  192. ==============================================
  193.  
  194. Most systems do not display kludge lines, and the ^ASPLIT line
  195. should be of no real interest.  However, in one particular
  196. application which was using this system, the ^ASPLIT lines were
  197. made visible for messages that could not be recombined (because
  198. they become too large for gating from FidoNet to another RFC-822
  199. compliant network), and hence it has been deemed essential that a
  200. "visible" line derived from ^ASPLIT became human readable, easily
  201. spotted, and comprehensible.  For much the same reason, fixed
  202. columns have been used, rather than free format, so that archaic
  203. FORTRAN programmers could easily develop "unsplitters" after
  204. getting all the pieces!  Lastly, in this system a sort was done
  205. to order the ^ASPLIT line to be the last kludge line before the
  206. message body proper.
  207.  
  208.  
  209. Acknowledgements
  210. ================
  211.  
  212. Particular thanks must be expressed to Randy Bush for offering to
  213. test this system in its earliest releases on the very busy 1/5
  214. zonegate, and for suggesting various improvements.  Thanks for
  215. testing are also due to Dave Wilson who operates the 5/1 zonegate
  216. at the other end of the link from Randy, and to Mike Lawrie of
  217. Rhodes Computer Centre for useful suggestions regarding the form
  218. of the ^ASPLIT line acceptable to non-Fido users.
  219.  
  220.  
  221. Prototype system
  222. ================
  223.  
  224. A version of SPLIT/UNSPLIT using this system may be FREQ'd
  225. from 1:105/42 or 5:494/4 using the magic name SPLITTER.  As at
  226. this time I have unsubstantiated reports that it does not work
  227. in conjunction with systems running Novell software (I have no
  228. access to Novell).  It works fine using Msged and QMail.
  229.  
  230.  
  231.  
  232.