As per Relevance of the word messages, we have this rfc below:
Network Working Group David C. Walden (WALDEN@BBN
Request for Comments: 687 Jun 1975
NIC #32654
IMP/Host and Host/IMP Protocol
This note sketches the design of an expansion to
IMP/host and host/IMP protocol which will include among
things the possibility of addressing hosts on more than 63 IMPs
Our intention in this expansion is to correct certain
limits without fundamental changes in the philosophy of
IMP/host protocol; i.e., while many issues which would
fundamental changes to the IMP/host protocol are presently
discussion in the world-wide packet-switching com unity, we
not able to undertake massive fundamental changes on a time
compatible with the short term needs for network
(e.g., already there are almost 60 IMPs).
The following paragraphs cover each of the
characteristics of the expanded protocol. A knowledge of
3 of BBN Report 1822 is assumed. As is discussed below,
expanded protocol is backwards compatible
1. Expanded Leader Size. The leader will be expanded from
to five 16-bit words. This will provide space for
field expansions and additions
2. Expanded Address Field. The address field will be
to 24 bits, 16 bits of IMP address and 8 bits of host address
This expansion is more than adequate for any foreseeable
Network growth
3. New Message Length Field. A new field will be added
will allow the source host to optionally specify the
length (in bits) to the IMP subnetwork. The IMP subnetwork
be able to use this information (when available) to
utilize network buffer storage. The destination host may also
able to use this information to better utilize its
storage. This field will be 13 bits wide
4. Expanded Handling Type Field. The handling type field
now is used to distinguish between priority and non-
message streams, etc., will be expanded to eight bits.
expanded field will provide for the possibility of a number
parallel message streams having different
characteristics between pairs of hosts; e.g., priority
non-priority, varying numbers of packets per message (see below),
unordered messages (i.e., the present type-3 messages), a
stream requiring guaranteed capacity, etc. Note that only
of these facilities will be available in the near term
5. Source Host Control of Packets per Message. The
will exist for the source host to specify a message stream
-1-
will use a given number of packets per multi-packet message (e.g
two packets per message or five packets per message). Since
IMP network will not have to use eight packet-buffers
reassembly purposes, as at present, this may result in
services for such messages. This will help users who need
low delay and high throughput
6. Unordered (type-3) Message Change. Unordered messages
be indicated by a handling type rather than by a message type
at present. This is compatible with the need to check the
access control capabilities of all messages. This will provide
slight backward incompatibility for the three or so hosts
presently use type-3 messages in their research
7. Change in Format of Fake Host Addresses. The For/From
bit will be eliminated. The fake host addresses will be the
highest host numbers (e.g., IMP Teletype will be host 252).
8. Addition of a Parameter to the IMP to Host NOP. The IMP
host NOP will have added to it a parameter specifying the
(IMP and host number) of the host
9. Backward Compatibility. The old and new formats will
supported in parallel in the IMPs for the foreseeable future
allow gradual phaseover of host software. A host will be able
specify to its IMP whether the old or new formats are to be used
thus, it will be possible for the host to specify switching
and forth between the two modes for debugging purposes.
specification of the mode to be used will be possible via
proper choice of format in the host to IMP NOP message; the
will use the mode of the host to IMP NOP message the IMP
received. Further, a host may select to use either the old
new format without needing to know more about the other
messages than to discard them should they arrive. The IMP
initialize by sending several NOP messages of each type to
the hosts its choice. Although a host not implementing the
format will not be able to address hosts on IMPs with IMP-
greater than 63, the IMPs will wherever possible do
conversion necessary to permit hosts using the old format
com unicate with hosts using the new format and the reverse
Finally, it will be possible to convert the leader format
old to new or the reverse without knowledge of the message type
11. Non-blocking Host Interface. A mechanism will be
which allows the IMP to refuse a message from a host
blocking the host interface. This mechanism will permit the
to gather the necessary resources to send the refused message
then ask the host to resend the message. Finally, the host
be permitted to ask to be able to send a message and be
when it is possible without requiring the message to actually
sent and refused
12. Maximum Message Length. The maximum number of bits of
in a message may be reduced by a few bits
-2-
We are presently working out the details of
implementation plan for making the above changes to the
software. We will distribute an implementation schedule
other necessary information (e.g., format details) in plenty
time for hosts desiring to use the new protocol as soon as it
available to implement in time
-3-
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
