home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
ftp.wwiv.com
/
ftp.wwiv.com.zip
/
ftp.wwiv.com
/
pub
/
PROTOCOL
/
SDP101G.ZIP
/
SDP.DOC
< prev
next >
Wrap
Text File
|
1993-08-27
|
73KB
|
1,649 lines
Streamline Design Protocol Module Version 1.01d
CopyRight (C) 1993 Streamline Design (984502 Ontario Inc.)
All Rights Reserved
Voice: (416)790-1997 10:00am to 6:00pm
BBS : (416)793-1411 24 Hours a Day
Table of Contents
1 - Introduction
2 - Liscencing
3 - Future Plans
4 - Quick Reference
5 - ASCII
6 - XModem
7 - YModem
8 - ZModem
9 - Kermit
10 - General
11 - Flip Screens
12 - Additional Programs
13 - Registration
1 - Introduction
The Streamline Design Protocol Module, aka SDP, was designed to
allow the transfer of data from various platforms. It will work
in DOS, PS2, OS2, Windows, Networked, and any of the previous
emulated environments. The goal of SDP is to make it easy to
transfer data with a great amount of flexibility and ease of
use.
SDP supports the following protocols: ASCII
XModem
XModem Relaxed
XModem/CRC
XModem/CRC Relaxed
XModem-1k
XModem-1k Relaxed
XModem-1kG
XModem-1kG Relaxed
Ymodem
YModem Relaxed
YModemG
YModemG Relaxed
YModem-128
YModem-128 Relaxed
ZModem
ZModem-8k
Kermit
If you have any comments or suggestions about this product we
would be glad to hear from you about them.
The following is a list of machines and environments this
product has been tested on:
Environments
- DOS
- Lantastic
- MS Windows 3.xx
- Novell
Hardware
- Phillips 486/25 EISA
- Phillips 386/33 ISA with Phoenix BIOS
- Intel 386/33 ISA with AMI BIOS
- Intel 9600EX Modem
- USR Robotics 19200 Modem
- Generic 2400 Modem
2 - Liscencing
This program is NOT public domain and is (c)Copyrighted
1993 by Thomas S. Thayer with all rights reserved. It may
not be distributed for personal gain under any circumstances.
The SDPxxx.ZIP file in its original form may be copied or
distributed thru Bulletin Board systems provided no fee is
charged for its distribution and no modifications are made to
the program files contained therein.
User Supported Software is a way for you to review a
program on a trial basis and test its operation on your
system prior to purchasing it. Under this type of
distribution system, you are insured that the program meets
your needs and requirements. You may review this program
for a period of 30 days, free of charge, after which, you
must either order a copy or remove it from your system.
This software is provided on an "As Is" basis without
warranty either implied or expressed of any kind. Thomas S.
Thayer, the author and sole owner of this software, takes
no responsibility for loss of data or damage to equipment
thru the use of this software. Should the software prove
defective the entire burden of any and all repairs and
replacements and/or data restoration rests with the user. In
no event will the author be liable for any costs and/or
losses either tangible or intangible arising from the use of
this software.
3 - Future Plans
In future updates we plan to implement as many suggestions
and enhancements as is possible. The following is a list of
future enhancements already planned:
- Multi port operation. Currently working with an eight port
DIGI board.
- Background Transfers
- Sealink
- Telink
- BPlus
- Bi-directional operation
4 - Quick Reference
A command that accepts an argument will always have a '=' preceding the
argument.
##### - Numeric Value
$$$$$ - ASCII Numeric Value
CCCCC - Character or String Value
????? - Boolean Value (On/Off)
ASCII Commands
Command Description Args Default
------- ---------------------------------------------------- ----- -------
sa Sends a file using the ASCII protocol N/A N/A
ra Receives a file using the ASCII protocol N/A N/A
acl The amount of time to pause, (in milliseconds), ##### 0
between lines
acd The amount of time to pause, (in milliseconds), ##### 500
between characters
ae Sets the character used to mark the end of a line $$$$$ 13 (CR)
az Specifys whether to suppress the Ctrl Z when ????? False/Off
transferring files
XModem Commands
Command Description Args Default
------- ---------------------------------------------------- ----- -------
xrx Use XModem in the relaxed state N/A N/A
sx Send a file using XModem N/A N/A
sxc Send a file using XModem/CRC N/A N/A
sxk Send a file using XModem-1k N/A N/A
sxg Send a file using XModem-1kG N/A N/A
rx Receive a file using XModem N/A N/A
rxc Receive a file using XModem/CRC N/A N/A
rxk Receive a file using XModem-1k N/A N/A
rxg Receive a file using XModem-1kG N/A N/A
YModem Commands
Command Description Args Default
------- ---------------------------------------------------- ----- -------
sy Send a file using YModem N/A N/A
syg Send a file using YModemG N/A N/A
ry Receive a file using YModem N/A N/A
ryg Receive a file using YModemG N/A N/A
n1k Do not use 1k, (1024 byte), blocks ????? false/off
nrx Do not use YModem in the relaxed state ????? false/off
ZModem Commands
Command Description Args Default
------- ---------------------------------------------------- ----- -------
sz Send a file using ZModem N/A N/A
rz Receive a file using ZModem N/A N/A
rzr Set up ZModem to allow file recovery ????? false/off
zf1 Overwrite the existing file if the incoming file ????? false/off
is newer or longer than the existing file
zf2 Currently acts the same as zf4 ????? false/off
zf3 Write the transmitted file no matter what ????? false/off
zf4 If the file is new write it, otherwise append it to ????? false/off
the end of the existing file
zf5 Write the file if it is new, or newer than the ????? false/off
existing file.
zf6 Write the file if it is new, or if its date or size ????? false/off
is different from the existing file
zf7 Write the file only if it is new ????? true/on
z8k Use large, (8k/8192 byte), with ZModem ????? false/off
zov When receiving a file ignore the transmitting ????? false/off
systems file management options and use the receiving
systems file management options
skn Skip all incoming files that don't already exist on ????? false/off
the receiving system
Kermit Commands
Command Description Args Default
------- ---------------------------------------------------- ----- -------
sk Send file using Kermit N/A N/A
rk Receive a file using Kermit N/A N/A
kpl Set the maximum length of the data field ##### 80
mto Set the maximum time out between characters in secs. ##### 5
kpc Set the number of pad characters before packets ##### 0
kpk Set the pad character $$$$$ 0 (NULL)
ktm Set the packet terminator $$$$$ 13 (CR)
kcp Set the control character prefix $$$$$ 35 (#)
khp Set the 7bit quoting prefix $$$$$ 89 (Y)
kch Set the check method $$$$$ 49 (1)
krp Set the repeat prefix $$$$$ 126 (~)
kml Set the maximum length for a long packet ##### 0
kws Set the Kermit window size ##### 0
ktd Set the turn around delay for Kermit ##### 1000
kns Do not strip names in kermit ????? false/off
General Commands
Command Description Args Default
------- ---------------------------------------------------- ----- -------
gid Include directory with file names ????? false/off
ghd Honor directory in file names ????? false/off
grl Lower RTS during disk writes ????? false/off
dhw The amount of time, (in clock tics), to wait ##### 182/10 sec
before retrying a handshake signal
dhr The maximum number time to retry before aborting ##### 10
transfer
dtt The number of tics to wait for a receiver flow ##### 1092
control release
dsi The amount of time to wait between updates to the ##### 91/5 secs
status screen in tics
bfc The fill character for partial protocol blocks $$$$$ 26 (^Z)
gho The hour offset to correspond the GMT ##### 0
td Set the Telix delay, (in tics),will usually never ##### 9
need this.
dd Set the destination directory for received files CCCCC blank
fln Set the name for the file log CCCCC blank
oh Set the number of bytes per block ##### N/A
std Set the time, (in milliseconds), that it takes the ##### N/A
block to get to the remote, for the remote to
acknowledge and for that acknowledgement to reach us
fs Force the Status updates ????? True/On
si The amount of time to wait between updates to the ##### 91/5 secs
status screen in tics
sab Set the actual BPS (needed only if modem differs ##### N/A
from port)
soo Set option for what to do when the destination file ##### 1
already exists
ugd Use the graphical/Color status screen rather than the ????? false/off
ASCII screen
@fl The path and name to the list of files you wish to CCCCC blank
transfer
com The comport to use with this session ##### 1
bd Override the baudrate with this value ##### N/A
irq Define Non-Standard IRQs and/or base address CCCCC N/A
fnm Name for file to be transferred or received CCCCC blank
inb Set the size of the input buffer ##### 4096
otb Set the size of the output buffer ##### 4096
par Override the parity type CCCCC N/A
stb Override the Stop Bits ##### N/A
dtb Override the data bits ##### N/A
hud Use DTR for Receive Flow Control ????? false/off
hur Use RTS for Receive Flow Control ????? true/On
hrd Require DSR before transmitting ????? false/Off
hrc Require CTS before transmitting ????? true/on
hdl Make DTR Active Low ????? false/off
hrl Make RTS Active Low ????? false/off
hsl Make DSR Active Low ????? false/off
hcl Make CTS Active Low ????? false/off
rpg Return partial strings from the input buffer ????? true/on
rd Return the delimiter character from the input buffer ????? true/on
epp Execute partial puts to the output buffer ????? true/on
idc Ignore the case justification on delimiter chars ????? false/off
roc Restore the UART when ending a session ????? false/off
dmc Hangup the modem when finished with session ????? false/off
rmo Raise the DTR and RTS signals when SDP is started ????? true/on
idt Do not initialize port with DTR low ????? false/off
irt Do not initialize port with RTS low ????? false/off
pcb Display PCBoard Users name in Info screen ????? false/off
dsz Adhere to DSZ standards ????? false/off
5 - ASCII
The term ASCII is a bit of a misnomer. In an ASCII transfer neither
side adheres to any agreed upon rules for data transfer. An ASCII
protocol is really just a convenient way of transferring a text or
ASCII file.
A good example of a situation where you may use an ASCII protocol is
when the machine you are linked with doesn't support any type of
protocol. One such situation would be the need to transfer a text
file to a minicomputer that does not have protocol ability. To solve
this issue you would connect your PC to the mini as a terminal,
start up the minicomputers editor, open a new text file, and start
an ASCII transfer of the file you wished on the mini. The mini
would see the characters being transmitted as keystrokes and input
and input them to the editor. You would then finish the transfer
by saving the contents in the editor to a file on the mini.
SDP provides options that will allow the user to tailor the transfer
of data so it matches the receiving machines speed. Such options are,
delays between transmitted characters and lines. In the above example
you may need to set these type of delays in order to stop the overflow
of the editors keystroke buffer.
When receiving data using an ASCII protocol it is difficult to know
when the transfer is finished. This is because there is no agreed
upon method for telling the receiver when the transfer is complete.
SDP will terminate the transfer when it receives one of the following
three conditions: when it receives a ^Z, (This can be suppressed, or
changed), when it times out waiting for data, or when the user aborts
the protocol.
The ASCII protocol does not support batch transfers.
Options
sa - This command has no arguments and simply starts the transfer
of the file specified by the fnm command.
ie: SDP sa fnm=c:\sdp\test.txt
The above would transfer/Upload a file named test.txt from
a directory named SDP on the C drive.
ra - This command has no arguments and simply receives data and
stores it to the file specified by the fnm command.
ie: SDP ra fnm=c:\sdp\test.txt
The above would receive/download to a file named test.txt in
a directory named SDP on the C drive.
acl - This command accepts numeric argument that specifies the amount
of time, (in milliseconds), to wait between sending lines of
data. The default is 0. This means it will just send line
after line without any pause whatsoever.
ie: SDP sa acl=500 fnm=c:\sdp\test.txt
The above would transfer/Upload a file named test.txt from
a directory named SDP on the C drive and wait 500 milliseconds
between each line transferred.
acd - This command accepts a numeric argument that specifies the
of time, (in milliseconds), to wait between sending characters.
the default is 500. This means that the system will wait 500
milliseconds between transferring characters.
ie: SDP sa acd=0 fnm=c:\sdp\test.txt
The above would transfer/upload a file named test.txt from a
directory named SDP on the C drive and would not wait between
characters transferred.
ae - This command accepts a numeric value that represents the ASCII
value of the character you wish to use for a EOL, (End of Line),
signal. The default is a carriage return, (13). This character
is assumed to mark the end of a line.
ie: SDP sa ae=26 fnm=c:\sdp\test.txt
The above would transfer/upload a file named test.txt from a
directory named SDP on the C drive and would assume the end of
a line everytime a ^Z was received.
az - This command has no arguments and simply specifies whether you
wish to suppress the ^Z that signifies the end of a file.
ie: SDP sa az fnm=c:\sdp\test.txt
The above would transfer/upload a file named test.txt from a
directory named SDP on the C drive and would not send a ^Z
when the transfer is finished.
6 - XModem
XModem is the oldest protocol supported by SDP. It was first
developed by Ward Christensen in 1977 and then placed in the public
domain. It became a very popular protocol and is still in wide use.
However, it's use has diminished over the years as faster and more
efficient protocols arrived.
XModem is also the simplest, and perhaps the slowest, protocol
supported by SDP. XModem uses 128 bytes blocks, requires an
acknowledgement of each block, and uses only a simple checksum
for data integrity.
SDP provides a few options for better speed and flexibility when
using XModem. Such options are 1024 byte(1k) blocks, CRC checks,
G Mode, and relaxed mode.
The XModem protocol does not support batch transfers.
Options
xrx - This command has no arguments and simply puts the XModem
transfer into relaxed mode. Relaxed mode simply sets the
time out for XModem to 10 seconds rather than the default
of 5 seconds.
ie: SDP rx xrx fnm=c:\sdp\test.txt
The above would receive/download to a file named test.txt in a
directory named SDP on the C drive. It would also set the
XModem timeout to 10 seconds.
sx - This command has no arguments and simply starts the transfer
a file specified by the fnm command using XModem.
ie: SDP sx fnm=c:\sdp\test.txt
The above would transfer/Upload a file named test.txt from
a directory named SDP on the C drive.
sxc - This command has no arguments and simply starts the transfer
a file specified by the fnm command using XModem/CRC. XModem/CRC
is an improvement on the original XModem. It provides a 16 bit
CRC (cyclic redundancy check) block check for the original
checksum. This gives you a higher level of data integrity.
ie: SDP sxc fnm=c:\sdp\test.txt
The above would transfer/Upload a file named test.txt from
a directory named SDP on the C drive.
sxk - This command has no arguments and simply starts the transfer
a file specified by the fnm command using XModem-1k. XModem-1k
is an improvement on the original XModem. It provides a 16 bit
CRC (cyclic redundancy check) block check for the original
checksum as well as using 1024 byte blocks rather than the
original 128 byte blocks. This gives you a higher level of data
integrity and a faster transfer.
ie: SDP sxk fnm=c:\sdp\test.txt
The above would transfer/Upload a file named test.txt from
a directory named SDP on the C drive.
sxg - This command has no arguments and simply starts the transfer
a file specified by the fnm command using XModem-1kG. XModem-1kG
is an improvement on the original XModem. It provides a 16 bit
CRC (cyclic redundancy check) block check for the original
checksum, uses 1024 byte blocks rather than the original 128 byte
blocks, and performs a streaming transfer. A streaming transfer
means that the transmitter continuously transfers blocks without
waiting for acknowledgements. This gives you a higher level of
data integrity and a faster transfer, but it should never be used
with non error correcting modems. If you are using a non error
correcting modem, and the receiver receives a bad block, the
transfer will be aborted.
ie: SDP sxg fnm=c:\sdp\test.txt
The above would transfer/Upload a file named test.txt from
a directory named SDP on the C drive.
rx - This command has no arguments and receives data and stores it to
a file specified by the fnm command using XModem.
ie: SDP sx fnm=c:\sdp\test.txt
The above would receive/download to a file named test.txt in
a directory named SDP on the C drive.
rxc - This command has no arguments and receives data and stores it to
a file specified by the fnm command using XModem/CRC. XModem/CRC
is an improvement on the original XModem. It provides a 16 bit
CRC (cyclic redundancy check) block check for the original
checksum. This gives you a higher level of data integrity.
ie: SDP rxc fnm=c:\sdp\test.txt
The above would receive/download to a file named test.txt in
a directory named SDP on the C drive.
sxk - This command has no arguments and receives data and stores it to
a file specified by the fnm command using XModem-1k. XModem-1k
is an improvement on the original XModem. It provides a 16 bit
CRC (cyclic redundancy check) block check for the original
checksum as well as using 1024 byte blocks rather than the
original 128 byte blocks. This gives you a higher level of data
integrity and a faster transfer.
ie: SDP rxk fnm=c:\sdp\test.txt
The above would receive/download to a file named test.txt from
a directory named SDP on the C drive.
rxg - This command has no arguments and receives data and stores it to
a file specified by the fnm command using XModem-1kG. XModem-1kG
is an improvement on the original XModem. It provides a 16 bit
CRC (cyclic redundancy check) block check for the original
checksum, uses 1024 byte blocks rather than the original 128 byte
blocks, and performs a streaming transfer. A streaming transfer
means that the transmitter continuously transfers blocks without
waiting for acknowledgements. This gives you a higher level of
data integrity and a faster transfer, but it should never be used
with non error correcting modems. If you are using a non error
correcting modem, and the receiver receives a bad block, the
transfer will be aborted.
ie: SDP rxg fnm=c:\sdp\test.txt
The above would receive/download to a file named test.txt in
a directory named SDP on the C drive.
7 - YModem
Ymodem is basically the same as XModem-1k with batch file transfer
ability. This means a single YModem transfer can transfer as many
files as you wish. It also provides the receiver with information
about the incoming files such as: file name, size, date.
Options
sy - This command has no arguments and starts a transfer of a file
specified by the fnm command, or the @fl command, using YModem.
ie: SDP sy fnm=c:\sdp\test.txt
The above would transfer/upload a file named test.txt from a
directory named SDP on the C drive.
syg - This command has no arguments and starts a transfer of a file
specified by the fnm command, or the @fl command, using YModemG.
YModemG is a streaming protocol. A streaming protocol means that
the transmitter continuously transfers blocks without waiting for
acknowledgements. This gives you a faster transfer, but it
should never be used with non error correcting modems. If you
are using a non error correcting modem, and the receiver
receives a bad block, the transfer will be aborted.
ie: SDP syg fnm=c:\sdp\test.txt
The above would transfer/upload a file named test.txt from a
directory named SDP on the C drive.
ry - This command has no arguments and receives data and stores it to
a file specified by the fnm command using YModem. If the fnm
command is not specified you could use the dd command to specify
the destination directory and the protocol would use the incoming
filename and store it in that directory. Without the dd command
and the fnm command YModem will simply store the file, using the
incoming name, to the current directory.
ie: SDP ry
The above would receive/download a file using the incoming name
into the current directory.
ryg - This command has no arguments and receives data and stores it to
a file specified by the fnm command using YModemG. YModemG is a
streaming protocol. A streaming protocol means that the
transmitter continuously transfers blocks without waiting for
acknowledgements. This gives you a faster transfer, but it
should never be used with non error correcting modems. If you
are using a non error correcting modem, and the receiver
receives a bad block, the transfer will be aborted.
ie: SDP ryg fnm=c:\sdp\test.txt
The above would receive/download a file named test.txt in a
directory named SDP on the C drive.
n1k - This command has no arguments and simply tells SDP to use 128
byte blocks rather than 1024 byte blocks.
ie: SDP ry n1k dd=c:\sdp
The above would receive data in 128 byte blocks and store it to
a file, using the incoming name, in a directory named SDP on the
C drive.
nrx - This command has no arguments and simply tells SDP not to use the
the relaxed state for the transfer. By default, YModem uses a
XModem relaxed state. Using this option tells YModem to
implement 5 second timeouts rather than 10 second timeouts.
ie: SDP ry n1k nrx
The above would receive data in 128 byte blocks, use 5 second
timeouts, and store it to a file, using the incoming name, in
a directory named SDP on the C drive.
8 - ZModem
Zmodem was developed by Chuck Forsberg under contract to Telenet.
It was developed for the public domain and its purpose was to
provide a durable protocol with strong error recovery features and
good performance over a variety of network types (satellite,
switched, etc.). For the most part is has achieved these goals
and is by far the best choice overall.
ZModem offers the best overall mix of speed, features, and tolerance
for errors. This protocol has lots of room for growth, and many
options. Unlike XModem and YModem, Zmodem employs headers, data
subpackets, and frames. This allows ZModem to implement many
features that other protocols simply cannot achieve.
ZModem will do its best to correct errors in the transmission. It
does this by a variety of ways. It will use file recovery if the
transfer was aborted and it will also increment and decrement block
sizes to compensate for errors. For instance, if you are using the
8k option with ZModem and you get a noisy line ZModem will drop to
1k blocks and if the errors still occur will then try 512 byte blocks.
If the errors still persist it will try 256 byte blocks as a last
resort. After it has tried the 256 byte blocks, if the errors still
persist, it will abort the transfer.
ZModem offers batch transfers.
Options
sz - This command has no arguments and simply transmits a file
specified by either the fnm command or the @fl command.
ie: SDP com=2 ugd sz fnm=c:\sdp\test.txt
The above would transmit/upload a file named test.txt in a
directory named SDP on the C drive. It also uses COM 2 and
provides graphical display.
rz - This command has no arguments and simply receives a file
specified by either the fnm command or the @fl command or
the incoming name is used. The destination directory of
the file can be specified by the dd command.
ie: SDP rz dd=c:\sdp
The above would receive/download a file using the incoming name
to a directory named SDP on the C drive. It defaults to COM1.
rzr - This command has no arguments and simply instructs ZModem to
use the file recovery option. File recovery allows you to
resume a transfer at the point it left off. The following
will explain a little better:
Suppose you are doing a batch transfer of three files. To
simplify things the files are named A, B, and C.
File A = 12000 bytes
File B = 14000 bytes
File C = 25000 bytes
You start the transfer and File A is completed but when you
are at byte 7000 of file B the transfer aborts. If you
implemented the file recovery option the following would
occur:
File A would not be transferred since it already exists on
the remote system.
File B would start off at byte 7000
File C would be transferred completely.
All 3 files would be in the exact shape you wish them to be
on the remote system.
ZModem offers several file management routines. These are simple
rule that tell ZModem to accept a file or not. As a general rule
all file management specifications are defined by the transmitter.
However, SDP implements an option that allows the receiver to
override this functionality. The following is a list of file
management options. Only one option can be specified at a time.
zf1 - This command has no arguments and instructs ZModem to transfer
the file and overwrite the existing file only if the file
being transferred is newer or longer than the existing file.
zf2 - This command accepts no arguments and acts the same as zf4.
Refer to the command zf4 for more information.
zf3 - This command has no arguments and instructs ZModem to transfer
the file and overwrite the existing file regardless of anything.
zf4 - This command has no arguments and instructs ZModem to transfer
the file and overwrite the existing file only if it is new.
Otherwise, it will append to the existing file.
zf5 - This command has no arguments and instructs ZModem to transfer
the file and overwrite the existing file only if it is new or
newer than the existing file.
zf6 - This command has no arguments and instructs ZModem to transfer
the file and overwrite the existing file only if it is new or
its date or size if different from the existing file.
zf7 - This command has no arguments and instructs ZModem to transfer
the file only if the file does not exist.
z8k - This command has no arguments and simply tells ZModem to
implement large subpackets. This sets the subpacket size to
8k, (8192 bytes). This provides a faster transfer as a general
rule.
zov - This command has no arguments and simply tells ZModem to ignore
the transmitting systems filemanagement options and implement
those specified on this end of the transfer.
skn - This command has no arguments and simply tells ZModem not to
receive files that do not already exist.
9 - Kermit
This protocol was developed to enable transfers in environments that
other protocols cannot handle. Examples of these environments are
links that only pass 7 data bits, links that can't handle control
characters, computer systems that can't handle large blocks, and
other specialized links such as a PC and a mainframe.
This protocol was developed for the public domain at Columbia
University in New York City. The name Kermit actually refers to
Kermit the Frog from The Muppet Show. To receive the complete
description of this protocol write to Columbia University, Kermit
Distribution, Department OP, 612 West 115th Street, NY, NY,10025.
Options
sk - This command has no arguments and simply transmits/uploads a
file specified by either the fnm command or the @fl command.
ie: SDP sk fnm=c:\sdp\test.txt
The above transmits/uploads a file named test.txt in a
directory named SDP on the C drive using Kermit.
rk - This command has no arguments and simply receives/downloads a
file specified by either the fnm command or uses the incoming
file name. If using the incoming file name you can specify
the destination directory by using the dd command.
ie: SDP rk dd=c:\sdp
The above receives downloads a file(s), using the incoming
name(s) to a directory named SDP on the C drive using Kermit.
kpl - This command accepts a numeric argument that specifies the
maximum length of the data field for kermit.
ie: SDP rk kpl=80
The above would receive/download a file(s), using the incoming
name(s), to the current directory and set the data fields length
to 80 characters.
mto - This command accepts a numeric argument that specifies the
maximum time out between characters in seconds.
ie: SDP rk mto=10
The above would receive/download a file(s), using the incoming
name(s), to the current directory and tell Kermit to issue a
timeout after a delay of 10 seconds.
kpc - This command accepts a numeric argument that specifies the number
of pad characters that will be transmitted before a packet. The
usual reason for implementing pad characters is that the remote
system is slow in switching from receive mode to transmit mode
and visa-versa.
ie: SDP rk kpc=10 kpk=13
The above would receive/download a file(s), using the incoming
name(s), to the current directory and tell Kermit to transmit
10 carriage returns between each packet.
kpk - This command accepts a numeric ASCII representation argument that
specifies the character to use to pad transmissions. This
command must be used in conjunction with the kpc command.
ie: SDP rk kpc=10 kpk=13
The above would receive/download a file(s), using the incoming
name(s), to the current directory and tell Kermit to transmit
10 carriage returns at then beginning of each packet.
ktm - This command accepts a numeric ASCII representation argument that
specifies the character to use for an EOL, End of Line,
character. This command should rarely be changed. It is only
required by systems that need some sort of EOL character before
they can start processing.
ie: SDP rk ktm=13
The above would receive/download a file(s), using the incoming
name(s), to the current directory and tell Kermit to send a
carriage return at the end of each packet.
kcp - This command accepts a numeric ASCII representation argument that
specifies the prefix character Kermit uses when quoting control
characters.
ie: SDP rk ktm=13
The above would receive/download a file(s), using the incoming
name(s), to the current directory and tell Kermit to use a
carriage return as the control prefix.
khp - This command accepts a numeric ASCII representation argument that
specifies whether Kermit will use high bit prefixing or not.
There two valid arguments for this command they are 89, (Y), and
78, (N).
Kermit defaults to 89, (Y).
ie: SDP rk khp=78
The above would receive/download a file(s), using the incoming
name(s), to the current directory and tell Kermit not to use
high bit prefixing.
kch - This command accepts a numeric argument that specifies the check
method that Kermit will utilize. 1 is a one byte checksum, 2 is
a two byte checksum, and 3 is a three byte CRC.
Kermit defaults to 1.
ie: SDP rk kch=3
The above would receive/download a file(s), using the incoming
name(s), to the current directory and tell Kermit to verify the
integrity of each packet by using a three byte CRC.
krp - This command accepts a numeric ASCII representation argument that
specifies the repeat prefix character that will be used when
Kermit compresses repeat strings of characters.
Kermit defaults to 126, (~).
ie: SDP rk krp=13
The above would receive/download a file(s), using the incoming
name(s), to the current directory and tell Kermit to use a
carriage return as the repeat prefix character.
kml - This command accepts a numeric argument that specifies the
length for a long packet. A long packet is an extension to
standard Kermit that permits data packets of up to 1024 bytes.
Long packets can substantially improve protocol throughput on
relatively clean connections that have small turnaround
delays. To keep within the design intentions for long packets as
expressed in the Kermit Protocol Manual, long packet support is
turned off by default and must be specifically enabled.
In most cases it will probably be turned off at the remote end as
well.
Kermit defaults to this option being set off.
ie: SDP rk kml=1024
The above would receive/download a file(s), using the incoming
name(s), to the current directory and tell Kermit to use a
packet length of 1024 bytes.
kws - This command accepts a numeric argument that specifies the
size of the sliding windows you will be using.
Sliding Windows Control, also called "SuperKermit.", provides a
send-ahead facility that can dramatically improve protocol
throughput under conditions where turnaround delays tend to be
large, such as across satellite links. "Send-ahead" means that
the transmitter sends many blocks at once, without waiting for
an acknowledgement for each block. It collects acknowledgements
when they eventually arrive and marks the previously transmitted
blocks as acknowledged. This minimizes turnaround delay (the
time it takes the receiver to send an acknowledgement) to zero --
significantly improving throughput.
SWC works by keeping a circular table of transmitted packets --
the maximum number of packets in this table is called the
"window size." The window size is selected at runtime and must
be between 0 and 31 (0 meaning no sliding window support). If the
transmitter and receiver specify different window sizes the
smaller of the two will be used.
As each packet is transmitted it is added to the table. When an
acknowledgment is eventually received for that packet the table
is rotated (i.e. the oldest acknowledged packet is discarded).
If the table fills the transmitter won't send any more packets
until it receives acknowledgements for one or more existing
packets.
SDP doesn't allow mixing of long packets and SWC. While it's
theoretically possible to do so (and the Kermit Protocol
specification allows it) the memory required would excessive.
Since we expect the majority of Kermit implementations to be
aimed at BBS and general-purpose communications use, where the
link is usually PC-to-PC and turnaround delays are small, SDP
will always choose long packets over SWC.
By default SWC is off.
ie: SDP rk kws=10
The above would receive/download a file(s), using the incoming
name(s), to the current directory and tell Kermit to use a
sliding window size of 10.
ktd - This command accepts a numeric argument that specifies the turn
around delay, in tics, when using Sliding Windows Control.
Kermit defaults this to 1000.
ie: SDP rk ktd=2000
The above would receive/download a file(s), using the incoming
name(s), to the current directory and tell Kermit to set the
sliding window turn around delay to 2000 tics.
kns - This command has no arguments and simply specifies whether
Kermit will strip the directory information from file names
before sending the file name packet.
Kermit defaults this to off.
ie: SDP rk kns
The above would receive/download a file(s), using the incoming
name(s), to the current directory and tell Kermit to strip
directory information from file names before sending the file
name packet.
10 - General
These options allow you to use SDP in a myriad of ways and in many
environments. These control things such as DTR, RTS, CTS, DSR,
graphical displays, destination directories, etc.
Options
gid - This command has no arguments and simply tells SDP to include
directory names in the file information packet when transmitting
files. Not all protocols support file information packets.
ie: SDP sz gid fnm=c:\sdp\test.txt
The above would transmit/upload a file named test.txt from a
directory named SDP on the C drive. It would also include
c:\sdp\test.txt in the file info packet as opposed to test.txt.
ghd - This command has no arguments and simply tells SDP to try and
honor the incoming directory names. This does not mean that it
will create directories. If the path does not exist it will
save the file in the current directory or the directory
specified by the dd command. This is not supported by ASCII and
all XModem protocols.
SDP defaults this to off.
ie: SDP rz ghd dd=c:\sdp
The above would receive/download a file(s) using the incoming
name(s). SDP will check the pathing of each file being
received and if the path exists will store the file in that
directory. If the path does not exist, it will store it in
the specified by the dd command.
grl - This command has no arguments and all SDP protocols will force
RTS off while writing received data to disk (temporarily
preventing the modem from sending additional data). RTS is
turned back on as soon as the disk write is finished. This
option might be required when running SDP under some
multi-tasking operating systems or in network environments
that leave interrupts disabled while writing to network devices.
SDP defaults this to off.
ie: SDP rz grl
The above would receive/download a file(s) into the current
directory using COM 1 and using the incoming file names. It
would also lower the RTS signal every time the data was
written to disk.
dhw - This command accepts a numeric argument that specifies the amount
of time, (in tics), to wait before retrying a handshake
signal. Note: ASCII does not use handshaking and the ZModem
default is 60 seconds/1092 tics as opposed to the 10
second/182 tic default for all other protocols. This will usually
be used in conjunction with the dhr command.
ie: SDP rz dhw=120 dhr=20
The above would receive/download a file(s) using ZModem, COM1,
the current directory as the destination, incoming file name(s),
and would set the handshake to a 120 second/1092 tic timeout with
20 retries.
dhr - This command accepts a numeric argument that specifies the
maximum number times to retry a handshake before aborting
the protocol. This will usually be used in conjunction with the
dhw command.
ie: SDP rz dhw=120 dhr=20
The above would receive/download a file(s) using ZModem, COM1,
the current directory as the destination, incoming file name(s),
and would set the handshake to a 120 second/1092 tic timeout with
20 retries.
dtt - This command accepts a numeric argument that specifies the number
of tics to wait for a receiver flow control release.
SDP defaults this to 1092
ie: SDP rz dtt=182
The above would receive/download a file(s) using COM1, ZModem,
the current directory as the destination, and set the timeout
for a receiver flow control release to 182 tics/10 seconds.
dsi - This command accepts a numeric argument that specifies the amount
of time to wait between updates to the status screen in tics.
SDP defaults this to 91 tics/5 seconds
ie: SDP rz dsi=182
The above would receive/download a file(s) using COM1, ZModem,
the current directory as the destination, and set the status
screen update interval 10 182 tics/10 seconds. This may
improve throughput but it will rarely be noticed.
bfc - This command accepts a numeric ASCII representation argument
that specifies the fill character for partial protocol blocks.
A block fill character is used to fill the last block transmitted
by a protocol that doesn't keep track of the file size.
SDP defaults this to 26/^Z
ie: SDP rx bfc=13
The above would receive/download a file(s) using COM1, XModem,
the current directory as the destination, and set the block
fill character to a carriage return.
gho - This command accepts a numeric argument that specifies the
difference, in hours, between the current time zone and the
Greenwich Meridian Time (GMT). The specifications for YModem
and ZModem state the file creation date stamp should be
referenced to GMT. In order to meet this specification both
the receiver and transmitter must adjust the time stamp by
the difference between the current time zone and the GMT time
zone. In practice, most YModem and ZModem implementations
ignore this.
SDP defaults this to 0.
ie: SDP rz gho=1
The above would receive/download a file(s) using COM1, ZModem,
the current directory as the destination, and set the GMT
offset to 1 hour.
td - This command accepts a numeric argument that specifies the Telix
delay, (in tics). You will usually never need this.
SDP defaults this to 9
ie: SDP rz td=12
The above would receive/download a file(s) using COM1, ZModem,
the current directory as the destination, and set the Telix
delay to 12 tics.
dd - This command accepts a character string argument that specifies
the destination directory for received files. This option will
be used depending on other options selected.
SDP defaults this to a blank, meaning the current directory.
ie: SDP rz ghd dd=c:\sdp
The above would receive/download a file(s) using the incoming
name(s). SDP will check the pathing of each file being
received and if the path exists will store the file in that
directory. If the path does not exist, it will store it in
the specified by the dd command.
fln - This command accepts a character string argument that specifies
the path and name for the file log. The file log will log
information about your transfers. The logging capabilities
are only activated if a name and path are specified. Otherwise
SDP will not log transfer information. This file is an ASCII
text file.
SDP defaults this to blank, meaning no logging capabilities.
ie: SDP rz fln=c:\sdp\sdp.log
The above would receive/download a file(s) using COM1, ZModem,
the current directory as the destination, and saves transfer
information in a file named sdp.log in a directory named SDP
on the C drive.
oh - This command accepts a numeric argument that specifies the
number of overhead bytes per block. This does not affect the
block sizes for the protocols. It is simply a modification
procedure for efficiency calculations on the status screen. This
could be handy when using directly linked PCs.
ie: SDP rz oh=256 std=500
The above would receive/download a file(s) using COM1, ZModem,
the current directory as the destination, set the overhead block
size to 256, and set the turn around delay to 500.
std - This command accepts a numeric argument that specifies the turn
the time, (in milliseconds), that it takes the block to get to
the remote, for the remote to acknowledge and for that
acknowledgement to reach us. It is simply a modification
procedure for efficiency calculations on the status screen. This
could be handy when using directly linked PCs.
ie: SDP rz oh=256 std=500
The above would receive/download a file(s) using COM1, ZModem,
the current directory as the destination, set the overhead block
size to 256, and set the turn around delay to 500.
fs - This command has no arguments and simply tells SDP to always
update the status screen.
si - This command acts the same as the dsi command.
sab - This command accepts a numeric argument that sets the actual BPS
(needed only if modem differs from port).
This routine may be used in cases such as the following:
- Two machines are communicating at 9600 BPS via MNP or
v.32 modems
- Both modems are using their built in data compression
facilities to increase the effective BPS rate
- The machines are communicating at a rate of 19200 baud to
insure that the modem doesn't have to waste time waiting
for data to send, and they are using hardware flow control
to pace the flow of data between the modems and machines
In such a case the protocol will base any transfer rate
calculations on a BPS rate of 19200, the rate at which the data
is being sent to the modem, and it will under estimate the
efficiency of the transmission, since the data isn't actually
being sent to the remote at that rate.
To get more accurate calculations in this case you would set
the actual BPS to 9600, the rate at which the data is being sent
to the remotes modem. The calculations will be slightly
inaccurate but will better reflect the actual efficiency.
ie: SDP rz sab=9600
The above would receive/download a file(s) using COM1, ZModem,
the current directory as the destination, and set the actual
BPS to 9600
soo - This command accepts a numeric argument in the range of 1 to 3.
It sets option for what to do when the destination file already
exists. The following is a list of actions SDP will take
when using this option:
1 - Will abort the transfer
2 - Will rename the incoming file and write to that name
3 - Will overwrite the file
SDP defaults this to 1
ie: SDP rz soo=2
The above would receive/download a file(s) using COM1, ZModem,
the current directory as the destination, and would rename the
incoming file(s) if they already exist.
ugd - This command has no arguments and simply tells SDP to use the
graphical display as opposed to the ASCII display. The
graphical display looks best on machines with color monitors and
offers more statistical information.
@fl - This command accepts a character string argument that specifies
the path and name to the list of files you wish to transfer.
This file is an ASCII text file with each file/path on a
separate line. This will allow you to set up batch transfers
easily and quickly.
com - This command accepts a numeric argument between 1 and 36. It
specifies the comport you wish to use. 1 = COM1, 2 = COM2, etc..
ie: SDP rz com=2
The above would receive/download a file(s) using COM2, ZModem,
the current directory as the destination, and would rename the
incoming file(s) if they already exist.
bd - This command accepts a numeric argument that specifies the baud
rate, that is different from the current port, you wish to use.
This should rarely be used.
ie: SDP rz com=2 bd=2400
The above would receive/download a file(s) using COM2, ZModem,
the current directory as the destination, would rename the
incoming file(s) if they already exist, set the baud rate to
2400.
irq - This option accepts a character string argument that equates to
Non-Standard IRQs and/or base addresses. This is accomplished
by the following rules:
1 - Irq value must be in the range of 0 and 15.
2 - Base Address is Hexadecimal string.
3 - The irq value must be specified first, then a /, the
the hexadecimal base address string.
ie: SDP rz com=2 bd=2400 irq= 7/02E8
The above would receive/download a file(s) using ZModem,
the current directory as the destination, would rename the
incoming file(s) if they already exist, set the baud rate to
2400, and define COM2 as using interrupt 7 and address 2E8.
fnm - This command accepts a character string argument which specifies
the name/path for a file to be transferred or received.
ie: SDP rz com=2 bd=2400 irq= 7/02E8 fnm=c:\sdp\test.txt
The above would receive/download a file(s) using ZModem,
the current directory as the destination, would rename the
incoming file(s) if they already exist, set the baud rate to
2400, define COM2 as using interrupt 7 and address 2E8, and
receive a file named test.txt to a directory named SDP on the
C drive.
inb - This command accepts a numeric argument that defines the
size of the input buffer.
SDP defaults this to 4096
ie: SDP rz com=2 bd=2400 irq= 7/02E8 fnm=c:\sdp\test.txt inb=1024
The above would receive/download a file(s) using ZModem,
the current directory as the destination, would rename the
incoming file(s) if they already exist, set the baud rate to
2400, define COM2 as using interrupt 7 and address 2E8,
receives a file named test.txt to a directory named SDP on the
C drive, and sets the input buffer to 1024 bytes.
otb - This command accepts a numeric argument that defines the
size of the output buffer.
SDP defaults this to 4096
ie: SDP rz com=2 bd=2400 irq= 7/02E8 fnm=c:\sdp\test.txt otb=1024
The above would receive/download a file(s) using ZModem,
the current directory as the destination, would rename the
incoming file(s) if they already exist, set the baud rate to
2400, define COM2 as using interrupt 7 and address 2E8,
receives a file named test.txt to a directory named SDP on the
C drive, and sets the output buffer to 1024 bytes.
par - This command accepts a character string argument that changes
the current parity type. Valid arguments are as follows:
NoParity
OddParity
EvenParity
MarkParity
SpaceParity
ie: SDP rz par=NoParity
The above would receive/download a file(s) using ZModem, the
current directory as the destination, COM1, and set the parity
to None.
stb - This command accepts a numeric argument that overrides the
current stop Bit value. Valid range is 1 to 2.
ie: SDP rz par=NoParity stb=2
The above would receive/download a file(s) using ZModem, the
current directory as the destination, COM1, sets the parity
to None, and sets the stop bits to 2.
dtb - This command accepts a numeric argument that overrides the
current data bit value. Valid range is 5 to 8.
ie: SDP rz par=NoParity stb=2 dtb=6
The above would receive/download a file(s) using ZModem, the
current directory as the destination, COM1, sets the parity
to None, sets the stop bits to 2, and sets the data bits to 6.
hud - This command has no arguments and simply tells to utilize DTR
for Receive Flow Control
ie: SDP rz hud
The above would receive/download a file(s) using ZModem, the
current directory as the destination, COM1, and implement a
DTR hardware flow control method.
hur - This command has no arguments and simply tells to utilize RTS
for Receive Flow Control
ie: SDP rz hur
The above would receive/download a file(s) using ZModem, the
current directory as the destination, COM1, and implement a
RTS hardware flow control method.
hrd - This command accepts no arguments and simply tells SDP to require
a DSR signal before transmitting
ie: SDP rz hrd
The above would receive/download a file(s) using ZModem, the
current directory as the destination, COM1, and would require
a DSR signal before transmitting.
hrc - This command accepts no arguments and simply tells SDP to require
a CTS signal before transmitting
ie: SDP rz hrc
The above would receive/download a file(s) using ZModem, the
current directory as the destination, COM1, and would require
a CTS signal before transmitting.
hdl - This command has no arguments and simply tells SDP to set the
DTR signal low.
ie: SDP rz hdl
The above would receive/download a file(s) using ZModem, the
current directory as the destination, COM1, and would set the
DTR signal low.
hrl - This command has no arguments and simply tells SDP to set the
RTS signal low.
ie: SDP rz hrl
The above would receive/download a file(s) using ZModem, the
current directory as the destination, COM1, and would set the
RTS signal low.
hsl - This command has no arguments and simply tells SDP to set the
DSR signal low.
ie: SDP rz hsl
The above would receive/download a file(s) using ZModem, the
current directory as the destination, COM1, and would set the
DSR signal low.
hcl - This command has no arguments and simply tells SDP to set the
CTS signal low.
ie: SDP rz hcl
The above would receive/download a file(s) using ZModem, the
current directory as the destination, COM1, and would set the
CTS signal low.
rpg - This command accepts no arguments and tells SDP to return
whatever exists in the input buffer if it is a partial block.
rd - This command accepts no arguments and tells SDP to return the
delimiter character used as well as the string it delimits.
epp - This command accepts no arguments and tells SDP to store as much
data as possible, in the output buffer, if there is not enough
room to store the whole block.
idc - This command has no arguments and tells SDP to treat characters
in a delimited set with case sensitivity.
roc - This command has no arguments and simply tells SDP to restore the
UART to its original state when the session is completed.
dmc - This command has no arguments and simply tells SDP to hangup
the modem when the session is completed.
rmo - This command accepts no arguments and tells SDP to raise the DTR
and RTS signals when the session is started.
idt - This command has no arguments and tells SDP not to initialize
the port with DTR low.
irt - This command has no arguments and tells SDP not to initialize
then port with RTS low.
pcb - This command has no arguments and tells SDP to display the
current users name, in PCBoard, inside the information screen.
dsz - This command has no arguments and tells SDP to adhere to DSZ
standards. This will allow you to setup SDP as a DSZ protocol
inside PCBoard.
11 - Flip Screens
SDP has 2 flip screens that allow you to access information about
protocols and settings while the transfer is progressing. F1 give
you information on protocols and port setup. F2 gives you information
on the general options. This is only available in graphics mode.
12 - Additional Programs
With the SDP bundle you will receive four programs designed to
help you define various values for the commands specified in this
manual.
SEC2TIC.EXE - This program will allow you to find out what the
proper tic value is for a value in seconds. These
conversions depend on your system so be sure to run
it at least once.
TIC2SEC.EXE - This program will allow you to find out what the
proper second value is for the tics specified. These
conversions depend on your system so be sure to run
it at least once.
MILL2SEC.EXE - This program will tell you what the specified
millisecond value equates to in seconds.
SEC2MILL.EXE - This program will tell you what the specified second
value equates to in milliseconds.
13 - Registration
Upon Registering SDP you will receive a serialized copy of SDP that will
allow you to access many other features.
Pricing and taxation is based upon the shipping point.
You can order SDP online at Streamline Design or The Support Group using
a VISA or Mastercard. You can also order over the phone using VISA or
Mastercard.
-------------------------------------------------------------------------------
Order Form
-------------------------------------------------------------------------------
Addressing Information
Billing Address Shipping Address
Name : ________________________ Name : ________________________
Company : ________________________ Company : ________________________
Department : ________________________ Department : ________________________
Address : ________________________ Address : ________________________
: ________________________ : ________________________
: ________________________ : ________________________
Prov/State : ________________________ Prov/State : ________________________
City : ________________________ : ________________________
Country : ________________________ Country : ________________________
Postal/ZIP : ________________________ Postal/ZIP : ________________________
Phone 1 : ________________________ Phone 1 : ________________________
Phone 2 : ________________________ Phone 2 : ________________________
Product Information - Please Ship [ ] Will Download [ ]
Please allow 3 to 4 business days upon receipt for processing.
Shipping Media
3 1/2 inch, 720 Diskette [ ] 3 1/2 inch, 1.44 Diskette [ ]
5 1/4 inch, 360 Diskette [ ] 5 1/4 inch, 1.2 Diskette [ ]
Download Media
ZIP File Format Ver 1.02 [ ] LHARC File Format Ver 1.13 [ ]
ARJ File Format Ver 2.22 [ ] PKPAK File Format Ver 3.61 [ ]
Quantity 1 to 9 : ____________ x 35.00 = Subtotal: ________________
Quantity 10 to 24 : ____________ x 32.00 = Subtotal: ________________
Quantity 25 to 49 : ____________ x 28.00 = Subtotal: ________________
Quantity 50 to 99 : ____________ x 20.00 = Subtotal: ________________
Quantity 100 and above, please call.
Ontario Residents add 7% Sales Tax Taxation: ________________
and 8% GST
The Rest of Canada add 8% GST
Add 5.00 for Shipping and handling Shipping: ________________
Total : ________________
Credit Card Information
Name on Card : _________________ Card Type: VISA [ ] MasterCard [ ]
Credit Card # : _________________ Expiry : _______
Thank You for using The Streamline Design Protocol Module