home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Shareware Overload
/
ShartewareOverload.cdr
/
comm
/
zmax.zip
/
MAILER.DOC
< prev
next >
Wrap
Text File
|
1990-08-01
|
7KB
|
181 lines
Zmax
Mailer Implementation
LEGAL STUFF
------------------------------------------------------------------------------
The protocol, documentation, and Zmax.c routines are by Mike Bryeans.
Zmax is NOT public domain. Micro TECH Systems Retains ALL RIGHTS TO
THIS PROTOCOL.
No PART of Zmax may be used in development of a NON-ZMAX protocol.
Developers are granted a license to use Zmax in NON-COMMERCIAL
applications and environments ONLY.
A 10 dollar donation is requested to help
offset development costs and to help with
the salaries of the technical support
person(s).
If you application is intended for use in a program that is to be sold
commercially, including shareware, you must apply for a Zmax COMMERCIAL
License.
If you intend to develop a Zmax driver for USE in a commercial
environment, you must apply for a Zmax COMMERCIAL license.
All goverment agents Federal, State, and Local must apply for a Zmax
COMMERICAL license.
You may NOT modify Zmax specifications. Zmax MUST remain uniform and
only Micro TECH Systems may issue NEW or IMPROVED Zmax specifications.
If you have a particular item in mind, submit it along with a modified
Zmax.c (Using our Zmax.c driver code) to Micro TECH Systems.
Micro TECH Systems
555 North Spring, #39
Cape Girardeau Mo. 63701
Data Number 1-314-334-6359
Mailer on-line supporting:
HTMS and HTMS with Zmax
Wazoo
Zmax
FSC001 (Pure FSC001 only. Binkley, FD, and
D'bridge's versions not supported)
SEAlink (Overdrive Supported).
UUCP (Requires Password Authorization,
arrange in advance.)
FEATURES
------------------------------------------------------------------------------
The features of Zmax include
* non-interference with systems that don't understand the
handshake
* relatively foolproof method for identifying a remote system
and establishing a common ground for transmission
* built-in room to expand the capabilities of Zmax without
having to resort to a kludge
* Faster than normal Zmodem transfers, Handles noisy lines
better and protects ALL data during a transfer with 32 bit
CRCs.
* The Zmax protocol requires roughtly 1/2 as much memory as
Zmodem and my be implemented on systems with 64K of system
memory. Even those that may not be able to handle receiving
data and writing to the disk drive at the same time.
* Uniform method of implementing Service Requests.
* Full functional code included so all implementations should
be uniform despite the author.
USAGE
------------------------------------------------------------------------------
Follow normal Wazoo procedures, but replace all 0xF1's with 0xF6 and
all 0x05 with 0x03. If you do not already have a wazoo driver written,
follow the instructions in FSC-0006.txt and replace the 0xF1 and 0x05
characters as outlined.
Use Zmax.c as a guide to coding your sendfile and receive file protocol
sections. No special modifications need to be made to Zmax.c. Zmax in its
original state may be used as a mailer protocol or a BBS protocol.
You may wish to code a driver and test it against zmax.exe before moving
the code into your mailer.
Feel free to call our CBIS system at the number listed above to test your
mailer implementation.
SOME DIFFERENCES
------------------------------------------------------------------------------
Unlike Wazoo, the sender doesn't START a transfer unless he actual has
something to send. If the sender has nothing, then simply go directly to
end of batch send as outlined in the Zmax.c code.
Block sizes should range from 2048 bytes at 2400 baud to 8192 at 9600+.
Although testing shows no BIG improvement once you exceed 2048 (even at
9600), your users will no doubt want the large blocks because their use
to them.
Unlike Zmodem, Zmax doesn't automatically start sending when a re-send
request is received. Zmax ackknowledges the request and then waits for
the receivers OK to begin sending again. The receiver will wait until the
line has NOTHING on it before giving that OK. This keeps both the
receiver and sender in perfect sync. It also give noise bursts a chance
to die down rather than attempt to send THROUGH them, which generally
ends up being bad anyway.
If you stay to FAR ahead of the receiver, this will cause re-syncs to
take longer.
SERVICE REQUESTS - HTMS and ZMAX
------------------------------------------------------------------------------
A service request is a request for an external service not directly
related to the process of sending or receiving files.
A service request program can do anything within reason, reason being
the amount of time it can take to do it. The maximum amount of time the
receiver can be forced to wait is 5 minutes.
The service request is triggered by the caller sending a file using a
special name XXXXXXXX.SRV. XXXXXXXX being the name of the service. The
file MUST have the file extension of SRV to set it apart from other
files.
The contents of the XXXXXXXX.SRV can be anything from special text
formated instructions (passwords, names, etc.) to a binary structure. In
short, the contents or makeup of the XXXXXXXX.SRV is set by the service
program being called.
Below are the steps for processing a service request.
1. Mail Session established.
2. Receiver goes into receive loop getting all files, etc. from caller.
3. End of Receive loop, Check for any *.SRV file in the inbound file
directory.
4. If found, pull off up to 8 characters (from the filename) to identify
the service being requested. Validate the service (method is up to
the programmer).
5. If valid, send ENQ to caller who is now waiting for the start of the
first file. Caller is required to ACK the ENQ. Continue to send until
the caller ACKS it.
6. Call the service program passing FULL drive, path, and filename
information so it can locate, and use the XXXXXXXX.SRV file.
7. If Service program wishs to pass back any information, files -
messages, etc. then it can do so. I personally require the service
programs to write this information to a XXXXXXXX.RPT file and if it
exists, I send it and then delete it.
8. Delete the XXXXXXXX.SRV file.
9. Proceed with normal sending, if any.
The ENQ was added to force the caller to wait longer than the original
60 seconds. The processing that goes on during that 5 minute wait is
independent of the Zmax protocol. It was intend for use as a method of
doing service requests but it doesn't have to be.