Indonesian Political, Business & Finance News

Communications standards and more modem madness

| Source: JP

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?"

View JSON | Print