Beijing Paradise BBS Backup/PARADISE.ISO/software/BBSDOORW/CDCOM.ZIP/PROTOCOL.DOC

Text File | 1991-10-13 | 11.6 KB | 291 lines

Supplemental doc file CdCom protocols.

Protocols for CdCom are dynamic, meaning you can add/modify/delete at will.

All protocols mentioned in this doc file will be posted on His Board
[phone] 1200/2400/9600 14.4k.  They are all FREQ'able by filenames
mentioned in this doc file.


PROTOCOL FILES:

PROTOCOL.BBS   -  Menu dump file for protocols (ansi = .scr)
PROTOCOL.DEF   -  Main configuration file that CdCom reads
PROTOCOL.BAT   -  Protocol batch file.
PROTOCOL.DOC   -  This file

PROTOCOL.BBS:

This is a simple text file that is dumped to the user when they change
or select a protocol.  It does not reflect what protocols are really
active.  You can modify this at will to have whatever format you like.
I include a sample one in the distribution file but you don't have to
keep that format.  For an ansi menu make this a .SCR extension.

PROTOCOL.DEF:

This is the main configuration file for adding/modifying/removing
protocols.  Format goes as follows:

The first line is the number of protocols you will be supporting.

The other lines, the protocol identification lines, must follow this
format:

1    2    3  4   5   6   7    8   9   10  11
----------------------------------------------
z,Zmodem,30,115,225,450,940,1200,1400,0,s or b

1:  Menu select command.  If the user presses z then they will get
    zmodem in this example.  I reserve Q and q for <Q>uit back to Menu.
    All other letters, numbers, characters are fair game. I convert it to
    upper case (if its a letter) in the program.  This must only
    be a single character.

2:  Protocol name.  This is the name that will be shown to the user
    when they select a protocol, also the name that will be passed to
    the protocol.bat file.  Insure you match this name exactly with the
    test name (%1 ==) in the batch file as it is case sensitive.  This
    name is also used in the log entries.

Items 3-9 are the character/second transfer rates for the given
protocol and baudrate.  This value is given to you by protocols like
DSZ and superk when the transfer is complete.  Other packages may do the
same.  If not you will have to time it yourself.  This gives you the option
to tweak them to your hearts desire at will for each protocol and baudrate.
These are the values that will be used when calculating file transfer times.
I do file transfer time calculations by a division, filesize/char_sec,
where char_sec is the characters per second you enter on these lines.
I don't know if this is the correct way to do it, but it comes out exactly
to what these protocols report so I figured it must be right.

 3:  ch/sec for 300 baud
 4:  ch/sec for 1200 baud
 5:  ch/sec for 2400 baud
 6:  ch/sec for 4800 baud
 7:  ch/sec for 9600 baud
 8:  ch/sec for 19200 baud
 9:  ch/sec for 38400 baud

10: This is the DOS errorlevel that is passed for a successful
    file transfer.  Most large packages like DSZ and superk pass
    an errorlevel 0 for success, 1 for any error.  CdCom will check
    this on return.  If a non-success error code is returned it will
    ask the user if they want to re-attempt the transfer, saving the
    hassle of going thru the download process again.  Note that if your
    protocol is not pathed or cannot be found (bad command or filename
    from dos), a 0 will be returned back into the program, and cdcom
    has no way of knowing this happened, and will think the transfer went
    ok.  So make sure your protocols can be found by the protocol.bat file,
    either by having them pathed or in the same directory.

11:
    This specifies whether or not the protocol is a batch or single
    file protocol.  To be batch the protocol has to be able to read
    a filename for the files to transfer.  DSZ, Puma, and Lynx (that
    I know of) do this with a @ before the filename.  Ex:
    @c:\cdcom\batch.dsz
    passed to DSZ will tell it to read the filename c:\cdcom\batch.dsz
    for the filenames to send.  This does away with the dos command line
    limitation for most protocols.  CdCom will automatically put the @,
    use the path from line 2 of cdcom.def and then add the \batch.dsz
    so all you need to do is check to see if the protocol supports the
    @filename convention or not.  This file is overwritten each time
    a transfer occurs.

    For multi-node setups a BATCH#.DSZ will be written/passed, where # is
    the node number they are on so there will be no collisions.

