|
|
 |
|
|
|
register |
bbs |
search |
rss |
faq |
about
|
|
|
meet up |
add to del.icio.us |
digg it
|
|
|
|
Explanation of a whole bunch of software protocols
Combat Arms
2869 Grove Way
Castro Valley, California 94546-6709
Telephone (415) 538-6544
======================== All About Protocols ========================
A protocol is a set of rules and conventions that apply to a
specific area of communications that allow participants to properly
communicate regardless of the hardware brand or software package
being used. The protocol file transfer is a set of rules for
transferring files which specify a set of ASCII handshaking
characters and the sequence of handshaking required to perform
certain file transfer functions. Protocol handshaking signals allow
communication software to transfer text, data and machine code files,
and to perform sophisticated error-checking.
Some protocols are faster then others and some are more
foolproof in the way they detect errors.
Here is a list of the popular and most common protocols
supported on various BBS systems around the United States.
ASCII
Xmodem Checksum
Xmodem CRC
1K Xmodem CRC (pseudo-Ymodem)
Kermit
Ymodem
Zmodem
W/Xmodem
SeaLink
The following is a discussion of each.
ASCII
-----
ASCII stands for American Standard for Computer Information
Interchange. Is consists of 128, 7 bit codes (0 - 127). Many
computers implement a "bit-8" set (128-255) but these will differ
from system to system. The bottom 128 are always the same.
ASCII transfer is not really error checked at all. The only
"handshaking" that takes place is the use of Xon/Xoff (ASCII codes 17
and 19, decimal, or ^S/^Q). When the sending system receives a ^S
from the receiver it stops sending until the receiver transmits a ^Q.
Only plain text files should be transmitted with this protocol
since they generally will not contain bit-8 characters. You may use
7 word bits, Even parity, 1 stop bit communications parameters with
ASCII. All the remaining protocols require 8-N-1.
Xmodem (Checksum)
-----------------
In the early 1960's, Ward Christensen developed one of the first
public domain "8-bit" error checking protocols. He originally
developed it for CP/M systems and called it MODEM-7. The late Andrew
Fluegelman popularized it as Xmodem when he implemented it in his
PC-TALK III program.
Xmodem sends information in "packets" of 128 bytes. The error
checking comes about by adding up the ASCII value of these bytes,
dividing by 256, and throwing away the remainder. This is called a
modulo 256 checksum. The sender calculates this checksum and
transmits it along with the 128 byte packet. Once received, the
receiver calculates it again on the received packet. If the two
checksums DON'T agree, the receiver sends a NAK (Negative
AcKnowledgement) which causes the sender to retransmit the packet.
If the checksums DO agree the receiver sends an ACK character. The
transfer continues in this manner until completed.
Modulo 256 checksum checking is not 100% foolproof. Certain
kinds of line noise can cause corrupted packets to be received which
contain the correct checksum but incorrect data.
Most communications programs support Xmodem. Several of them
also support what is known as "relaxed" Xmodem. Relaxed Xmodem uses
the same checksum protocol, but relaxes several of the timing
constraints built into Xmodem in order to work on busy time sharing
systems such as CompuServe. You need not use relaxed Xmodem when
connected to a bulletin board system such as this one.
Xmodem CRC
----------
Xmodem CRC uses a complex polynomial equation to calculate a 16
bit (2 bytes) Cyclical Redundancy Check (CRC) on the Xmodem 128 byte
packet. The CRC value is a much more robust method of detecting
transmission errors. The remainder of the handshaking takes place in
the same manner as checksum Xmodem.
CRC Xmodem is transparent to the user. That is, if you select
CRC as your protocol and your system fails to send the proper codes,
CRC Xmodem will "fall back" to checksum Xmodem. So, if you don't
know if your communications program supports CRC, select it anyway.
Older comm programs such as PC-TALK III do not support CRC
Xmodem.
Ymodem
------
Ymodem was developed by Chuck Forsberg of Omen Technology in
Portland, OR, as the next protocol after Xmodem.
Ymodem is essentially CRC Xmodem with 1024 byte (or 1 kilobyte,
or 1K) packets. (see also 1K Xmodem, below).
However, UNLIKE Xmodem, which always starts off with its first
packet being labeled #1, true Ymodem starts off with its first packet
labeled as #0. This packet contains the time and date stamp of the
file being transferred along with its filesize and filespec. In
addition, true Ymodem may operate in "batch mode" which, if
implemented, allows the receiver to specify more than one file to be
transferred in a session. Ymodem also will send the file in a true
file size, not having to "stuff" null bytes in the final block to
make a full 1024 byte block.
Many communication programs and BBS's have not implemented
Ymodem properly. Some, Procomm for example, have "Ymodem" and
"Ymodem Batch." Quoting Chuck Forsberg,"Ymodem Batch is redundant.
If it's Ymodem, it supports batch operations. If it doesn't support
batch operations it isn't Ymodem, but 1K Xmodem."
1K Xmodem
---------
1K Xmodem is CRC Xmodem using 1024 byte (1K) packets. The first
packet sent is labeled #1. Select this protocol if you have had
problems with Ymodem. Better yet, use Zmodem (see below).
Kermit
------
Kermit was developed at Columbia University in New York. It is
a public domain protocol that has several interesting features we
won't bother to detail here.
W/Xmodem
--------
A form of Xmodem, This protocol provides true full duplex
(sliding window) protocol. Good for packet switching (e. g. PC
Pursuit),the NAK/ACK for each block can be up to 4 blocks behind the
transmitter. It actually is like a game in which the transmitter is
trying to send fast enough to get a 4 block lead and the receiver is
continually trying to catch up. W/Xmodem is not supported by Auntie.
Sealink Batch
-------------
This is a W/Xmodem type protocol that allows batch file
transfers. Mainly useful on Packet type networks and satelite
communications where there will be time delays. The latest release
of SEAlink now has a full streaming mode like Zmodem where it only
gets answers back from the receiver on errors.
Zmodem
------
Zmodem (the next one after Ymodem) is a public domain protocol
developed by Chuck Forsberg.
Zmodem uses a 32 bit CRC to detect transmission errors. It also
allows for batch transfer of more than one file along with time/date
stamping. Unlike X/Ymodem, Zmodem doesn't wait for the receiver to
acknowledge receipt of an error free packet. Rather, it continues
sending until the receiver sends a "packet NAK" which causes the
sender to resend that one bad packet. This lack of "turnaround" time
delay is what greatly speeds up Zmodem transfers. Zmodem also has
the ability to pick up where it left off on an aborted transfer if
you have the -r command in the command line. A real time saver on
large files that abort half way through! Another nice feature of
Zmodem is the ability to adjust the block size on the fly by the line
noise conditions. Thus, on a clean line the blocks work up to 1024
bytes which reduces the overhead of the CRC data which is sent with
each block. This may seem like the best to go with all the time
until you think about re-transmitting of bad blocks. Zmodem can drop
down to 256 byte blocks under noisy conditions which means a re-send
is a smaller block thus speeding up the overall transmission.
Implementing Zmodem
-------------------
Chuck Forsberg has written a "user supported" program called
DSZ. He asks only $20 for it and it is worth every penny. It is
available on this BBS as DSZxxxx.ARC, where xxxx is the date of his
latest version. Issue a DIR;DSZ*.* to locate it.
DSZ is a program which supports X/Y and Zmodem. It must be run
as a "child process" of another program such as a comm or BBS
program.
If your comm program allows a "shell" or "door" or "gateway" to
DOS or a DOS function you can implement DSZ. The following is a list
of some popular programs which can do this:
Program Key for SHELL to DOS
---------------- --------------------
Procomm 2.4.2 Alt F4
Qmodem SST Alt R
Telix Alt V
Boyan Alt J or Ins
GT PowerComm, version 12.20 runs DSZ directly.
After you have told this BBS which file to transfer, SHELL out
to DOS and run DSZ. DSZ expects the serial port to be connected and
will use all the parameters it finds. One exception to this is if
you are running on COM2. Consult the DSZ.DOC which comes with
DSZxxxx.ARC.
One very easy way to use DSZ is to create two small .BAT files
to handle all the chores (or write two CED or PCED SYNonyms). Here
are two that are known to work well:
RZ.BAT (or CED SYN RZ)
dsz rz -r [or, for COM2,] dsz port 2 rz -r
SHELL to DOS and type RZ, this BBS will send the proper filename
and the file. Enter "Exit" to return to your comm program when done.
Note: If you add -r to the end of the command instead of -y, you
have ability to resume an aborted transfer (i. e. pick up at the
point it broke). This is very handy in saving time on large
transfers.
SZ.BAT (or CED SYN SZ)
dsz sz %1 [or, for COM2,] dsz port 2 sz %1
To upload FOO.BAR, SHELL to DOS and enter SZ FOO.BAR and the
file will be sent. Again, enter "Exit" to return to your comm
program when done.
DSZ can also be brought up in the communications programs by a
number of small files that are usually put in as the editor function
of the package so you can treat Zmodem as an internal. POE is one of
the better programs that allows this. Qmodem and Boyan now treat
Zmodem as an internal although they still shell out to run DSZ.
We hope this discussion helps. The use of Zmodem will assure
error free files transfer and will save you time and phone charges.
=====================================================================
This material was originally found on the ATT-PAC BBS (telephone
415-829-6062) and was provided originally through the efforts of Wes
Meier of WC-BBS and Randy Young of ATT-PAC BBS.
|
|
|
To the best of our knowledge, the text on this page may be freely reproduced and distributed.
If you have any questions about this, please check out our Copyright Policy.
totse.com certificate signatures
|
|
|
About | Advertise | Bad Ideas | Community | Contact Us | Copyright Policy | Drugs | Ego | Erotica
FAQ | Fringe | Link to totse.com | Search | Society | Submissions | Technology
|
|
|
|
|
|
