RFC312 - Proposed Change in IMP-to-Host Protocol

王朝other·作者佚名  2008-05-31
窄屏简体版  字體: |||超大  

Network Working Group A. McKenzie

RFC#312 BBN

NIC 9342 22 March 1972

Categories: B.1

Proposed Change in IMP-to-Host Protocol

We are currently considering a redefinition of the IMP-to-Host

error message types (type 1 and type 8) and the creation of addi-

tional IMP-to-Host error message types. We believe that these

changes will assist the Hosts in determining appropriate recovery

action, without causing any serious reprogramming problems. Our

current plans are to install these changes within a few months;

therefore we should be informed of any strong negative reactions

relatively quickly.

The proposed changes fall into two general classes as de-

scribed below:

A) General Error Message

---------------------

Under certain circumstances, particularly when the Host

has been unresponsive to queued input for a "long time"

the IMP drops its ready line for a short period, causing

the "error flip-flops" to be set (see RFC#270, NIC 7818).

Under these conditions the IMP sends a few NOP's to the

Host and then resumes normal operation. We propose to

send the Host a new message (message type 13) in addition

to the NOPs; this message will tell the Host that the

IMP's Ready Line was dropped, that the IMP's error flop

was set, and that the IMP will respond to the next com-

pletion of a Host-to-IMP message with a type 1 or type 8

message (because of the setting of the IMP's error flop.

B) Error Messages which are Responses to Specific

----------------------------------------------

Host-to-IMP Transmissions:

--------------------------

1) IMP-to-Host message type 1 will be redefined to mean:

"IMP's Error flip-flop was set on a message which

the IMP cannot identify."

2) IMP-to-Host message type 8 will be redefined to mean:

"IMP's Error flip-flop was set during receipt of the

message identified by the 'source' and 'link number'

bits of this error message."

[Page 1]

3) IMP-to-Host message type 10 will be defined to mean:

"A Host-to-IMP message was too short (and cannot be

identified)."

4) IMP-to-Host message type 11 will be defined to mean:

"A Host-to-IMP message was too long; the message is

identified by the 'source' and 'link number' bits

of this error message."

5) IMP-to-Host message type 12 will be defined to mean:

"A Host-to-IMP message with an illegal message type

code was received; the message is identified by the

'source' and 'link number' bits of this error message.

(Note that the erroneous type code is not included in

the error message.)"

AAM/jm

[ This RFCwas put into machine readable form for entry ]

[ into the online RFCarchives by BBN Corp. under the ]

[ direction of Alex McKenzie. 12/96 ]

 
 
 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
 
 
© 2005- 王朝網路 版權所有 導航