Communications standards and more modem madness<\/p>\n
By James O. Scharf [10pt ML]<\/p>\n
JAKARTA (JP): Last week, we looked at communications
\n\"standards\" and I gave you a list of some of them. By no means
\nwas the list complete. Many other standards are in use and it
\nseems that, at the drop of a hat, another \"standard\" will pop up
\nto confuse us even more.<\/p>\n
If you counted, there were 22 standards, encompassing 42
\ndifferent speeds and modulation techniques. At least 10 others
\ncould have been added to the list but I just didn't have the
\nspace to include them. And those were just the ones from AT&T and
\nCCITT!<\/p>\n
Please take note that the ascending numbers (V.21, V.22, etc.)
\ndo not necessarily mean that a lower number has been superseded
\nby a higher one. Also, the abbreviations \"bis\" and \"ter\" refer
\n(respectively) to second and third revisions of the standard.<\/p>\n
How many standards are there? I count at least 52 others but,
\nsince most of these are class designations, it's difficult to
\ntell what this translates into in terms of actual numbers of
\nstandards.<\/p>\n
The CCITT V-numbers run from V.1 to V.230. There is also a set
\nof T-numbers from T.1 to T.503 that may be quoted by facsimile
\nand fax modem manufacturers. No matter how you count them, the
\nnumbers are daunting.<\/p>\n
It seems that the Comite Consultatif Internationale de
\nTelephonie et de Telegraphie (CCITT), based in Geneva (where
\nelse?), publishes these \"recommendations\" every four years. Each
\nupdate is known by the color of its cover. (No, I'm not putting
\nyou on.) The '88 edition is known as the Blue Book and the '92
\nedition is the White Book. (Do these people have day-jobs at the
\nWorld Bank?)<\/p>\n
'Networking'<\/p>\n
Once you have sifted through the information pertaining to the
\ntransmission hardware, you might want to know about another
\nstandard called the Microcom Networking Protocol (MNP). The term
\n\"Networking\" here, refers to public networks. These standards
\ndefine protocols for data compression and error detection and
\ncorrection. They also work with V.42 and V.42bis standards.
\n(Someone get me an aspirin!)<\/p>\n
The \"classes\" of MNP are: NONE, MNP2 (Error correction only),
\nMNP4 (EC with improved speed due to larger data packet sizes),
\nMNP5 (EC + Basic Data Compression at 2:1) and MNP7 (EC + Enhanced
\nData Compression at 3:1).<\/p>\n
Before you start sucking the exhaust pipe of your Kijang, the
\nsituation is not as bewildering as it sounds. Your choices are
\nbasically V.42 and MNP4 for error control, and V42bis and MNP5
\nfor data compression. Virtually all newer modems offer all four
\nschemes, or none.<\/p>\n
The V.42 standard simply provides error correction using Link
\nAccess Procedure for Modems (LAPM) as the primary correction
\nmethod. It can also use MNP2 or MNP4 as alternative methods.
\nV.42bis provides all of the V.42 capabilities plus a data
\ncompression scheme. It may also use V.42, MNP7, MNP5 or MNP4 as
\nalternative methods depending on the modem's capabilities. Let's
\nsee how this works.<\/p>\n
When terminals first connect, they go through a dialog called
\na \"handshaking\" phase. During this phase, all transmission
\nparameters set by each user are reviewed and both terminals must
\nagree that, \"Yes, I am ready to proceed.\" Before this agreement,
\nsome of the parameters may have to be changed. If both terminals
\nhave connected through newer more expensive modems, all
\nparameters are negotiable -- even data frames.<\/p>\n
Older modems may be incapable of negotiation or, are only able
\nto negotiate some basic parameters. For example, modem A might
\nconnect in at 9600bps but modem B is set for 2400bps. If modem B
\ncan step up to 9600bps it will do so. If, however, B only has a
\nmax speed of 2400bps, then modem A must fall back to the slower
\nbit rate. If A is unable to comply, the negotiation fails -- with
\na resultant disconnect.<\/p>\n
Both V.42 and V.42bis depend on the modem having the hardware
\nnecessary to implement the protocol. V.42 will fall back to MNP7,
\nMNP5 then MNP4. V.42bis will fall back to V.42, MNP7, MNP5, MNP4
\nthen NONE or normal. (I include MNP7 here, since many programs
\nemulate it in software.) NONE will usually wind up as V.32.<\/p>\n
If your program supports MNP7, and you know the other terminal
\nsupports it, go ahead and use it. If the remote computer cannot
\nsupport MNP, and you have set up to use it, the negotiation will
\nfail. Renegotiation attempts will start at V.42bis and fall back
\nfrom there. This wasted time could be costly on international
\ncalls. Best to set MNP to NONE if you're not sure.<\/p>\n
If you find yourself getting lost in all the protocols,
\nstandards and jargon, don't feel too bad. Many computer
\nprofessionals never get into communications and they are just as
\nlost as you are.<\/p>\n
Admittedly, the learning curve is steep and information is
\nscarce. If you're just starting out, a cheap 1200 or 2400bps
\nmodem is fine to experiment with. Don't forget, you can always
\ncompress files with PKzip, or any other file compression program,
\nand then transmit them. You don't need V.42 for that.<\/p>\n
Smartcom<\/p>\n
Along with the modem, you'll need some software application to
\nrun it. Some better known packages are: CrossTalk, Qmodem, Relay,
\nSmartcom and COMit. Smartcom runs under Windows, as do later
\nversions of CrossTalk. These programs all use the Hayes AT
\ncommand set. (Which is why you should make sure your modem is
\nHayes compatible.) Basically, all of these programs do the same
\nthing but will provide different degrees of help and screen
\nlayouts to do it.<\/p>\n
One of the things that usually confuse new users are the terms
\n\"download\" and \"upload.\" These terms are both archaic and
\nconfusing and should not be used in communications. By
\ndefinition, \"The requesting PC initiates a download and receives
\nthe file. The remote PC receives the uploaded file.\" This might
\nbe clear if we are talking about up\/downloading to\/from a
\nmainframe or to\/from a server on a network. But suppose we have
\ntwo PC users typing to each other, in chat mode, over a phone
\nline.<\/p>\n
Bob has a file that he wants to send Ken. He wants Ken to
\nproofread it and send it back. (Remember, this is being typed
\nback and forth.) Bob: \"Hey Ken. I'm going to upload a file to
\nyou. Please read it and download back.\" Ken: \"Ok, can do. Take me
\nabout two minutes and I'll upload it to you. Can you also
\ndownload STAR.GEM?\" Bob: \"Sure. I'll upload it right after I get
\nyour download.\"<\/p>\n
Now let's take the same conversation and use appropriate
\ncommunications terms. Bob: \"Hey Ken. I'm going to send a file to
\nyou. Please read it and send it back.\" Ken: \"Ok, can do. Take me
\nabout two minutes and I'll send it to you. Can you also send
\nSTAR.GEM?\" Bob: \"Sure. I'll send it right after I receive my
\nfile.\"<\/p>\n
Although I have belabored the point somewhat, conversations
\nlike this are real enough. Up\/download depends on your point of
\nview. Take Ken's question, \"Can you also download STAR.GEM?\" From
\nKen's point of view, Bob is downloading a file to him. But Bob
\nsees it as just the reverse, an upload to Ken. Conversations like
\nthis can get quite hilarious at four in the morning, when you've
\nbeen up all night trying to get a comlink up and running, and
\nyou're bleary-eyed and suffering from terminal carpal syndrome
\nand your weary friend on the other end of the link types, \"Which
\ndirectory do I send this file to -- upload or download?\"<\/p>",
"url": "https:\/\/jawawa.id\/newsitem\/communications-standards-and-more-modem-madness-1447899208",
"image": ""
},
"sponsor": "Okusi Associates",
"sponsor_url": "https:\/\/okusiassociates.com"
}