rfc909.txt
来自「RFC 的详细文档！」· 文本 代码 · 共 2,217 行 · 第 1/5 页
TXT
2,217 行
Page 2
LDP Specification General Description
CHAPTER 2
General Description
2.1 Motivation
LDP is an application protocol that provides a set of
commands used by application programs for loading, dumping and
debugging target machines across a network.
The goals of this protocol are shown in the following list:
o The protocol should support various processor types and
operating systems. Overhead and complexity should be
minimized for simpler cases.
o The protocol should provide support for applications in
which more than one user can debug the same target
machine. This implies an underlying transport mechanism
that supports multiple connections between a host-target
pair.
o LDP should have a minimal subset of commands for boot
loading and dumping. Target machine implementations of
these applications are often restricted in the amount of
code-space they may take. The services needed for
loading and dumping should be provided in a small,
easily implemented set of commands.
o There should be a means for communicating exceptions and
errors from the target LDP process to the host process.
o LDP should allow the application to implement a full set
of debugging functions without crippling the performance
of the target's application (i.e., PSN, PAD, gateway).
For example, a breakpoint mechanism that halts the
target machine while breakpoint commands are sent from
the host to the target is of limited usefulness, since
the target will be unable to service the real-time
Page 3
RFC-909 July 1984
demands of its application.
2.2 Relation to Other Protocols
LDP is an application protocol that fits into the layered
internet protocol environment. Figure 1 illustrates the place of
LDP in the protocol hierarchy.
+------------------------------+
| LDP | Application
+------------------------------+ Layer
| |
| |
| |
+---------+ +---------+
| RDP | or | TCP | Transport Layer
+---------+ +---------+
| or | |
| | |
| +--------------------+
| | Internet Protocol | Internetwork
| +--------------------+ Layer
| |
+------------------------------+
| Network Access Protocol | Network Layer
+------------------------------+
Relation to Other Protocols
Figure 1
Page 4
LDP Specification General Description
2.2.1 Transport Service Requirements
LDP requires that the underlying transport layer:
o allow connections to be opened by specifying a network
(or internet) address. Support passive and active
opens.
o for each connection, specify the maximum message size.
o provide a mechanism for sending and receiving messages
over an open connection.
o deliver messages reliably and in sequence
o support multiple connections, and distinguish messages
associated with different connections. This is only a
requirement where LDP is expected to support several
users at the same time.
o explictly return the outcome (success/failure) of each
request (open, send, receive), and provide a means of
querying the status of a connection (unacknowledged
message count, etc.).
Data is passed from the application program to the LDP user
process in the form of commands. In the case of an LDP server
process, command responses originate in LDP itself. Below LDP is
the transport protocol. The Reliable Data Protocol (RDP --
RFC 908) is the recommended transport procotol. Data is passed
across the LDP/RDP interface in the form of messages. (TCP may
be used in place of RDP, but it will be less efficient and it
will require more resources to implement.) An internet layer
(IP) normally comes between RDP and the network layer, but RDP
may exchange data packets directly with the network layer.
Figure 2 shows the flow of data across the protocol
interfaces:
Page 5
RFC-909 July 1984
+------+
| |
|Appli-|
|cation|
| |
+------+
^
Commands |
V
+------+
| |
| LDP |
| |
+------+
^
Messages |
V
+-----+
| |
| RDP |
| |
+-----+
^
Segments |
V
+----+
| |
| IP |
| |
+----+
^
Datagrams |
V
? * !
$ = ^ +
*
> Internet
, ?
! )
* % $
Form of Data Exchange Between Layers
Figure 2
Page 6
LDP Specification General Description
Page 7
RFC-909 July 1984
Page 8
LDP Specification Protocol Operation
CHAPTER 3
Protocol Operation
3.1 Overview
An LDP session consists of an exchange of commands and
responses between an LDP user process and an LDP server process.
Normally, the user process resides on a host machine (a
timesharing computer used for network monitoring and control),
and the server process resides on a target machine (PSN, PAD,
gateway, etc.). Throughout this document, host and target are
used as synonyms for user process and server process,
respectively, although in some implementations (the Butterfly,
for example) this correspondence may be reversed. The host
controls the session by sending commands to the target. Some
commands elicit responses, and all commands may elicit an error
reply.
The protocol contains five classes of commands: protocol,
data transfer, management, control and breakpoint. Protocol
commands are used to verify the command sequencing mechanism and
to handle erroneous commands. Data transfer commands involve the
transfer of data from one place to another, such as for memory
examine/deposit, or loading. Management commands are used for
creating and deleting objects (processes, breakpoints,
watchpoints, etc.) in the target machine. Control commands are
used to control the execution of target code and breakpoints.
Breakpoint commands are used to control the execution of commands
inside breakpoints and watchpoints.
3.2 Session Management
An LDP session consists of a series of commands sent from a
host LDP to a target LDP, some of which may be followed by
responses from the target. A session begins when a host opens a
transport connection to a target listening on a well known port.
LDP uses RDP port number zzz or TCP port number yyy. When the
connection has been established, the host sends a HELLO command,
and the target replies with a HELLO_REPLY. The HELLO_REPLY
contains parameters that describe the target's implementation of
LDP, including protocol version, implementation level, system
Page 9
RFC-909 July 1984
type, and address format. The session terminates when the host
closes the underlying transport connection. When the target
detects that the transport connection has been closed, it should
deallocate any resources dedicated to the session.
The target process is the passive partner in an LDP session,
and it waits for the host process to terminate the session. As
an implementation consideration, either LDP or the underlying
transport protocol in the target should have a method for
detecting if the host process has died. Otherwise, an LDP
target that supported only one connection could be rendered
useless by a host that crashed in the middle of a session. The
problem of detecting half-dead connections can be avoided by
taking a different tack: the target could allow new connections
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?