Bi-Directional Protocols for the Macintosh __________________________________________ by Glen Stewart The Association Mac BBS, 313-695-6955 FidoNet 1:2240/173 The following protocols will be discussed: Janus, HS-Link, Hydra, Multi-Xfer, MCS, Bi-Modem I think the first time I heard of a bi-directional protocol was when I reviewed a p rogram called "Mul ti-Xfer", by Martin Dubuc, written for the Macintosh in 1988 or so. In his documentation, and from reading elsewhere, I've learned that normal file transfers generally only flow data in one direction. However, there is something known as a "back-channel" which allows data to flow just as fast on it, as on the 'main' channel. The back-channel is typically used for error control. But on most v.32 and v.32bis modems, both channels can flow data equally fast. What this means is that a download AND an uploa d can take place simultaneously with twice the effective throughput of a standard protocol. Basically, the upload is free! Effective data rates are around 3200cps. Two popular modems takes an exception to this capability - Hayes and USR. A description of their problem is provided in the HS-Link documentation: Some older high speed modems, such as the HST and Hayes-V, do not implement V.32 and are able to transfer quickly in only one direction, while the other direction is relatively slow. HS/Link will still perform well as a single direction protocol with these modems, but bidirectional thruput will be low due to the "ping pong" effect of the modem switching the high speed channel back and forth. ------------------------ |The "Ping Pong" effect | |slows bidirectional | |transfers on older 9600 | |baud modems. | ------------------------ With that out of the way, here is an excerpt from the Multi-Xfer documentation, which sheds light on its features. Several of these features are not available with MCS, whose authors were also not available via e-mail. About Multi-Xfer: ---------------- "MultiXfer protocol does not use new concepts; it just takes those used in some established standards (like CCITT X.25 and ZModem) and joins them together. That is why the MultiXfer protocol is a very e fficient protocol, particularly when used for simultaneous upload/download, in which case it outperforms ZModem by as much as 90%. For those of you who are familiar MCS, you will find similarities in MultiXfer. In fact, the protocol used in MCS is also based on X.25, which is the main inspiration of MultiXfer. However, MultiXfer is more flexible. Let's see why... You can receive files from the Macintosh peer by selecting the Receive item in the File menu or the Receive button beneath the Host File Catalo g List. MultiXfer will notify the peer to send you the file or folder selected in the Host File Catalog List. If MultiXfer notices that the selected file has already been partly transfered, it will initiate the file recovery procedure. This can save you lots of troubles if there is a power failure or if a transfer is interrupted inadvertedly. In the File Transfer Mode, MultiXfer is always ready to receive a file. If MultiXfer detects that the peer wants to send a file to your Mac, it will receive and store it. You can abort a transfer at any given time by pressing the Stop button. The Macintosh peer will be notified of this action and the current transfer will be stopped. You can set the File Transfer Folder of the Macintosh peer to a new folder by using the Change Directory item under the File menu or the Change Directory button beneath the Host File Catalog List. MultiXfer will notify the peer to change to the folder selected in the Host File Catalog List and the new catalog of files will be displayed. MultiXfer will give a number extension to a received file which already exists on the current volume. Also, before creating any files on the receiving computer, MultiXfer will check to see if there is enough space to store it. If not, the current transfer will abort and the peer will be notified of the problem." I contacted Martin Dubuc to see if he would be willing to share his source code, and he responded: (1/2): Finally! Name: mdubuc@ccrit.doc.ca, 107/10 Date: Thu, Feb 4, 1993 2:46:59 AM From: mdub uc@ccrit.doc.ca (Martin Dubuc) To: Glen.Stewart@f175.n2240.z1.ieee.org Date: 1 Feb 93 16:37 +0500 Glen, I would be quite interested to see someone port MultiXfer to CTB. I don't have time to do it myself. If you can give me some insurance that you could do it, then I might share the MultiXfer code with you. When I was still working on the MultiXfer code, I had restructured it so that it could be understood by someone else and I also did structured it so that it would be easier to port to CTB. Maybe you could do something nice with it... Martin ______________________________________________________________________________ About Janus and Hydra: --------------------- I first came across the Janus protocol, while reading through the documentation (and source code) for BinkleyTerm 2.5. Janus seems to have been developed primarily for FIdoNet use. Then just a week ago, I saw a file called HydraKit.arj on a local IBM developer's BBS. This is a full specification and example implementation of a protocol called "Hydra", which has also been released for public use - and for FidoNet. Its authors say: Introduction to Hydra ===================================================================== This document will not attempt to convince the reader that HYDRA is of value to him/her or that it is better than other file transfer protocols, it will simply describe the protocol. Just to get it out of the way, HYDRA is not the ultimate file transfer protocol. The authors do, however, feel that it offers an significant improvement over those file transfer protocols available today. HYDRA is a bi-directional protocol with the ability to receive and send files simultaneously. There are other bi-directional file transfer protocols, but to the authors' knowledge no public specifications exist. HYDRA owes much to Zmodem and its designer, Chuck Forsberg as well as to Janus, designed by Rick Huebner. We would like to think of HYDRA as a combination of both with a few extra options installed. The basic concept of a bi-directional file transfer protocol is simple. Both data channels are utilized to transmit and receive files simultaneously. I.e. two 100 kb files can be exchanged between two parties in the time it takes a fully streaming uni-directional file transfer protocol to transmit one of the files. Protocol design ===================================================================== The ultimate goal when designing HYDRA was to design a protocol that is as simple and robust as possible; complexity increase the problem of faulty implementations. The obvious function of a file transfer protocol is to transport a collection of data from its source to its destination as efficient possible and without jeopardizing the integrity of the data. The lack of data compression and lost packet management (as used in Kermit and Super Kermit) is intentional. The authors feel that this unnecessarily increases the complexity of the protocol. While HYDRA performs to its best on full duplex links, it should be possible to use it on links using proprietary protocols such as the US Robotics HST protocol which features one 14.4 kbps data channel and one 450 bps back channel. The protocol design should be flexible enough for future enhancements while maintaining backward compatibility. The authors ===================================================================== The authors can bereached at the following addresses: Joaquim H. Homrighausen Arjen G. Lentz 389, route d'Arlon Lentz Software Development L-8011 Strassen Langegracht 7B Luxembourg 3811 BT Amersfoort The Netherlands joho@ae.lu FidoNet 2:270/17 aglentz@fido.lu FidoNet 2:283/512 Sow we are left with HS-Link and Bi-Modem for discussion... I've attempted to contact the authors of both programs. I have also briefly evaluated both programs, and find HS-Link to be superior in features. The author(s) of Bi-Modem could not be reached, but I was able to contact Sam Smith on his BBS, the Toolbox BBS, and discussed my interest in a Macintosh version of HS-Link. Sam was very pleasant to chat with (sometimes I feel this is a rarity) and was willing to share the source & specification for HS -Link, provided that he receive a modest royalty for each copy of the shareware program sold. He prefered that the Mac version be ported as a CTB tool (an external protocol, in IBM lingo) so everyone could use it. Locally, about 3 out of 10 BBS's are running HS-Link, which now features bi-directional transfers as well as simultaneous chat. It's getting on par with Multi-Xfer from 4 years ago ! However, Multi-Xfer is currently a dead product, while HS-Link is thriving. Sam mentioned that he is not quite ready to release the HS-Link source code to the public, but that someday he may do it. He would require a confidentiality agreement before releasing it to another developer at this time. Sam Smith may be contacted at his BBS: _________________________________________________________________ HS/Link was Written by Samuel H. Smith Contact me at: The Tool Shop BBS Phone number Modem type -------------- --------- ----------------------------------- (818) 891-6780 US Robotics 2400 (free line) (818) 891-3772 US Robotics HST 9600 ($20/yr subscription) (818) 891-1344 Hayes-V series 9600 ($20/yr subscription) You will always find the latest release version of HS/Link on the Tool Shop, as well as a variety of support files and programs. Because of the popularity of HS-Link, I lean towards wanting a Macintosh port that would allow the two platform s to remain compatible. But there ARE some features in Multi-Xfer that HS-Link could learn from, such as the ability to initiate new transfers (uploads) at any time during an existing transfer. Perhaps HS-Link could be improved in this area. It may be that some co-development could take place on both platforms. With this in mind, I have contacted Glenn Howes, author of the Kermit, Ymodem (and soon Zmodem?) CTB tools, to see if he would do the Mac implementation. H e is very busy, but I suspect that with enough encouragement, he may provide us with one! But write and ask - he's at HOWES@bert.chem.wisc.edu, 107/10. I am distributing this 'memo' on all the major BBS support echoes and MACSYSOP echo, to stir the pot (so to speak). I hope you will add your enthusiasm for a Macintosh bi-directional CTB tool AND BBS implementations - and be sure to contact both your favorite BBS's author, as well as Glenn Howes and Sam Smith to encourage them on! References (FREQable files): hslink10.arj <--- HS-Link 1.0 Program bdoc_250.zip <--- BinkleyTerm Doc's bexe_250.zip <--- Binkley executables bsrc_250.zip <--- Binkley source in C (Janus code) HYDRAKIT.ARJ <--- Hydra package, with C source MCS 1.1.sit <--- Macintosh Application MultiXfer V0.6.sit <--- Martin Dubuc's Application *** sorry I don't have Bi-Modem online! Final Remarks: ------------- The topic of bi-directional protocols reminds me of communication with God... Sometimes it seems like talking to God is about the same as the Hayes V-series or the HST modem - either not working in one direction, or going real slow! Perhaps it's time for many of us to take a second look at the quality of our time of prayer, and work along with God to see it enhanced. My wife and I are especially encouraged when God answers a special request we have asked for. One of my best memories is from the time of my daughter's birth, just a couple years ago. My wife had been in the labor room for over 30 hours, and the doctors gave her one more hour to dialate (she was less than 2) to a 10, otherwise they would do a C-section. We like to do things the natural way, and were quite concerned with our 'family-bearing' future, if my wife had a C-section. So we prayed, and asked God to work his will. A few moment later, she began contracting and was up to a 10 within the hour! During our prayer, we had promised to dedicate our child to the Lord God - something we had not previously committed to, though we INTENDED to do that. I think it is important to take these good intentions and turn them into committments - DO them! If you have been considering a dedicated relationship with God, why not work out a plan for getting it off the ground? Chat with him and see what he thinks! If you've been like me - kind of like that V-series modem - when it comes to talking with God, won't you join me in renewing the communication we once had? God has promised that he WILL reveal himself to those who seek him! May God be with you!