Sample PROTOCOL.DEF file:

The ch/sec rates may or may not be correct.  I did not verify most
of them so you may want to check them.

13
z,Zmodem,30,115,225,450,940,1200,1400,0,b
t,MobyTurbo,30,115,225,450,940,1200,1400,0,b
w,Wxmodem,30,110,210,450,940,1000,1200,0,s
y,Ymodem,30,110,175,400,900,900,1000,0,s
b,Ymodem-Batch,30,115,210,410,920,1000,1100,0,b
x,Xmodem,30,100,175,390,880,900,950,0,s
s,Sealink,30,100,175,390,880,900,950,0,s
m,Megalink,30,100,175,390,880,900,950,0,s
k,Kermit,30,100,175,390,880,900,950,0,s
9,K9Xmodem,30,100,175,390,880,900,950,0,s
j,Jmodem,30,100,175,390,880,900,950,0,s
8,Super8K,30,100,175,390,880,900,950,0,s
l,Lynx,30,100,175,390,880,900,950,0,b

IF THIS IS TOTALLY CONFUSING:

If this is your first time using file transfer protocol programs, then your
best bet is to just use DSZ initially.  It supplies Xmodem (Checksum and
CRC), 1k Xmodem (also called Ymodem), Ymodem-Batch, Zmodem and the Zmodem
derivative MobyTurbo.  Ymodem-G is also offered for registered versions
of dsz.  Call the DSZ bbs (see number is dsz section below) and get the
latest version, or it may be on a local bbs.  If you find it on a bbs it
will usually have the date in the filename also, like dsz0703.zip would
mean dsz version date july 3.  Either source for dsz is fine, however I
always get the latest dsz from the support bbs due to bad copies I've come
across in the past from the local bbs's.

The protocol.bat supplied should work for 2400 baud and less systems,
and for 9600 systems the ha on will have to be added to the line
for zmodem, ymodem-batch and moby-turbo protocols.  This is covered
in the protocol.bat file.  Then simply put the dsz program somewhere
in your active dos path (like a utilities sub directory that you have
pathed using the PATH command), or in the same directory as cdcom if
you want, and your ready to go.  The protocols supplied by dsz should be
more than enough for any system initially, and you can add others later
as you get more comfortable with the programs (cdcom and protocol programs).

Your basic protocol.def would then look like so (you could mark this block
and write it to a protocol.def file if you wanted):

5
z,Zmodem,30,115,225,450,940,1200,1400,0,b
t,MobyTurbo,30,115,225,450,940,1200,1400,0,b
y,Ymodem,30,110,175,400,900,900,1000,0,s
b,Ymodem-Batch,30,115,210,410,920,1000,1100,0,b
x,Xmodem,30,100,175,390,880,900,950,0,s

protocol.bbs would look like this:

[B] Ymodem-Batch, [X]modem, [Y]modem (Xmodem-1K), [Z]modem
[T] MobyTurbo, [Q]uit

Like I mentioned above you shouldn't need to edit the protocol.bat file
unless you are running 9600.  In that case just un-rem the 9600 line
for zmodem, mobyturbo and ymodem-batch (and rem the other line without
the ha on) and your set.

PROTOCOL.BAT:

In this file are some examples for various protocol packages.
The examples in there should work with no problem for 2400 baud systems,
and will need a little modifying for 9600 systems (handshaking for certain
protocols needs to be added).  This is the same protocol.bat I use when
testing the program, so one would think it would work <grin>.

It will still be up to you however to read the docs for each protocol to
get it to work correctly on your system, especially if you are running
locked port or anything like that.  Dsz does not need to be told information
like this, in fact it is the easiest to use in that respect, but other
protocols may need such information.

