In this issue, I am going to talk about File Transfer Protocols. This particular article is going to be a wee bit technical, but I’ll try to make it as human as possible.

What is a File Transfer Protocol ?

Many times you will need to send or receive information that cannot be handled using a text based message. Examples of this are data files, programs or any other kind of file that are not text based.

Unlike text messages, binary files cannot tolerate even the slightest error or anomaly. To explain this, let us take the example of a simple message :

Deer Raju,

Hi! hou arre yoo ? Deed yu geth de letyer Aih sended yastrdey ?

Rply suuuun,

Atul.

In the example shown above, it is fairly obvious that the writer (in this case me, and this is an example – I was NOT sleeping during grammar and spelling classes at school) has made some gross errors in both spellings and grammar. Yet the message, once received by the addressee, will carry its meaning across, inspite of all the errors. This is because the interpretation of the message is left to the human brain, which is much more accomadating (or fault tolerant) than a computer can ever be.

But take the example of a binary program that, let’s say, reads and displays sectors of a disk. It uses the DOS interrupt 25H to read the sector, and then displays it to you. By itself, this represents a relatively innocent and safe utility program, but if it is even slightly altered, it can be a potential monster. If this program, sent over the telephone line using modems, gets “hit” by line noise or interference (as described in the first of these articles), then a simple bit shift can turn the Interrupt 25H instruction into Interrupt 26H. This is fatal to the user of the program, because Interrupt 26H does not READ from a disk sector, but WRITES to it, and the innocent program you sent potentially can wipe out the addressee’s hard disk !

Or take the example of a database file that contains salary information. A single hit, and Mr.ABC’s salary for the next month suddenly jumps a hundred fold, causing losses to the company ! This is not too uncommon, and you yourself may have experienced it if you have ever sent a fax or telex message that got garbled.

To prevent this sort of thing from happening, we use a system called “Protocol Driven File Transfers” involving “Error Detecting and Correcting Methods”. In plain English this means that a File Transfer Protocol lets you transfer files without a chance of an error creeping into the file. If one does creep in, it is detected, and corrected.

A file transfer protocol is an agreed upon method or set of rules (between the sender and receiver) of transfering file information. These rules, unique to each protocol, form the basis of the comparitive strengths and weaknesses of differing communications protocols.

There are literally hundreds of file transfer protocols used today, but the most common ones are XMODEM, XMODEM-1K, ZMODEM, YMODEM BATCH, YMODEM-G BATCH and KERMIT.

Most good communication packages support all the above mentioned protocols, both for sending as well as receiving files.

Selecting a Protocol

Any file transfer begins with your selection of File Transfer Protocol (FTP) that you wish to use. Naturally you must choose a FTP that is supported by both sides of the connection.

Which transfer protocol should you use ? There is no definite answer to this question, but there ARE some guidelines which you can follow :

1. First of all, check which of the protocols is supported by your communication program. You can determine the FTPs available in your communication program by going through its manual. If you are using ProComm, hit to see a menu of available protocols.

2. What is the line condition like ? If you are NOT using an error correcting modem, and frequently see junk on the screen, then it is advisable that you use either of the “short packet” FTPs, i.e. XMODEM or KERMIT. Though the throughput of these FTPs is less (slower) than that of XMODEM-1K, YMODEM BATCH or ZMODEM, they provide faster error recovery.

3. Are you calling using a 7 bit line ? Normally you shouldn’t, because most Communication Hosts specify that you should call using 8 bits no parity, but in some cases using a 7 bit setting may be unavoidable, such as when you are calling from a mini computer terminal or your communication software does not permit anything else. If you ARE calling at 7 bits, then you have only one choice – KERMIT, which is the only FTP that works on a 7 bit connection.

4. Are you calling using an error correcting modem ? If yes, then the high-throughput FTPs XMODEM-1K, YMODEM BATCH, YMODEM-G BATCH or ZMODEM should be used. Since the chances of an error occuring are remote, these FTPs allow you to push through larger data packets, speeding up the process immensely.

OK, now that you have decided which protocol you wish to use, indicate your choice to the remote host (who usually shows you ITS available protocols in the form of a list or a menu).

