[프로그램] The transfer protocol package version 2.05
마루
0
15,244
2008.04.25 08:06
"P"
The transfer protocol package version 2.05
Copyright (c) 1994 by Jyrki Salmi
All rights reserved.
1. Introduction
This is a transfer protocol package providing Zmodem,
Ymodem-g, Ymodem and Xmodem protocols for Bulletin Board
Systems, Terminal programs and where ever reliable high speed
file transfer protocols are needed.
Package consists of two parts:
P.DLL - A dynamic link library that contains the transfer
protocol routines.
P.EXE - The front-end for P.DLL. A program that processes
user options and then calls the DLL to do the actual
transfer.
During development the main goal has been achieving the maximum
performance possible under OS/2. Not much time has been spent
on creating a beautiful and 'friendly' user interface. If you
aren't happy with P.EXE, you can always make your own
front-end for the DLL.
The author takes no responsibility whatsoever for any damage
caused by P. If you decide to use this package or parts of it,
you do it at your own risk!
2. Credits
Chuck Forsberg for creating Zmodem and documenting it.
Public domain sources of rzsz were used as a reference during
the development of P.DLL.
Ward Christensen for creating Xmodem and Ymodem.
Gary S. Brown for the CRC calculation routines. These were
found from the public domain rzsz sources.
Jeffrey Altman for making the CKOP200.INI file.
Many people who reported about bugs in the previous versions
of P and gave me lots of new ideas.
3. Distribution policy
P.EXE - the front-end for the DLL is distributed as public
domain, meaning that anyone can modify and recompile the
sources and do whatever they want with it. However, credits to
the original author (me) would be highly appreciated but not
required, if found so repugnant.
P.DLL - the transfer protocol engine is distributed as
freeware, meaning that the author (me) wants to keep his
copyright to the program but gives everyone the right to use
and copy it freely, without of charge.
4. Supported protocols and their variations
4.1 Xmodem
This is one of the oldest transfer protocols ever. It was
developed by Ward Christensen in 1977. It proved to be an
excellent file transfer protocol because of its robustness and
reasonable performance.
The basic Xmodem used 128 byte blocks and one byte Checksum
for error checking. There has been many extension to Xmodem
over the years. One is CRC-16 checking and one is the use of
1024 byte blocks. Both of these extensions are support by P
(-alternative option and -kilo option).
4.2 Ymodem
Ymodem is one of many extensions to Xmodem. It adds one block
in front of every transferred file, providing file name, size
and date information, you don't have to enter the file name at
both ends of transmission like with Xmodem. Ymodem
also made it possible to transfer many files with just one
command. Ymodem uses CRC-16 as its default error checking
method, however Checksum is still supported (-alternative
option). P uses 128 blocks with Ymodem as the default, you
might want to use 1024 byte blocks (-kilo option) to improve
the throughput.
Xmodem and Ymodem were very efficient with low speed
connections, but due to introduction of new high speed and
buffered modems we found that it wasn't enough.
4.3 Ymodem-g
Ymodem-g is an extension to Ymodem protocol. All it adds is a
continuous data transfer. Transferred blocks don't wait for
acknowledge before transferring the next one. Ymodem-g made it
possible to take out virtually all of the throughput provided
by hardware. However, it had one downgrade: It didn't have any
kind of error recovery. CRC-16 checking was still done, but in
case of an error the transfer was simply aborted instead of
retransmission of the broken block.
There were also many other problems with all of the Xmodem
derived implementations. They needed a totally transparent
data path, making it impossible to use them over connections
which used software flow control (XON/XOFF).
The error recovery / speed tradeoff was also one of the main
reasons for the development of new de facto protocol: Zmodem.
4.4 Zmodem
Zmodem was developed by Chuck Forsberg at Omen Technology,
Inc. in 1986. It wasn't based on the old Xmodem engine and
that made it possible to implement many new features. The
major feature was its possibility to send data in continuous
stream and still recover from possible errors. Zmodem also
introduced escaping, making it possible to transfer binary
files over non-transparent connections.
User convenience was also taken in consideration in
development of Zmodem. Transmission parameters needed to be
specified only at the one end. File name, size, and date
information is of course also transferred, just like in
Ymodem. Automatic start of receiving is also made possible by
sending a ZRQINIT sequence at the beginning of the transfer,
allowing terminal programs to monitor for it.
Zmodem supports 32-bit CRC frame checking (frames are
equivalent to Xmodem and Ymodem blocks) which increases the
reliability remarkably.
With Zmodem you don't have to transfer files right from the
beginning in case connection was lost for some reason. Zmodem
offers a crash recovery which you can use to continue the
transfer from right there where it got interrupted.
Since the late 1980s Zmodem has remained as the de facto
transfer protocol and is still going strong.
5. Installation
To transfer files you will need only P.EXE and P.DLL. The
DLL will be searched from the directories on your LIBPATH and
if not found there, it's looked up from the directory where
your P.EXE resides.
5.1 C-Kermit
Included in this package is file CKOP200.INI which is an
initialization file for C-Kermit. Copy it to your C-Kermit
directory and add the following line in your CKERMOD.INI file:
take ckop200.ini
Next time you'll start your C-Kermit you'll have following
commands added to it:
rz - Receive with Zmodem
sz - Send with Zmodem
ry - Receive with Ymodem
sy - Send with Ymodem
rg - Receive with Ymodem-g
sg - Send with Ymodem-g
rx - Receive with Xmodem
sx - Send with Xmodem
The connect type will be automatically detected and therefore
same commands work for asynchronous, named pipe and TCP/IP
stream socket connections.
Check the CKOP200.INI file and change the paths and options if
necessary.
5.2 LiveWire
Included in this package is a file named LW_P.CMD. It is an
OS/2 command file that is meant to be called from LiveWire.
First, copy that LW_P.CMD to your LiveWire directory and then
start LiveWire.
Go to Protocol menu and choose first blank entry from the
list. Fill the fields with following information:
郞袴?External Protocol 袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴拷
?Name Zmodem (P)같같같같같 ?
?Hotkey P ?
?Prompt filename Yes ?
?Auto-receive string B00같같같같같같같같같같같같같같같같같같같같같같같 ?
?Receive command 1 LW_P.CMD async receive Zmodem %0 %1 %2 %3같같같같??
?Receive command 2 같같같같같같같같같같같같같같같같같같같같같같같같같 ?
?Send command 1 LW_P.CMD async send Zmodem %0 %1 %2 %3같같같같같같 ?
?Send command 2 같같같같같같같같같같같같같같같같같같같같같같같같같 ?
突袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴袴槁
Note that you'll get the arrow pointing upwards by pressing
CTRL-X.
Now choose Zmodem-32 batch from the list and set the
Auto-download to Off. From now on P's Zmodem will
automatically start Zmodem receiving when needed.
Other protocols are added just like but by replacing
occurrences of "Zmodem" with the name of corresponding
protocol: "Ymodem", "Ymodem-g" or "Xmodem". Also remember to
remove the Auto-receive string for other protocols.
To use P with named pipe connection you have to have separate
protocol entries. Add protocols just like above but change the
"async" text to "pipe" in each protocol command.
See also LW_P.CMD if you want to change the options passed to
P.EXE.
6. Command-line parameters of P.EXE
When you run P.EXE without any parameters you will get an usage
that lists all of the available options. Here they are once again,
with detailed descriptions:
6.1 -type {async | pipe | socket}
Select the type of communications to be used.
async = OS/2 Asynchronous device (RS-232C)
pipe = OS/2 Named pipe (Local or network)
socket = TCP/IP stream socket
If not specified, async will be assumed.
6.2 -device <name | path>
Specify the name of asynchronous device (e.g. COM1), or path
to the named pipe (e.g. \PIPE\P).
Affects only to async and pipe communications.
6.3 -host <address>
Internet address of host to connect to. This can be a
resolvable name or plain IP number.
Affects only to socket communications.
6.4 -port <port>
Number of stream socket port to use. Choose this number to be
big enough to not collide with other ports. See your
TCPIP\ETC\PROTOCOLS file for reserved ports.
Affects only to socket communications.
6.5 -server
Specifies that we act as a server for the file transfer. We'll
create a named pipe or stream socket and wait for a client to
connect to it. The wait time can specified with the -wait
option.
Has an effect only when type of communications is pipe or socket,
and no already open handle is available.
6.6 -wait <seconds>
Specifies the number of seconds to wait for the client to connect to
us. While waiting a beep can be heard every second, to disable
the noise specify -quiet option.
Has an effect only when acting as a server.
6.7 -share
Open the communication device in shared mode. Specify this
option if you can't pass a handle to P and you have to "steal"
the communication device from a suspended process. With this
option it is also possible to use P.EXE from a DOS program.
Affects only to async and pipe communications, when no already open
handle is available.
6.8 -handle <handle>
Specifies a handle for an already open asynchronous device,
pipe or socket. If specified and connection is asynchronous or
pipe, the -device option should also be specified to make the
error messages report possible errors on the correct
device. If -device is not specified, error messages could be
something like this:
Failed to control device: "(null)"
But if for example "-device com1" option was specified the
error message would be:
Failed to control device: "com1"
That's all the -device option is used for when handle is
available, therefore it's not required for transfer to work.
For stream socket connections -host and -port option are not
needed at all. Socket numbers are used with error messages
instead of device name.
6.9 -loose
If specified, the state of carrier signal will be ignored during the
the file transfer. You might need to specify this option if
your modem fails to maintain the state of carrier signal, or
if you're transferring files with a null-modem cable.
Affects only to async communications.
6.10 -telnet
Escape telnet IAC characters and CR NUL sequences in the data stream
and process possible incoming telnet commands. Use this option
when you're transferring files through a telnet
session. However, this can be used with other types of
communication too.
6.11 -receive
Specifies that we are receiving files.
6.12 -send
Specifies that we are sending files.
6.13 -protocol {xmodem | ymodem | ymodem-g | zmodem}
Specifies the transfer protocol to be used. See section 4 in
this document for further information about the transfer
protocols.
If not specified, Zmodem will be assumed.
6.14 -escape {controls | minimal}
Specify the escaping to be done during the file transfer.
By default P escapes following characters in the data flow
when transferring with Zmodem:
ASCII 16 (Ctrl-P)
ASCII 144 (Ctrl-P with 8th bit set)
ASCII 17 (*) (XON)
ASCII 145 (*) (XON with 8th bit set)
ASCII 19 (*) (XOFF)
ASCII 147 (*) (XOFF with 8th bit set)
ASCII 24 (*) (Ctrl-X)
ASCII 152 (Ctrl-X with 8th bit set)
And these if they follow an ASCII 64 ('@') or
ASCII 192 ('@' with 8th bit set):
ASCII 13 (Carriage return)
ASCII 141 (Carriage return with 8th bit set)
control - This makes us to escape all control characters
(ASCII 0 to 31). Escaping generates overhead by
transmitting two bytes to represent every control
character. Use it only if your connection can't pass
them through.
minimal - This makes us to escape as few characters as
possible so that the protocol still works with
standard implementations (marked with asterisks in
the list above).
Affects only to Zmodem transfers.
6.15 -alternative
Specifies that an alternative error checking method should be used.
Here is the list of supported protocols with their default and
alternative checking methods:
Protocol Default Alternative
-------- ------- -----------
Zmodem CRC-32 CRC-16
Ymodem-g CRC-16 N/A
Ymodem CRC-16 Checksum
Xmodem Checksum CRC-16
See the following sections for detailed information about the
checking methods.
This option has no meaning when sending files with Ymodem-g,
Ymodem or Xmodem, it is up to the receiver to choose the error
checking method to be used.
6.15.1 CRC-32
32-bit CRC is the most effective error checking method
supported by P. It's based on a 32-bit number (4 bytes)
calculated with a polynomial specified by ANSI X3.66
specification.
This 32-bit number is calculated by the sender and
transferred with every 1024 (or less) bytes. The receiver does
the same calculation on received data and if the results
are different the data is requested to be sent again. The
probability of garbled data getting through is practically
nil.
6.15.2 CRC-16
This is based on a 16-bit number (2 bytes) calculated with a
similar polynomial to one used with 32-bit CRC. The
probability of garbled data getting through is much higher
than with CRC-32, but it's still very very small.
6.15.3 Checksum
This an ancient checking method used by the first versions of
Xmodem. It's based on a 8-bit (1 byte) number calculated from
transferred data by summing up all bytes in it.
For example, Checksum of three bytes: 'a' (ASCII decimal 97),
'b' (ASCII decimal 98) and 'c' (ASCII decimal 99) is '&'
(ASCII decimal 38). It comes from 97 + 98 + 99 = 294 saved in
8-bit number, which cuts it to 38.
With Checksum checking the probability of garbled data getting
acknowledged is relatively high, so whenever possible you
should use CRC-16 instead.
6.16 -kilo
If specified, 1024 byte blocks will be used instead of default
128 byte. This speeds up the transfer considerably on high
speed connections. However, the probability of garbled data
getting through grows when there is more data to calculate the
check value from, thus you should avoid using 1024 byte blocks
with Checksum checking.
Affects only to Ymodem-g, Ymodem and Xmodem sending, when
receiving it's up to the sender to define the block size.
6.17 -window <bytes>
Specifies the size of transfer window to be used. Valid range is
from 256 to 65472, and the size must be a multiple of 64.
By specifying a window size you make P to wait for acknowledge
from the remote for every <bytes> transferred, when the
default is sending data in full streaming, without any
acknowledges.
Using this option might be necessary if you're sending data through a
network where some nodes might timeout if data isn't
transferred to one direction for a certain time.
Using a small window size slows down the transfer somewhat.
Affects only to Zmodem transfers.
6.18 -automatic
Specifies that we should send a string "rz" followed by a carriage
return to the remote before starting the transfer. If there's
an UNIX shell running at the other end it will be interpreted
as the user has just typed "rz" and then pressed enter, and
the UNIX rz program will be run.
If you're not transferring files to an UNIX system this option
just generates more garbage to remote screen at the
initialization phase, in case it hasn't started the receiving
program yet.
Affects only to Zmodem sending.
6.19 -serial
If specified, the serial number of the remote will we queried and
displayed. This option is meant for informational purposes
only.
Affects only to Zmodem sending.
6.20 -attention <string>
Specifies an attention string that will be sent when receiving
files with Zmodem and you would like to get the attention of the
sender.
Following characters have a special meaning in the attention string:
ASCII 221 -- Break signal
ASCII 222 -- One second pause
6.21 -commbufs <bytes>
Specifies the size of both, input and output communication buffer.
Default is 2048 bytes.
Specifying a bigger buffer has an effect only to protocols
sending and receiving data in continuous streams: Zmodem and
Ymodem-g.
With a bigger buffer and a reliable connection you can speed up
the throughput considerably. But if the connection requires
retransmits, a big buffer can slow down the throughput much
more and generate a lot of annoying garbage to the remote
screen if the transfer gets cancelled.
For example if you specify 32768 bytes long buffers, we will
block in read or write routines until all data is read or
written. If you're sending with Zmodem and there is an error
in transmission, it won't be recovered until all data in the
buffers is transferred. And if you're using Ymodem-g the
transfer will be aborted in case of an error, all data in
buffers will be written to the remote screen until we
recognize the abortion.
And when receiving with Zmodem or Ymodem-g, we won't check for
possible transmission errors until whole buffer is received,
making it possible for us to transfer a lot of data that's to
be resent.
There's no maximum limit for the buffer sizes. The bigger you
specify the more memory will be eaten. Under multitasking
environments like OS/2, with bigger buffers a bit less
processor time will be consumed during the transfer.
6.22 -comminbuf <bytes>
Specifies explicitly the size of communication input
buffer. See -commbufs option for further information.
6.23 -commoutbuf <bytes>
Specifies explicitly the size of communication output
buffer. See -commbufs option for further information.
6.24 -filebuf <bytes>
Specifies the size of file read and write buffer. If not specified,
no internal file buffering will be done.
By specifying a bigger file buffer it is possible to speed up
considerably file transfers to or from slow media, like
CD-ROMs or floppy drives.
It's also possible to send contents of a floppy without needing
to keep it in the drive all the time. Just specify big enough
buffer for files to be sent and all data will be read into
memory in the beginning of the transfer and send from there.
Transfers using an asynchronous device (cps < 10000) are not
likely to benefit from a bigger file buffer, but if the
communication device is either named pipe or stream socket,
bigger buffer is most likely to improve the throughput.
There's no maximum limit for the size of file buffer, you
could even transfer contents of a whole hard drive if you
wanted to (and had enough memory for the buffer).
The optimal buffer size is best found by experimenting. You
could start for example by specifying a 32k byte buffer and
compare the CPSs to what you get without a buffer at all.
6.25 -speed <bps>
Specifies the throughput speed in bits per second. This
value will be used only to calculate the transfer time
estimates. If not specified or <bps> is 0, time estimates
will not be shown.
6.26 -mileage
If specified, the number of files and bytes left to transfer
(and estimated time) is displayed before each file.
Affects only to batch transfers and works only when receiving
and the sender provides such information.
6.27 -options
If specified, the conversion, management and transport options
received from the sender will be shown on the screen in a
verbal form. This option is meant mainly to aid problem
determination.
Affects only to Zmodem receiving.
6.28 -headers
Specifies that received Zmodem headers and their contents
should be shown on the screen in a verbal form during the
transfer. This option is meant mainly to aid problem
determination.
Affects only to Zmodem transfers.
6.29 -frameends
Specifies that received Zmodem frame ends should be shown on
the screen in verbal form during the transfer. This option is
meant mainly to aid problem determination.
Affects only to Zmodem transfers.
6.30 -note <text>
With this option you can specify a text that will be displayed
on the top line of screen during the transfer. This is
especially useful for BBS operators who want to see the name
of the user transferring files. The line is written by using
ANSI screen control codes.
6.31 -quiet
Do not beep after the file transfer and when acting as a communication
server and waiting for a client to connect to us.
6.32 -priority <class> <delta>
Specifies the priority of file transfer process.
Valid values for priority class are:
0 - No class change
1 - Idle-time
2 - Regular
3 - Time-critical
4 - Server
Priority delta can be any value in range of -31 to 31.
You might want to specify a higher priority for the file
transfer process if you are running simultaneously something
that is consuming lot of CPU time, like playing DOS games, etc.
Lower priority might come into consideration if you're
transferring files on the background and don't want the
foreground process to get effected by the transfer.
6.33 -dszlog <path>
If specified, a DSZ compatible log about files transferred
will be created in the file pointed by the <path>. This option
is essential for most of the Bulletin Board Systems.
6.34 -pause
Wait for a key press after the transfer, before exiting. This
option might became useful if you're using P.EXE as an
external protocol provider for some software that clears the
screen after we exit. By clearing the screen it prevents the
user from reading the messages displayed by P.EXE at the end
of the transfer.
6.35 -directory <directory>
Specifies the directory where received files are to be saved.
If not specified, files will be saved to the current
directory. Directory path can be trailed by a backslash or not.
6.36 -paths
Do not strip drive and directory components from the file
paths sent and received.
Be careful with this option if you're receiving files, it
would be possible for the other end to send files to any drive
and directory on your system.
Has no meaning to Xmodem transfers.
6.37 -create
If specified, non-existing directory structures will be
created.
Has meaning only when receiving files and -paths option is
specified.
6.38 -clean
Delete files from failed transfers. If specified, transfers cannot
be resumed later on. This option is useful for keeping your
disks clean from garbage files.
6.39 -touch
If specified, the date information received with files will be
ignored. The date of received files will correspond to the
time of transfer.
6.40 -recursive
If specified, files specified on the command-line are searched
recursively, making it possible to send contents of whole
directory structure.
Affects only to Zmodem, Ymodem-g and Ymodem sending.
6.41 -text
If specified, a text conversion will be done on received and sent
files. Meaning that CR LF line end sequences will be
translated to the convention used by the remote system and
vice versa.
Note that this option should be used only when transferring
text files.
With Zmodem, this option is passed also to the remote at the
initialization phase.
6.42 -resume
Specifies that we should try to resume aborted file transfers
i.e. when file already exists and its size is smaller than the
size of the new file.
With Zmodem, this option is passed also to the remote at the
initialization phase.
Affects only to Zmodem transfers.
6.43 -existing
If specified, no new files will be created. Only the already
existing files will be updated or re-transferred.
With Zmodem, this option is passed also to the remote at the
initialization phase.
6.44 -update
If specified, already existing files will be replaced only if the
new file is longer or newer.
With Zmodem, this option is passed also to the remote at the
initialization phase.
6.45 -append
If specified, already existing files will get the new data appended
to them.
With Zmodem, this option is passed also to the remote at the
initialization phase.
6.46 -replace
If specified, already existing files will be replaced by the new
ones.
With Zmodem, this option is passed also to the remote at the
initialization phase.
6.47 -newer
If specified, already existing files will be replaced only if the
new one has a later date.
With Zmodem, this option is passed also to the remote at the
initialization phase.
6.48 -different
If specified, already existing files will be replaced only if
dates or lengths are different.
With Zmodem, this option is passed also to the remote at the
initialization phase.
6.49 -protect
If specified, already existing files won't be replaced at any
situation.
With Zmodem, this option is passed also to the remote at the
initialization phase.
6.50 -rename
If specified, files will be renamed if one with an identical name
already exists.
With Zmodem, this option is passed also to the remote at the
initialization phase.
6.51 [<file> | <@listfile> ...]
The rest of the command-line is for paths to files to be sent
or received. If you have a lot of files to transfer you might
want to use a listfile instead of specifying them all on the
command-line. Listfiles are plain ASCII files containing file
paths on separate lines.
Listfiles are distinguished from the normal file paths on the
command-line by the preceding '@' character. You can mix up
any number of paths and listfiles on the command-line.
Either backslash ('\') or slash ('/') characters can be used
as a directory and name separator.
If the name of first file to be transferred begins with a
character '-', it should be preceded by a plain '-' separated
by space from the last option and this file name.
When sending files, the use of these file paths is obvious,
those files are to be sent. If the file specified can't be
opened, either it doesn't exist or it's being used by some
another application, it will be skipped.
You can specify any number of files to be transferred with
protocols that support batch transmissions, that is all but
Xmodem. With Xmodem you can specify only one file, whether you
are receiving or sending.
When receiving with a protocol supporting batch transfers you
don't have to specify any files at all. However, if you do,
only those files specified will be received. If you are
receiving with Zmodem, the files not found on the command-line
will be skipped. With Ymodem, the transfer will be aborted,
because the protocol does not support skipping.
7. Using P.DLL with your own applications
The whole protocol engine itself resides in P.DLL. P.EXE only
acts as a front-end. Anyone can use the DLL with their
application to provide file transfer protocols. User interface
is not limited anyway, the calling program can be either PM
based or plain VIO text application.
P.DLL can be linked to your application by using an import
library or by dynamically loading and freeing the library when
needed. For more information about import libraries see your C
compiler's manual or IMPLIB section of OS/2 Toolkit's Tools
Reference. No import library is included in this distribution,
you have to create one from the DLL with IMPLIB or similar
utility.
P.DLL has only one entry function: p_transfer(). A pointer to a
configuration structure is passed as a parameter to the entry
function. The configuration structure contains transfer
parameters and pointers to callback functions which are used
to give information about the progress of the transfer back to
the calling application, and to handle files being
transferred. For detailed description of the configuration
structure and callback functions see P.H header file in the
"exesrc" directory.
The best way to get hold of it is probably by studying the
sources of P.EXE, especially callback.c.
8. Afterword
I hope you find some use for all this. If you have any problems,
questions or you just want to give a comment, drop me a note:
Internet: jytasa@jyu.fi
FidoNet: Jyrki Salmi (2:225/12)
* * *