MODEM TO MODEM FILE TRANSFER PROTOCOLS With the increasing use of modems for transferring large files, transfer protocols are becoming more and more widely used. At the same time, more and more different protocols are being used. Now, with the arrival of high speed modems, and the sending of much larger files, the particular protocol that is used is becoming far more important. Here, we will take a brief look at various protocols, and then examine the elements involved in deciding what sort of protocol to use and what to consider when designing a protocol. XMODEM Perhaps the most famous protocol is XModem. Developed by Ward Christensen, this protocol rapidly took hold, quickly becoming the "standard" file transfer protocol. As far as protocols go, it is a very simple and straightforward one. There are, however, a few oddities about it. The most important, as far as the user of XModem is concerned, is the fact that there are two different error checking methods that can be used: a checksum (ie. the sum of the ASCII values of all the characters sent in that block), or a CRC, meaning Cyclic Redundancy Check, another form of error detection. According to the definition of XModem, a CRC check is always performed first, and, failing that, the checksum method is used. This can cause problems when one of the two machines involved in the transfer is using a variety of XModem that does not follow these specifications. The only other notable oddity of XModem is that it uses a very rigid timing sequence, which can cause problems on large multi- user systems, where the processor delays occur. Some communications software supports a version of XModem in which the timing becomes less critical, but this is by no means a standard. Apart from that, XModem is very simple and straightforward - A 256 byte block is sent, along with error check information, and if the block is determined to be "bad", then a request to re-send is issued; otherwise the next block is started. While XModem is not a particularly efficient protocol, it is easy to use, and, most importantly, very common. YMODEM YModem is little more than an XModem variant. Its main difference lies in the fact that 1024 byte blocks are used, rather than the 256 byte blocks of XModem. Some varieties suppose a mixed 1024 and 128 byte block system, but this is the exception rather than the rule. (The idea behind the 128 byte block is that on a noisy line, with frequent errors, it is more efficient to send a smaller block - there is less chance of an error occurring in it). The larger blocks make for an increased transfer speed, because YModem checks for errors once where XModem would have checked four times. On a large file, this can make an appreciable difference. KERMIT Kermit was developed at Columbia University, and is also very popular. Kermit includes all sorts of features, such as the ability to transfer files between 7 and 8 bit systems, data compression, sending file names and attributes, and sliding windows. It is the sliding windows that really sets Kermit apart from the XModem variety of protocols. Essentially, Kermit operates in a full duplex mode. Whereas XModem waits for the acknowledge sequence before sending the next block, Kermit allows the two machines to send data simultaneously, thus eliminating the wait time while the block is checked and confirmed. This greatly speeds the transfer of files, and block size becomes virtually irrelevant. Unfortunately, not all varieties of Kermit support sliding windows, as this was a later enhancement. Because of Kermit's sliding window, small blocks are generally used, often 90 bytes. Kermit also includes what are called server commands. This allows commands to be sent to the host computer (assuming that it is operationg in the Kermit server mode). As these commands are not really related to protocols in gerneral, we won't go into them here. OTHERS Any other protocol can be considered a variant of the ones detailed above. For example, WXModem (Windowed XModem) is simply an XModem with the sliding windows of Kermit. Modem7 and Telink are XModem variants that include file headers (blocks of code that specify the name of the file), permitting multiple file transfers. YModem batch is YModem that includes these file headers. There are countless others, but the differences between them are too slight to be worth mentioning. When deciding which protocol to use, there are many things to consider, but a few general rules can make the decision much easier. Firstly, a sliding window protocol is always faster than the same protocol without the sliding windows. Next, we get to block size. For clean, clear lines, with good modems, the larger the block size, the more efficient the protocol. Conversely, the noisier the line, the more efficient a small block becomes. There is, unfortunately, no easy way to determine the state of the line prior to the transfer. Remember, though, that small blocks mean little to sliding window protocols, as they are not slowed by the error check, so you can rid yourself of the block size worry by using one of them. Another important factor to consider is the nature of the system sending the file. No matter what protocol you use, if the other system is using "Uncle Joe's 94% Compatible Protocol", you may run into trouble. It is sad to see that some software manufacturers have strayed from the precise specifications in the interests of easy programming, especially where some of the more advanced protocols come into play. For this reason, when using a strange or unknown system, it is often best to use one of the plain protocols, such as XModem or YModem. Other than these words of advice, you're on your own. With a little bit of experimentation, you can quickly discover which protocol gives you the best results on the systems that you use. There is no one set "best" protocol. Or, at least, not yet. We can expect to see a lot of new developement in future protocols, as programmers try harder and harder to reach that unattainable 100% efficiency. Guessing, I would say that the next developements will come in the area of data compression, although whether this will be done with hardware or software has yet to be seen. Or, perhaps, the quest for the ideal protocol is already over, and now it's just a question of waiting for affordable high speed modems to solve the transfer problem. One way or the other, we can safely say that the next five years hold a great deal in store for us. ======>>> Let's talk about it!