What happens next is dependant on the choice of FTP, the operation (upload/send or download/receive) and the procedure from where the file transfer was initiated.

Transferring a File

If the transfer involves a download (receiving a file), then the remote host will almost always ask you for the name of the file you wish to receive (unless there isn’t any choice, since there is only one file).

If the file requested is found, then the remote host will ask you to initiate your receive procedure using the specified protocol, and will await your start signal. At this point, you can usually abort the transfer by pressing a couple of times.

To initiate the transfer at your end, you have to instruct your communication package to begin downloading the file with the matching protocol. If you are using ProComm, then hit and select the same protocol as you have instructed the remote host to use. (If you are not using ProComm, you can determine the exact procedure from your communication software manual.) In the case of either of the XMODEM FTPs, you will have to tell your program what file name to use at your end, while the YMODEM BATCH, YMODEM-G BATCH, KERMIT and ZMODEM protocols do that automatically for you.

Now you will usually see a status screen on your terminal, telling you about the progress of the transfer. The actual transfer should begin within 1-10 seconds. If it does not, then something is wrong, and you will have to cancel the transfer.

Once the transfer begins, you will see the number of blocks of data that your computer has received, and the error status. Don’t be worried if you see errors being reported. This is actually a positive sign – it means that the FTP has detected an error, and is correcting it ! Of course the non-appearance of errors is a good sign, too.

After the transfer completes, your communication program will tell you so.

That’s it ! The file has been successfully transferred ! If it has not (because of excessive or fatal errors, or because you chose to abort the transfer), you will usually be given an option to retry. Answering “YES” will restart the process from the point of the FTP selection, answering “NO” aborts the process and returns you to the calling procedure.

More about File Transfer Protocols

Although each file transfer protocol differs in the specific rules that it follows in transferring information, all FTPs have certain similarities:

* Each Communication session begins with an initialization state where the receiver and sender establish the specific method of information transfer. (Techno-jargon that means that both sides agree on which “language” they are going to speak in)

* The contents of a file are transmitted in the form of packets or frames of an agreed upon format.

* All of the protocols are “stop and wait” protocols where after sending a packet or frame, the sender stops and waits for a response to the sent packet. Ymodem-G Batch and Zmodem are exceptions to this – they blast data across “full throttle” unless specifically told to pause by the protocol at the other end.

* Each packet or frame has a Start-of-Header character or sequence which indicates to the receiver the beginning of the packet or frame.

* Each packet or frame is uniquely identified by a frame number or sequence number.

* The integrity of the frame or packet is assured through the use of an error detection code typically placed at the end of the packet or frame.

* The packet or frame contains a data portion which is the file information being transferred.

Like I said, the basic reason for the use of a file transfer protocol is to maintain the integrity of transmitted and received data. Since all communications may be subjected to noise or other data corrupting forces, use of a communication protocol will insure that all information is transmitted and received error free.

Let’s take a closer look at each of the common protocols.

XMODEM and XMODEM-1K :

This protocol is the “grand-daddy” of them all, since it was the first one ever to appear for general usage. It was conceived and developed by Ward Christiansen in the late 70′s, and gained rapid popularity because of its straight-forward implementation, and wide spread support on many BBSs.

XMODEM is receiver-initiated – both the receiver and sender computers are aware of the file transfer. XMODEM is generally used to download a file from a host to a user’s PC that is operating as a terminal emulator. File name is not preserved and receiver and sender must both specify the file name of the file being transfered. File length is not preserved and is padded to the nearest 128 byte (XMODEM) or 1024 byte (XMODEM-1K) increment.

The XMODEM session begins with an interchange of initialization characters in order to establish the format of the data transfer. Once the session has been initialized, the sender begins transmitting information starting with frame number 1. The session progresses with the sender transmitting a data frame and the receiver responding to the data frame. Upon successful transfer of the last data frame, the sender indicates to the receiver that the session has completed.

YMODEM BATCH :

