home *** CD-ROM | disk | FTP | other *** search
/ The World of Computer Software / World_Of_Computer_Software-02-385-Vol-1of3.iso / z / zr245l1.zip / ZYRION.TXT < prev    next >
Text File  |  1992-11-24  |  14KB  |  338 lines

  1. Draft 112492
  2.  
  3.  
  4.  
  5.  
  6.  
  7.                            ╔══════════════╗
  8.                            ║  ╔════════╗  ║
  9.                            ║  ║        ║  ║
  10.                            ╚══╝        ╚══╝
  11.                             A product From
  12.                       International Communication
  13.                                Research
  14.                            ╔══╗        ╔══╗
  15.                            ║  ║        ║  ║
  16.                            ║  ╚════════╝  ║
  17.                            ╚══════════════╝
  18.  
  19.  
  20.  
  21.  
  22.  
  23.  
  24.  
  25.  
  26.  
  27.  
  28.  
  29.  
  30.  
  31.                          ZyRion<Tm> General Information
  32.  
  33.      Released By DreamScape "Another break in the wall of Communications"
  34.      Copyright 1990,91,92 By International Communication Research Holland
  35.  
  36.                        ZyRion Version 2.45.1.0  [ Level-1 ]
  37.  
  38.  
  39.  
  40.  
  41.  
  42.  
  43.  
  44.  
  45.  
  46.  
  47.  
  48. PREFACE ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
  49. -------
  50.  
  51. In early 1986, Telenet funded a project to develop an improved public
  52. domain application to application file transfer    protocol.  This    protocol
  53. would alleviate    the throughput problems    network    customers were
  54. experiencing with XMODEM and Kermit file transfers.
  55.  
  56. In the beginning, we thought a few modifications to XMODEM would allow
  57. high performance over packet switched networks while preserving    XMODEM's
  58. simplicity.
  59.  
  60. The initial concept would add a    block number to    the ACK    and NAK    characters
  61. used by    XMODEM.     The resultant protocol    would allow the    sender to send
  62. more than one block before waiting for a response.
  63.  
  64. But how    to add the block number    to XMODEM's ACK    and NAK?  WXMODEM,
  65. SEAlink, MEGAlink and some other protocols add binary byte(s) to indicate
  66. the block number.
  67.  
  68. Pure binary was unsuitable for ZYRION because binary code combinations
  69. won't pass bidirectionally through some    modems,    networks and operating
  70. systems.  Other    operating systems may not be able to recognize something
  71. coming back unless a break signal or a system dependent code or
  72. sequence is present.  By the time all this and other problems with the
  73. simple ACK/NAK sequences mentioned above were corrected, XMODEM's simple
  74. ACK and    NACK characters    had evolved into a real    packet.     The Frog was
  75. riveting.
  76.  
  77. debugging The Source's SuperKermit protocol indicated a    window size of
  78. about 1000 characters was needed at 1200 bps.  High speed modems require a
  79. window of 20000    or more    characters for full throughput.     Much of the
  80. SuperKermit's inefficiency, complexity and debugging time centered around
  81. its ring buffering and window management.  There had to    be a better way    to
  82. get the    job done.
  83.  
  84. A sore point with XMODEM and its progeny is error recovery.  More to the
  85. point, how can the receiver determine whether the sender has responded,    or
  86. is ready to respond, to    a retransmission request?  XMODEM attacks the
  87. problem    by throwing away characters until a certain period of silence.
  88. Too short a time allows    a spurious pause in output (network or timesharing
  89. congestion) to masquerade as error recovery.  Too long a timeout
  90. devastates throughput, and allows a noisy line to lock up the protocol.
  91. SuperKermit solves the problem with a distinct start of    packet character
  92. (SOH).  ZMODEM and ZYRION use unique character sequences to delineate the
  93. start of frames.  SEAlink and MEGAlink do not address this problem.
  94.  
  95. A further error    recovery problem arises    in streaming protocols.     How does
  96. the receiver know when (or if) the sender has recognized its error signal?
  97. Is the next packet the correct response    to the error signal?  Is it
  98. something left over "in    the queue"?  Or    is this    new subpacket one of many
  99. that will have to be discarded because the sender did not receive the
  100. error signal?  How long    should this continue before sending another error
  101. signal?     How can the protocol prevent this from    degenerating into an
  102. argument about mixed signals?
  103.  
  104. SuperKermit uses selective retransmission, so it can accept any    good
  105. packet it receives.  Each time the SuperKermit receiver    gets a data
  106. packet,    it must    decide which outstanding packet    (if any) it "wants most"
  107. to receive, and    asks for that one.  In practice, complex software "hacks"
  108. are needed to attain acceptable robustness.
  109.  
  110. For ZYRION, we decided to forgo the complexity of SuperKermit's packet
  111. assembly scheme    and its    associated buffer management logic and memory
  112. requirements.
  113.  
  114. Another    sore point with    XMODEM and WXMODEM is the garbage added    to files.
  115. This was acceptable with the old CP/M files which had no exact length, but
  116. not with newer systems such as PC-DOS and Unix.     YMODEM    uses file length
  117. information transmitted    in the header block to trim the    output file, but
  118. this causes data loss when transferring    files that grow    during a transfer.
  119.  
  120.  
  121. GENERAL  ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
  122. -------
  123.  
  124. All file transfer protocols make tradeoffs between throughput, reliability,
  125. universality, and complexity according to the technology and knowledge base
  126. available to their designers.
  127.  
  128. In the design of ZYRION, three applications deserve special attention, these
  129. are the same as ZMODEM does.
  130.  
  131.   + Network applications with significant delays (relative to character
  132.     transmission time) and low error rate
  133.  
  134.   + Timesharing and buffered modem applications with significant delays
  135.     and    throughput that    is quickly degraded by reverse channel traffic.
  136.  
  137.     ZYRION's economy of reverse channel bandwidth allows modems that
  138.     dynamically    partition bandwidth between the    two directions to operate
  139.     at optimal speeds.  Special ZYRION features allow simple, efficient
  140.     implementation on a    wide variety of    timesharing hosts.
  141.  
  142.   + Traditional direct modem to modem communications with high error rate.
  143.  
  144. ZYRION is not optimized for optimum throughput when error rate and delays
  145. are both high.
  146.  
  147. This tradeoff markedly reduces code complexity and memory requirements.
  148. ZYRION generally provides faster error recovery than network compatible
  149. ZMODEM implementations.
  150.  
  151. In the absence of network delays, rapid    error recovery is possible, much
  152. faster than TMODEM, ZMODEM, MPT or YMODEM and XMODEM.
  153.  
  154. File transfers begin immediately regardless of which program is    started
  155. first.
  156.  
  157.  
  158. ZYRION  ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
  159. ------
  160.  
  161. In some cases, the file length may be unknown, as when data is obtained
  162. from a process.     Variable length data subpackets solve both of these
  163. problems.
  164.  
  165. Since some characters had to be    escaped    anyway,    there wasn't any point
  166. wasting    bytes to fill out a fixed packet length    or to specify a    variable
  167. packet length.  In ZYRION, the length of data subpackets is denoted by
  168. ending each subpacket with an escape sequence similar to BISYNC    and HDLC.
  169.  
  170. The end result is a ZDFCX header containing a "frame type", four bytes of
  171. supervisory information, and its own DFC.  Data frames consist of a header
  172. followed by 1 or more data subpackets.    In the absence of transmission
  173. errors,    an entire file can be sent in one data frame.
  174.  
  175. Since the sending system may be    sensitive to numerous control characters
  176. or strip parity    in the reverse data path, all of the headers sent by the
  177. receiver are sent in hex.  A common lower level    routine    receives all
  178. headers, allowing the main program logic to deal with headers and data
  179. subpackets as objects.
  180.  
  181. With equivalent    binary (efficient) and hex (application    friendly) frames,
  182. the sending program can    send an    "invitation to receive"    sequence to
  183. activate the receiver without crashing the remote application with
  184. unexpected control characters.
  185.  
  186. The objects as above are fixed for 8 data bits, and NOT to its real variable
  187. bit coded matrix, each byte can overlap a characte.
  188. An Byte in normal transfer is one character [ all protocols ] handle it this
  189. way, ZYRION don't.
  190.  
  191. ZyRion uses a fixed Matrix code table that reduce the overhead of extra bits
  192. Not compression or RLE, NO it use his own table for binary transfers.
  193. The bits are only shifted into the ringbuffer to get 8 bits as a simulated
  194. byte, REAL one byte can be 5 bits or 8 bits depended on the high or low
  195. DFC order control frame for the fixed matrix code table.
  196.  
  197. Going "back to scratch" in the protocol design presents an opportunity to
  198. steal good ideas from many sources and to add a    few new    ones.
  199.  
  200. From Kermit and    UUCP comes the concept of an initial dialog to exchange
  201. system parameters.
  202.  
  203. ZMODEM generalizes Compuserve B    Protocol's host    controlled transfers to
  204. single command AutoDownload and    command    downloading.  A    Security Challenge
  205. discourages password hackers and Trojan    Horse authors from abusing
  206. ZMODEM's power.
  207.  
  208. ZYRION has the advantage of this, we know the technology we need only to
  209. make it better, The security challenge of ZMODEM is used in ZYRION aswell
  210. but in another way, it will send a Signature that prevent MTE or other
  211. related infected remote or local ZYRION protocols.
  212.  
  213. People try to design Virus scan technics to prevent infections, ZYRION will
  214. prevent the file to be saved to disk IF the Signature fails.
  215.  
  216. Do NOT confuse this with checking a file while it will be transfered.
  217.  
  218. Extensive testing has demonstrated ZYRION to be compatible with
  219. satellite links.
  220.  
  221. THROUGHPUT  ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
  222. ----------
  223.  
  224. Between two single task PC-XT computers sending a program image on
  225. an in house Telenet link, SuperKermit provided 72 ch/sec throughput
  226. at 1200    baud.  YMODEM-k    yielded    85 chars/sec, and ZMODEM provided
  227. 113 chars/sec.    XMODEM was not measured, but would have    been much
  228. slower based on    observed network propagation delays.
  229.  
  230. Recent tests downloading large binary files to an IBM PC (4.7 mHz
  231. V20) running ZYRION 2.46.2.8 with table driven 64 bit DFC calculation
  232. yielded a throughput of 1936 cps on a 19200 bps direct connection.
  233.  
  234. Tests with TELEBIT TrailBlazer modems have shown transfer rates
  235. approaching 1600 characters per second for long files.  When files
  236. are compressed, effective transfer rates of 2200 characters per
  237. second are possible.
  238.  
  239. ERROR RECOVERY IN TIMESYNC DFC BASED MODE ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
  240. -----------------------------------------
  241.  
  242. Some tests of ZYRION protocol error recovery performance have been
  243. made.  A PC-AT with SCO SYS V Xenix or DOS 5.0 was connected to a PC
  244. with DOS 3.1 either directly at 9600 bps or with unbuffered dial-up
  245. 1200 bps modems.  The ZYRION software was configured to use 2048
  246. byte data subpacket lengths above 2400 bps, 1024 otherwise.
  247.  
  248. Because    no time    delays are necessary in    normal file transfers, per
  249. file negotiations are much faster than with ZMODEM, the only
  250. observed delay being the time required by the program(s) to update
  251. matrix coded buffers.
  252.  
  253. During a file transfer,    a short    line hit seen by the receiver
  254. usually induces a DFC error.  The interrupt sequence is usually seen
  255. by the sender before the next data subpacket is    completely sent, and
  256. the resultant loss of data throughput averages about half a data
  257. subpacket per line hit.     At 1200 bps this is would be about .75
  258. second lost per    hit.  At 10-5 error rate, this would degrade
  259. throughput by about 9 per cent.
  260.  
  261. The throughput degradation increases with increasing channel delay,
  262. as more    data subpackets    in transit through the channel are discarded
  263. when an    error is detected.
  264.  
  265. A longer noise burst that affects both the receiver and    the sender's
  266. reception of the interrupt sequence usually causes the sender to
  267. remain silent until the receiver times out in 6 seconds.  If the
  268. round trip channel delay exceeds the receiver's 6 second timeout,
  269. recovery from this type    of error may become difficult.
  270.  
  271. Noise affecting    only the sender    is usually ignored, with one common
  272. exception. 
  273.  
  274. In summation, ZYRION performance in the presence of errors resembles
  275. that of ZMODEM or TMODEM, ZMAX e.c  Short  bursts cause minimal data
  276. retransmission.
  277.  
  278. Long bursts (such as pulse dialing noises) often require a timeout error
  279. to restore the flow of data.
  280.  
  281. Unlike traditional and many recently introduced protocols, ZYRION
  282. Signature Pulse safeguards all data and supervisory information with
  283. effective error detection.
  284.  
  285. ZYRION rapidly transfers files, particularly with buffered (error
  286. correcting) modems, timesharing    systems, satellite relays, and wide area
  287. packet switched    networks.
  288.  
  289. User Friendliness is an important ZYRION feature.  ZYRION AutoDownload
  290. (Automatic file    Download initiated without user    intervention) greatly
  291. simplifies file    transfers compared to the traditional protocols.
  292.  
  293. ZMODEM also has this feature (it was the first one), and ZYRION folows
  294. this step.
  295.  
  296. ZYRION provides advanced file management features including Crash
  297. Recovery, flexible control of selective    file transfers,    and security
  298. USER "coded in the key" verified sequence.
  299.  
  300. ZYRION protocol features allow implementation on a wide variety of systems
  301. operating in a wide variety of environments.  A    choice of buffering and
  302. windowing modes allows ZYRION to operate on systems that cannot support
  303. other streaming    protocols.  Finely tuned control character escaping allows
  304. operation with real world networks without Kermit's high overhead.
  305.  
  306. ZYRION and ZMODEM are the only high performance high reliability public
  307. protocols that does not require large buffer allocations for normal file
  308. transfers.
  309.  
  310. In compare with ZMODEM, ZYRION uses another way to send his packets also
  311. the CRC method has been taken out of the loop, since DFC was a better -
  312. method to support the Bit Matrix Shift BMS[HI] and BMS[LO] sequences.
  313.  
  314. This feature makes ZYRION one of the best protocols on the marked today.
  315.  
  316.  
  317. BETA TESTER! ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
  318. ------------
  319.  
  320. IF you want to be a beta, please send your personal information to one
  321. of the ICR/Sites listed in "SITES.TXT"!
  322.  
  323.  
  324. FREE KEY FOR! ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
  325.  
  326. REAL System Operators that can be found in the NODELIST!
  327. If you are the one, call also one of the systems listed in "SITES.TXT"!
  328.  
  329. My Thanks to :
  330.  
  331. ALL Systems listed in the file "SITES.TXT", Included :
  332.  
  333. Jan Janmaat         Dennis Hammerstein       John Lots       Herman ter Braake
  334. Reinier De Groot    Rob V.D Hoeven           Wim Meesters    Truus Pisano
  335.  
  336. Please IF you are not listed, excuse me but I have a busy live.
  337.  
  338.