em@dce.ie (Eamonn McManus) (12/04/90)
I have a couple of questions on subjects I would like to put in the lexicon. First, I recall reading here that the CCITT will no longer be publishing its standards in sets of coloured books. Will it be publishing standards individually, or what will the form of publication be? Second, I would like to say a bit more about FAX, but unfortunately I am rather ignorant in that area. Do people think that more needs to be said than the brief mention of V.29 under <V series>? , Eamonn
em@dce.ie (Eamonn McManus) (01/03/91)
[Since there don't seem to have been many Frequently Asked Questions recently
I'm thinking of changing the frequency of this posting to monthly instead
of fortnightly. Comments are welcome.]
$Id: lexicon,v 0.2 90/12/03 18:27:26 em Exp $
Comp.dcom.modems lexicon, by Eamonn McManus <em@dce.ie>. Contributions by:
Charles Bryant <ch@dce.ie>.
Ronald S H Khoo <ronald@robobar.co.uk>
David Lesher <wb8foz@mthvax.cs.miami.edu>
Chip Rosenthal <chip@chinacat.unicom.com>
This lexicon is intended to provide a basic introduction to terms used in
modem technology. In the interests of brevity, some technical details and
qualifications are omitted. Corrections, additions, and suggestions are
welcome; send them to <em@dce.ie>.
This document is not copyrighted and may be used freely.
Words in angle brackets, like <this>, denote cross-references. The
following terms are defined or discussed here:
Asynchronous, AT commands, back channel, baud, Bell standards, bps,
carrier, CCITT, compression, CTS, DCD, DCE, DSR, DTE, DTMF, DTR, error
correction, external modem, fall back, flow control, four wire, full
duplex, half duplex, Hayes, internal modem, leased line, MNP, modulation,
parallel, PEP, PTT, RTS, serial, speed buffering, spoofing, synchronous,
Trailblazer, uucp, V series, window, XMODEM, XON/XOFF, ZMODEM.
---
Asynchronous. Used of a <serial> connection where each byte is sent
independently. The start and end of a byte are indicated by separate bits
so each byte takes 10 bits to transmit. See <synchronous>.
AT commands. See <Hayes>. (Unrelated to the PC/AT.)
Back channel. A slow communications channel provided in the reverse
direction to the main channel, in <V.23> for example.
Baud. A unit of communication speed, defined as signalling elements per
second. Not the same as bps since sometimes each signalling element
carries several bits. (There is no such thing as a 9600 baud modem,
for instance.) Terminals always have baud the same as bps.
Bell standards. <Modulation> techniques used in North America. Bell 103
is a 300bps standard; Bell 212 is 1200bps. Not allowed in some European
countries. See <V series>.
Bps. Bits per second. See <baud>.
Carrier. Roughly speaking, the tones a modem sends when it is not sending
data. Data are then variations in these tones. When the remote modem
stops emitting carrier, the local modem can assume it has hung up, unless
the local modem is now the sending party in a <half duplex> connection.
CCITT. A French acronym for the International Telegraph and Telephone
Consultative Committee, which sets standards for telephone communication
among other things. Their standards (or `recommendations' as they have
it) are published every so often in a set of `fascicles', whose colour
varies with the year. The current set is the `blue books' published in
1988. The standards are copyrighted, so they are not available
electronically. You should be able to find them at any good
engineering library. See <V series>.
Compression. Reduction of the size of data by exploiting redundancy. Many
modern modems incorporate use <MNP5> or <V.42 bis> to compress data
before they are sent over the phone line. For this to be effective, the
modem must be fed data at a higher speed than the phone line speed.
Compression is most useful for interactive sessions in the modem. If you
are sending files, compressing them on the computer before sending is
usually more effective. In this case, make sure that the modem is not
also trying to compress, because already-compressed data will become
bigger if re-compressed.
For compression to work, it is essential that the data are sent over an
error-free link. Otherwise the modems could get out of sync and
hopelessly garble the data. Since common <error correction> protocols are
<synchronous>, there is usually a throughput gain there as well.
Manufacturer claims that MNP5 provides a 2:1 reduction in size, or that
V.42 bis provides 4:1, should be taken with a grain of salt. They are
only true for suitable data. See <MNP5> and <V.42 bis>.
CTS. Clear to send. A signal from <DCE> to <DTE>. Typically used for
<flow control>.
DCD. Data carrier detect. A signal from <DCE> to <DTE>, indicating that a
<carrier> tone is being heard from the remote modem. See <DSR>.
DCE. Data circuit-terminating equipment. Whatever is connected to a phone
line. Effectively, a modem.
DSR. Data set ready. A signal from <DCE> to <DTE>, indicating that a
connection is in progress. For <half duplex> connections, DSR will be on
during the entire session, while <CD> will be on only when the modem is
receiving.
DTE. Data terminal equipment. The computer or terminal that talks to a
modem locally.
DTMF. Dual tone multiple frequency. The standard method for tone dialling.
DTR. Data terminal ready. A signal from <DTE> to <DCE>. Sometimes used
for <flow control>, though <RTS> is more usual nowadays. Typically,
dropping DTR will cause the modem to hang up.
Error correction. Communication between the modems to ensure that the data
sent by one end are the same as those received by the other, even in the
presence of noise on the line. Typically this is done by adding
checksums to the data. If the received data don't match their checksum
the receiving modem asks for them to be sent again.
Like <compression>, error correction is most useful for interactive use.
When sending files, it is generally best to let the computers at each end
do the correction, using a protocol like Kermit or <uucp>. However, the
ability of <MNP4> and <V.42> to send data <synchronously> may make it
worthwhile to use them. See also <spoofing>.
External modem. See <internal modem>.
Fall back. The ability of a modem to operate at a lower speed than its
maximum, used either for compatibility with a different type of modem
(e.g. <V.22 bis> can fall back to <V.22>) or to reduce the number of
errors over a link that cannot carry the fastest speed.
Flow control. Ensuring that a unit, whether modem or computer, is not
supplied with more data than it can cope with. The unit must have some
way to signal to the data source to stop sending. Ideally, every unit on
the communication path should have a way to manage flow control with its
peers; otherwise if available buffer space is exceeded some data may be
lost.
Between <DTE> and <DCE> the possibilities are <RTS>/<CTS> and <XON/XOFF>.
Between two <DCE>s <XON/XOFF> is the only possibility. However, if a
protocol such as <MNP> is being run between the modems, this will
contain provision for flow control. If you can guarantee that the <DTE>s
will always be able to accept data, you should not need flow control
between the <DCE>s.
Four wire. A <leased line> with separate connections for transmitting data
in each direction.
Full duplex. Able to send data in both directions at once.
Half duplex. Able to send data in only one direction at a time.
Hayes. Modem manufacturer. The `Hayes command set' is supported by most
modern modems. Hayes commands look like ATD1234 (dial 1234) or ATA
(answer the phone). The commands for simple things like this are fairly
standard, but more complex things tend to be manufacturer-specific. A
<CCITT> standard for Hayes commands is in preparation.
Internal modem. A modem card that slots into your computer, as opposed to
an external modem, which is a separate unit. Internal modems are usually
cheaper but they have some disadvantages. An external modem can be used
with any computer; it will have diagnostic lights to see what is going
on; and it means the phone line is further from your PC and so less likely
to conduct lightning strikes into it.
Leased line. A permanent point-to-point connection rented from the phone
company.
MNP. Microcom Network Protocols. A set of modem-to-modem protocols that
provide <error correction> and <compression>. The commonly encountered
ones are these:
MNP2. <Error correction> using <asynchronous> transmission.
MNP3. <Error correction> using <synchronous> transmission between the
modems (the <DTE> interface is still <asynchronous>). Since each
eight-bit byte takes eight rather than ten bits to transmit there is
scope for a 20% increase in throughput. Unfortunately the MNP3
protocol overhead is rather high so this increase is not realised.
MNP4. Introduces `data phase optimisation', which improves on the rather
inefficient protocol design of MNP2 and MNP3. <Synchronous> MNP4 comes
closer to achieving the 20% throughput increase mentioned above.
MNP5. Simple data compression. Dynamically arranges for commonly
occurring characters to be transmitted with fewer bits than rare
characters. It takes account of changing character frequencies as it
runs. Also encodes long runs of the same character specially. Typically
compresses text by 35%; with 20% for MNP4 this reduces data by almost
50%.
Modulation. Converting a data stream into sounds to be sent down a phone
line. The opposite is demodulation. `Modem' stands for modulator/
demodulator.
Parallel. Sending several bits at a time, usually 8, each over a separate
wire. Some modems have a parallel connection from <DTE> to <DCE>.
PEP. A proprietary <modulation> technique devised by Telebit and used in
their Trailblazer modems. It can achieve throughput of 9600bps or
better, and is reported to be more resilient than <V.32>. However, it is
<half duplex> with a long <turnaround time>, so for file transfer it
generally has to be used with protocol <spoofing>. Trailblazers can
spoof <uucp>, Kermit, and Z-modem, among other things.
PTT. General term for the national organisation(s) in charge of telephone
and postal communications.
RTS. Request to send. A signal from <DTE> to <DCE>. In modern modems,
this is generally used for <flow control>; when RTS is off the modem will
not send data to the terminal.
Serial. Sending one bit at a time. Opposite of <parallel>.
Speed buffering. Early modems had very simple hardware which modulated
data from the terminal directly onto the phone line. This meant that the
terminal speed and the line speed had to be the same. Modern modems
allow them to be different (speed buffering), but unfortunately the old
assumption is wired into many communications programs, so modems also
have to provide the ability to change the terminal speed to the same as
the line speed when a connection is established.
Spoofing. Protocol spoofing is used by Trailblazers (see <PEP>). The
modem knows what protocol you are using to transfer files to the far end.
It pretends to be the remote computer and acknowledges the local data as
soon as it gets them. The two Trailblazers then conspire to get the data
safely to the far end.
Synchronous. Used of a <serial> connection where bytes are sent in a
continuous stream. Some sort of protocol is needed to flag the case
where no bytes are available to be sent.
Trailblazer. See <PEP>.
Turnaround time. The time taken in a <half duplex> link to reverse the
direction of communication.
uucp. Unix-to-Unix copy. This is the name of a Unix command, but it is
now also used to refer to the protocols used by it to transfer files
between Unix machines. There are a number of such protocols, and the two
machines choose between the ones supported by each. Free implementations
also exist for VMS and MS-DOS. The newsgroup comp.mail.uucp may be more
appropriate for discussions.
V series. A set of standards published by the <CCITT> for `Data
Communication over the Telephone Network'. The following standards
describe the important <modulation> techniques:
V.21: 300bps.
V.22: 1200bps, with <fall back> to 600bps.
V.22 bis: 2400bps, with <fall back> to V.22.
V.23: 1200bps with 75bps <back channel>, with <fall back> to 600bps/75bps.
V.29: 9600bps <half duplex> or <four wire> (used by FAX) with <fall back>
to 7200bps and 4800bps.
V.32: 9600bps with <fall back> to 4800bps.
V.32 bis: 14400bps with <fall back> to 12000bps, 9600bps, 7200bps and
4800 bps.
Other standards you may encounter:
V.24: connection between <DCE> and <DTE>. Effectively the same as RS232,
though V.24 only specifies the meaning of the signals, not the
connector nor the voltages used.
V.25 bis: a cryptic command language for modems.
V.42: <error correction> with <asynchronous> to <synchronous> conversion.
V.42 bis: data <compression> using a Lempel-Ziv related technique, which
detects frequently occurring character strings and replaces them with
tokens. This is similar to Unix compress. Typical compression for
text is 50% or better; with nearly 20% gain from <synchronous>
conversion this gives reduces transmission time by almost 60%.
Window. Most protocols divide the data to be sent into `packets'.
To eliminate delays several packets may be sent before any one is
acknowledged. If this is allowed by a protocol, the window is the
number of packets that can be sent before an acknowledgement is
received.
XMODEM. A primitive file-transfer protocol. It has the property that
files must be a multiple of 128 bytes long. It is <half duplex> so it
performs badly on fast modems.
XON/XOFF. A method of <flow control>. The XOFF character (ASCII 19) is
sent to stop further characters, and XON (ASCII 17) is sent to resume
them. This method is inferior to hardware flow control using <RTS> and
<CTS>, since it means that XON and XOFF characters cannot be freely used
in the data.
ZMODEM. A file-transfer protocol.em@dce.ie (Eamonn McManus) (03/05/91)
[No change since last posting.]
$Id: lexicon,v 1.0 91/02/01 16:47:06 em Exp $
Comp.dcom.modems lexicon, by Eamonn McManus <em@dce.ie>. Contributions by:
Charles Bryant <ch@dce.ie>
Ronald S H Khoo <ronald@robobar.co.uk>
David Lesher <wb8foz@mthvax.cs.miami.edu>
Chip Rosenthal <chip@chinacat.unicom.com>
Colin Plumb <ccplumb@rose.uwaterloo.ca>
This lexicon is intended to provide a basic introduction to terms used in
modem technology. In the interests of brevity, some technical details and
qualifications are omitted. Corrections, additions, and suggestions are
welcome; send them to <em@dce.ie>.
This document is not copyrighted and may be used freely.
Words in angle brackets, like <this>, denote cross-references. The
following terms are defined or discussed here:
Asymmetric, asynchronous, AT commands, back channel, baud, Bell
standards, bps, carrier, CCITT, compression, CTS, DCD, DCE, DSR, DTE,
DTMF, DTR, EIA232, error correction, external modem, fall back, flow
control, four wire, full duplex, half duplex, Hayes, internal modem,
latency, leased line, MNP, modulation, parallel, PEP, PTT, RS232, RTS,
serial, speed buffering, spoofing, synchronous, Trailblazer, turnaround
time, uucp, V series, window, XMODEM, XON/XOFF, ZMODEM.
---
Asymmetric. Faster in one direction than the other. The faster direction
is called the main channel and the slower is the back channel. See
<V.23> and <PEP> for examples. Both of these allow the directions of the
channels to be exchanged; see <turnaround time>.
Asynchronous. Used of a <serial> connection where each byte is sent
independently. The start and end of a byte are indicated by separate bits
so each byte takes 10 bits to transmit. See <synchronous>.
AT commands. See <Hayes>. (Unrelated to the PC/AT.)
Back channel. See <asymmetric>.
Baud. A unit of communication speed, defined as signalling elements per
second. Not the same as <bps> since sometimes each signalling element
carries several bits. (There is no such thing as a 9600 baud modem,
for instance.) <RS232> terminals always have baud the same as bps.
Bell standards. <Modulation> techniques used in North America. Bell 103
is a 300bps standard; Bell 212 is 1200bps. Not allowed in some European
countries. See <V series>.
Bps. Bits per second. See <baud>.
Carrier. Roughly speaking, the tones a modem sends when it is not sending
data. Data are then variations in these tones. When the remote modem
stops emitting carrier, the local modem can assume it has hung up, unless
the local modem is now the sending party in a <half duplex> connection.
CCITT. A French acronym for the International Telegraph and Telephone
Consultative Committee, which sets standards for telephone communication
among other things. Their standards (or `recommendations' as they have
it) are published every so often in a set of `fascicles', whose colour
varies with the year. The current set is the `blue books' published in
1988. The standards are copyrighted, so they are not available
electronically. You should be able to find them at any good
engineering library. See <V series>.
Compression. Reduction of the size of data by exploiting redundancy. Many
modern modems incorporate use <MNP5> or <V.42 bis> to compress data
before they are sent over the phone line. For this to be effective, the
modem must be fed data at a higher speed than the phone line speed.
Compression is most useful for interactive sessions in the modem. If you
are sending files, compressing them on the computer before sending is
usually more effective. In this case, make sure that the modem is not
also trying to compress, because already-compressed data will become
bigger if re-compressed.
For compression to work, it is essential that the data are sent over an
error-free link. Otherwise the modems could get out of sync and
hopelessly garble the data. Since common <error correction> protocols are
<synchronous>, there is usually a throughput gain there as well.
Manufacturer claims that MNP5 provides a 2:1 reduction in size, or that
V.42 bis provides 4:1, should be taken with a grain of salt. They are
only true for suitable data. See <MNP5> and <V.42 bis>.
CTS. Clear to send. A signal from <DCE> to <DTE>. Typically used for
<flow control>.
DCD. Data carrier detect. A signal from <DCE> to <DTE>, indicating that a
<carrier> tone is being heard from the remote modem. See <DSR>.
DCE. Data circuit-terminating equipment. Whatever is connected to a phone
line. Effectively, a modem.
DSR. Data set ready. A signal from <DCE> to <DTE>, indicating that a
connection is in progress. For <half duplex> connections, DSR will be on
during the entire session, while <DCD> will be on only when the modem is
receiving.
DTE. Data terminal equipment. The computer or terminal that talks to a
modem locally.
DTMF. Dual tone multiple frequency. The standard method for tone dialling.
DTR. Data terminal ready. A signal from <DTE> to <DCE>. Sometimes used
for <flow control>, though <RTS> is more usual nowadays. Typically,
dropping DTR will cause the modem to hang up.
EIA232. See <RS232>.
Error correction. Communication between the modems to ensure that the data
sent by one end are the same as those received by the other, even in the
presence of noise on the line. Typically this is done by adding
checksums to the data. If the received data don't match their checksum
the receiving modem asks for them to be sent again.
Like <compression>, error correction is most useful for interactive use.
When sending files, it is generally best to let the computers at each end
do the correction, using a protocol like Kermit or <uucp>. However, the
ability of <MNP4> and <V.42> to send data <synchronously> may make it
worthwhile to use them. See also <spoofing>.
External modem. See <internal modem>.
Fall back. The ability of a modem to operate at a lower speed than its
maximum, used either for compatibility with a different type of modem
(e.g. <V.22 bis> can fall back to <V.22>) or to reduce the number of
errors over a link that cannot carry the fastest speed.
Flow control. Ensuring that a unit, whether modem or computer, is not
supplied with more data than it can cope with. The unit must have some
way to signal to the data source to stop sending. Ideally, every unit on
the communication path should have a way to manage flow control with its
peers; otherwise if available buffer space is exceeded some data may be
lost.
Between <DTE> and <DCE> the possibilities are <RTS>/<CTS> and <XON/XOFF>.
Between two <DCE>s <XON/XOFF> is the only possibility. However, if a
protocol such as <MNP> is being run between the modems, this will
contain provision for flow control. If you can guarantee that the <DTE>s
will always be able to accept data, you should not need flow control
between the <DCE>s.
Four wire. A <leased line> with separate connections for transmitting data
in each direction.
Full duplex. Able to send data in both directions at once.
Half duplex. Able to send data in only one direction at a time. Some
protocol is usually used to switch the direction as needed.
Hayes. Modem manufacturer. The `Hayes command set' is supported by most
modern modems. Hayes commands look like ATD1234 (dial 1234) or ATA
(answer the phone). The commands for simple things like this are fairly
standard, but more complex things tend to be manufacturer-specific. A
<CCITT> standard for Hayes commands is in preparation.
Internal modem. A modem card that slots into your computer, as opposed to
an external modem, which is a separate unit. Internal modems are usually
cheaper but they have some disadvantages. An external modem can be used
with any computer; it will have diagnostic lights to see what is going
on; and it means the phone line is further from your PC and so less likely
to conduct lightning strikes into it.
Latency. The delay between data being sent and being received by the far
end. A combination of transmission delays and <modulation> properties.
Leased line. A permanent point-to-point connection rented from the phone
company.
MNP. Microcom Network Protocols. A set of modem-to-modem protocols that
provide <error correction> and <compression>. The commonly encountered
ones are these:
MNP2. <Error correction> using <asynchronous> transmission.
MNP3. <Error correction> using <synchronous> transmission between the
modems (the <DTE> interface is still <asynchronous>). Since each
eight-bit byte takes eight rather than ten bits to transmit there is
scope for a 20% increase in throughput. Unfortunately the MNP3
protocol overhead is rather high so this increase is not realised.
MNP4. Introduces `data phase optimisation', which improves on the rather
inefficient protocol design of MNP2 and MNP3. <Synchronous> MNP4 comes
closer to achieving the 20% throughput increase mentioned above.
MNP5. Simple data compression. Dynamically arranges for commonly
occurring characters to be transmitted with fewer bits than rare
characters. It takes account of changing character frequencies as it
runs. Also encodes long runs of the same character specially. Typically
compresses text by 35%; with 20% for MNP4 this reduces data by almost
50%.
Modulation. Converting a data stream into sounds to be sent down a phone
line. The opposite is demodulation. `Modem' stands for modulator/
demodulator.
Parallel. Sending several bits at a time, usually 8, each over a separate
wire. Some modems have a parallel connection from <DTE> to <DCE>.
PEP. A proprietary <modulation> and <error correction> technique devised
by Telebit and used in their Trailblazer modems. It can achieve
throughput of 9600bps or better, and is reported to be able to sustain
noisy connections better than <V.32>. However, it is <asymmetric> a
with a very slow <back channel> and a long <turnaround time> and
<latency>. Protocols with small <windows> work very poorly unless
<spoofing> is used. Trailblazers can spoof <uucp>, Kermit, and <XMODEM>.
PTT. General term for the national organisation(s) in charge of telephone
and postal communications.
RS232. The usual connection between <DCE> and <DTE>, now properly called
EIA232. It allows for 25 signals, most of which are not used on typical
connections. The minimum needed signals are ground, TxD (transmit data),
and RxD (receive data). Typically modem control lines <DCD> and <DTR>
and flow control lines <RTS> and <CTS> will also be used. See <V.24>.
RTS. Request to send. A signal from <DTE> to <DCE>. In modern modems,
this is generally used for <flow control>; when RTS is off the modem will
not send data to the terminal. In <half duplex> connections, RTS may
mean that the <DTE> has data to send, so the <DCE> should stop sending
to it and assert <CTS>.
Serial. Sending one bit at a time. Opposite of <parallel>.
Speed buffering. Early modems had very simple hardware which modulated
data from the terminal directly onto the phone line. This meant that the
terminal speed and the line speed had to be the same. Modern modems
allow them to be different (speed buffering), but unfortunately the old
assumption is wired into many communications programs, so modems also
have to provide the ability to change the terminal speed to the same as
the line speed when a connection is established. If the terminal speed
is faster than the line speed, <flow control> to the terminal will
usually be needed.
Spoofing. Protocol spoofing is used by Trailblazers (see <PEP>). The
modem knows what protocol you are using to transfer files to the far end.
It pretends to be the remote computer and acknowledges the local data as
soon as it gets them. The two Trailblazers then conspire to get the data
safely to the far end.
Synchronous. Used of a <serial> connection where bytes are sent in a
continuous stream. Some sort of protocol is needed to flag the case
where no bytes are available to be sent.
Trailblazer. See <PEP>.
Turnaround time. The time taken in a <half duplex> or <asymmetric> link to
reverse the direction of communication.
uucp. Unix-to-Unix copy. This is the name of a Unix command, but it is
now also used to refer to the protocols used by it to transfer files
between Unix machines. There are a number of such protocols, and the two
machines choose between the ones supported by each. Free implementations
also exist for VMS and MS-DOS. The newsgroup comp.mail.uucp may be more
appropriate for discussions.
V series. A set of standards published by the <CCITT> for `Data
Communication over the Telephone Network'. The following standards
describe the important <modulation> techniques:
V.21: 300bps.
V.22: 1200bps, with <fall back> to 600bps.
V.22 bis: 2400bps, with <fall back> to V.22.
V.23: 1200bps with 75bps <back channel>, with <fall back> to 600bps/75bps.
V.29: 9600bps <half duplex> or <four wire> (used by FAX) with <fall back>
to 7200bps and 4800bps.
V.32: 9600bps with <fall back> to 4800bps.
V.32 bis: 14400bps with <fall back> to 12000bps, 9600bps, 7200bps and
4800 bps.
Other standards you may encounter:
V.24: connection between <DCE> and <DTE>. Effectively the same as
<RS232>, though V.24 only specifies the meaning of the signals, not
the connector nor the voltages used.
V.25 bis: a cryptic command language for modems.
V.42: <error correction> with <asynchronous> to <synchronous> conversion.
V.42 bis: data <compression> using a Lempel-Ziv related technique, which
detects frequently occurring character strings and replaces them with
tokens. This is similar to Unix compress. Typical compression for
text is 50% or better; with nearly 20% gain from <synchronous>
conversion this gives reduces transmission time by almost 60%.
Window. Most protocols divide the data to be sent into `packets'.
To eliminate delays several packets may be sent before any one is
acknowledged. If this is allowed by a protocol, the window is the
number of packets that can be sent before an acknowledgement is
received.
XMODEM. A primitive file-transfer protocol. It has the property that
files must be a multiple of 128 bytes long. It is <half duplex> (has a
<window> of one packet) so it performs badly on fast modems.
XON/XOFF. A method of <flow control>. The XOFF character (ASCII 19) is
sent to stop further characters, and XON (ASCII 17) is sent to resume
them. This method is inferior to hardware flow control using <RTS> and
<CTS>, since it means that XON and XOFF characters cannot be freely used
in the data.
ZMODEM. A fast file-transfer protocol with <windows>.schuster@panix.uucp (Michael Schuster) (03/06/91)
In article <bishop@dce.ie> em@dce.ie (Eamonn McManus) writes: >[No change since last posting.] > >$Id: lexicon,v 1.0 91/02/01 16:47:06 em Exp $ > >Comp.dcom.modems lexicon, by Eamonn McManus <em@dce.ie>. Contributions by: > Charles Bryant <ch@dce.ie> > Ronald S H Khoo <ronald@robobar.co.uk> > David Lesher <wb8foz@mthvax.cs.miami.edu> > Chip Rosenthal <chip@chinacat.unicom.com> > Colin Plumb <ccplumb@rose.uwaterloo.ca> > >Full duplex. Able to send data in both directions at once. > >Half duplex. Able to send data in only one direction at a time. Some > protocol is usually used to switch the direction as needed. > Toby Nixon has stated on CompuServe that according to CCITT terminology, "duplex" means transmitting simultaneously in both directions at the same speed. Therefore "full duplex" is undefined and redundant. (Toby, are you listening?) -- Mike Schuster | CIS: 70346,1745 NY Public Access UNIX: ...cmcl2!panix!schuster | MCI Mail, GENIE: The Portal (R) System: schuster@cup.portal.com | MSCHUSTER
grr@cbmvax.commodore.com (George Robbins) (03/06/91)
In article <1991Mar5.225546.6672@panix.uucp> schuster@panix.uucp (Michael Schuster) writes: > In article <bishop@dce.ie> em@dce.ie (Eamonn McManus) writes: > > > >Full duplex. Able to send data in both directions at once. > > > >Half duplex. Able to send data in only one direction at a time. Some > > protocol is usually used to switch the direction as needed. > > > > Toby Nixon has stated on CompuServe that according to CCITT terminology, > "duplex" means transmitting simultaneously in both directions at the > same speed. Therefore "full duplex" is undefined and redundant. > (Toby, are you listening?) Oh, let's fight!!! 8-) The opposite of duplex is simplex, i.e. able to transmit one way, over on set of wires, period. Given this, and the fact that half-duplex technology probably preceeded full duplex, and the full was added to to make the distinction, I think it's still a meaningful modifier. > > -- > Mike Schuster | CIS: 70346,1745 > NY Public Access UNIX: ...cmcl2!panix!schuster | MCI Mail, GENIE: > The Portal (R) System: schuster@cup.portal.com | MSCHUSTER -- George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr but no way officially representing: domain: grr@cbmvax.commodore.com Commodore, Engineering Department phone: 215-431-9349 (only by moonlite)
tnixon@hayes.uucp (03/06/91)
With regard to the discussion on "duplex" vs. "full duplex", etc.: I serve on the Vocabulary Special Rapporteur's Group in Study Group XVII, and so try to pay attention to these things. I sometimes point out, particularly when people are _already_ confused about word meanings, what the current practice is in the CCITT and other standards committees. For example, we've officially abandoned the term "baud", because of widespread misuse, and instead use "symbols per second". "Full duplex" never has been an official term, so we couldn't abandon it, but we avoid using it. It gets used pretty often in discussion, but never in printed documents. Personally, I don't see any real harm in saying "full duplex" when you mean "duplex", in terms of two-way simultaneous transmission on the phone line. There's really no confusion here. I would prefer that glossaries and lexicons mention that the correct term is simply "duplex". I _do_, however, object to the use of "half duplex/full duplex" when, from context, the meaning seems to be "local echo/no local echo"; that is a serious misapplication of the terminology. The issue of "duplex" vs. "simplex" is interesting. The standards committees generally use "simplex" when the modem is truly capable of only transmission OR reception, and "half-duplex" when it is capable of alternating between transmission and reception, but not performing both at the same time. I suppose we could call it "alternating simplex". We've also adopted "asymmetrical duplex" when the modem transmits and receives simultaneously, but at different rates (either symbol rates or data rates), and the two channels are always flowing in opposite directions. If the two channels are not linked but are instead independent with regard to direction, then this is a "half-duplex modem with secondary channel", not an asymmetrical modem. In article <19552@cbmvax.commodore.com>, grr@cbmvax.commodore.com (George Robbins) writes: > The opposite of duplex is simplex, i.e. able to transmit one way, over > on set of wires, period. Given this, and the fact that half-duplex > technology probably preceeded full duplex, and the full was added to > to make the distinction, I think it's still a meaningful modifier. Actually, the first modems standardized by the CCITT were V.21 (300 baud duplex) and V.23 (600 or 1200 baud forward channel with 75 baud backward channel). V.23 can be implemented with or without the reverse channel, and the direction of transmission on the reverse channel can be either linked or not linked to the forward channel direction. -- Toby Nixon, Principal Engineer | Voice +1-404-840-9200 Telex 151243420 Hayes Microcomputer Products Inc. | Fax +1-404-447-0178 CIS 70271,404 P.O. Box 105203 | UUCP uunet!hayes!tnixon AT&T !tnixon Atlanta, Georgia 30348 USA | Internet hayes!tnixon@uunet.uu.net
russotto@eng.umd.edu (Matthew T. Russotto) (03/07/91)
In article <1991Mar5.225546.6672@panix.uucp> schuster@panix.uucp (Michael Schuster) writes: >In article <bishop@dce.ie> em@dce.ie (Eamonn McManus) writes: >>[No change since last posting.] >> >>$Id: lexicon,v 1.0 91/02/01 16:47:06 em Exp $ >> >>Comp.dcom.modems lexicon, by Eamonn McManus <em@dce.ie>. Contributions by: >> Charles Bryant <ch@dce.ie> >> Ronald S H Khoo <ronald@robobar.co.uk> >> David Lesher <wb8foz@mthvax.cs.miami.edu> >> Chip Rosenthal <chip@chinacat.unicom.com> >> Colin Plumb <ccplumb@rose.uwaterloo.ca> >> >>Full duplex. Able to send data in both directions at once. >> >>Half duplex. Able to send data in only one direction at a time. Some >> protocol is usually used to switch the direction as needed. >> > >Toby Nixon has stated on CompuServe that according to CCITT terminology, >"duplex" means transmitting simultaneously in both directions at the >same speed. Therefore "full duplex" is undefined and redundant. >(Toby, are you listening?) Half duplex has meant the definition above since the Early Days of Modems. (I've also seen it called "auto-simplex") -- Matthew T. Russotto russotto@eng.umd.edu russotto@wam.umd.edu .sig under construction, like the rest of this campus. I mine 600 wells, and whaddo I get? Another day older and deeper in debt! --- Saddam Hussein.
floyd@ims.alaska.edu (Floyd Davidson) (03/07/91)
In article <3832.27d4dcf9@hayes.uucp> tnixon@hayes.uucp writes: >With regard to the discussion on "duplex" vs. "full duplex", etc.: > >I serve on the Vocabulary Special Rapporteur's Group in Study Group >XVII, and so try to pay attention to these things. I sometimes point > [...] >per second". "Full duplex" never has been an official term, so we > [...] >Personally, I don't see any real harm in saying "full duplex" when >you mean "duplex", in terms of two-way simultaneous transmission on >the phone line. There's really no confusion here. I would prefer >that glossaries and lexicons mention that the correct term is simply >"duplex". > >I _do_, however, object to the use of "half duplex/full duplex" >when, from context, the meaning seems to be "local echo/no local >echo"; that is a serious misapplication of the terminology. > >The issue of "duplex" vs. "simplex" is interesting. The standards >committees generally use "simplex" when the modem is truly capable >of only transmission OR reception, and "half-duplex" when it is >capable of alternating between transmission and reception, but not >performing both at the same time. I suppose we could call it > [...] >In article <19552@cbmvax.commodore.com>, grr@cbmvax.commodore.com >(George Robbins) writes: > >> The opposite of duplex is simplex, i.e. able to transmit one way, over >> on set of wires, period. Given this, and the fact that half-duplex >> technology probably preceeded full duplex, and the full was added to >> to make the distinction, I think it's still a meaningful modifier. > >Actually, the first modems standardized by the CCITT were V.21 (300 >baud duplex) and V.23 (600 or 1200 baud forward channel with 75 baud >backward channel). V.23 can be implemented with or without the >reverse channel, and the direction of transmission on the reverse >channel can be either linked or not linked to the forward channel >direction. I don't want to add any confusion to this subject, but it might do well to note the difference in the historical derivation of the duplex/simplex and full/half duplex terminology. Duplex vs. simplex originally was used to define radio communications that could be carried on in both directions at the same time (duplex), as opposed to communications that used the same spectrum and facilities for both directions, but not at the same time (simplex). The terms were applied to two-way radios, for instance CB, police FM, etc. Certainly the same usage could be applied to a two wire telephone circuit used for data. Full/Half Duplex originated with teletype circuits on telephone carrier circuits. And it did directly relate to local echo. Both a full dux and a half dux circuit used a two way (duplex) modem at the point where a digital signal was converted to an analog signal to be sent over the telephone carrier system. An half dux circuit used the same digital circuit for transmit and receive. (Generally this was a 60ma neutral loop.) By definition a half dux circuit HAD local echo, and that was what made it half duplex. And that was a function of the terminal equipment on the digital side, not a function of the modem. The digital side of the modem did have to be arranged to not send what it received (we used to call it a "reflection" if it did). The terms are confusing today because historically they came from two different areas of technology (telephone people have always had their own terminology that is distinctly different from the rest of the world of electronics). I'm not so sure that Toby is correct in calling it a misuse of the terminology to use full/half duplex to refer to local echo. That is exactly how the term was derived as it relates to data modems. But it certainly has become ambigiuos, and such use should be discouraged. Likewise I don't think a modem that can only transmit or receive is a simplex device. It is a "read-only" or "transmit-only" device. A device that can transmit or receive, but not at the same time is a simplex device. A device that is essentually a duplex device (can send and receive at the same time), but which is arranged for local echo (and hence can't be used in both directions at the same time) is using a half duplex mode of operation. I'll accept failure in not wanting to add confusion to the subject. I probably have added just that. Also I am willing to accept whatever definition CCITT wants to give any of these terms, and use that definition henceforth. Floyd -- Floyd L. Davidson | floyd@ims.alaska.edu | Alascom, Inc. pays me Salcha, AK 99714 | Univ. of Alaska | but not for opinions.
grr@cbmvax.commodore.com (George Robbins) (03/07/91)
In article <1991Mar7.055236.16871@ims.alaska.edu> floyd@ims.alaska.edu (Floyd Davidson) writes: > Duplex vs. simplex originally was used to define radio > communications that could be carried on in both directions at > the same time (duplex), as opposed to communications that used > the same spectrum and facilities for both directions, but not at > the same time (simplex). The terms were applied to two-way > radios, for instance CB, police FM, etc. Certainly the same usage > could be applied to a two wire telephone circuit used for data. Cough, choke, gasp... The simplex/duplex distinction goes back to telegraphy, like Western Union, and this usage probably predates the radio orgin you suggest. I don't know when the full/half duplex distinction came in - it could have been early or could have awaited telephone carrier system to show up. > I'm not so sure that Toby is correct in calling it a misuse of > the terminology to use full/half duplex to refer to local echo. > That is exactly how the term was derived as it relates to > data modems. But it certainly has become ambigiuos, and such > use should be discouraged. It's a misuse when all it refers to is enabling and disabling local echo, while the modem is actually still modulating in the full duplex mode. Remember that things like teletypes didn't really generate a "local echo", it's just the transmitter and receiver were normally wired in series on the same circuit and couldn't the receiver seeing what was trasmitted, unless you manually bridged across it. > Likewise I don't think a modem that can only transmit or receive > is a simplex device. It is a "read-only" or "transmit-only" > device. You're on very thin ice here. You want to avoid confusing the sense of the terms as used to describe radio equipment from data communications modems and communication channels. A simplex modem is one that can only send or receive. A simplex data terminal is something like a stock ticker. > Also I am willing > to accept whatever definition CCITT wants to give any of these > terms, and use that definition henceforth. I don't have too much trouble with the CCITT trying to define these terms precisely and non-ambiguously, however that doesn't particularly effect the traditional definitions of the words, at least outside the context of the standards community. I would be impressed if any committe could elide infamous "baud rate"... -- George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr but no way officially representing: domain: grr@cbmvax.commodore.com Commodore, Engineering Department phone: 215-431-9349 (only by moonlite)
ronald@robobar.co.uk (Ronald S H Khoo) (03/07/91)
tnixon@hayes.uucp writes: > "Full duplex" never has been an official term, so we > couldn't abandon it, but we avoid using it. > Personally, I don't see any real harm in saying "full duplex" when > you mean "duplex", I'm having a little bit of difficulty with this whole thread. The usage I'm used to is: simplex: A can talk to B but B cannot talk to A half-duplex: A can talk to B and B can talk to A (but not at the same time) full-duplex: A can talk to B and B can talk to A (at the same time) and all three terms are necessary, because the three cases are all different. Are you saying that CCITT considers it clearer to say "duplex" where I say "full-duplex" ? I would consider that less clear. Maybe it's just my mind becoming fixed in a heirarchical manner after years of bashing Unix, but to my mind, I'd actually want a fourth different meaning to plain "duplex", viz: | | +--------+-------+ | | simplex duplex | | +--------+-------+ | | half full If you equate full duplex with just plain duplex, then how do you say duplex without specifying whether it's full or half? -- Ronald Khoo <ronald@robobar.co.uk> +44 81 991 1142 (O) +44 71 229 7741 (H)
floyd@ims.alaska.edu (Floyd Davidson) (03/08/91)
In article <19594@cbmvax.commodore.com> grr@cbmvax.commodore.com (George Robbins) writes: >In article <1991Mar7.055236.16871@ims.alaska.edu> floyd@ims.alaska.edu (Floyd Davidson) writes: >> Duplex vs. simplex originally was used to define radio >> communications that could be carried on in both directions at >> the same time (duplex), as opposed to communications that used >> the same spectrum and facilities for both directions, but not at >> the same time (simplex). The terms were applied to two-way >> radios, for instance CB, police FM, etc. Certainly the same usage >> could be applied to a two wire telephone circuit used for data. > >Cough, choke, gasp... I'm not sure what you are choking on there. >The simplex/duplex distinction goes back to telegraphy, like Western >Union, and this usage probably predates the radio orgin you suggest. How is it applied to telegraphy ????? Perhaps exactly as described above... >I don't know when the full/half duplex distinction came in - it could >have been early or could have awaited telephone carrier system to >show up. > >> I'm not so sure that Toby is correct in calling it a misuse of >> the terminology to use full/half duplex to refer to local echo. >> That is exactly how the term was derived as it relates to >> data modems. But it certainly has become ambigiuos, and such >> use should be discouraged. > >It's a misuse when all it refers to is enabling and disabling >local echo, while the modem is actually still modulating in >the full duplex mode. Not so. See below. (By the way, would you be so kind as to define "modulating in the full duplex mode". :-) > Remember that things like teletypes didn't >really generate a "local echo", it's just the transmitter and >receiver were normally wired in series on the same circuit and >couldn't the receiver seeing what was trasmitted, unless you >manually bridged across it. Maybe you will have to blame Ma Bell for that definition. At the other end of that teletype loop there is a modem, though it was called a Teletype Terminal Unit at the time, which had two modes of operation: half duplex and full duplex. In some cases, such as the Western Electric 43A1 it had a switch, in others it was just wired differently. In either case the modem put out an analog transmit signal and received an analog receive signal. In other words the modem was "duplex" on the analog side no matter what was on the digital side. The fd/hd switch or option only affected the digital side. There is a little more to a TTY circuit than what you see at the customer end. Half dux vs. full dux had more to do with the terminal unit than it did with how the machine was wired. The machine in fact was wired in series for half dux. The transmitting distributor and receiver selector magnets were wired to separate loops for full dux. Pretty simple. On the modem it was still pretty simple, but more complex than that. (I am sitting six feet from four each eleven foot bays of Lenkurt telegraph equipment. Some pretty old 25D stuff, there are about 200 modems, all of which have a half/full duplex option.) >> Likewise I don't think a modem that can only transmit or receive >> is a simplex device. It is a "read-only" or "transmit-only" >> device. > >You're on very thin ice here. You want to avoid confusing the >sense of the terms as used to describe radio equipment >from data communications modems and communication channels. My turn to cough and gag. >A simplex modem is one that can only send or receive. A simplex >data terminal is something like a stock ticker. I've been looking at circuit layout cards for a couple decades and don't recall seeing one labeled that way. They are always labeled as read-only or transmit-only. Of course, usually they are in fact simplex because there is only one pair provided and they use the entire bandwidth allowed in only one direction. Usually, but not always, they can in fact be wired up for the other half of the circuit. >I don't have too much trouble with the CCITT trying to define these >terms precisely and non-ambiguously, however that doesn't particularly >effect the traditional definitions of the words, at least outside the >context of the standards community. The problem is the several "traditional" definitions. And as you have demonstrated, most have very foggy derivations, not to mention meanings. I think it is fairly obvious where the modem people (and the computer people) originally got the terms full and half duplex. But they don't seem to know what the telephone company used the terms for. With big changes in technology came a slight change in terminology... And now it is ambigious. It doesn't make the original meaning wrong. >I would be impressed if any committe could elide infamous "baud rate"... The committee has exactly the right idea, never use the term baud. Maybe "baud rate" won't go away, but at least they aren't adding to its popularity. Floyd -- Floyd L. Davidson | floyd@ims.alaska.edu | Alascom, Inc. pays me Salcha, AK 99714 | Univ. of Alaska | but not for opinions.
tnixon@hayes.uucp (03/08/91)
In article <1991Mar7.115717.17186@robobar.co.uk>, ronald@robobar.co.uk (Ronald S H Khoo) writes: > ... > If you equate full duplex with just plain duplex, then how do you say > duplex without specifying whether it's full or half? Well, I guess it like saying "sandwich" vs. "half a sandwich". It's rare in our language that we find it necessary to explicitly state "whole", "entire", or "full" when referring to something; that we mean "all of it" is generally implied. We only add the modifier when we need to. Since the definition of "duplex", all by itself, is "a dwelling with two separate living areas" -- no wait, wrong definition -- "able to transmit two messages simultaneously in opposite directions on a single wire" (American Heritage Dictionary, 1982), further qualification with the word "full" is considered to be unnecessary. If I live in a single-family house, does that mean I live in a "half duplex"? -- Toby Nixon, Principal Engineer | Voice +1-404-840-9200 Telex 151243420 Hayes Microcomputer Products Inc. | Fax +1-404-447-0178 CIS 70271,404 P.O. Box 105203 | UUCP uunet!hayes!tnixon AT&T !tnixon Atlanta, Georgia 30348 USA | Internet hayes!tnixon@uunet.uu.net
jeffb@world.std.com (Jeffrey T Berntsen) (03/09/91)
tnixon@hayes.uucp writes: >Since the definition of "duplex", all by itself, >is "a dwelling with two separate living areas" -- no wait, wrong >definition -- "able to transmit two messages simultaneously in >opposite directions on a single wire" (American Heritage Dictionary, >1982), further qualification with the word "full" is considered to >be unnecessary. >If I live in a single-family house, does that mean I live in a "half >duplex"? He's happy V.32bis passed; I can tell. ;-) ----------------------------------------------------------------------------- Jeffrey T. Berntsen | Looking for a good .sig jeffb@world.std.com | -----------------------------------------------------------------------------
lstowell@pyrnova.pyramid.com (Lon Stowell) (03/09/91)
In article <1991Mar8.200030.27855@world.std.com> jeffb@world.std.com (Jeffrey T Berntsen) writes: >tnixon@hayes.uucp writes: > T>>If I live in a single-family house, does that mean I live in a "half >>duplex"? > J>He's happy V.32bis passed; I can tell. ;-) > Yes, and if Toby is not embarrassed to put his half duplex house on the wire, I guess my "half-fast duplex" term for the proprietary asymmetric modems isn't much worse... Now that V.32bis has passed, is there much movement in CCITT for attempting to provide interoperability between the local/remote network management techniques for dial modems? Many of the measurements from vendors I've seen appear to be quite similar....but no vendor will admit that THEIR modem at the master site can read info and/or configure modems from another vendor at the remote. BTW, if you haven't seen some of the neat features for mgt of dial modems, try to get a tech manual for one of the new V.32bis modems....
grr@cbmvax.commodore.com (George Robbins) (03/09/91)
In article <1991Mar8.082523.25819@ims.alaska.edu> floyd@ims.alaska.edu (Floyd Davidson) writes: > In article <19594@cbmvax.commodore.com> grr@cbmvax.commodore.com (George Robbins) writes: > >In article <1991Mar7.055236.16871@ims.alaska.edu> floyd@ims.alaska.edu (Floyd Davidson) writes: > > > >It's a misuse when all it refers to is enabling and disabling > >local echo, while the modem is actually still modulating in > >the full duplex mode. > > Not so. See below. (By the way, would you be so kind as to define > "modulating in the full duplex mode". :-) In this case of the Bell 103/113/212 modem, something where you've said "half/duplex or local echo", but are still using separate transmit/receive carriers instead of a controlled carrier. > > > Remember that things like teletypes didn't > >really generate a "local echo", it's just the transmitter and > >receiver were normally wired in series on the same circuit and > >couldn't the receiver seeing what was trasmitted, unless you > >manually bridged across it. > > Maybe you will have to blame Ma Bell for that definition. At > the other end of that teletype loop there is a modem, though it > was called a Teletype Terminal Unit at the time, which had two > modes of operation: half duplex and full duplex. In some > cases, such as the Western Electric 43A1 it had a switch, in > others it was just wired differently. In either case the modem > put out an analog transmit signal and received an analog receive > signal. In other words the modem was "duplex" on the analog side > no matter what was on the digital side. The fd/hd switch or > option only affected the digital side. This is blatent revisionism. 8-) The original teletype circuit was a telegraph current loop. The "modems" reflect the adoption of FDM multiplexing of multiple teletype channels over a single teletype or telephone circuit and subsequently use of fairly standard modem technology to extend teletype services though standard telephone networks. > (I am sitting six feet from four each eleven foot bays of > Lenkurt telegraph equipment. Some pretty old 25D stuff, there > are about 200 modems, all of which have a half/full duplex > option.) Scary! -- George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr but no way officially representing: domain: grr@cbmvax.commodore.com Commodore, Engineering Department phone: 215-431-9349 (only by moonlite)
floyd@ims.alaska.edu (Floyd Davidson) (03/09/91)
In article <19660@cbmvax.commodore.com> grr@cbmvax.commodore.com (George Robbins) writes: >In article <1991Mar8.082523.25819@ims.alaska.edu> floyd@ims.alaska.edu (Floyd Davidson) writes: >> In article <19594@cbmvax.commodore.com> grr@cbmvax.commodore.com (George Robbins) writes: >> >In article <1991Mar7.055236.16871@ims.alaska.edu> floyd@ims.alaska.edu (Floyd Davidson) writes: >> > >> >It's a misuse when all it refers to is enabling and disabling >> >local echo, while the modem is actually still modulating in >> >the full duplex mode. >> >> Not so. See below. (By the way, would you be so kind as to define >> "modulating in the full duplex mode". :-) > >In this case of the Bell 103/113/212 modem, something where you've >said "half/duplex or local echo", but are still using separate >transmit/receive carriers instead of a controlled carrier. I guess you didn't realize the the phrase is utter nonsense. It doesn't mean anything. And your definition doesn't match the phrase, or even close. [...] >> Maybe you will have to blame Ma Bell for that definition. At >> the other end of that teletype loop there is a modem, though it >> was called a Teletype Terminal Unit at the time, which had two >> modes of operation: half duplex and full duplex. In some >> cases, such as the Western Electric 43A1 it had a switch, in >> others it was just wired differently. In either case the modem >> put out an analog transmit signal and received an analog receive >> signal. In other words the modem was "duplex" on the analog side >> no matter what was on the digital side. The fd/hd switch or >> option only affected the digital side. > >This is blatent revisionism. 8-) The original teletype circuit was >a telegraph current loop. The "modems" reflect the adoption of FDM >multiplexing of multiple teletype channels over a single teletype It didn't multiplex multiple teletype channels over a single teletype channel. >or telephone circuit and subsequently use of fairly standard modem >technology to extend teletype services though standard telephone >networks. Revisionism? What are you talking about, "fairly standard modem technology"? It predated the whole idea of a "modem" as you know them. A teletype terminal unit does exactly what you described above as a definition of "modulating in the full duplex mode". It has nothing to do with modulation (or demodulation) modes. It multiplexes 16 teletype channels onto a single voice channel. The earliest TU that I've worked on was the WECO 43A1, which probably was designed in the late '40s. It had *tubes* in it. And the 43A1, and all other TU's that I've worked on (and that is a few...) all have a half/full duplex option. And in all cases the analog side is totally unaffected by which option is in use. The purpose of half/full duplex is to provide local echo operation of the teletype machine. The half/full duplex option affects ONLY the digital side. The idea that half/full duplex had anything at all to do with the analog side of the modem is a relatively recent event. >> (I am sitting six feet from four each eleven foot bays of >> Lenkurt telegraph equipment. Some pretty old 25D stuff, there >> are about 200 modems, all of which have a half/full duplex >> option.) > >Scary! Ah, we agree on something. Except I doubt you really know what is scary about it. Your government still pays money to use them. Now that is scary. (Thats why they still exist.) Floyd -- Floyd L. Davidson | floyd@ims.alaska.edu | Alascom, Inc. pays me Salcha, AK 99714 | Univ. of Alaska | but not for opinions.
evanc@isishq.fidonet.org (Evan Champion) (03/11/91)
Speaking of tech refrences, where would I get one on V32 bis, V32, V22bis, V22, V21, etc. If possible, I'd like it to not cost me a arm and a leg (this would be mostly for personal use... I always wanted to learn how these things work.) Evan Champion evanc@isishq.fidonet.org
tnixon@hayes.uucp (03/11/91)
In article <147556@pyramid.pyramid.com>, lstowell@pyrnova.pyramid.com (Lon Stowell) writes: > Now that V.32bis has passed, is there much movement in CCITT for > attempting to provide interoperability between the local/remote > network management techniques for dial modems? No. In fact, there is an established US position that the CCITT _should not_ attempt to standardize the actual line signalling, because of the huge number of existing proprietary solutions and the impossibility of reaching a consensus. But this position is based on the various types of modulation-based signalling schemes, such as those used with leased-line modems; I believe there's still hope for being able to standardize dial network management of V.42 modems, since we've already reserved one of the LAPM address field values for network management purposes. As in all other areas of OSI management, the definition of objects and attributes for management of the physical layer is progressing quickly; we just need to see if we can reach agreement on carrying the OSI management protocols on the V.42 management channel. -- Toby Nixon, Principal Engineer | Voice +1-404-840-9200 Telex 151243420 Hayes Microcomputer Products Inc. | Fax +1-404-447-0178 CIS 70271,404 P.O. Box 105203 | UUCP uunet!hayes!tnixon AT&T !tnixon Atlanta, Georgia 30348 USA | Internet hayes!tnixon@uunet.uu.net
tnixon@hayes.uucp (03/11/91)
In article <RRBmy3w163w@isishq.fidonet.org>, evanc@isishq.fidonet.org (Evan Champion) writes: > Speaking of tech refrences, where would I get one on V32 bis, V32, V22bis, > V22, V21, etc. If possible, I'd like it to not cost me a arm and a leg > (this would be mostly for personal use... I always wanted to learn how > these things work.) Well, the best "tech reference" (although not a tutorial) for these standards is -- the standards themselves. All of the V series CCITT Recommendations are in Volume VIII, Fascicle VIII.1, of the Blue Book (1988). These are available through several sources, including the UN Bookstore in New York, the ITU Bookstore in Geneva, the National Technical Information Service, and (my choice) Omnicom in Vienna, VA (1-800-OMNICOM; +1 (703) 281-1135). It costs (gulp) $94, but there's no other single place to get all of this valuable information. It doesn't, by the way, include V.42bis, V.17, or V.32bis, since these were adopted after it was published. V.42bis has been published and is available as a separate document; V.17 and V.32bis won't be published for another couple of months. -- Toby Nixon, Principal Engineer | Voice +1-404-840-9200 Telex 151243420 Hayes Microcomputer Products Inc. | Fax +1-404-447-0178 CIS 70271,404 P.O. Box 105203 | UUCP uunet!hayes!tnixon AT&T !tnixon Atlanta, Georgia 30348 USA | Internet hayes!tnixon@uunet.uu.net
em@dce.ie (Eamonn McManus) (05/04/91)
Here is version 1.2 of the lexicon. The changes since the last version
are rather minor. I am now wondering whether to add information about
packet switched networks (X25 and related standards); there doesn't seem
to be much discussion of them here so perhaps it would not be
worthwhile. Differing opinions are welcome.
,
Eamonn
$Id: lexicon,v 1.2 91/05/03 18:05:25 em Exp $
Comp.dcom.modems lexicon, by Eamonn McManus <em@dce.ie>. Contributions by:
Charles Bryant <ch@dce.ie>
Ronald S H Khoo <ronald@robobar.co.uk>
David Lesher <wb8foz@mthvax.cs.miami.edu>
Chip Rosenthal <chip@chinacat.unicom.com>
Colin Plumb <ccplumb@rose.uwaterloo.ca>
Toby Nixon <tnixon@hayes.uucp>
Eric Gundrum <gundrum@sv.portal.com>
Evan Gamblin <0001847804@mcimail.com>
This lexicon is intended to provide a basic introduction to terms used in
modem technology. In the interests of brevity, some technical details and
qualifications are omitted. Corrections, additions, and suggestions are
welcome; send them to <em@dce.ie>.
This document is not copyrighted and may be used freely.
Words in angle brackets, like <this>, denote cross-references. The
following terms are defined or discussed here:
Asymmetric, asynchronous, AT commands, back channel, baud, Bell
standards, bps, carrier, CCITT, compression, CTS, DCD, DCE, DSR, DTE,
DTMF, DTR, EIA232, error correction, external modem, fall back, FAX,
flow control, four wire, full duplex, half duplex, Hayes, internal
modem, Kermit, latency, leased line, MNP, modulation, octet, parallel,
PEP, PTT, RS232, RTS, serial, speed buffering, spoofing, synchronous,
Trailblazer, turnaround time, uucp, V series, window, XMODEM,
XON/XOFF, ZMODEM.
---
Asymmetric. Faster in one direction than the other. The faster direction
is called the main channel and the slower is the back channel. See
<V.23> and <PEP> for examples. Both of these allow the directions of the
channels to be exchanged; see <turnaround time>.
Asynchronous. Used of a <serial> connection where each byte is sent
independently. The start and end of a byte are indicated by separate bits
so each byte takes 10 bits to transmit. See <synchronous>.
AT commands. See <Hayes>. (Unrelated to the PC/AT.)
Back channel. See <asymmetric>.
Baud. A unit of communication speed, defined as signalling elements per
second. Not the same as <bps> since sometimes each signalling element
carries several bits. (There is no such thing as a 9600 baud modem,
for instance.) <RS232> terminals always have baud the same as bps.
Bell standards. <Modulation> techniques used in North America. Bell 103
is a 300bps standard; Bell 212 is 1200bps. Not allowed in some European
countries. See <V series>.
Bps. Bits per second. See <baud>.
Carrier. Roughly speaking, the tones a modem sends when it is not sending
data. Data are then variations in these tones. When the remote modem
stops emitting carrier, the local modem can assume it has hung up, unless
the local modem is now the sending party in a <half duplex> connection.
CCITT. A French acronym for the International Telegraph and Telephone
Consultative Committee, which sets standards for telephone communication
among other things. Their standards (or `recommendations' as they have
it) are published every so often in a set of `fascicles', whose colour
varies with the year. The current set is the `blue books' published in
1988. The standards are copyrighted, so they are not available
electronically. You should be able to find them at any good
engineering library. See <V series>.
Compression. Reduction of the size of data by exploiting redundancy. Many
modern modems incorporate use <MNP5> or <V.42 bis> to compress data
before they are sent over the phone line. For this to be effective, the
modem must be fed data at a higher speed than the phone line speed.
Compression is most useful for interactive sessions in the modem. If you
are sending files, compressing them on the computer before sending is
usually more effective. In this case, make sure that the modem is not
also trying to compress, because already-compressed data will become
bigger if re-compressed.
For compression to work, it is essential that the data are sent over an
error-free link. Otherwise the modems could get out of sync and
hopelessly garble the data. Since common <error correction> protocols are
<synchronous>, there is usually a throughput gain there as well.
Manufacturer claims that MNP5 provides a 2:1 reduction in size, or that
V.42 bis provides 4:1, should be taken with a grain of salt. They are
only true for suitable data. See <MNP5> and <V.42 bis>.
CTS. Clear to send. A signal from <DCE> to <DTE>. Typically used for
<flow control>.
DCD. Data carrier detect. A signal from <DCE> to <DTE>, indicating that a
<carrier> tone is being heard from the remote modem. See <DSR>.
DCE. Data circuit-terminating equipment. Whatever is connected to a phone
line. Effectively, a modem.
DSR. Data set ready. A signal from <DCE> to <DTE>, indicating that a
connection is in progress. For <half duplex> connections, DSR will be on
during the entire session, while <DCD> will be on only when the modem is
receiving.
DTE. Data terminal equipment. The computer or terminal that talks to a
modem locally.
DTMF. Dual tone multiple frequency. The standard method for tone dialling.
DTR. Data terminal ready. A signal from <DTE> to <DCE>. Sometimes used
for <flow control>, though <RTS> is more usual nowadays. Typically,
dropping DTR will cause the modem to hang up.
EIA232. See <RS232>.
Error correction. Communication between the modems to ensure that the data
sent by one end are the same as those received by the other, even in the
presence of noise on the line. Typically this is done by adding
checksums to the data. If the received data don't match their checksum
the receiving modem asks for them to be sent again.
Like <compression>, error correction in the modem is most useful for
interactive use. When sending files, it is generally best to let the
computers at each end do the correction, using a protocol like <Kermit>
or <uucp>. However, the ability of <MNP4> and <V.42> to send data
<synchronously> may make it worthwhile to use them. See also <spoofing>.
External modem. See <internal modem>.
Fall back. The ability of a modem to operate at a lower speed than its
maximum, used either for compatibility with a different type of modem
(e.g. <V.22 bis> can fall back to <V.22>) or to reduce the number of
errors over a link that cannot carry the fastest speed.
FAX. Discussions on FAX should usually be in the newsgroup comp.dcom.fax.
This entry names some of the <CCITT> standards used by Group 3 FAX.
Parameter negotiation and session control are done using <V.21>; the
formats are defined by T.3. Images are sent using <V.27 ter> and
<V.29>; the format is defined by T.4. The new <V.17> standard may be
available in recent machines. FAX transmission is <half duplex>.
Flow control. Ensuring that a unit, whether modem or computer, is not
supplied with more data than it can cope with. The unit must have some
way to signal to the data source to stop sending. Ideally, every unit on
the communication path should have a way to manage flow control with its
peers; otherwise if available buffer space is exceeded some data may be
lost.
Between <DTE> and <DCE> the possibilities are <RTS>/<CTS> and <XON/XOFF>.
Between two <DCE>s <XON/XOFF> is the only possibility. However, if a
protocol such as <MNP> is being run between the modems, this will
contain provision for flow control. If you can guarantee that the <DTE>s
will always be able to accept data, you should not need flow control
between the <DCE>s.
Four wire. A <leased line> with separate connections for transmitting data
in each direction.
Full duplex. Able to send data in both directions at once.
Half duplex. Able to send data in only one direction at a time. Some
protocol is usually used to switch the direction as needed.
Hayes. Modem manufacturer. The `Hayes command set' is supported by most
modern modems. Hayes commands look like ATD1234 (dial 1234) or ATA
(answer the phone). The commands for simple things like this are fairly
standard, but more complex things tend to be manufacturer-specific. A
<CCITT> standard for Hayes commands is in preparation.
Internal modem. A modem card that slots into your computer, as opposed to
an external modem, which is a separate unit. Internal modems are usually
cheaper but they have some disadvantages. An external modem can be used
with any computer; it will have diagnostic lights to see what is going
on; and it means the phone line is further from your PC and so less likely
to conduct lightning strikes into it.
Kermit. A file-transfer protocol, available for a wide variety of
machines. It contains provisions for transferring text and binary files
over 7- and 8-bit connections.
Latency. The delay between data being sent and being received by the far
end. A combination of transmission delays and <modulation> properties.
Leased line. A permanent point-to-point connection rented from the phone
company.
MNP. Microcom Network Protocols. A set of modem-to-modem protocols that
provide <error correction> and <compression>. The commonly encountered
ones are these:
MNP2. <Error correction> using <asynchronous> transmission.
MNP3. <Error correction> using <synchronous> transmission between the
modems (the <DTE> interface is still <asynchronous>). Since each
eight-bit byte takes eight rather than ten bits to transmit there is
scope for a 20% increase in throughput. Unfortunately the MNP3
protocol overhead is rather high so this increase is not realised.
MNP4. Introduces `data phase optimisation', which improves on the rather
inefficient protocol design of MNP2 and MNP3. <Synchronous> MNP4 comes
closer to achieving the 20% throughput increase mentioned above.
MNP5. Simple data compression. Dynamically arranges for commonly
occurring characters to be transmitted with fewer bits than rare
characters. It takes account of changing character frequencies as it
runs. Also encodes long runs of the same character specially. Typically
compresses text by 35%; with 20% for MNP4 this reduces data by almost
50%.
Modulation. Converting a data stream into sounds to be sent down a phone
line. The opposite is demodulation. `Modem' stands for modulator/
demodulator.
Octet. Standard <CCITT> term for a group of eight bits, i.e., what the
rest of us think of as a byte. They avoid `byte' because some strange
machines have bytes with more or less than eight bits.
Parallel. Sending several bits at a time, usually 8, each over a separate
wire. Some modems have a parallel connection from <DTE> to <DCE>.
PEP. A proprietary <modulation> and <error correction> technique devised
by Telebit and used in their Trailblazer modems. It can achieve
throughput of 9600bps or better, and is reported to be able to sustain
noisy connections better than <V.32>. However, it is <asymmetric> a
with a very slow <back channel> and a long <turnaround time> and
<latency>. Protocols with small <windows> work very poorly unless
<spoofing> is used. Trailblazers can spoof <uucp>, <Kermit>, and
<XMODEM>.
PTT. General term for the national organisation(s) in charge of telephone
and postal communications.
RS232. The usual connection between <DCE> and <DTE>, now properly called
EIA232. It allows for 25 signals, most of which are not used on typical
connections. The minimum needed signals are ground, TxD (transmit data),
and RxD (receive data). Typically modem control lines <DCD> and <DTR>
and flow control lines <RTS> and <CTS> will also be used. See <V.24>.
RTS. Request to send. A signal from <DTE> to <DCE>. In modern modems,
this is generally used for <flow control>; when RTS is off the modem will
not send data to the terminal. In <half duplex> connections, RTS may
mean that the <DTE> has data to send, so the <DCE> should stop sending
to it and assert <CTS>.
Serial. Sending one bit at a time. Opposite of <parallel>.
Speed buffering. Early modems had very simple hardware which modulated
data from the terminal directly onto the phone line. This meant that the
terminal speed and the line speed had to be the same. Modern modems
allow them to be different (speed buffering), but unfortunately the old
assumption is wired into many communications programs, so modems also
have to provide the ability to change the terminal speed to the same as
the line speed when a connection is established. If the terminal speed
is faster than the line speed, <flow control> to the terminal will
usually be needed.
Spoofing. Protocol spoofing is used by Trailblazers (see <PEP>). The
modem knows what protocol you are using to transfer files to the far end.
It pretends to be the remote computer and acknowledges the local data as
soon as it gets them. The two Trailblazers then conspire to get the data
safely to the far end.
Synchronous. Used of a <serial> connection where bytes are sent in a
continuous stream. Some sort of protocol is needed to flag the case
where no bytes are available to be sent.
Trailblazer. See <PEP>.
Turnaround time. The time taken in a <half duplex> or <asymmetric> link to
reverse the direction of communication.
uucp. Unix-to-Unix copy. This is the name of a Unix command, but it is
now also used to refer to the protocols used by it to transfer files
between Unix machines. There are a number of such protocols, and the two
machines choose between the ones supported by each. Free implementations
also exist for VMS and MS-DOS. The newsgroup comp.mail.uucp may be more
appropriate for discussions.
V series. A set of standards published by the <CCITT> for `Data
Communication over the Telephone Network'. The following standards
describe the important <modulation> techniques:
V.17: 14400bps <half duplex> with <fall back> to 12000bps, 9600bps and
7200bps.
V.21: 300bps.
V.22: 1200bps, with <fall back> to 600bps.
V.22 bis: 2400bps, with <fall back> to V.22.
V.23: 1200bps with 75bps <back channel>, with <fall back> to 600bps/75bps.
V.27 ter: 4800bps with <fall back> to 2400bps, used by <FAX>.
V.29: 9600bps <half duplex> or <four wire> (used by <FAX>) with <fall back>
to 7200bps and 4800bps.
V.32: 9600bps with <fall back> to 4800bps.
V.32 bis: 14400bps with <fall back> to 12000bps, 9600bps, 7200bps and
4800 bps.
Other standards you may encounter:
V.24: connection between <DCE> and <DTE>. Effectively the same as
<RS232>, though V.24 only specifies the meaning of the signals, not
the connector nor the voltages used.
V.25 bis: a cryptic command language for modems.
V.42: <error correction> with <asynchronous> to <synchronous> conversion.
V.42 bis: data <compression> using a Lempel-Ziv related technique, which
detects frequently occurring character strings and replaces them with
tokens. This is similar to Unix compress. Typical compression for
text is 50% or better; with nearly 20% gain from <synchronous>
conversion this gives reduces transmission time by almost 60%.
Window. Most protocols divide the data to be sent into `packets'.
To eliminate delays several packets may be sent before any one is
acknowledged. If this is allowed by a protocol, the window is the
number of packets that can be sent before an acknowledgement is
received.
XMODEM. A primitive file-transfer protocol. It has the property that
files must be padded to a multiple of 128 bytes long. It is <half
duplex> (has a <window> of one packet) so it performs badly on fast
modems.
XON/XOFF. A method of <flow control>. The XOFF character (ASCII 19) is
sent to stop further characters, and XON (ASCII 17) is sent to resume
them. This method is inferior to hardware flow control using <RTS> and
<CTS>, since it means that XON and XOFF characters cannot be freely used
in the data.
ZMODEM. A fast file-transfer protocol with <windows>. It has been
carefully optimised for a variety of conditions, and has useful features
such as the ability to resume an aborted transfer where it left off.bob@uis-oc.UUCP (Robert J. Mathias Jr.) (05/07/91)
Since you include PEP in your lexicon, I would suggest you add US Robitics HST to your lexicon. While PEP is king on Unix boxes, HST is still the king of the high speed modems on PC boxes. -- Bob Mathias uucp: ...!uunet!ccicpg!uis-oc!bob Unisys Corporation CServ: 70340,165 A and V Series Systems Engineering voice: (714) 727-0323 Irvine, California
cheselka@cactus.org (Mike R. Cheselka) (05/29/91)
I'm sure this is a FAQ. I have looked around and decided I needed a 9600 bps modem with PEP and v.32. What is the relationship between v.32, v.32bis, v.42, and v.42bis? I heard that v.32 encompassed both MNP5 and v.42. And of course, where is the best bargain for such a beast. I bought a zoom 2400 with v.22bis for 70$. The other day someone very knowledgable said he bought a good 2400 bps modem for 140$. I said I could get one for 65$ now. He said the one he bought was a "good" one. How can I decide? I said I wanted the best bargain, but some bargains are "better" than others, yet I'm almost clueless as to what would make one 9600 bps modem better than another 9600 bps modem, maybe even worth twice as much. How do I evaluate modems? Can someone point to an easy to understand article about 9600 bps modems? E-mail anything you might want to send my way( advice, endorsement, flames, etc.) . Thanks! -- cheselka@cactus.org cs.utexas!cactus.org!cheselka
abashir@kermit.Eng.Sun.COM (Aref Bashir) (06/21/91)
I am looking for something that will allow me use of my phone and modem simultanously. I understand devices that are called datasets serve this purpose. I am searching for an alternative to a second phone line. Is there one ? Thanks Aref. If someone doea have an answer I would appreciate being mailed Interent address: aref.bashir@Eng.Sun.Com