YMODEM BATCH is a receiver initiated protocol. Essentially, it is an embellishment of the XMODEM-1K protocol which provides CRC error detection. It can use 1K data blocks, multiple files can be transferred within one session, and both the transfered file name and exact file length are sent to the receiver.

Like XMODEM, the YMODEM BATCH session begins with an interchange of initialization characters in order to establish the format of the data transfer. Once the session has been initialized, the sender begins transmitting information starting with packet number 0. Packet 0 contains the file name and (optionally) the file length information of the file data to be transferred. The session progresses with the sender transmitting a data packet and the receiver responding to the data frame. Upon successful transfer of the last data packet, the sender indicates to the receiver that the session has completed.

Since the filename of each file being transferred is preserved (from sender to receiver), the receiving YMODEM BATCH session need only specify the destination drive/directory for the path argument of the YMODEM BATCH receive function calls.

YMODEM-G BATCH :

This is probably the fastest possible file transfer protocol that exists today.

YMODEM-G BATCH is, essentially, an embellishment of the YMODEM BATCH protocol which provides CRC error detection, 1K data blocks, multiple files transferred within one session, and preservation of both the transfered file name and exact file length. In addition, this is a “flowing” protocol, especially meant for the use with Error Correcting (MNP) modems.

YMODEM-G BATCH is almost identical to YMODEM-BATCH, but in the case of YMODEM-G BATCH, the receiver does not respond to the data frame, unless an error takes place, in which case the protocol is aborted.

KERMIT :

The Kermit file transfer protocol was developed in 1981 by Frank da Cruz and Bill Catchings at Columbia University in order to facilitate the transfer of information between mainframes and PCs.

Kermit provides for multiple files to be transferred within one session and for preservation of both the file name and exact file length. It also allows for communication to take place on both 7 and 8 bit communication channels (This is accomplished via the 8th bit prefixing option. Any 8 bit data is prefaced with a special character that tell the receiver to treat the next character as an 8 bit byte).

Kermit transfers all information in the form of packets. After a packet is sent, Kermit will stop and wait for a response (in the form of a packet) before it sends the next packet. All Kermit packets are composed of printable characters

Kermit packets can be a maximum of 96 bytes in length and use the 8 bit folded into 6 bit checksum error detection method to insure data integrity.

This is the only protocol that can be used to transfer binary data over 7 bit lines, but does have the disadvantage of being less throughput efficient than any other protocol.

ZMODEM :

Zmodem is sometimes referred to as the “King of FTPs”, and with good reason. It can do things that almost no other protocol can do, such as receover from a crash, by continuing the transfer from the point where the transfer failed, rather than sending all the data once more.

Zmodem also has a unique “Auto Download” feature, that automatically starts the transfer at the receiver’s end (provided this feature is enabled at the receiving end).

The protocol was developed by Chuck Forsberg, a developer at a company called Omen Technology, on request of the carrier network giant Telenet, for a very specific purpose : to overcome the pitfalls of packet switching networks.

Packet switching networks are data links similar to telephone lines, but specific to computer communication. They too use a form of data packetisation, which interferes with the functioning of normal file transfer protocols. (More on packet switching networks, including I-NET, in my next article).

Omen Technology developed the protocol, which was later placed in the public domain by Telenet.

Zmodem, like Ymodem-G Batch, uses the streaming style of data transfer, i.e. it doesn’t wait for an acknowledgement of a packet before sending the next one. But unlike Ymodem-G Batch, it recognises error messages from the receiver, and takes action to rectify the problem.

Winding Down

Woops, out of space again ! (How words fly)

OK, my apologies about the “techno-junkie” feel of this article. Next month, I look at various ways to broaden your horizons, including BBSs and Carrier Networks – in particular I-NET, India’s premier network.

Till then,

Ciao !

This must have happened to all of us at some time or the other while using a modem:You are transferring a file, the error count keeps building up, and finally the transfer crashes. Bad line ? Not necessarily. As a matter of fact, it could be too good a line that’s causing the problem. Data could be coming in too fast to be handled by your computer !

What’s faster – your 486 or your serial port ?

