ftp.update.uu.se/ftp.update.uu.se.2014.03.zip/ftp.update.uu.se/pub/rainbow/msdos/decus/RB136/microcom.lzh/MICROCOM.DOC

Text File | 1989-11-12 | 20KB | 359 lines

                            Microcomputer Communications

                                 By David P. Maroun

         Communication is the transfer of information.  The purpose of my
         discussion is to describe the transfer of information from a
         computer of desktop size or smaller to another computer, whether
         small or not.

         Diskette And Tape Transfers
         ---------------------------

         One way to communicate is to exchange diskettes or tapes.  To
         transfer a file from one computer to another, one simply records
         the file on a diskette, say, and then puts the diskette into the
         receiving computer to be read.

         Of course, complications can arise in this procedure.  For
         example, the two computers involved may use different diskette
         formats.  The solution may sometimes be to find a format that both
         machines can understand.  For example, operators of IBM PCs are
         accustomed to using double-sided, 40-track diskettes while those
         with DEC Rainbows use 80-track single-sided diskettes.  Luckily,
         both machines can read and write to 40-track, single-sided
         diskettes.  The main precaution is not to write to the same
         diskette on both machines.  You use one diskette to go from the
         Rainbow to the IBM, and another to go from the IBM to the Rainbow.

         Direct Connection
         -----------------

         But what if one machine has only 3.5-inch diskettes while the
         other has just 5.25-inch drives?  Or, what if one computer uses
         only cassettes for storage, while the other has disk drives but no
         tape drive?  If the two computers are reasonably close to each
         other, and if both have serial ports, then you can use a cable to
         connect one port to the other.  The job is sometimes easier said
         than done.  You can expect to spend time trying to decide which
         pin on one end to connect to which pin on the other, and may have
         to build the cable yourself.  If both ports accept standard 25-pin
         connectors, it may suffice to connect pin number two on each end
         to number three on the other, and also to connect the two pins
         number 7 to each other.  This is the arrangement to use if each
         machine sends information from pin 2, receives on 3, and uses 7
         for a ground.  To make the connection, you can use a straight-
         through 25-wire cable and a null modem adapter to switch between
         pins 2 and 3.

         However, some ports send on pin 3 and receive on 2.  And some may
         use 9-pin connectors or 4-pin DIN connectors.  Furthermore, a port
         may be male or female.  So, you must check your particular
         arrangement before you buy a cable.

         You will also need software that allows the transfer.  That
         software can be as simple and common as CP/M's PIP utility along
         with whatever is necessary to set the rate of transfer and other
         characteristics required for successful communications.

         Note that you should not use a modem for direct connection of one
         computer to another.  A modem introduces unnecessary complication
         and unnecessary chances of error.  In many cases, a modem limits
         the transfer to a slower rate than the computers themselves can
         handle.

         Transfer Over Telephone Lines
         -----------------------------

         But what if the computers are far from each other?  Suppose, for
         example, one is in San Francisco and the other in Chilliwack.
         Then you can communicate over telephone lines.  For that, you need
         a modem.

         The name 'modem' is supposed to be short for 'modulator-
         demodulator'.  Whatever the truth may be in that regard, modems
         convert computer signals into forms that telephone lines can
         handle, and then convert them back.

         To use a modem, you must connect it to a computer and to a
         telephone.  The connections may be made in various ways.  Some
         modems are designed to fit inside computers.  This arrangement
         reduces the price of the modem and the clutter on a desktop but at
         the expense of versatility.  Making mechanical adjustments to the
         modem requires opening up the computer, and using the modem with a
         different computer involves all the complication of removing the
         modem from one computer and installing it in the other.  An
         internal modem is also one more drain on the computer power
         supply, and an extra source of heat inside the computer.

         A modem may be manual, in which case the user must take care of
         dialing or responding to the call of another computer.  Automatic
         modems are specialized computers that can be programmed, and can
         dial or reply to telephone calls.  Various sets of commands may be
         used, but those for Hayes modems has become more or less the
         standard, though it is an unofficial one.  Most Hayes commands
         begin with 'AT', which is taken from the word 'ATTENTION'.  For
         example, if a telephone line uses pulses rather than touch tones,
         'ATDP 1-555-1212' is the Hayes command to dial the number
         1-555-1212.

         Note that various Hayes modems use somewhat different commands.

         Hayes brand modems are generally considered to be of high quality,
         but their high prices make many people avoid them.  Hence, you are
         likely to find many "Hayes compatible" modems rather than modems
         actually made by Hayes.  Being Hayes compatible is no guarantee of
         quality; it means only that a Hayes command set (or a similar set)
         is used.

         Modems may be capable of transferring at different rates.  Typical
         rates are 300 bits per second, 1200 bits per second, or 2400 bits
         per second.  These correspond respectively to about 30, 120, and
         240 characters per second.  I am allowing ten bits per character,
         not eight, because each character is preceded by a start bit and
         followed by at least one stop bit for typical modem transfers.
         The term 'baud' is often taken as equivalent to 'bits per second',
         so that one hears of "1200 baud modems", but to people in the
         field, 'baud' refers to a rate of change of state rather than a
         transfer rate.  The two are often, but not always, the same.

         Modems designed for the three rates I just mentioned are
         sufficiently standardized that any two late-model modems operating
         at one of these speeds can be expected to communicate with each
         other.  The situation is different with those very expensive
         modems functioning at 9600 bits per second or more.  The owner of
         such a fast modem may find himself able to collaborate only with
         someone who has the same brand of modem.

         Some modems are designed to compress information before transfer
         and de-compress it at the other end of the line.  The procedure
         effectively increases the rate of transfer.  However, there is no
         need to buy a special modem to get this effect.  There are plenty
         of programs that will compress files at much less cost.  The
         MS-DOS archiving utility LHARC typically reduces files to half or
         a quarter of their original sizes, and LHARC is available free of
         charge.

         Communications Programs
         -----------------------

         Once you get the required hardware for communications, you need
         software; that is, you need programs which will allow exchanging
         information with other computers.  Some computers--the DEC Robin
         and Rainbow, for example--have built-in terminal modes.  These are
         adequate for contacting other machines and leaving messages.  To
         transfer files, more elaborate software is needed.  A great many
         communications software packages are available in the public
         domain, or at moderate cost as shareware.  The popular CP/M-80
         program MEX (Modem EXecutive) is available for the price of a
         diskette.  Perhaps the standard for MS-DOS is ProComm, which
         (except for the commercial ProComm Plus version) is distributed
         free of charge with the condition that regular users should pay a
         fee directly to the authors.  That fee is as little as $25 in US
         funds.

         Any communications package must allow deciding what characters can
         be transmitted.  Computers use up to eight binary digits (bits) to
         represent characters.  However, the numerals '0' through '9' and
         the letters of the alphabet can be encoded in seven bits.  Some
         systems are set up to handle only seven-bit information--that is,
         ordinary text without special characters like line drawing
         symbols.  Such a system cannot handle an executable file
         transmitted as such.  Your communications package should allow
         setting up a transfer for seven or eight data bits, and allow
         deciding whether to use a so-called parity bit for error checking.
         Finally, the program should allow deciding whether to use one or
         two bits to indicate the end of a character.

         ASCII Transfers
         ---------------

         Typically, a communication program allows various methods (or
         "protocols") of exchanging information.  Usually, you can expect
         the ASCII method, which involves sending information character by
         character with no error checking.  This is the simplest kind of
         transfer over a telephone line, or over a cable connecting two
         computers.  The ASCII method is also the worst I know of.  Any
         disturbance in the connection is likely to introduce changes in
         the information transferred.  Besides, if the receiver cannot keep
         up with the sender--perhaps because the receiver must pause to
         save to disk--then characters will be lost.  This last problem can
         be eliminated by using flow control.  The receiver can supply a
         control-S character which makes the sender stop sending, and
         supply a control-Q when it (the receiver) is ready for more.

         XMODEM And Its Offshoots
         ------------------------

         A step up from the ASCII method is XMODEM, which we can take as
         the basic error-checking transfer method for desktop computers.
         An XMODEM transfer begins with the receiver sending control-U or
         capital 'C' characters until the sender begins to transmit.  Then
         the sender sends a file in blocks of 128 characters.  Each packet
         of 128 characters is preceded by three characters:  A control-A,
         then a sequence number ranging from 1 to 255, and then the
         complement of the sequence number.  After the 128-character
         packet, a checksum (that is, the sum of the 128 characters) or
         cyclic redundancy check is sent.  The receiver also calculates the
         checksum or cyclic redundancy check.  A checksum is made if the
         communication began with a control-U; initial capital 'C's
         determine the use of cyclic redundancy checks.  If the receiver's
         calculation agrees with the sender's, the receiver sends a
         control-F, and the sender transmits another packet.  If the two
         calculations do not agree, then the receiver sends a control-U,
         and the sender resends the last packet.  A control-D character
         indicates the end of the transmission.

         The structure of XMODEM shows its origin under the CP/M operating
         system.  That operating system allots file sizes in blocks of 128
         characters.  If a file is set up with, say, 130 characters,
         another 126 are added as fillers.  If that file is a text file, a
         control-Z is used to indicate the actual end after the 130th
         character.  MS-DOS uses exact file sizes and does not necessarily
         put a control-Z at the end of a text file.  So, files sent by
         XMODEM may pick up as many as 127 garbage characters at the end,
         and these may be very evident in a text file.

         XMODEM also does not transmit the file name nor the creation time
         and date that MS-DOS stores.  These problems are overcome in the
         TELINK method, which is a variation on XMODEM that allows sending
         the exact file size and file name.  TELINK also eliminates another
         restriction of XMODEM by permitting transferring many files with
         one command.

         Another variation on XMODEM is YMODEM, which uses packets of 1024
         characters rather than 128.  That speeds up the transfer by
         reducing the time spent on error checking--provided there are no
         disturbances on the connecting line.  If there are disturbances,
         then resending long packets can make YMODEM slower than XMODEM.

         Some versions of YMODEM allow transfers of several files, and will
         transfer filenames, exact sizes, and creation times.

         The time taken for error checking with XMODEM, TELINK, or YMODEM
         is the same at 300 bits per second as at 2400.  Furthermore, the
         programs make pauses in transmissions to check for errors.  That
         partly reduces the benefit of switching to a faster modem.  This
         problem and others are addressed by ZMODEM, which has the sender
         transmit continuously while inserting from time to time special
         error-checking packets.  Error checking is done even on the error-
         checking packets.  If the receiver finds an error, it tells the
         sender to resend beginning at a specific position in the file.
         Thus, ZMODEM permits sending part of a file.  ZMODEM also allows
         coding special characters, so that for example, control characters
         as such may not appear in the information transferred.  These
         features promise to make ZMODEM fast, versatile, and reliable.

         KERMIT
         ------

         A quite different communications protocol is KERMIT.  KERMIT is
         designed to allow transferring to systems that put severe
         restrictions on communicated information.  For example, only
         seven-bit information may be allowed, and the length of a packet
         may be just 32 characters.  KERMIT permits encoding eight-bit
         information to be transferred to seven-bit systems.  A KERMIT
         transfer begins with an extensive dialogue to decide the precise
         nature of the transfer, and the transfer itself includes extensive
         error-checking.  That makes KERMIT transfers somewhat (or even
         very) slow, especially over networks.  However, KERMIT may be the
         only error-checking method available for dealing with a large
         mainframe.

         To give you an idea of what a communications package can do, here
         are the characteristics of Columbia University's MS-DOS KERMIT
         version 2.32, as reported in the documentation for that program:

              KERMIT-MS Capabilities At A Glance:

              Local operation:                Yes
              Remote operation:               Yes
              Transfers text files:           Yes
              Transfers binary files:         Yes
              Wildcard send:                  Yes
              File transfer interruption:     Yes
              Filename collision avoidance:   Yes
              Can time out:                   Yes
              8th-bit prefixing:              Yes
              Repeat count compression:       Yes
              Alternate block check types:    Yes
              Terminal emulation:             VT102, H19, VT52, Tektronix 4010
              Communication settings:         Speed, Parity, Flow Control, Echo
              Transmit BREAK:                 Yes (and Long BREAK)
              IBM mainframe communication:    Yes
              Transaction logging:            Yes
              Session logging (raw download): Yes
              Raw upload:                     Yes
              Act as server:                  Yes
              Talk to server:                 Yes
              Advanced server functions:      Yes
              Advanced commands for servers:  Yes
              Local file management:          Yes
              Command/init files:             Yes
              Command macros:                 Yes
              Extended-length packets:        Yes
              Local area networks:            Yes (NetBIOS and other support)
              MS-Windows compatibility:       Yes
              Attribute packets:              Yes
              Sliding windows:                No


         Compression Utilities
         ---------------------

         A very significant role is played in microcomputer communications
         by compression utilities.  I mentioned previously that LHARC (to
         name just one) can reduce file sizes significantly, and so
         effectively reduce transfer time.  For this reason, microcomputer
         bulletin boards typically allow only compressed files, with
         perhaps a few exceptions made for text files that provide
         information to people who dial in.  As an example of what a
         compression utility can do, examine the contents of an archive
         created by LHARC:

         Listing of archive : 'A:MICROCOM.LZH'

           Name          Original    Packed  Ratio   Date     Time   Attr Type  CRC
         --------------  --------  -------- ------ -------- -------- ---- ----- ----
         \MICROCOM.CTX
                              801        54   6.7% 89-11-06 23:55:02 a--w -lh1- 1754
         \MICROCOM.DOC
                            14414      5608  38.9% 89-11-06 23:55:00 a--w -lh1- 6AA5
         --------------  --------  -------- ------ -------- --------
              2 files       15215      5662  37.2% 89-11-06 23:58:48

         Not only does the compression utility reduce the overall file
         sizes, but it combines several files into one, thus allowing
         keeping related files together.

         Of course, the archiving utility introduces a bit of overhead.
         The total file size is a bit larger than the 5662 characters
         indicated in the archive directory listing.  In fact, the MS-DOS
         listing is

              MICROCOM LZH     5737  89-11-06  23:58

         Still, 5737 characters are much less than 15215.

         LHARC is by no means the only compression utility.  Under MS-DOS,
         two others especially, PAK and PKZIP, vie with it for top honors
         at compression.  And, these utilities are not only used for
         preparing files for communications.  Archivers make good back-up
         utilities, and using archives is an efficient way of storing files
         in a library.

         Using archives avoids certain problems of transferring files.  For
         example, if you transferred MICROCOM.LZH by XMODEM, 23 garbage
         characters would be added to make the archive's size a whole
         number multiple of 128.  But these characters would be added to
         the archive, not to its component files.  The receiver would be
         able to extract MICROCOM.DOC to its original size.  Furthermore,
         MICROCOM.DOC's name and creation time would be preserved.

         For Further Study
         -----------------

         If you are would like more information, you can consult the
         documentation included with your equipment and software.