Mon, 18 Apr 1994

Communications standards and more modem madness

By James O. Scharf [10pt ML]

JAKARTA (JP): Last week, we looked at communications "standards" and I gave you a list of some of them. By no means was the list complete. Many other standards are in use and it seems that, at the drop of a hat, another "standard" will pop up to confuse us even more.

If you counted, there were 22 standards, encompassing 42 different speeds and modulation techniques. At least 10 others could have been added to the list but I just didn't have the space to include them. And those were just the ones from AT&T and CCITT!

Please take note that the ascending numbers (V.21, V.22, etc.) do not necessarily mean that a lower number has been superseded by a higher one. Also, the abbreviations "bis" and "ter" refer (respectively) to second and third revisions of the standard.

How many standards are there? I count at least 52 others but, since most of these are class designations, it's difficult to tell what this translates into in terms of actual numbers of standards.

The CCITT V-numbers run from V.1 to V.230. There is also a set of T-numbers from T.1 to T.503 that may be quoted by facsimile and fax modem manufacturers. No matter how you count them, the numbers are daunting.

It seems that the Comite Consultatif Internationale de Telephonie et de Telegraphie (CCITT), based in Geneva (where else?), publishes these "recommendations" every four years. Each update is known by the color of its cover. (No, I'm not putting you on.) The '88 edition is known as the Blue Book and the '92 edition is the White Book. (Do these people have day-jobs at the World Bank?)

'Networking'

Once you have sifted through the information pertaining to the transmission hardware, you might want to know about another standard called the Microcom Networking Protocol (MNP). The term "Networking" here, refers to public networks. These standards define protocols for data compression and error detection and correction. They also work with V.42 and V.42bis standards. (Someone get me an aspirin!)

The "classes" of MNP are: NONE, MNP2 (Error correction only), MNP4 (EC with improved speed due to larger data packet sizes), MNP5 (EC + Basic Data Compression at 2:1) and MNP7 (EC + Enhanced Data Compression at 3:1).

Before you start sucking the exhaust pipe of your Kijang, the situation is not as bewildering as it sounds. Your choices are basically V.42 and MNP4 for error control, and V42bis and MNP5 for data compression. Virtually all newer modems offer all four schemes, or none.

The V.42 standard simply provides error correction using Link Access Procedure for Modems (LAPM) as the primary correction method. It can also use MNP2 or MNP4 as alternative methods. V.42bis provides all of the V.42 capabilities plus a data compression scheme. It may also use V.42, MNP7, MNP5 or MNP4 as alternative methods depending on the modem's capabilities. Let's see how this works.

When terminals first connect, they go through a dialog called a "handshaking" phase. During this phase, all transmission parameters set by each user are reviewed and both terminals must agree that, "Yes, I am ready to proceed." Before this agreement, some of the parameters may have to be changed. If both terminals have connected through newer more expensive modems, all parameters are negotiable -- even data frames.

Older modems may be incapable of negotiation or, are only able to negotiate some basic parameters. For example, modem A might connect in at 9600bps but modem B is set for 2400bps. If modem B can step up to 9600bps it will do so. If, however, B only has a max speed of 2400bps, then modem A must fall back to the slower bit rate. If A is unable to comply, the negotiation fails -- with a resultant disconnect.

Both V.42 and V.42bis depend on the modem having the hardware necessary to implement the protocol. V.42 will fall back to MNP7, MNP5 then MNP4. V.42bis will fall back to V.42, MNP7, MNP5, MNP4 then NONE or normal. (I include MNP7 here, since many programs emulate it in software.) NONE will usually wind up as V.32.

If your program supports MNP7, and you know the other terminal supports it, go ahead and use it. If the remote computer cannot support MNP, and you have set up to use it, the negotiation will fail. Renegotiation attempts will start at V.42bis and fall back from there. This wasted time could be costly on international calls. Best to set MNP to NONE if you're not sure.

If you find yourself getting lost in all the protocols, standards and jargon, don't feel too bad. Many computer professionals never get into communications and they are just as lost as you are.

Admittedly, the learning curve is steep and information is scarce. If you're just starting out, a cheap 1200 or 2400bps modem is fine to experiment with. Don't forget, you can always compress files with PKzip, or any other file compression program, and then transmit them. You don't need V.42 for that.

Smartcom

Along with the modem, you'll need some software application to run it. Some better known packages are: CrossTalk, Qmodem, Relay, Smartcom and COMit. Smartcom runs under Windows, as do later versions of CrossTalk. These programs all use the Hayes AT command set. (Which is why you should make sure your modem is Hayes compatible.) Basically, all of these programs do the same thing but will provide different degrees of help and screen layouts to do it.

One of the things that usually confuse new users are the terms "download" and "upload." These terms are both archaic and confusing and should not be used in communications. By definition, "The requesting PC initiates a download and receives the file. The remote PC receives the uploaded file." This might be clear if we are talking about up/downloading to/from a mainframe or to/from a server on a network. But suppose we have two PC users typing to each other, in chat mode, over a phone line.

Bob has a file that he wants to send Ken. He wants Ken to proofread it and send it back. (Remember, this is being typed back and forth.) Bob: "Hey Ken. I'm going to upload a file to you. Please read it and download back." Ken: "Ok, can do. Take me about two minutes and I'll upload it to you. Can you also download STAR.GEM?" Bob: "Sure. I'll upload it right after I get your download."

Now let's take the same conversation and use appropriate communications terms. Bob: "Hey Ken. I'm going to send a file to you. Please read it and send it back." Ken: "Ok, can do. Take me about two minutes and I'll send it to you. Can you also send STAR.GEM?" Bob: "Sure. I'll send it right after I receive my file."

Although I have belabored the point somewhat, conversations like this are real enough. Up/download depends on your point of view. Take Ken's question, "Can you also download STAR.GEM?" From Ken's point of view, Bob is downloading a file to him. But Bob sees it as just the reverse, an upload to Ken. Conversations like this can get quite hilarious at four in the morning, when you've been up all night trying to get a comlink up and running, and you're bleary-eyed and suffering from terminal carpal syndrome and your weary friend on the other end of the link types, "Which directory do I send this file to -- upload or download?"