Ever sat through a file transfer that seemed to take forever for even a small 100 KB file ? And, to make it worse, after the transfer was over it took just two seconds to copy the same file from one disk to another ? Can anything be slower ?

And yet it is possible for a modem to run faster than your computer can handle it !

Modems have always been rated very low in terms of speed, and saying that a modem could “outrun” your computer would bring pitying smiles on the face of the listeners. “Outrun my 486 based, 33 MHz, Cache RAM based super desktop ?” they would say.

After all, a modem typically works at 2400 bps, or 240 bytes per second (in asynchronous communication, 10 bits are required to transfer a single 8 bit byte). How can something as slow as that be faster than even a 4.77 MHZ PC ? Ridiculous !

But think again, friends. There are darker sides to your PC that make it an ideal target for “Comm Overruns”. You don’t believe me ? Well, read on, and be prepared for some surprises.

The Dark Side of the Moon

The PC (whether 8088 based or 80486) communicates with your modem via its serial port. This includes internal “modems-on-a-card”, which typically have serial port circuitry onboard, but suffer from the same serial port problems as an external modem nevertheless. And this serial port functions on the principle that it receives one character from the modem, then waits for the PC to pick up that character, thereby clearing the way for the next character. This includes internal “modems-on-a-card”, which typically have serial port circuitry onboard, but suffer from the same serial port problems as an external modem nevertheless.

Should a character arrive from the modem when the earlier character has not yet been picked up by the PC, then we have an overrun.

“OK, but why should the PC not pick up the character waiting in the serial port’s buffer ? After all, the PC is thousands of times faster than the fastest speed that the serial port will work at !” says the sceptic.

True, a PC is much faster than its serial port, but there is a catch – a PC is sometimes not free to service the serial port. And just like even a Ferrari Formula 1 racing car cannot win a race if it doesn’t even participate in it, the character waiting at the serial port can get overrun because the PC isn’t checking for that character.

“How come ?”

To explain that, I’ll have to give you a bit of background on how communication software deals with the serial port.

May I interrupt you for a moment ?

Modern communications no longer works on the basis of “polling” (checking every now and then) the serial port for characters. Instead, it relies on interrupts from the serial port to inform it that a character is ready to be picked up. This is much faster than polling, and is the way 99% of modern communications programs work.

To understand this, picture yourself sitting in an office, with a phone by your side. Now the phone is a useful thing to have, but its utility would be severely curtailed if you had to pick up the receiver every now and then to see if there is a call coming in.

Naturally, the phone has a way to tell you that there is a call waiting to be answered. It rings a bell. So you stop whatever you are doing, pick up the phone and talk. If the phone doesn’t ring, you know that there is no call, and can go about doing something else.

The PC’s communication interrupt mechanism works in a similar fashion. Instead of constantly checking the serial port, the PC relies on the fact that when a complete character has been received and needs to be picked up, the serial port sends an interrupt to the CPU, effectively tapping it on the shoulder and saying “Hey ! Could I have your undivided attention for a moment ?” The CPU passes this signal to your communications program, which in turn picks up the character from the port.

Unfortunately there are instances when the PC “takes the phone off the hook” for a while by turning off all interrupts, thereby making it incapable of receiving an interrupt from the serial port. If this happens, the CPU never realises that there is a character waiting to be serviced, and as soon as the next character comes in, it kicks the original character out of the buffer, causing data loss.

Paradoxically, the most common of such instances is when the PC is accessing the disk ! When this happens, the PC’s BIOS turns off all interrupts until the disk access is complete. And if this happens for long enough, we get overruns at the serial port !

How long is “long enough” ?

Assume you are receiving data at 2400 bps from the modem. This means 240 characters per second, or one character every 1/240 of a second. So, the first character is ready after 0.004 of a second, the next one is there after 2/240, or 0.008th of a second. And that, my friend, is your “long enough” time. If your PC hasn’t picked up the first character by the time the second character is fully received, then an overrun takes place !

Now just take a typical disk access. Assume that you are receiving data and, after every 1024th character, are writing this data to disk. The instant you start writing to disk, the PC turns off all interrupts, and begins the write operation. Now, if your hard disk is slow, this can take as long as a second (longer if the target is a floppy disk). That means that your PC could be “out of action” long enough to lose upto 240 characters !

