1

file to just about any other kind of computer to which What is a file transfer? you can connect. The main limitation you will run across is that most computers you connect with will A file transfer is a procedure that allows you to move information from one computer system to another. When you use Procomm Plus to connect one computer to another, one way of exchanging information between the two computers is by typing on your keyboard. A file transfer takes the concept of communicating with another computer system a step further. A file transfer will allow you to move files stored on the hard drive of a computer (or on floppy disks, CD ROM drives, for example,) to the system to which you are connected. Any file you can store on your disk drive can be sent to the other computer, including text documents, graphics, and actual programs. You can also retrieve the same types of files from another computer and save them on your disk drive. only have a few protocols to choose from. Your choice of protocol will be narrowed down by the fact that the same protocol has to be available on both computers. Any protocols that are not available on both computers can be eliminated, so this will simplify your choice. The X-Y-ZMODEM group of protocols allows you to transfer any kind of data on a disk drive. There are a number of technical differences between the protocols in this group, but the only thing you really need to be concerned about is to select them in reverse alphabetical order. If the system you are connecting with will allow you to use ZMODEM, then use it. If ZMODEM isn't available, use one of the YMODEM protocols. If XMODEM is the only protocol available, use XMODEM. If other protocols are available, it is still usually best to use one of the X-Y-Z protocols. What is a file transfer protocol? History of File Transfer Protocols A file transfer works by sending information back and forth between the computers, but the information is not displayed on the screen of either system. Instead, it is diverted from the disk drive of one computer through the connection line and then stored on the disk drive of the other computer. The communication software accomplishes this by using a file transfer protocol. The process of transferring data using a file transfer protocol is a two-sided process. Both computers must use a file transfer protocol, whether you are sending data to the other computer or receiving data from it. If only one side activates a file transfer protocol, no information will be sent. Although there are many different file transfer protocols in use, the most commonly used ones fall into one of the following groups: the X-Y-ZMODEM group, the ASCII group, the Kermit group, or the CIS-B+ group. These four groups allow you to transfer any kind of data XMODEM became public domain shortly File transfer protocols are becoming an increasingly important part of daily modem communications. These rules for sending and receiving files are becoming more complex at the same time they are becoming easier to use. As the list grows, a few protocols stand out above the rest in universal acceptance. In the following sections you will find a short history of the development of the major protocols: XMODEM Family

The XMODEM Family of protocols began its development in the late 1970s when Ward Christensen designed XMODEM, which served as a basis for the creation of many other protocols.

after its completion in August of 1977. This protocol, originally called MODEM or MODEM2, is one of the most simple, widely used protocols today. Despite its limitations of 128 byte block size and fragile timing rules, making it difficult to use with packet switching networks like Tymnet or CompuServe, XMODEM is widely available, providing compatibility between many different computers.

1K XMODEM-G, one of two "streaming" protocols by Chuck Forsberg, evolved with, and depends on, high speed (9600 BPS and above), error correcting modems used on clean data lines. This very fast protocol depends on external error-detection to insure data integrity.

YMODEM-G, yet another Chuck Forsberg creation, parallels the functions performed by the 1K XMODEM-G protocol, adding the

1K XMODEM, designed by Chuck Forsberg of Omen Technology, Inc., allowed the transfer of a 1024 byte XMODEM packet instead of a 128 byte packet. It only uses CRC error detection, doing away with XMODEM's optional Checksum method. 1K XMODEM was a partial solution to XMODEM's problems on packet switching networks.

file attribute information of the YMODEM protocol.

Using HyperTerminal HyperTerminal is a Windows accessory that enables you to connect your computer to another PC or online service. HyperTerminal is a fullfeatured communications tool that greatly simplifies getting online. With HyperTerminal, you can connect to a friend's computer, a university, an Internet service provider, or even CompuServe. Before the existence of graphical interfaces to online services such as CompuServe and The Microsoft Network, most communications tools were character oriented. For example, students all over the world used terminal emulation programs to connect to their schools' computers. They typically used VT100 terminal emulation, to make their PCs behave like any other display terminal on the system. Description Xmodem is an error-correcting protocol supported by virtually every communications program and online service. It is slower than the other protocols. 1K Xmodem is faster than Xmodem, transferring files in 1,024-byte blocks as opposed to the slower 128-byte blocks in regular Xmodem. Otherwise, they are similar.

YMODEM, also developed by Chuck Forsberg in 1980, added file attribute information to 1K XMODEM. YMODEM uses more extensive error checking than 1K XMODEM and allows transmission of multiple files by including file information in the first packet. File Transfer Protocols Supported by HyperTerminal Protocol Xmodem

1K Xmodem

XMODEM The XMODEM protocol is one of the oldest file transfer protocol invented to move files between computers. Developed in 1977 by Ward Christensen, XMODEM was simple and easy to program and it became extremely popular. XMODEM was offering a block length of 128 bytes and a 8-bit checksum followed at the end of each block.

With XMODEM a file were transferred one packet at a time. The protocol is completely receiver controlled. When each data packet received, the packet's checksum was calculated and compared to the one received. If the two checksum matched, the receiver replied with the <ACK> (ASCII 6) message to inform the sender to transmit

