home *** CD-ROM | disk | FTP | other *** search
/ The World of Computer Software / World_Of_Computer_Software-02-386-Vol-2of3.iso / b / bi-proto.zip / BI-DIREC.TXT next >
Text File  |  1993-02-07  |  14KB  |  305 lines
  1.                   Bi-Directional Protocols for the Macintosh
  2.                   __________________________________________
  3.  
  4.                                by Glen Stewart
  5.                     The Association Mac BBS, 313-695-6955
  6.                              FidoNet 1:2240/173
  7.  
  8.  
  9. The following protocols will be discussed:
  10.  
  11.                 Janus, HS-Link, Hydra, Multi-Xfer, MCS, Bi-Modem
  12.  
  13.  
  14. I think the first time I heard of a bi-directional protocol was when I
  15. reviewed a p rogram called "Mul ti-Xfer", by Martin Dubuc, written for
  16. the Macintosh in 1988 or so.  In his documentation, and from reading
  17. elsewhere, I've learned that normal file transfers generally only flow
  18. data in one direction.  However, there is something known as a
  19. "back-channel" which allows data to flow just as fast on it, as on the
  20. 'main' channel.  The back-channel is typically used for error control.
  21. But on most v.32 and v.32bis modems, both channels can flow data equally
  22. fast.
  23.  
  24. What this means is that a download AND an uploa d can take place
  25. simultaneously with twice the effective throughput of a standard
  26. protocol.  Basically, the upload is free!  Effective data rates are
  27. around 3200cps.  Two popular modems takes an exception to this
  28. capability - Hayes and USR.  A description of their problem is provided
  29. in the HS-Link documentation:
  30.  
  31. Some older high speed modems, such as the HST and Hayes-V, do not
  32. implement V.32 and are able to transfer quickly in only one direction,
  33. while the other direction is relatively slow.  HS/Link will still
  34. perform well as a single direction protocol with these modems, but
  35. bidirectional thruput will be low due to the "ping pong" effect of the
  36. modem switching the high speed channel back and forth.
  37.                                              ------------------------
  38.                                             |The "Ping Pong" effect  |
  39.                                             |slows bidirectional     |
  40.                                             |transfers on older 9600 |
  41.                                             |baud modems.            |
  42.                                              ------------------------
  43.  
  44. With that out of the way, here is an excerpt from the Multi-Xfer
  45. documentation, which sheds light on its features.  Several of these
  46. features are not available with MCS, whose authors were also not
  47. available via e-mail.
  48.  
  49. About Multi-Xfer:
  50. ----------------
  51. "MultiXfer protocol does not use new concepts; it just takes those used
  52. in some established standards (like CCITT X.25 and ZModem) and joins
  53. them together. That is why the MultiXfer protocol is a very e fficient
  54. protocol, particularly when used for simultaneous upload/download, in
  55. which case it outperforms ZModem by as much as 90%.
  56.  
  57. For those of you who are familiar MCS, you will find similarities in
  58. MultiXfer. In fact, the protocol used in MCS is also based on X.25,
  59. which is the main inspiration of MultiXfer. However, MultiXfer is more
  60. flexible. Let's see why...
  61.  
  62. You can receive files from the Macintosh peer by selecting the Receive
  63. item in the File menu or the Receive button beneath the Host File Catalo
  64. g List. MultiXfer will notify the peer to send you the file or folder
  65. selected in the Host File Catalog List. If MultiXfer notices that the
  66. selected file has already been partly transfered, it will initiate the
  67. file recovery procedure. This can save you lots of troubles if there is
  68. a power failure or if a transfer is interrupted inadvertedly.
  69.  
  70. In the File Transfer Mode, MultiXfer is always ready to receive a file.
  71.  If MultiXfer detects that the peer wants to send a file to your Mac, it
  72.  will receive and store it.
  73.  
  74. You can abort a transfer at any given time by pressing the Stop button.
  75. The Macintosh peer will be notified of this action and the current
  76. transfer will be stopped.
  77.  
  78. You can set the File Transfer Folder of the Macintosh peer to a new
  79. folder by using the Change Directory item under the File menu or the
  80. Change Directory button beneath the Host File Catalog List. MultiXfer
  81. will notify the peer to change to the folder selected in the Host File
  82. Catalog List and the new catalog of files will be displayed.
  83.  
  84.  
  85. MultiXfer will give a number extension to a received file which already
  86. exists on the current volume. Also, before creating any files on the
  87. receiving computer, MultiXfer will check to see if there is enough space
  88. to store it. If not, the current transfer will abort and the peer will
  89. be notified of the problem."
  90.  
  91.  
  92.  
  93. I contacted Martin Dubuc to see if he would be willing to share his
  94. source code, and he responded:
  95.  
  96. (1/2): Finally!
  97. Name: mdubuc@ccrit.doc.ca, 107/10
  98. Date: Thu, Feb 4, 1993 2:46:59 AM
  99.  
  100. From: mdub
  101. uc@ccrit.doc.ca (Martin Dubuc)
  102. To:   Glen.Stewart@f175.n2240.z1.ieee.org
  103. Date: 1 Feb 93 16:37 +0500
  104.  
  105. Glen,
  106.  
  107. I would be quite interested to see someone port MultiXfer to CTB. I
  108. don't have time to do it myself. If you can give me some insurance that
  109. you could do it, then I might share the MultiXfer code with you.
  110.  
  111. When I was still working on the MultiXfer code, I had restructured it so
  112. that it could be understood by someone else and I also did structured it
  113. so that it would be easier to port to CTB. Maybe you could do something
  114. nice with it...
  115.  
  116. Martin
  117. ______________________________________________________________________________
  118.  
  119.  
  120.  
  121. About Janus and Hydra:
  122. ---------------------
  123. I first came across the Janus protocol, while reading through the
  124. documentation (and source code) for BinkleyTerm 2.5.  Janus seems to
  125. have been developed primarily for FIdoNet use.  Then just a week ago, I
  126. saw a file called HydraKit.arj on a local IBM developer's BBS.  This is
  127. a full specification and example implementation of a protocol called
  128. "Hydra", which has also been released for public use - and for FidoNet.
  129. Its authors say:
  130.  
  131.     Introduction to Hydra
  132.     =====================================================================
  133.     This document will not attempt to convince the reader that HYDRA is
  134.     of value to him/her or that it is better than other file transfer
  135.     protocols, it will simply describe the protocol. Just to get it out
  136.     of the way, HYDRA is not the ultimate file transfer protocol.
  137.  
  138.     The authors do, however, feel that it offers an significant
  139.     improvement over those file transfer protocols available today.
  140.     HYDRA is a bi-directional protocol with the ability to receive and
  141.     send files simultaneously. There are other bi-directional file
  142.     transfer protocols, but to the authors' knowledge no public
  143.     specifications exist.
  144.  
  145.     HYDRA owes much to Zmodem and its designer, Chuck Forsberg as well
  146.     as to Janus, designed by Rick Huebner. We would like to think of
  147.     HYDRA as a combination of both with a few extra options installed.
  148.  
  149.     The basic concept of a bi-directional file transfer protocol is
  150.     simple. Both data channels are utilized to transmit and receive
  151.     files simultaneously. I.e. two 100 kb files can be exchanged between
  152.     two parties in the time it takes a fully streaming uni-directional
  153.     file transfer protocol to transmit one of the files.
  154.  
  155.  
  156.     Protocol design
  157.     =====================================================================
  158.     The ultimate goal when designing HYDRA was to design a protocol that
  159.     is as simple and robust as possible; complexity increase the problem
  160.     of faulty implementations.
  161.  
  162.     The obvious function of a file transfer protocol is to transport a
  163.     collection of data from its source to its destination as efficient
  164.     possible and without jeopardizing the integrity of the data.
  165.  
  166.     The lack of data compression and lost packet management (as used in
  167.     Kermit and Super Kermit) is intentional. The authors feel that this
  168.     unnecessarily increases the complexity of the protocol.
  169.  
  170.     While HYDRA performs to its best on full duplex links, it should be
  171.     possible to use it on links using proprietary protocols such as the
  172.     US Robotics HST protocol which features one 14.4 kbps data channel
  173.     and one 450 bps back channel.
  174.  
  175.     The protocol design should be flexible enough for future
  176.     enhancements while maintaining backward compatibility.
  177.  
  178.     The authors
  179.     =====================================================================
  180.     The authors can bereached at the following addresses:
  181.  
  182.     Joaquim H. Homrighausen                    Arjen G. Lentz
  183.     389, route d'Arlon                         Lentz Software Development
  184.     L-8011 Strassen                            Langegracht 7B
  185.     Luxembourg                                 3811 BT Amersfoort
  186.                                                The Netherlands
  187.     joho@ae.lu
  188.     FidoNet 2:270/17                           aglentz@fido.lu
  189.                                                FidoNet 2:283/512
  190.  
  191.  
  192.  
  193.  
  194. Sow we are left with HS-Link and Bi-Modem for discussion...
  195.  
  196. I've attempted to contact the authors of both programs.  I have also
  197. briefly evaluated both programs, and find HS-Link to be superior in
  198. features.  The author(s) of Bi-Modem could not be reached, but I was
  199. able to contact Sam Smith on his BBS, the Toolbox BBS, and discussed my
  200. interest in a Macintosh version of HS-Link.
  201.  
  202. Sam was very pleasant to chat with (sometimes I feel this is a rarity)
  203. and was willing to share the source & specification for HS -Link,
  204. provided that he receive a modest royalty for each copy of the shareware
  205. program sold.  He prefered that the Mac version be ported as a CTB tool
  206. (an external protocol, in IBM lingo) so everyone could use it.
  207.  
  208. Locally, about 3 out of 10 BBS's are running HS-Link, which now features
  209. bi-directional transfers as well as simultaneous chat.  It's getting on
  210. par with Multi-Xfer from 4 years ago <grin>!  However, Multi-Xfer is
  211. currently a dead product, while HS-Link is thriving.
  212.  
  213. Sam mentioned that he is not quite ready to release the HS-Link source
  214. code to the public, but that someday he may do it.  He would require a
  215. confidentiality agreement before releasing it to another developer at
  216. this time.
  217.  
  218. Sam Smith may be contacted at his BBS:
  219.           _________________________________________________________________
  220.  
  221.           HS/Link was Written by Samuel H. Smith
  222.  
  223.           Contact me at:
  224.  
  225.                          The Tool Shop BBS
  226.  
  227.           Phone number        Modem type
  228.           --------------      ---------  -----------------------------------
  229.           (818) 891-6780      US Robotics 2400      (free line)
  230.           (818) 891-3772      US Robotics HST 9600  ($20/yr subscription)
  231.           (818) 891-1344      Hayes-V series 9600   ($20/yr subscription)
  232.  
  233.  
  234.           You will always find the latest release version of HS/Link on
  235.           the Tool Shop, as well as a variety of support files and
  236.           programs.
  237.  
  238.  
  239. Because of the popularity of HS-Link, I lean towards wanting a Macintosh
  240. port that would allow the two platform s to remain compatible.  But
  241. there ARE some features in Multi-Xfer that HS-Link could learn from,
  242. such as the ability to initiate new transfers (uploads) at any time
  243. during an existing transfer.  Perhaps HS-Link could be improved in this
  244. area.  It may be that some co-development could take place on both
  245. platforms.  With this in mind, I have contacted Glenn Howes, author of
  246. the Kermit, Ymodem (and soon Zmodem?) CTB tools, to see if he would do
  247. the Mac implementation.  H e is very busy, but I suspect that with
  248. enough encouragement, he may provide us with one!  But write and ask -
  249. he's at HOWES@bert.chem.wisc.edu, 107/10.
  250.  
  251. I am distributing this 'memo' on all the major BBS support echoes and
  252. MACSYSOP echo, to stir the pot (so to speak).  I hope you will add your
  253. enthusiasm for a Macintosh bi-directional CTB tool AND BBS
  254. implementations - and be sure to contact both your favorite BBS's
  255. author, as well as Glenn Howes and Sam Smith to encourage them on!
  256.  
  257.  
  258. References (FREQable files):
  259.  
  260.                  hslink10.arj    <--- HS-Link 1.0 Program
  261.                  bdoc_250.zip    <--- BinkleyTerm Doc's
  262.                  bexe_250.zip    <--- Binkley executables
  263.                  bsrc_250.zip    <--- Binkley source in C (Janus code)
  264.                  HYDRAKIT.ARJ    <--- Hydra package, with C source
  265.                  MCS 1.1.sit     <--- Macintosh Application
  266.            MultiXfer V0.6.sit    <--- Martin Dubuc's Application
  267.  
  268.                  *** sorry I don't have Bi-Modem online!
  269.  
  270.  
  271.  
  272. Final Remarks:
  273. -------------
  274. The topic of bi-directional protocols reminds me of communication with
  275. God... Sometimes it seems like talking to God is about the same as the
  276. Hayes V-series or the HST modem - either not working in one direction,
  277. or going real slow!  Perhaps it's time for many of us to take a second
  278. look at the quality of our time of prayer, and work along with God to
  279. see it enhanced.
  280.  
  281. My wife and I are especially encouraged when God answers a special
  282. request we have asked for.  One of my best memories is from the time of
  283. my daughter's birth, just a couple years ago.  My wife had been in the
  284. labor room for over 30 hours, and the doctors gave her one more hour to
  285. dialate (she was less than 2) to a 10, otherwise they would do a
  286. C-section.
  287.  
  288. We like to do things the natural way, and were quite concerned with our
  289. 'family-bearing' future, if my wife had a C-section.  So we prayed, and
  290. asked God to work his will.  A few moment later, she began contracting
  291. and was up to a 10 within the hour!  During our prayer, we had promised
  292. to dedicate our child to the Lord God - something we had not previously
  293. committed to, though we INTENDED to do that.
  294.  
  295. I think it is important to take these good intentions and turn them into
  296. committments - DO them!  If you have been considering a dedicated
  297. relationship with God, why not work out a plan for getting it off the
  298. ground?  Chat with him and see what he thinks!  If you've been like me -
  299. kind of like that V-series modem - when it comes to talking with God,
  300. won't you join me in renewing the communication we once had?  God has
  301. promised that he WILL reveal himself to those who seek him!
  302.  
  303. May God be with you!
  304.  
  305.