Haven’t had enough yet ? Consider that most modems today are MNP or V.42 modems, and are capable of operation at 9,600 to 34,000 bits per second, the “time out” is shortened radically ! If you take as an example a modem delivering data at 9600 bps to your PC, then the “long enough” time is 2/960th of a second ! Want to really fall into depressions ? Try 34,000 bps on your calculator !

The Electronic Traffic Cop

OK, enough of doomsday. Now that you know WHY overruns happen, let’s see what we can do about it.

Actually, the matter is simple. Just tell the modem to stop sending data for the duration of the disk write.

“Aha !” you say “send an XOFF (Ctrl-S) to stop the flow !”

Nice try, my friend, but no cigar.

If your modem (or the remote source of the incoming data) is set up to recognise XOFF as a “hang on a sec” signal, then a spurious XOFF (caused by line noise or even program error) can send your communications link into limbo. Besides, sending an XOFF takes too long, anyway. And if you are transferring binary data such an EXE file using something like YMODEM or XMODEM, an XOFF that is part of the data can be misinterpreted as an error.

The answer lies in the very definition of the serial port’s signals. If you have a description of a serial port’s signals in front of you, you’ll see that two of the pins are marked as “RTS” and “CTS”. On a standard 25-pin serial port, they are pins 4 and 5. Now there must be a reason for these signals to be there in the venerable CCITT’s recommendation of RS232C. And there is. These signals are known as the “hardware handshake lines” or, more commonly, as the “hardware flow control” lines.

The RTS and CTS signals are interpreted as follows:

When the PC is ready to receive data, it raises its RTS (Request To Send) signal. This causes the CTS (Clear To Send) signal of the modem (or remote device) to be raised, indicating that it is safe to send data.

If the PC needs to halt the flow in order to do something like a disk write, then it lowers the RTS signal, which causes the remote CTS to drop, telling the sender to “hang on while I do something”.

Since the RTS and CTS signals are not part of the data stream, they are transparent to the actual data flow, and do not interfere in any way, making them ideal for purposes of flow control.

Using Hardware Flow control

So how do you implement it when using your communications program (such as Procomm or Crosstalk) ?

Easy enough. Just enable this hardware flow control setting in the program’s setup. And make sure that your modem is set up to recognise them, too. In Procomm this setting can be found in the Terminal Setup, in Crosstalk, it is in the main setup screen. While you are there, make sure that you disable software flow control (XON/XOFF) which has no place in high speed communications, anyway.

Secondly, make sure that your serial cable from the PC to the modem has all the nine critical wires connected correctly. Some people have been using three-wire cables for modem communications, which is not enough if we are talking about speeds in excess of 300 bps.

Your modem needs to be set too. On most modems, the AT&R0 setting causes the modem to let RTS and CTS act normally (there may be some jumpers involved). On most MNP modems, the ATQ3 setting will enable the modem’s hardware flow control (on some it is AT&E4&E7). Check your modem’s manual for this.

Now try downloading (transferring to your computer) that king sized file that you have been wanting for so long, but always failed to get because the transfer failed. Voila ! It worked !

Fish ‘n’ Chips

There are some other things you could also do to ensure that your communication session doesn’t cause you grief. One of the most common problems in PCs sold in India is that the serial port chip (known as the UART) on the I/O card is very often not meant for use with that particular machine.

Specifically, all BIOSs written for the 80286 and above expect to find a chip called the 16450 managing the serial port. But some “fishy” manufacturers, in order to save money, use the older 8250B chip. What most people do not know is that the 8250B has a documented bug in it that causes the chip to “lock up” at random when operating at speeds in excess of 1200 bps. Older XT BIOSs were written keeping this bug in mind. But the newer AT and 386 BIOSs were not. That is why you can virtually guarantee disaster if you are using such a chip on an AT class machine.

