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 >
Wrap
Text File
|
1993-02-07
|
14KB
|
305 lines
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 <grin>! 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!