home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Current Shareware 1994 January
/
SHAR194.ISO
/
modem
/
zr351wb.zip
/
ZYRION.DOC
< prev
next >
Wrap
Text File
|
1993-11-03
|
40KB
|
1,053 lines
╔══════════════╗
║ ╔════════╗ ║
║ ║ ║ ║
╚══╝ ╚══╝
A product From
International Communication
Research
╔══╗ ╔══╗
║ ║ ║ ║
║ ╚════════╝ ║
╚══════════════╝
ZyRion Version 3.51.P
Public Release
ZyRion<Tm> MatrixScript Encoded
"ZyRion.exe" Double Trible Shield Protection
By ScrambleWare<Tm>
Released By DreamScape "Another break in the wall of Communications"
Copyright 1990 ,91 ,92 ,93 By International Communication Research Holland
ZyRion Created by Marlin Lee England
All Internal codes by Frans Lupschen
ZyRion Version 3.51.P
ZyRion<Tm> Copyright 1993 by Frans Lupschen
LEGAL STUFF
-----------
T r a d e m a r k s U s e d
The products listed below are referenced in this manual and we feel that
proper credit should be given to each for the contribution made to our
project and the computing community as a whole.
BinkleyTerm Bit Bucket Software
BNU David Nugent
Borland C++, Turbo C++, Turbo Pascal Borland International
DESQview Quarterdeck Systems
DoubleDOS SoftLogic Systems
YAM, GSZ, DSZ, ZModem Chuck Forsberg
FrontDoor, TosScan Joaquim H. Homrighausen
IBM, PC-DOS International Business Machines,Inc.
RKPlus [ En/Decryption ] Scott Davis
Opus Wynn Wagner III
QuickBBS ---- Unknown ----
RemoteAccess Andrew Milner & Continental Software
TheDraw TheSoft Programming Services
X00 Ray Gwinn
ACKNOWLEDGMENTS
* Turbo Pascal is a registered trademark of Borland International
* OS/2 is a registered trademark of IBM Corporation
* MS-DOS is a registered trademark of Microsoft Corporation
* DESQview is a registered trademark of Quarterdeck Office Systems
* VMiX is a registered trademark of Commercial Software Associates
* Windows is a registered trademark of Microsoft Corporation
* MultiDos Plus is a registered trademark of Nanosoft Inc.
* All other programs are copyright and/or trademarked by their
respective author unless otherwise noted
W A R R A N T I E S
-------------------
By using this software you agree that ICR Holland in no way assumes
responsibility in any way for the use or misuse of its software.
In no way is ICR Holland liable for the inability to use any of its
products.
ICR Holland makes no warranty of any kind, either expressed or implied,
and no warranty that the program product is free of errors.
C O P Y R I G H T N O T I C E
-------------------------------
ZyRion is a copyrighted commercial product of ICR Holland, Inc., a
privately held corporation with offices located at Brunssum, 6443 XP.,
The Netherlands, Z.L.
Copyright 1990-1993 International Communication Research.
All Rights Reserved
Z y R i o n S h a r e w a r e
--------------------------------
ZyRion is NOT FREE, its ShareWare!
You may use it so as it is "UNREGISTERED" for unlimited time, but the
registered version gives you a lot more, the NON KEY version is just
a litle peek what ZyRion can give you, If we are talking about Data -
Transfers or File Transfer Protocols FTP's, then ZyRion is that what
you need, try ZyRion and decide what you'll do!
ZyRion Shareware may be distributed under the following terms:
ZyRion may not be modified in any way, for any reason, including but not
limited to de-compiling, disassembling, or reverse engineering of the -
program.
Copyright notices and version information and all other proprietary -
program output must never be altered, removed, bypassed or modified by -
any means.
You are free to distribute the PUBLICLY AVAILABLE shareware version of -
ZyRion to others subject to the above restrictions and also the following:
A. No fee is charged for its use.
B. No remuneration may be accepted for ZyRion. Normal charges for the -
method of transmission may be charged.
C. ZyRion must be copied in unaltered form, complete with files containing
license information, the FULL documentation and all accompanying files.
D. All shareware houses/distribution firms must make explicitly clear that
the diskette purchase containing any shareware program has NOT been
registered for use in a commercial environment with ICR Holland.
Shareware houses and software distribution houses must have a specific
license from ICR Holland, Inc.
System Operators may make ZyRion available for download only if the above
conditions are met. If the contents of the archive appear altered or not
complete, you may obtain the latest release of ZyRion directly from ICR
Holland, Inc.
Z y R i o n R e g i s t e r e d
---------------------------------
Registered Users will receive a new version which will allow use of
additional features such as increased speed and more. The registered
version may not be distributed.
A. ICR Holland authorizes the making of an archival copy of the
registered software for the sole purpose of backing-up your software
and protecting your investment from possible loss.
B. The medium on which the registered software is recorded is transferred
to the customer, but not the title to the software.
D. A single copy of the registered version of ZyRion may be operated on
more than one computer so long as there is ABSOLUTELY NO POSSIBILITY
of it being used at one location while being simultaneously used at
another.
E. ICR Holland is in no way whatsoever obligated to provide support, or
updates to ZyRion or any other of its software.
PREFACE
-------
Welcome to Another break in the wall of Communications its ZyRion, a
powerfull Filetransfer protocol.
This Documentation will help you to Install and interface ZyRion to
other communication products, like Terminals & BBS Systems.
If you have still problems after reading this document then I want to
know all about it.
You can call one of the systems listed in "Sites.txt".
Zyrion currently supports the following multitaskers:
Windows 3.x & NT
DESQview 2.xx
DoubleDOS
VMiX 2.xx
MultiDos Plus 4.xx
OS/2 2.0 & 2.1
DOS 5.0 & 6.0 Task Switcher and Compatibles
TaskView, TopView, OmniView, & Compatibles
TECHNICAL LOOK
--------------
Zyrion Professional (tm) Full Stream Protocol Driver
Version 3.51 Check Type DFC
Level P Avr. Cps 240 [ 100% ] at 2400 baud
Status Public Timer counts at start YES
Product Code 2 MTE & PMS Aware YES (tm)
Date 08/17/93 Multitask Aware YES
Data 8 Bits or 7 Bits 2 Bits Extra [ Start/Stop]
Data Len. complete file Transport type SDirectional
Data Sub Len 4096 Bidirectional Signature Frame
NC 32 Bits Matrix Check Ahead Count sender NON
DC 64 Bits Matrix Check Byte Count control Sync framed
Encoded "ZModem type" RLE NON at this time
Key security Bidirectional Destructive on conflict Randomized
Resume aborted xfers YES Headers included by Xfer time YES
Hold Buffer normal 4096 Hold Buffer MAX [ 32 KB ]
Reliable at errors YES Recover Size MAX 4096 or less
Batch mode YES Serial Xfer YES [ Standard RS232C ]
Ctl File Xfer YES Iquiniced on patern search YES
Constant Abarated YES Iquinice < > Abarate YES
Handshake Header 16 Bit CRC Header has all info "Hello Packet"
ZINF frame Then user info header ZINF First H/S Header afterwards
File Rewind option YES SUB Packet Rewind YES
Error correction at ZRPOS ZRPOS at Pos on Disk
Error retry count until CAN CAN Will be send if Abarated decided
Smart Decided routine YES Decided is FRAME based
Bidirectional Frame Returns Returns on ZSIMPL OFF Request
Security Frame and header based MTE Unit "NO INFO RELEASED" (tm)
Reject strange files YES! Bit rotation Lo/Hi used for speed!
Progress Bar YES Avr. repeated TimeSync's 2/10240 bytes
Extra I/O Check YES Ignore Bidirectional Frame YES
Hidden Start Frames YES Object Async used YES
PREFACE - 2 ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
-----------
In early 1986, Telenet funded a project to develop an improved public
domain application to application file transfer protocol. This protocol
would alleviate the throughput problems network customers were
experiencing with XMODEM and Kermit file transfers.
In the beginning, we thought a few modifications to XMODEM would allow
high performance over packet switched networks while preserving XMODEM's
simplicity.
The initial concept would add a block number to the ACK and NAK characters
used by XMODEM. The resultant protocol would allow the sender to send
more than one block before waiting for a response.
But how to add the block number to XMODEM's ACK and NAK? WXMODEM,
SEAlink, MEGAlink and some other protocols add binary byte(s) to indicate
the block number.
Pure binary was unsuitable for ZYRION because binary code combinations
won't pass bidirectionally through some modems, networks and operating
systems. Other operating systems may not be able to recognize something
coming back unless a break signal or a system dependent code or
sequence is present. By the time all this and other problems with the
simple ACK/NAK sequences mentioned above were corrected, XMODEM's simple
ACK and NACK characters had evolved into a real packet. The Frog was
riveting.
debugging The Source's SuperKermit protocol indicated a window size of
about 1000 characters was needed at 1200 bps. High speed modems require a
window of 20000 or more characters for full throughput. Much of the
SuperKermit's inefficiency, complexity and debugging time centered around
its ring buffering and window management. There had to be a better way to
get the job done.
A sore point with XMODEM and its progeny is error recovery. More to the
point, how can the receiver determine whether the sender has responded, or
is ready to respond, to a retransmission request? XMODEM attacks the
problem by throwing away characters until a certain period of silence.
Too short a time allows a spurious pause in output (network or timesharing
congestion) to masquerade as error recovery. Too long a timeout
devastates throughput, and allows a noisy line to lock up the protocol.
SuperKermit solves the problem with a distinct start of packet character
(SOH). ZMODEM and ZYRION use unique character sequences to delineate the
start of frames. SEAlink and MEGAlink do not address this problem.
A further error recovery problem arises in streaming protocols. How does
the receiver know when (or if) the sender has recognized its error signal?
Is the next packet the correct response to the error signal? Is it
something left over "in the queue"? Or is this new subpacket one of many
that will have to be discarded because the sender did not receive the
error signal? How long should this continue before sending another error
signal? How can the protocol prevent this from degenerating into an
argument about mixed signals?
SuperKermit uses selective retransmission, so it can accept any good
packet it receives. Each time the SuperKermit receiver gets a data
packet, it must decide which outstanding packet (if any) it "wants most"
to receive, and asks for that one. In practice, complex software "hacks"
are needed to attain acceptable robustness.
For ZYRION, we decided to forgo the complexity of SuperKermit's packet
assembly scheme and its associated buffer management logic and memory
requirements.
Another sore point with XMODEM and WXMODEM is the garbage added to files.
This was acceptable with the old CP/M files which had no exact length, but
not with newer systems such as PC-DOS and Unix. YMODEM uses file length
information transmitted in the header block to trim the output file, but
this causes data loss when transferring files that grow during a transfer.
GENERAL ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
-------
All file transfer protocols make tradeoffs between throughput, reliability,
universality, and complexity according to the technology and knowledge base
available to their designers.
In the design of ZYRION, three applications deserve special attention, these
are the same as ZMODEM does.
+ Network applications with significant delays (relative to character
transmission time) and low error rate
+ Timesharing and buffered modem applications with significant delays
and throughput that is quickly degraded by reverse channel traffic.
ZYRION's economy of reverse channel bandwidth allows modems that
dynamically partition bandwidth between the two directions to operate
at optimal speeds. Special ZYRION features allow simple, efficient
implementation on a wide variety of timesharing hosts.
+ Traditional direct modem to modem communications with high error rate.
ZYRION is not optimized for optimum throughput when error rate and
delays are both high.
This tradeoff markedly reduces code complexity and memory requirements.
ZYRION generally provides faster error recovery than network compatible
ZMODEM implementations.
In the absence of network delays, rapid error recovery is possible, much
faster than TMODEM, ZMODEM, MPT or YMODEM and XMODEM.
File transfers begin immediately regardless of which program is started
first.
ZYRION ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
------
In some cases, the file length may be unknown, as when data is obtained
from a process. Variable length data subpackets solve both of these
problems.
Since some characters had to be escaped anyway, there wasn't any point
wasting bytes to fill out a fixed packet length or to specify a variable
packet length. In ZYRION, the length of data subpackets is denoted by
ending each subpacket with an escape sequence similar to BISYNC and HDLC.
The end result is a ZDFCX header containing a "frame type", four bytes of
supervisory information, and its own DFC. Data frames consist of a header
followed by 1 or more data subpackets. In the absence of transmission
errors, an entire file can be sent in one data frame.
Since the sending system may be sensitive to numerous control characters
or strip parity in the reverse data path, all of the headers sent by the
receiver are sent in hex. A common lower level routine receives all
headers, allowing the main program logic to deal with headers and data
subpackets as objects.
With equivalent binary (efficient) and hex (application friendly) frames,
the sending program can send an "invitation to receive" sequence to
activate the receiver without crashing the remote application with
unexpected control characters.
The objects as above are fixed for 8 data bits, and _NOT_ to its real
variable bit coded matrix, each byte can overlap a character.
An Byte in normal transfer is one character [ all protocols ] handle it
this way, ZYRION don't.
ZyRion uses a fixed Matrix code table that reduce the overhead of extra
bits Not compression or RLE, it use his own table for binary transfers.
The bits are only shifted into the ringbuffer to get 8 bits as a simulated
byte, REAL one byte can be 5 bits or 8 bits depended on the high or low
DFC order control frame for the fixed matrix code table.
Going "back to scratch" in the protocol design presents an opportunity to
steal good ideas from many sources and to add a few new ones.
From Kermit and UUCP comes the concept of an initial dialog to exchange
system parameters.
ZMODEM generalizes Compuserve B Protocol's host controlled transfers to
single command AutoDownload and command downloading.
Security Challenge discourages password hackers and Trojan Horse authors
from abusing ZMODEM's power.
ZYRION has the advantage of this, we know the technology we need only to
make it better, The security challenge of ZMODEM is used in ZYRION aswell
but in another way, it will send a Signature that prevent MTE or other
related infected remote or local ZYRION protocols.
People design Virus scan technics to prevent futher infections, ZYRION -
will prevent the file to be saved to disk IF the Signature fails.
Do NOT confuse this with checking a file while it will be transfered.
Extensive testing has demonstrated ZYRION to be compatible with
satellite links.
The security Handshake packet mode will take some time, but it is needed
since both sites Exchange a lot of information, you can compare this with
EMSI, but it works in a complete other way, I used the word EMSI so that
you know what I mean in general.
THROUGHPUT ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
----------
Between two single task PC-XT computers sending a program image on
an in house Telenet link, SuperKermit provided 72 ch/sec throughput
at 1200 baud. YMODEM-k yielded 85 chars/sec, and ZMODEM provided
113 chars/sec. XMODEM was not measured, but would have been much
slower based on observed network propagation delays.
Recent tests downloading large binary files to an IBM PC (4.7 mHz
V20) running ZYRION 3.51.B with table driven 64 bit DFC calculation
yielded a throughput of 1955 cps on a 19200 bps direct connection.
Tests with TELEBIT TrailBlazer modems have shown transfer rates
approaching 1856 characters per second for long files. When files
are compressed, effective transfer rates of 2200 characters per
second are possible.
Tests with Dallas 14400/ locked at 38400 modems have shown transfer
rates approaching 1933 characters per second for long files.
When files are compressed, effective transfer rates of 3490 characters
per second are possible.
ERROR RECOVERY IN TIMESYNC DFC BASED MODE ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
-----------------------------------------
Some tests of ZYRION protocol error recovery performance have been
made. A PC-AT with SCO SYS V Xenix or DOS 5.0 was connected to a PC
with DOS 3.1 either directly at 9600 bps or with unbuffered dial-up
1200 bps modems. The ZYRION software was configured to use 2048
byte data subpacket lengths above 2400 bps, 1024 otherwise.
Because no time delays are necessary in normal file transfers, per
file negotiations are much faster than with ZMODEM, the only
observed delay being the time required by the program(s) to update
matrix coded buffers.
During a file transfer, a short line hit seen by the receiver
usually induces a DFC error. The interrupt sequence is usually seen
by the sender before the next data subpacket is completely sent, and
the resultant loss of data throughput averages about half a data
subpacket per line hit. At 1200 bps this is would be about .75
second lost per hit. At 10-5 error rate, this would degrade
throughput by about 9 per cent.
The throughput degradation increases with increasing channel delay,
as more data subpackets in transit through the channel are discarded
when an error is detected.
A longer noise burst that affects both the receiver and the sender's
reception of the interrupt sequence usually causes the sender to
remain silent until the receiver times out in 6 seconds. If the
round trip channel delay exceeds the receiver's 6 second timeout,
recovery from this type of error may become difficult.
Noise affecting only the sender is usually ignored, with one common
exception.
In summation, ZYRION performance in the presence of errors resembles
that of ZMODEM or TMODEM, ZMAX e.c Short bursts cause minimal data
retransmission.
Long bursts (such as pulse dialing noises) often require a timeout error
to restore the flow of data.
Unlike traditional and many recently introduced protocols, ZYRION
Signature Pulse safeguards all data and supervisory information with
effective error detection.
ZYRION rapidly transfers files, particularly with buffered (error
correcting) modems, timesharing systems, satellite relays, and wide area
packet switched networks.
User Friendliness is an important ZYRION feature. ZYRION AutoDownload
(Automatic file Download initiated without user intervention) greatly
simplifies file transfers compared to the traditional protocols.
ZMODEM also has this feature (it was the first one), and ZYRION folows
this step.
ZYRION provides advanced file management features including Crash
Recovery, flexible control of selective file transfers, and security
USER "coded in the key" verified sequence.
ZYRION protocol features allow implementation on a wide variety of systems
operating in a wide variety of environments. A choice of buffering and
windowing modes allows ZYRION to operate on systems that cannot support
other streaming protocols. Finely tuned control character escaping allows
operation with real world networks without Kermit's high overhead.
ZYRION and ZMODEM are the only high performance high reliability public
protocols that does not require large buffer allocations for normal file
transfers.
In compare with ZMODEM, ZYRION uses another way to send his packets also
the CRC method has been taken out of the loop, since DFC was a better -
method to support the Bit Matrix Shift BMS[HI] and BMS[LO] sequences.
This feature makes ZYRION one of the best protocols on the marked today.
ZyRion Global under the loop ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
----------------------------
ZyRion uses some advanced multiFrame options, these frames can be reques -
ted from the other ZyRion "Any Time" if needed.
In general ZyRion will start with a Sync frame and Time reset frame, after
the remote has send his initialization to complete this procedure the -
transfer starts with a USER info field, this field can hold a lot of -
information, both ends are exchanging this information.
After this has been done a internal check will be performed, serial -
number, user name and "IF REGISTERED" the encrypted ID will be verified
so that no duplicated keys can be used, also in this sequence an extra -
CRC segment will be transfered to be sure that both keys are NOT the -
same, IF they are the same ZyRion will jump to his coinflict routine and
that will take the needed steps to advoid futher "Retry's" to use the same
keys on both ends.
Now the real transfer will start, this will be done with a hex header, -
this header is important for the DFC matrix buffer, if agree ZyRion will
proceed, if not the last sequence will be repeated until both ends are
agreed to begin the data flow.
The general rule for all this is "Nothing unreal excist", IF an RVC frame
has been added, ZyRion will try to figur out if/or it can handle RVC if
not this frame will be ignored, otherwise it will use the RVC timesync -
based routine to setup the Real Voice Chat, IF not we will proceed with -
the normal data sequence, DFC based data segments.
ZyRion RX ZyRion TX
ZFDS -----------------> ?
? <----------------- ZXLS
ZOKE ------------------> IDLE
ZFDS ------------------> ?
IDLE <----------------- ZOKE
Repeat until timeout or Data ZSQE received
HDR1 ------------------> WAIT
WAIT <----------------- HDR1
Both ends received ZSQE Frameend.
SPKT ---DATA-DFC-------> BUFF
BUFF <--DATA-DFC------- SPKT
LO1 ------------------> BUFF
BUFF <----------------- HI1
CRCL ------------------> MATRIX
MATRIX <--------------- CRCH
TMSYNC ----------------> WSYNC
WSYNC <---------------- TMSYNC
RVCOK -----------------> ?
? <---------------- RVCOK
RVCAC -----------------> ?
? <---------------- RVCAC
Verification Key and other info
If okay then ...
FLOW -----------------> START
START <---------------- FLOW
RVCDA -----------------> IDLE
IDLE <---------------- RVCDA
WAIT <----------------- FILE
FLOW -----------------> START
START <---------------- FLOW
RVCDA -----------------> IDLE
IDLE <---------------- RVCDA
FLOW -----------------> START
START <---------------- FLOW
RVCDA -----------------> IDLE
IDLE <---------------- RVCDA
? <---------------- ZEOF
RWNR? -----------------> ?
? -----------------> ZEOF
NEXT -----------------> ?
And so on ....
The complete sequences are Bit Shift Encoded and packet for optimized
speed, data, voice and all info are include + error timesync rate Sync
for IF an DFC error shows up.
BETA TESTER! ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
------------
IF you want to be a beta, please send your personal information to one
of the ICR/Sites listed in "SITES.TXT"!
FREE KEY FOR! ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
Read for this the SYSOP.DOC included in this package!
INSTALL
-------
First "ofcource" unpack the orginal distribution package into a sub -
directory of your choice.
For example :
C:\MD ZYRION
C:\CD ZYRION
C:\ZYRION> ARJ E C:\NEWFILES\ZR350-P.ARJ
Now you need to "EDIT" your "AUTOEXEC.BAT" file, and add this statement
SET ZSE=C:\ZYRION
The ZSE environment is not needed, but it will speedup ZyRion a bit.
Also include a Path statement, IF needed.
SET PATH=C:\ZYRION
IF you need a LOG file include this line :
SET ZRLOG=C:\ZYRION\ZYRION.LOG
Note that ZyRion.log can be any filename you want!
At this point you are ready to - REBOOT - so that the new Environments
are active.
If you did NOT read the file VERSIONS.TXT, please do that first before
you proceed with the SETUPn instructions.
SETUPn
------
Second type again :
C:\CD ZYRION
C:\ZYRION> ZYRION SETUPn "Where n=COM1 - COM8 as integer."
For Example IF you want to Setup ZyRion for COM4 type
C:\ZYRION> ZYRION SETUP4
If you have more lines, then simple Setup ZyRion for each line as above
the range is from 1 - 4 [ UNREGISTERED ], and from 1 - 8 [ REGISTERED ]!
SETUP CONFIGURATION
-------------------
Third step, now you need to tell ZyRion how your configuration need to
look like.
WALK WITH ME AND LETS SETUP ZYRION!
-----------------------------------
Lets first fill out the packet section,name, BBS Name, Country e.c
Here you need to Enter YOUR FULL name, Will be verified if you have
a "KEY"!
If you have NO KEY just press Enter!
Owner Name Verification [ First and Lastname ]............>
Next you need/or NOT to enter your BBS System name "IF ANY!"
Please enter your BBS System Name [ Enter=NON ]...........>
Enter here your REAL phone number [ for example 3145256961 ]
Your Phone Number Please..................................>
Enter now your country and City! (Real Please!!!!!!!!!)
Country and City..........................................>
The above lines are used to build a Hello Security Packet.
IF you use a HIGH SPEED Modem, then you'll need to enter here the
MAX. DTE Rate in Bits Per Seconds, For Example >38400
IF Locked the -C parameter need to be used, otherwise the -B Parameter
for this purpose more later in this documentation.
Locked Rate in Bits Per Second [ Press ENTER = NON ]......>
Enable/Disable Write Buffer, this option is Default Disabled, however
IF Enabled it CAN improve your CPS rate!
IF Enabled it will use an 32 Kbyte RAM Buffer between the I/O Matrix
System of ZyRion and your HardDisk.
Enable W_Buffer [ 32 Kb -- Default = OFF ] y/N............>
This option will Enable a security LOG so you can see who has called
with a Valid KEY or DEMO KEY or UNREGISTERED.
By Default this option is ON, Enabled, but IF you don't need it you -
can Disable it.
Enable Security Log (Create "Secure.log") Y/n.............>
Now we need to set the FIFO Transmit Interrupt Bytes, NOT needed
If you have NO 16550A.. Installed, by default ZyRion will set this
to 8!
Setting FIFO TX Interrupt Bytes to [ Default=8 ]..........>
IF you have a multitasker installed it would be better to use the -
Verification I/O sequence, to be sure that DOS will verify for -
proper read/write operations, Also IF you have a slow system this -
option need to be set to Y=ON!
This option will slow down ZyRion a litle bit .004% but it is a safe
way, therefore this option is set by default to ON.
Set Write/Read Verification Y=ON N=OFF [ Default=ON ].....>
By Default ZyRion uses Direct Screen writes, but you can Disable this
method and use BIOS instead.
Use BIOS Screen writes, y/N [ Default = No ]..............>
ZyRion will "AUTO READ" your IRN number IF a key excist, otherwise it
will be Disabled "000000000000" means, No KEY found, UNREGISTERED!
Internal Rev. Number....... [ ZCR Mode ] IRN..............>ZR??????????
How many HEADER Retry's should ZyRion do, before give up (Timeout).
Default = 12, This includes extra frames and error retry's!
Header Retry Counter, Sender only [ Default = 12 ]........>
This will force the receiver to use a alternate Download Path
whatsoever, the Download path on the command line, will be -
IGNORED!
IF you want a variable Download Parameter use [ ENTER ] here!
Default Download Path, or Press [ RETURN ] for NON........>
Here you can define how you want the calculation, in CPS or
in BPS or in "%"-Efficiency, IF you press Return here "%" -
will be used (Default).
CPS display unit E)fficiency in % or C)ps or B)ps.........>
By Default ZyRion will send SubPackets with a size from 4096
bytes, however you are free to change them, the range is from
128 bytes - 4096 bytes, If you set the SubPacketSize to 128
bytes then ZyRion will NOT exceed this size!
However IF you have a REAL BAD phone line (central), then you
can set the SubPacketSize to lower Packets, for Example 1024
bytes, to advoid large retransmissions on Error hits, to keep
the CPS rate in a good margin.
Define SubPacket Size [ Range 128 - 4096 ]................>
If you want you can Disable the Automatic hardware Handshake
by default this is set to CTS/RTS (Normal Operation).
Disable Automatic Hardware Handshaking y/N................>
And at last you can Enable the Automatic Software Handshake
XON/XOFF!
Disable Automatic Software Handshaking Y/n................>
Now Press Enter to close the PRM file, and this section is
done.
You are ready to use ZyRion, but _before_ you need to know
the parameters, needed for the proper operation.
PARAMETER LIST
--------------
R <______> First parameter R = RECEIVE Lower or Uppercase "R|r"
S <______> First parameter S = SEND Lower or Uppercase "S|s"
-P <______> Second parameter [ -Pn where n = portnumber ]
-B <______> Third parameter [ -Bnnnnnn Baud rate REAL or 0 = Abarated ]
-C <______> Third parameter [ -Cnnnnnn Baud rate CONNECT from Modem ]
Use this one IF your DTE rate is constant [ LOCKED! ]
@ <______> Send files from control file @SEND.CTL <-- ASCII PLAIN FILE
. <______> In receive mode, indicate current path
Setupn <__> Setup or Re-Setup n where n is the Portnumber
ZYRION EXAMPLE
--------------
ZyRion and interface problems are NOT easy for some end users, so let me
try to help you.
First we know that we need the Port number [ COMX ], the Baudrate in BPS
and the Up/Download Parameters, or IF Locked the Connect Rate.
A lot of people searching in Docs and compare that with the Docs from -
protocols, and then they hope that there is a answer somewhere.
Most of the times you got stuck, becauce all kind of variable from the
Terminal Communication Software.
Lets assume we have a terminal called "TelComm" but you got stuck, now
there is a simple method to find out what the passed variables are.
Please note that ZyRion will Ignore batch transfers in UNREGISTERED Mode!
Create a batch file called "GETVAR.BAT".
Put in this batch file the following statements :
COPY CON GETVAR.BAT
ECHO OFF
CLS
ECHO %1
ECHO %2
ECHO %3
ECHO %3
ECHO %4
ECHO %5
ECHO %6
ECHO %7
ECHO %8
PAUSE
^Z
Now that we have created this batch file, let it call by your terminal -
package, in our case "TelComm".
First call this batch file in receive mode, and you'll see something like
this :
C:\NEWFILES\ [1]
8 [2]
N [3]
2400 [4]
4 [5]
Write this down, and do the same in Transmit mode, and you'll see some -
thing like this :
0 [1]
8 [2]
N [3]
C:\TEMP\MYFILES\TELEM*.* [4]
2400 [5]
4 [6]
Write this down to, ofcource you'll get other variables but its for that -
you got the idea.
Now with the above parameters we can make a ZSend.bat and a ZRcvd.bat for
ZyRion.
This would be look like this, NOTE: Not locked!
COPY CON ZRCVD.BAT (Receive)
ECHO OFF
CLS
ZYRION R -P%5 -B%4 %1
^Z
You'll get this : ZYRION R -P4 -B2400 C:\NEWFILES\
COPY CON ZSEND.BAT
ECHO OFF
CLS
ZYRION S -P%6 -B%5 %4
^Z
You'll get this : ZYRION S -P4 -B2400 C:\TEMP\MYFILES\TELEM*.*
Now we do the same but this time we know our terminal package is locked
and ZyRion also at 38400 Bits Per Second DTE rate.
C:\NEWFILES\ [1]
8 [2]
N [3]
2400 [4]
4 [5]
38400 [6]
Write this down, and do the same in Transmit mode, and you'll see some -
thing like this :
38400 [1]
8 [2]
N [3]
C:\TEMP\MYFILES\TELEM*.* [4]
2400 [5]
4 [6]
Write this down to, ofcource you'll get other variables but its for that -
you got the idea.
Now with the above parameters we can make a ZSend.bat and a ZRcvd.bat for
ZyRion.
This would be look like this, NOTE: locked!
COPY CON ZRCVD.BAT (Receive)
ECHO OFF
CLS
ZYRION R -P%5 -C%4 %1
^Z
You'll get this : ZYRION R -P4 -C2400 C:\NEWFILES\
COPY CON ZSEND.BAT
ECHO OFF
CLS
ZYRION S -P%6 -C%5 %4
^Z
You'll get this : ZYRION S -P4 -C2400 C:\TEMP\MYFILES\TELEM*.*
Final the @<control File> option, this can be usefull if you send a lot of
files, since DOS will not allow that many.
All you need to do is REPLACE the %4 parameter with @MYCTL.CTL
At this point ZyRion will process the plain Ascii file, your control file
and ZyRion will send all files listed in this control file in batch mode
You need to have a registered version for this purpose, since ZyRion will
NOT allow Batch Transfers in UNREGISTERD Mode!
Sample control file
MYCTL.CTL
C:\TEMP\FLIB20.ZIP
D:\DOS\CHKDSK.EXE
A:\TERM312.ZIP
And so on, you can make this list so long as you want.
In the above Examples we used the method like below :
ZYRION S -P4 -C2400 C:\TEMP\MYFILES\TELEM*.*
But you can also do this :
ZYRION S -P4 -B9600 C:\*.ZIP A:\*.ARJ D:\TE*.* B:\*.GIF [ and so on ].
Thats all you'll need to do, and ZyRion will work!
FILES
-----
You need to set the statement FILES= at least to 20, so FILES=20!
Otherwise ZyRion will abort, because it need to open a lot of files in
some cases.
Also the best performance will be on a 386 or 486 based PC or better!
╔══════════════╗
║ ╔════════╗ ║
║ ║ ║ ║
╚══╝ ╚══╝
A product From
International Communication
Research
╔══╗ ╔══╗
║ ║ ║ ║
║ ╚════════╝ ║
╚══════════════╝