I use an public domain utility called UARTID (written by TurboPower) that tells me what chip is in use on a machine, but you can also check this out physically by sneaking a peep at the I/O card in your PC. This can be a problem if your I/O card uses one of those “all-in-one” ASIC (application specific integrated circuit) chips, which hide the true identity of the circuitry. In such a case, you WILL need the UARTID utility.

If you find an 8250B chip in your AT class machine, change it pronto to a 16450, and many of your problems will go away.

You could also use the newer 16550AF UART in place of the 16450. This chip has a special buffer built in that avoids port overruns. Many newer communications packages recognise and activate this chip, resulting in almost perfect data flow.

RAMbling on

Finally, a little tip for those concious of the clock when they are online. Instead of downloading onto a hard disk, try downloading onto a small RAM disk. This RAM disk should be about 10% bigger than the largest file you plan to transfer.

With protocols such as YMODEM-G BATCH or ZMODEM, this can make a substantial difference in transfer time and reliability, since the time taken to write to a RAM disk is negligible compared to the time taken to a Hard or Floppy Disk. Because of this, the time that the PC “takes the phone off the hook” is reduced considerably.

Winding down

Oh oh – did someone ask “what are YMODEM-G BATCH and ZMODEM?” I thought you knew about those !

You didn’t ?

Well, they are two of the most popular file transfer protocols in use today, and they, along with other protocols, feature in next month’s column, where I will be talking about different aspects of file transfers using modems, including which to use when and how to achieve the fastest possible transfer times.

See you next month !

Hi there !Welcome to my new column, where I will be addressing various computing issues that concern the end-user, i.e., you.

This month, I begin with the first of a series of articles dealing with modem communications.

A Tale of Bargains

Sometime back, I went to see a friend who was having a bad time. Let me tell you all about it:

This friend recently went on a trip to the Far East. Being a computer buff, always ready to go in for “the latest,” this chappie went in for a modem. “After all, with I-NET and other communication services coming up in India, a modem is a useful thing to have” was his argument.

Unfortunately, knowing nothing about modems, he went the classic route – he bought what seemed a really good bargain. “After all, all modems work the same way” says he.

Famous last words.

When he hit town, he connected everything up as shown in the three and half pages of documentation that accompanied the modem, fired up the pirated communication package that he got with it, and tried to log into my BBS (Bulletin Board Service).

Next morning, I looked at the activity log on my BBS machine, and saw a chaos of failed transfers and junked messages recorded there. I immediately got on the phone to my friend to check what had happened.

“I got all sorts of junk on my screen, and everytime I tried to transfer a file, the transfer got aborted because of too many errors” says my bargain-hunting friend. I told him I’d be right over to see what was the problem.

Reaching the scene of the crime, I flipped through the pages of the manual (which didn’t take too much time, considering its size), trying to find out how to enable the modem’s error correcting feature. It had to be there somewhere . . .

It wasn’t.

My friend had spent his money on a cheap, non error correcting modem. Something akin to buying a bullock cart for the German Autobahn. What had seemed a bargain was in fact a piece of junk.

Cross Connections

If there is one thing that is consistant about India’s telephone system, it is the terrible quality of the lines. Often, a call to a local number feels like a long-distance call to the moon – via Pluto. Cross-connections, crosstalk, clicks, buzzes and beeps are part and parcel of any phone conversation.

Now consider how a modem works. What it does is to take your computer’s digital signal, and turn it into Audio tones, which can be transmitted over the phone line. The receiving modem turns these tones back into digital signals for the receiving computer’s listening pleasure.

Great in theory. Now, just to provide a bit of entertainment to the process, add a heavy dose of “Indian Telephone Line”.

Fireworks ! Special Effects ! Chaos ! Now you know where the director of the movie “F/X” went for inspiration.

Since the receiving modem tries to make sense of every blip, beep and squawk it hears on the line, the noise on the line drives it plain batty.

This is what was happening to my friend’s first attempt at datacomm. Since his modem lacked a way to distinguish between signal and noise, what he got on his screen was his modem’s interpretation of the “symphony” it heard on the phone line.