the next packet in sequence. If the calculated checksum was not equal to the one received the receiver transmits <NAK> (ASCII 21) message instead. When the sender reads a <NAK> message it re-send the data packet. XMODEM/CRC Since the 8-bit checksum used was simple, errors within the data packet could go unnoticed. To avoid this the protocol changed by John Mahr in order to be able to transmit a 16-bit CRC. The intention for XMODEM/CRC was to remain backwards compatible with XMODEM. This was accomplished by using the character 'C' instead of the <NAK> (SYN character). So it's the receiver that decides which block check to be used by the sender. According to the above, XMODEM/CRC differs from standard XMODEM only in the two byte CRC used instead of the 8-bit checksum and the SYN character. Block length remains at 128 bytes. Both protocols are receiver driven. XMODEM-1K EXTENSION (YMODEM) The standard block length of 128 was acceptable for the low speed connections. As computer power and communication speed was growing the throughput could get even better if the data blocks were bigger. The 1k feature described in the YMODEM protocol increased the block length of XMODEM/CRC to 1024 bytes. This feature named by some as XMODEM-1k. The XMODEM-1k implementation is driven by the sender and assumes that the receiver can handle it. A fact that is not-normal to XMODEM. If the receiver does not know about it, the communication will fail.

impairments to interfere with dependable, accurate transfers. + Only one file could be sent per command. The file name had to be given twice, first to the sending program and then again to the receiving program. + The transmitted file could accumulate as many as 127 extraneous bytes. + The modification date of the file was lost. A number of other protocols have been developed over the years, but none have displaced XMODEM to date: + Lack of public domain documentation and example programs have kept proprietary protocols such as Blast, Relay, and others tightly bound to the fortunes of their suppliers. + Complexity discourages the widespread application of BISYNC, SDLC, HDLC, X.25, and X.PC protocols. + Performance compromises and complexity have limited the popularity of the Kermit protocol, which was developed to allow file transfers in environments hostile to XMODEM. The XMODEM protocol extensions and YMODEM Batch address some of these weaknesses while maintaining most of XMODEM's simplicity. XMODEM, even it is widely supported, it's rarely used, since it lacks of speed and other file transmission features that are standard today where ZMODEM rules. ZMODEM is fine but rather hard to implement. XMODEM on the other side is easy to implement and would perform as well as ZMODEM if it would include similar and well defined features. As computer power and communication speed was growing the throughput could get even better if the data blocks were bigger. The XMODEM-1k extension, defined in the YMODEM specification, increased the block length of XMODEM/CRC to 1024 bytes. The XMODEM-1k is driven by the sender, a fact that is not-normal to XMODEM and if

3. WHY YMODEM? Since its development half a decade ago, the Ward Christensen modem protocol has enabled a wide variety of computer systems to interchange data. There is hardly a communications program that doesn't at least claim to support this protocol. Advances in computing, modems and networking have revealed a number of weaknesses in the original protocol: + The short block length caused throughput to suffer when used with timesharing systems, packet switched networks, satellite circuits, and buffered (error correcting) modems. + The 8 bit arithmetic checksum and other aspects allowed line

the receiver does not know about it, the communication will fail. So the requirement was to define backwards compatible extensions to an already known The Standard XMODEM Protocol

protocol. The Extended XMODEM protocol was born.

The standard XMODEM starts each packet with the control character SOH followed by the packet number and the inverted packet number. 128 bytes of data follow and the packet ends with the 8-bit block-check.

The 8-bit block-check is calculated on the DATA part. The protocol is driven by the receiver. The sender must wait until the receiver transmit a NAK character. The sender then starts sending packets starting with block number 1, 2, 255, 0, 1, 2.... The last packet may include less data bytes than 128 and is therefore filled with EOF bytes (ASCII 26). Thus a file once transmitted with XMODEM grows to the next multiple of 128. XMODEM/CRC XMODEM/CRC just replaces the NAK with the letter 'C' and the 8-bit block-check with a 16-bit CRC (Cyclic Redundancy Check). The Extended XMODEM protocol The Extended XMODEM protocol specification defines various buffer sizes in order to optimize the data throughput on what the data link has to offer. It uses 16 bit CRC in order to maximize detection of changes in the transmitted data. The features of this protocol can be summarized as follows: The protocol is based on XMODEM/CRC. It appends a 16-bit CRC. It supports packets of 128, 512, 1K, 2K, 8K, 32K or 64K bytes in length (K=1024). It can be easily extended to other packet length. It expects an 8-Bit transfer medium. It is backwards compatible to the standard XMODEM and XMODEM/CRC. It supports transmitting file information (optional feature - file info). Receiver informs the sender about the file name to transmit (optional feature - file request).

((Datastorm was a computer software company that existed from 1986 until 1996. The company was founded by Bruce Barkelew and Thomas Smith.[1] Datastorm and their software, ProComm, was prominent in a pre-TCP/IP world where computer-to-computer modem connections (eg, bulletin board systems, or BBS's) were common.[2] Datastorm was the first company to grow from a shareware model to a large retail company[3] ProComm 2.4.3 for DOS is still available as shareware today.))

Receiver can 'wake up' sender and request a specific file (optional feature - file request). And the XMODEM feature that many expected: It transmits the exact file size without padding the file with a number of ASCII 26 bytes! Using the Extended XMODEM protocol, the file does not grow since the last short packet is recognized.