rfc802.txt
来自「RFC 的详细文档！」· 文本 代码 · 共 2,673 行 · 第 1/5 页
TXT
2,673 行
- 25 -
RFC 802 Andrew G. Malis
3.1 Host-to-IMP 1822L Leader Format
1 4 5 8 9 16
+--------+--------+----------------+
| | 1822L | |
| Unused | H2I | Handling Type |
| | Flag | |
+--------+--------+----------------+
17 20 21 22 24 25 32
+--------+-+------+----------------+
| |T|Leader| |
| Unused |R|Flags | Message Type |
| |C| | |
+--------+-+------+----------------+
33 48
+----------------------------------+
| |
| Source Host |
| |
+----------------------------------+
49 64
+----------------------------------+
| |
| Destination Host |
| |
+----------------------------------+
65 76 77 80
+-------------------------+--------+
| | |
| Message ID |Sub-type|
| | |
+-------------------------+--------+
81 96
+----------------------------------+
| |
| Unused |
| |
+----------------------------------+
Figure 5. Host-to-IMP 1822L Leader Format
- 26 -
RFC 802 Andrew G. Malis
Bits 1-4: Unused, must be set to zero.
Bits 5-8: 1822L Host-to-IMP Flag:
This field is set to decimal 13 (1101 in binary).
Bits 9-16: Handling Type:
This field is bit-coded to indicate the transmission
characteristics of the connection desired by the host. See
1822(3.3).
Bit 9: Priority Bit:
Messages with this bit on will be treated as priority
messages.
Bits 10-16: Unused, must be zero.
Bits 17-20: Unused, must be zero.
Bit 21: Trace Bit:
If equal to one, this message is designated for tracing as
it proceeds through the network. See 1822(5.5).
Bits 22-24: Leader Flags:
Bit 22: A flag available for use by the destination host.
See 1822(3.3) for a description of its use by the IMP's
TTY fake host.
Bits 23-24: Reserved for future use, must be zero.
- 27 -
RFC 802 Andrew G. Malis
Bits 25-32: Message Type:
Type 0: Regular Message - All host-to-host communication
occurs via regular messages, which have several sub-
types, found in bits 77-80. These sub-types are:
0: Standard - The IMP uses its full message and error
control facilities, and host blocking (see section
2.4) may occur.
1: Standard, short-blocking - See section 2.4.
2: Uncontrolled, short-blocking - See section 2.4.
3: Uncontrolled - The IMP will perform no message-
control functions for this type of message, and
network flow and congestion control (see section
2.4) may cause loss of the message. Also see
1822(3.6) and section 2.3.
4-15: Unassigned.
Type 1: Error Without Message ID - See 1822(3.3).
Type 2: Host Going Down - see 1822(3.3).
Type 3: Name Declaration Message (NDM) - This message is
used by the host to declare which of its 1822L names is
or is not effective (see section 2.2), or to make all
of its names non-effective. The first 16 bits of the
data portion of the NDM message, following the leader
and any padding, contains the number of 1822L name
- 28 -
RFC 802 Andrew G. Malis
entries contained in the message. This is followed by
the 1822L name entries, each 32 bits long, of which the
first 16 bits is a 1822L name and the second 16 bits
contains either of the integers zero or one. Zero
indicates that the name should not be effective, and
one indicates that the name should be effective. The
IMP will reply with a NDM Reply message (see section
3.2) indicating which of the names are now effective
and which are not. Pictorially, a NDM message has the
following format (including the leader, which is
printed in hexadecimal):
- 29 -
RFC 802 Andrew G. Malis
1 16 17 32 33 48
+----------------+----------------+----------------+
| | | |
| 0D00 | 0003 | 0000 |
| | | |
+----------------+----------------+----------------+
49 64 65 80 81 96
+----------------+----------------+----------------+
| | | |
| 0000 | 0000 | 0000 |
| | | |
+----------------+----------------+----------------+
97 112 113 128 129 144
+----------------+----------------+----------------+
| | | |
| # of entries | 1822L name #1 | 0 or 1 |
| | | |
+----------------+----------------+----------------+
145 160 161 176
+----------------+----------------+
| | |
| 1822L name #2 | 0 or 1 | etc.
| | |
+----------------+----------------+
Figure 6. NDM Message Format
An NDM with zero entries will cause all current
effective names for the host to become non-effective.
Type 4: NOP - This allows the IMP to know which style of
leader the host wishes to use. A 1822L NOP signifies
that the host wishes to use 1822L leaders, and an 1822
NOP signifies that the host wishes to use 1822 leaders.
All of the other remarks concerning the NOP message in
- 30 -
RFC 802 Andrew G. Malis
1822(3.3) still hold. The host should always issue
NOPs in groups of three to insure proper reception by
the IMP. Also see section 2.5 for a further discussion
on the use of the NOP message.
Type 8: Error with Message ID - see 1822(3.3).
Types 5-7,9-255: Unassigned.
Bits 33-48: Source Host:
This field contains one of the source host's 1822L names
(or, alternatively, the 1822L address of the host port the
message is being sent over). This field is not
automatically filled in by the IMP, as in the 1822 protocol,
because the host may be known by several names and may wish
to use a particular name as the source of this message. All
messages from the same host need not use the same name in
this field. Each source name, when used, is checked for
authorization, effectiveness, and actually belonging to this
host. Messages using names that do not satisfy all of these
requirements will not be delivered, and will instead result
in an error message being sent back into the source host.
If the host places its 1822L Address in this field, the
address is checked to insure that it actually represents the
host port where the message originated. If the message is
destined for an 1822 host on a non-C/30 IMP, this field MUST
- 31 -
RFC 802 Andrew G. Malis
contain the source host's 1822L address (see Figure 4 in
section 2.2).
Bits 49-64: Destination Host:
This field contains the 1822L name or address of the
destination host. If it contains a name, the name will be
checked for effectiveness, with an error message returned to
the source host if the name is not effective. If the
message is destined for an 1822 host on a non-C/30 IMP, this
field MUST contain the destination host's 1822L address (see
Figure 4 in section 2.2).
Bits 65-76: Message ID:
This is a host-specified identification used in all type 0
and type 8 messages, and is also used in type 2 messages.
When used in type 0 messages, bits 65-72 are also known as
the Link Field, and should contain values specified in
Assigned Numbers [3] appropriate for the host-to-host
protocol being used.
Bits 77-80: Sub-type:
This field is used as a modifier by message types 0, 2, 4,
and 8.
- 32 -
RFC 802 Andrew G. Malis
Bits 81-96: Unused, must be zero.
- 33 -
RFC 802 Andrew G. Malis
3.2 IMP-to-Host 1822L Leader Format
1 4 5 8 9 16
+--------+--------+----------------+
| | 1822L | |
| Unused | I2H | Handling Type |
| | Flag | |
+--------+--------+----------------+
17 20 21 22 24 25 32
+--------+-+------+----------------+
| |T|Leader| |
| Unused |R|Flags | Message Type |
| |C| | |
+--------+-+------+----------------+
33 48
+----------------------------------+
| |
| Source Host |
| |
+----------------------------------+
49 64
+----------------------------------+
| |
| Destination Host |
| |
+----------------------------------+
65 76 77 80
+-------------------------+--------+
| | |
| Message ID |Sub-type|
| | |
+-------------------------+--------+
81 96
+----------------------------------+
| |
| Message Length |
| |
+----------------------------------+
Figure 7. IMP-to-Host 1822L Leader Format
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?