Cdcom passes the following parameters via DOS variables %1, %2, %3, %4,
%5 and %6 to protocol.bat for use with the protocols.

%1 - Protocol name

%2 - Port number [1-4].

%3 - Baud Rate.  This is the value it reads from CALLINFO.BBS line 2.
     This is not the locked port speed (or at least it should not be).

%4 - Filename to be sent.  Remember for batch downloads this will actually
     be a list of filenames not individual filenames.

%5 - Port Rate.  This will be the locked rate if port is locked.  It is
     read from CALLINFO.BBS line 31.

%6 - Node number.  Although this is not used by the protocols, you can use
     it for testing which node you are on, in case you need it.

FILE PROTOCOL PROGRAMS:

DSZ:

DSZ supports Xmodem, Xmodem CRC, Xmodem 1k (also called Ymodem),
Ymodem Batch, Ymodem-G and Zmodem.  Versions after 06-07-88 must be
registered (ie: run putsnp) before Ymodem-G will work.  All new
versions also added MobyTurbo Zmodem, which supposedly gives
Ymodem-G transfer times with Zmodem 32 bit error detection (best of
both worlds?).  It requires little setup parameters, as it reads the
com information from the uart and goes from there.  In fact on most
systems you can just type dsz rz and you can recieve a file with zmodem.

You can get the latest version of DSZ from the dsz bbs at [phone].
Download as DSZ.ZIP.

DSZ uses the comport at whatever baud rate it is currently set at.
There is no need to tell it what baud rate to use.

The examples in the protocol.bat should work for most systems.  You
may need to turn handshaking on (ha on) for those with locked ports
or with high speed modems.  ex: dsz port %2 ha on sz %4

For the Xmodem protocol DSZ will check for checksum or CRC error
detection automatically.  You don't need two selections for xmodem
like most bbs packages do.

For the 9600 systems, here is the change you need to make:

for 2400: dsz port %2 sz %4
for 9600: dsz port %2 ha on sz %4

SUPERK:     (SUPERK44.ZIP)

Superk supports Xmodem, Xmodem CRC, Ymodem (Xmodem 1k), WXmodem (windowed
xmodem), Jmodem, K9Xmodem, Super8K and MNP Super8K-G.  These are the
ones supported in Ver 4.4.  Earlier versions like 3.3 do not support
the MNP Super8k or Jmodem.  There are also command line differences
between the versions (I have only seen 3.3 and 4.4).  Version 4.4
will be posted on His Board if you are interested in it, otherwise
the latest version of the program can be obtained at the authors BBS
at [phone] 12/24/9600.  Its been a long time since I've messed
with superk so your on your own with this protocol package.  If I'm
not passing sufficient information to protocol.bat for superk to
work correctly, let me know.

Superk requires that you pass it the port number and baudrate.  These
are passed via %2 and %3 from CdCom.  It may also require the locked
port speed.

Examples (for ver 4.4):

Px      - Comm Port to use.
Sbaud   - Port Speed.
F name  - Filename to xfer

Protocols:
S is for Send.

X = Xmodem
C = CRC Xmodem
Y = Ymodem (1k Xmodem)
W = WXmodem
J = Jmodem
K = K9Xmodem
S = Super8K
M = MNP Super8K-G

Wxmodem
superk p%2 s%3 sw f %4

Super8k
superk p%2 s%3 ss f %4

for ver 3.3 an example would be:

t=protocol to use (same as above, sans J and M)
d=direction of transfer (s=send)

Super8k
superk p%2 s%3 ts ds f%4

Wxmodem
superk p%2 s%3 tw ds f%4

Other protocols available:

PCZ0221.ZIP   - Sealink, Zmodem, Xmodem Chksum/CRC, Xmodem 1k (Ymodem) Ver 2.21
CLINK120.ZIP  - Sealink + C Source   Ver 1.2
MLINK16.ZIP   - Megalink  Ver 1.6

No option for Bi-Modem at this time, since it requires special files
to be created.  I have yet to put any serious time into bi-modem so
dunno if it feasible or not to work with the door.