The fact is – Indian telephone lines are completely unsuitable for unprotected computer conversations. (Actually, I have felt that way about some human phone conversations, too). The line noise caused by outdated crossbar exchanges and rotten trunk cables makes the Indian telephone system a place they send little modems to if they have been bad boys.

So how does one “protect” a datalink from line noise ?

Error Correcting Modems

Picture this :

You are talking to a friend and are giving him a phone number he wanted. Line noise being what it is, he doesn’t hear you clearly, meaning that he doesn’t get the phone number.

So he says “hold it, I didn’t get that clearly, can you repeat that please ?” and you repeat the number until he gets it perfectly.

That is how error correcting modems work. They “packetise” the data being transferred, and add some more data to it that allows the receiving modem to decide whether the data packet is “clean” or has been “hit” by line-noise. If it detects such an error, it asks the sending modem to retransmit the data packet until it gets through clean. This process is completely transparent to the user.

Error detection and correction is a basic requirement if you plan to use a modem on Indian telephone lines. This feature comes in two flavours – MNP and V.42.

MNP is the grand-daddy of error-correcting schemes, and was developed by modem manufacturer Microcom (therefore the acronym MNP – Microcom Network Protocol). Almost every error correcting modem produced today incorporates this scheme.

V.42 is the CCITT’s version of almost the same thing. The CCITT is the international body that decides what is a standard in communications, and what is not. It tags these weird names to their recommendations (such as V.42) that in itself tells you nothing except that it is official.

Anyway, MNP and V.42 are two schemes used for error correcting modems, and they ensure that they can communicate with other modems speaking the same lingo without errors. The two are compatible, and will talk to each other.

But error-correcting modems don’t stop at that. They have another function – data compression.

Effectively, what this means is that the modem collects a packet of data, compresses it, then sends it on its way. The receiving modem decompresses the packet and passes it on to the computer. Since it takes less time to send a compressed packet of data, the effective throughput of data between the modems is increased.

MNP has the MNP5 compression standard (MNP4 is the error correcting part of the protocol), where as V.42 has V.42bis. Unlike the error correcting parts of the protocols, MNP5 and V.42bis don’t talk to each other.

This is also where the old gives way to the new. MNP5 has a maximum compression ratio of 2:1, meaning that the effective throughput of a MNP5 modem running at 2400 bps (bits per second) is at the most 4800 bps.

V.42bis, on the other hand, compresses things down to 4:1, giving an effective throughput of 9600 bps.

The two also differ in how they treat pre-compressed data, such as the contents of a ZIP file. Whereas MNP5 tries to compress every packet of data it gets, thereby wasting time on data that cannot be compressed further, V.42bis recognises the pre-compressed state of the data, and simply sends it on its way without any further waste of time.

Most V.42bis modems also incorporate MNP5, so that if you are calling a MNP5 modem with your V.42bis modem, it will step down to the older protocol. Naturally, the same is not true the other way round.

By now you must have guessed that my friend’s modem had neither MNP nor V.42 error correction – to say nothing about compression.

Modem Vendor Jargon – Tricks and Traps

“This modem has dynamic signal balancing circuitry” says Vendor X, trying to convince me that his modem is just what I needed. When I asked him about error correction, he slunk away.

“This modem is rated for 2400 baud – meaning that you can transfer 2400 bytes in one second !” says Vendor Y. Surprising, I said. I have always thought that “bps” stands for “bits per second”, and that it takes 10 bits to transfer one 8 bit byte, meaning that 2400 bps equals 240 bytes a second. The vendor quickly became a dot on the horizon, fading out.

“This modem works at 1200 bps. Since Indian telephone lines do not support faster speeds, this saves you money because you don’t spend on expensive 2400 bps capabilities that are useless to you” warbles Vendor Z. I just cast a pitying smile on the poor animal, while checking on the progress of the 9600 bps file transfer from Bombay on the V.32/V.42bis modem standing on my desk.

“An internal card modem is much more productive than an external modem” says yet another aspirant. When I eagerly asked him to prove his point by attaching the modem to my Notebook computer (on which I am writing this and which does not have any expansion slots), and then move it to my other machines all within a minute, he politely wished me good day.

