📄 rfc909.txt
字号:
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 to usurp inactive connections. A connection with no activity could be declared 'dead', but would not be usurped until the connection resource was needed. However, this would still require the transport layer to support two connection channels: one to receive connection requests, and another to use for an active connection. 3.3 Command Sequencing Each command sent from the host to the target has a sequence number. The sequence number is used by the target to refer to the command in normal replies and error replies. To save space, these numbers are not actually included in host commands. Instead, each command sent from the host is assigned an implicit sequence number. The sequence number starts at zero at the beginning of the LDP session and increases by one for each command sent. The host and target each keep track of the current number. The SYNCH <sequence number> command may be used by the host to synchronize the sequence number. 3.4 Data Packing and Transmission
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -