Organization: China Interactive Publishing Network (http://www.china-pub.com/)
RFC Document Chinese Translation Program (http://www.china-pub.com/compters/emook/aboutemook.htm)
E-mail: Ouyang@china-pub.com
Translator: An Zipping (FiveStar Anzp@xanet.edu.cn)
Translation time: 2001-4-13
Copyright: This Chinese translation copyright belongs to China Interactive Publishing Network. Can be used for non-commercial use free reprint, but the translation and copyright information of this document must be retained.
Network Working Group Jonathan B. Postel
RFC # 516 UCLA-NMC
NIC # 16683 May 18, 1973
Detection of lost messages
(Lost Message Detection)
I have three recommendations on the loss of news due to the problem of the communication subsystem. The first possibility is the strongest and easier implementation of them, because there is no new concept and you can reread the loss of the loss.
First scheme:
When the host sends a message, save a copy of the message until:
* Returns an RFNM, which means some normal and then processes the next message.
* Returns an Incomplete Transmission, and the message is returned (this may be a loop, so set a maximum number of repeated sends a message).
* Returns the Destination DEAD, which means that the host is turned off, and the reset command must be exchanged before further communication.
* Other returns indicate errors in the network or local interface packet processor (IMP), at least to record errors, turn off dialog.
Follow the steps to prevent the loss of the message.
Second plan:
When the host sends a message, the message number is included in the header area of the host in the host, and the message is sent in order (this is the same as the current network except the priority ", so this recommendation requires the host to send There is no priority distinguishing when anything), and then the host compares the received message number to the previously received message number so that the loss of the message can be found.
When the reset command is swapped, the serial number between the host is set to 0.
When a message is sent each time, add the current send message number to the specified area of the message head, and then send the current send message number 1 (molded with N, assuming n = 256).
Each time a message is received, this message number is compared to the current receiving message number:
If the received message is desired, then the message can be accepted, then the current received message number 1 (molded).
If the received message is not a desired, the message is lost.
When the message is detected, it is not obvious, but at least recorded, and reported to the network control center. The loss of messages may be unimportant to interactive sessions, but it is fatal for file transfer. Therefore, it is recommended that if the message does not recover, the management is managed.
The third program:
You can ask the host to respond between the host. This response can be implemented in a similar manner in a response between the interface packet processor. Because this is necessary to significantly modify the current agreement, it is necessary to develop a reasonable response strategy, there is still a further study, so I don't explain it in detail here. In the above three suggestions, the first is the most practical, and it is also easier to implement. These programs have no conflict with each other and can be implemented simultaneously.
[This RFC WAS PUT INTO MACHINE READABLE FORM for Entry]
[INTO THE ONLINE RFC Archives By Alex Mckenzie with]
[Support from Gte, Formerly BBN Corp. 9/99]
RFC516 Lost Message Detection RFC516 Detection of Lost Messages
1
RFC Chinese Translation Program
