rfc782.txt
来自「RFC 的详细文档！」· 文本 代码 · 共 1,299 行 · 第 1/3 页
TXT
1,299 行
of the display is a scarce resource, not all logical
displays need be mapped at the same time. Therefore, the
workstation may roll-out and roll-in selected displays under
the user control, thereby also multiplexing the physical
display in time.
o Multiplexing the workstation input devices in time.
5
The input devices always map to a single user conversation
(i.e., a single logical terminal). However, the user can
select a new logical terminal by some well-defined
interaction (e.g., depressing a function key, using a
pointing device, and such), effectively switching the
ownership of the input tools.
o Concurrent multi-mode use of the workstation.
The capabilities of the workstation limit the scope and
character of the individual conversations. If the
workstation supports rubout processing (i.e., erase
operations on lines and characters), then the logical
terminals can be independent, scrolling "terminals," some
page-oriented, others line-oriented. If the architecture of
the workstation supports graphics objects as primitive
objects then so can the individual logical terminals. As a
consequence, while some logical terminal displays may be
dedicated to alphanumeric output, others may include raster
graphics and imaging data together with positioned text.
o The sharing of a single logical terminal among several
users.
Several end-users may link to a single logical terminal.
All linked parties are viewed by the shared "device" as both
input sources and output sinks. As a consequence this
device sharing need not be limited only to the sharing of
device output. In general, each linked party may have full
read and write access to the logical terminal, if it so
desires.
o Selective viewing on a logical terminal display.
In the user's view, a logical terminal display is a user-
specified window on a potentially larger structure, the
"device" display. This window provides the "peephole"
through which the device display is viewed. The portion of
the device display mapped on this window is not limited to
its "present contents." Under the user control, the
workstation may invoke the viewing of past activity on a
logical terminal display when the device display is I/O
file-extended. Since the window mechanism is an integral
part of the device architecture, it is available on all
logical terminal displays. Furthermore, the viewing of past
activity does not affect others sharing access to the
device.
6
o Discarding, suspending, and resuming the output of a logical
terminal always under user control.
As part of the user interface, the workstation provides
simple "keys" through which the user controls the output on
a logical terminal display. These workstation "keys" need
not be physical keys, but could be other input tools used
for this purpose (e.g., analog dials, hit-sensitive areas on
the physical display, and such). In any event, through the
auspices of the workstation, the user's control requests
translate into the proper commands to the "device"
associated with the logical terminal.
APPLICATION <---> ADAPTATION UNIT
o A logical view of real devices.
For each real terminal architecture, one canonical
representation: a logical device.
o For a particular logical device, several possible
interaction paradigms.
Some logical devices are intrinsically half-duplex (e.g., a
page-oriented logical device), some are full-duplex (e.g.,
communicating processes using a stream-oriented logical
device), and some may be either half or full-duplex (e.g., a
line-oriented logical device). Some full-duplex logical
devices can provide no echoing, remote echoing, or local
echoing. Those that interface with applications that
support command completion (e.g., command-line interpreters)
can shift the locus of echoing as a function of a dynamic
break character set.
o One application communicating with several logical devices.
As part of an application's model of interaction, an
application may "own" several logical devices. For example,
an editor could use a line-oriented logical device to gather
top-level commands, and a page-oriented logical device to
provide editing workspace.
2.1 The VTM Model Components
The virtual terminal management model consists of two major
components: the virtual terminal model, and the workstation model
(see Figures 2.1, 2.2, and 2.3 respectively).
7
AU1
|
AU0 | AU2
| | |
_______________
| |
| VT2 |
| |
| |
_______________
| _______________
| | |----AU0
|_______| VT0 |
|_______| |
| | |----AU1
| _______________
|
________________
| |
| |
| VT1 |
| |
________________
| | |
AU0 | AU2
|
AU1
VT = VIRTUAL TERMINAL
AU = ADAPTATION UNIT
FIGURE 2.1 - THE VIRTUAL TERMINAL MODEL
8
___ ___ ___ ___
|VT1||VT2| |VT1||VT2|
____ _____ _____ ____
| | | |
__|_____|_________________|_____|__
| | | | | | | |
| REMOTE | -CONTROLLER-| REMOTE |
| KEYS | | DISPLAYS |
| | | |
| VIRTUAL | | DATA |
| KEYS | | STORE |
| |<----------->| |
| LOCAL | | LOCAL |
| KEYS | | DISPLAYS |
| | | |
__|_____|__________________|_____|__
| | | |
____ ____ _____ ____
|AU0||AU1| |AU0||AU1|
____ ____ _____ ____
FIGURE 2.2 -- VT0 (expanded from previous figure)
9
+--------------------+
| |
o-|-------------------|
| EXECUTIVE |
|--------------------|
Screen +-------+ o-|--------------------| +-----+
+---------+ /|OUTPUT | | ADAPTATION UNIT 0 |<---->| VT0 |
|EXECUTIVE| / | |<---|--------------------| +-----+
|---------| / |HANDLER| o-|--------------------| +-----+
| AU0 | / |-------| | ADAPTATION UNIT 1 |<---->| VT1 |
|---------| / | INPUT | |--------------------| +-----+
| AU1 |/ | | o-|--------------------|
|---------| |HANDLER| | . |
| | | /--|o | . |
~ ~ +-------+ ~ . ~
~ ~ / ~ ~
|---------| / o-|--------------------| +-----+
| AUK | / | ADAPTATION UNIT K |<---->| VTK |
+---------+ / +--------------------+ +-----+
/ | |
+---------+ / +--------------------+
|Keyboard | /
+---------+ /
|[] [] [] | /
|[] [] [] |/
+---------+
FIGURE 2.3 - THE WORKSTATION MODEL
The first component embodies the canonical device, while the second
component includes the adaptation unit and its associated
environment. Each component will be described in turn below.
2.2 The Virtual Terminal Model
The objective of virtual terminal protocols is to provide the
users of the service with a common, logical view of terminals. The
common user view is attained through a standard, protocol-wide
representation of a canonical terminal, the virtual terminal. This
10
permits the exchanges between users of the protocol to be free of
device-specific encodings.
The design postulates an integrated virtual terminal model which
extends the nature and scope of this canonical device in several
important ways. The major aspects of the model, its connectivity,
its organization, and its architecture are described below.
2.2.1 Virtual Terminal Connectivity
Most virtual terminal protocols only cater to two-way dialogues
in which a single virtual terminal terminates each end of the
communication path.
We define the virtual terminal as a n-way device where one or
more of the correspondents to this device are local users of the
service, and the remaining correspondents (if any) are peer virtual
terminals. Each correspondent to the virtual terminal has its own
bi-directional path to produce virtual input to, and receive virtual
output from, the virtual terminal. This bi-directional path provides
the vehicle for a virtual terminal session between user and virtual
terminal. Globally, the cooperating virtual terminals and these bi-
directional paths span a dendritic (tree-like) topology.
It is important to note that we have decoupled the virtual
terminal from its physical realization, a single real terminal.
Indeed, a virtual terminal does not map necessarily to just one real
device, but possibly to many real devices.
The virtual terminal is viewed ultimately as a well-defined data
structure which provides its correspondents with a non-dedicated
virtual terminal service. And these correspondents may have read
only, write only, or read/write access rights to this data structure.
2.2.2 Virtual Terminal Organization
The virtual terminal is an abstraction; its organization, the
building blocks which make up the virtual terminal, is the result of
a feature extraction of the real terminal that it is tailored to
support.
We have conceptualized the virtual terminal as a meta-terminal
(i.e., the terminal of terminals). The meta-terminal is composed of
three well-distinguished building blocks: virtual keys, a virtual
controller, and a virtual display.
11
2.2.2.1 The Virtual Keys. The analog of the virtual keys is
the physical keyboard of real terminals. However, while the keys of
a physical terminal are controlled by a single manual process, these
virtual keys can be activated by multiple, concurrent entities (the
virtual terminal correspondents). Each correspondent of the virtual
terminal, be it a user of the service or a peer virtual terminal, has
its input stream to the meta-terminal terminated at the virtual keys.
The virtual keys provide the control of access of input streams to
the meta-terminal.
2.2.2.2 The Virtual Controller. The virtual controller
provides virtual terminal session management. It manages the
establishment and termination of a virtual terminal session with a
correspondent; supports the possible negotiation and renegotiation of
the session attributes; and enables the deactivation and later
activation of the session. The virtual controller also provides
virtual terminal signalling control by managing the out-of-band
signals addressed to the virtual terminal.
2.2.2.3 The Virtual Display. The virtual display is the
dynamic component in the meta-terminal organization. For each class
of real device (e.g. stream, line, page, or graphics-oriented
devices) there is a corresponding virtual terminal class. The
organization of the virtual terminal data structure is class-
specific. A virtual terminal models a particular terminal class when
it is 'fitted' with the proper data structure manager or virtual
display. This binding need not be static (e.g., a line-class
specialist, and so forth), but could be result of decisions made at
"run-time" by applying the principle of negotiated options.
The virtual display manages the data structure associated with
the meta-terminal and performs operations on the control and data
elements of the structure. As a direct consequence of these
operations on the meta-terminal data structure, the virtual display
may generate display updates to one, some, or all of the
correspondents. All virtual terminal output streams originate at the
virtual display.
Different virtual terminal classes are spawned by different
"kinds" of virtual displays, and this is realized in one of two ways.
For character-oriented virtual devices, it is possible to use a
single, wide-scoped virtual display with a character-oriented data
structure by constraining it to conform to the model of the device
class (e.g., line-oriented devices must be constrained to line-access
rules). For non character-oriented virtual devices (e.g., graphics
devices), an altogether different virtual display must be used with
12
properties better suited for the new domain (e.g., a graphics virtual
display based on a structured display file).
2.2.3 Virtual Terminal Architecture
The commands, and associated parameters, which are available to
the users of the virtual terminal constitute the virtual terminal
architecture. The commands available to a user -- to request the
virtual controller to establish, abort, or close a session, and
discard, suspend, or resume output -- remain invariant to the virtual
terminal class. However, as one would expect, the user interface to
the virtual display depends on the nature of this data structure.
Three important architectural features of the meta-terminal are:
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?