“This modem is imported from the USA, and is better than anything available in the Indian market” shimmers the heavily accented salesman. “Great !” I say, “naturally it also comes with the Department of Telecommunications License that allows me to use it on P&T lines without having my phone disconnected . . .”

Where did he go? Probably left before I could ask him about servicing of his modem in India in case of problems.

“This 2400 bps modem actually operates at 9600 bps” gloats another. “Oh Gee !” smiles his tormentor, “let’s try that with this heavily compressed ZIP file”. Is that a bird ? Is it a plane ? Nope, it is just another jargoning salesman beating a hasty retreat.

I think the savvy reader is beginning to see the point I am trying to make. Modems are new to most people, and many modem vendors and their salesmen will try to confuse you with technical jargon that is designed to cover the obvious flaws of the merchandise, such as the lack of Error Correction.

I think this is highly irresponsible, and whereever possible try to get such vendors blacklisted by my clients. To help my clients decide what is genuine and what is not, here is a set of questions that I ask them to place to the vendor (some vendors call them “Atul’s Dirty Dozen”) :

1. Does the modem have error correcting facilities ? (The answer better be “YES”)

2. If yes, what is the error correction scheme that is used ? (Should be MNP or V.42)

3. Does the modem have compression ? (Ideally, should be “YES”)

4. If yes, what scheme does it use (Should be MNP5 or V.42bis. Some vendors use MNP7 – a protocol that was Dead on Arrival and is not used anywhere in the world)

5. What is the modem’s true speed ? (should be 2400, 9600 or 14400 bps, with four times that if using compression)

6. Does the modem have the D.O.T. license for use on the Indian P&T lines ? (Must be “YES”, or you may have your phone disconnected)

7. Is the modem an internal or external model ? (An eternal model has many advantages over an internal one, such as easy mobility, status lights, a voice/data switch, independant power supply, audible speaker, etc.)

8. Does it come with any licensed communication software ? (The answer must be “YES” – modems are useless without communication software, and the software must be legal – piracy is a crime)

9. Does the modem come with any written warranty of at least one year? (If no, you can expect it to fail two days after the invoice is paid)

10. Is the modem made in India ? (Unlike many other electronic devices, Indian modems made by reputable manuacturers tend to perform better under Indian conditions than imported ones, and have the advantage of local support in case of problems. Besides, I am pretty patriotic)

11. Is a comprehensive manual included with the modem ? (You’ll need one to optimise performance and adapt to different situations)

12. Is a serial cable included with the external modem ? (Many vendors try to make this a hidden cost for which they charge you later. Make sure that this is not so)

Get the answers to these questions from the vendor in writing. If possible, ask for a list of references, such as at least five other customers. Check with them about the vendor’s claims of performance and support. If more than 20% of them have complaints, you can expect to join their ranks soon.

Also make sure that the support personnel knows their business. Ask someone from the company to show you how to use the modem, and ask him to demonstrate a file transfer between two of his modems, as well as between his modem and that of another make. If he cannot demonstrate a file transfer, or resorts to the Kermit protocol (a very slow file transfer protocol that places the least strain on the communication link – more on this in a later article), then you cannot expect much support from the vendor when you have problems.

Finally, make sure that you test the modem yourself for at least two days, preferably in the presence of a friend who knows something about modem communications. I have often seen situations where someone blames the bad performance of the modem on his lack of knowledge about such things. This is rarely true.

If you expect the modem to act as a Host Modem that receives calls 24 hours a day all round the year, do not buy the modem if no customer can report long-run performance of the modem. Many modems are likely to fail under such conditions because of component degradation due to heat and power fluctuations.

Winding down

Hey ! Don’t tell me I am out of space already ? I don’t like that evil gleam in my editor’s eye as he advances with his dreaded pair of scissors.

Anyway, to close this piece – my friend bit the bullet and bought a modem locally according to my guidelines. I am happy to report that he not only happily communicates all over the world with his new modem, but is also busy advising people on how to buy a modem.

Next month, I am going to get a bit technical by talking about things like Hardware Flow Control and how it plays an important role in high speed communications. So stay tuned !