As per Relevance of the word destination, we have this rfc below:
Network Working Group John E.
RFC-17
27 August 1969
Some Questions Re: HOST-IMP
l. Automatic deletion of links, as indicated in BBN 1822, page 11,
bad
a) Link use may be dependent upon human use of a time share terminal -
indefinite time between messages
b) Program using link may be slow due to
i) Bush HOST (many jobs
ii) Much local I/O and/or CPU time between messages - is it that
if a HOST's user failes to use a link for 15 seconds, the
network program must generate a dummy message merely to
the link open
2. Steve Crocker, HOST Software, 1969 Apr 7, asks on page 2: "Can a HOST
as opposed to its IMP, control RFNM's?" BBN, Report No. 1837, 1969 Jul
says on page 2: "The principal function of the (IMP) program...
...generating of RFNM's..." What if an IMP generates an RFNM and
discovers it cannot, for some reason, complete timely delivery of
last received message to its HOST? This seems especially pressing
I can't recall seeing anywhere an IMP constraint upon HOSTs that
must accept incoming messages within some specified maximum time
3. A HOST has to be prepared to repeat transmissions of a message
network (see, e.g., Page 17, BBN 1822) therefore why the
discardable NOP message (Page 12, BBN 1822).
4. "Arbitrary delays," middle paragraph, page 23, BBN 1822, seems
with automatic link deletion questioned in 1 above. Normally the
involved differ by many orders of magnitude but a high priority
HOST responsibility could delay next bit for a long time
1. Abhi Bhushan, Proj. MAC 10. Sal Aranda,
2. Steve Crocker, UCLA 11. Jerry Cole, "
3. Ron Stoughton, UCSB 12. John Kreznar,"
4. Elmer Shapiro, SRI 13. Dick Linde, "
5. Steve Carr, Utah 14. Bob Long, "
6. John Haefner, RAND 15. Reg Martin, "
7. Paul Rovner, LL 16. Hal Sackman, "
8. Bob Kahn, BB&N 17. C. Weissman, "
9. Larry Roberts,
THE FOLLOWING COMMENTS ARE IN RESPONSE TO JOHN KREZNAR'S
WHICH WERE RAISED NWG: - 17
The deletion of a link entry from an IMP's link table will, in general
have no effect upon a Host transmission (or reception) at that IMP'
site. Let us distinguish between nonuse of a link in-between
and nonuse of a link due to Host program delays in the middle of
transmitting or receiving a message. When the Host transmits a
on a link for which an entry is not in the link table, one will simply
inserted there. There is no need for "dummy" Host messages to keep a link
"open" since a link is effectively always open. Only if the link
becomes full immediately after an entry is deleted (a situation we do
expect to occur) is there a possibility of resulting delay
Arbitrary delays introduced by Host programs are also not
with the link entry delection procedure. A link is blocked when the
access of the link table is made during transmission from the source
and is unblocked when the RFNM returns. Only nonblocked transmit
entries are deleted after 30 seconds of disuse. The statement on page 23
referencing arbitrary delays was only intended to have hardware
insofar as the Host/IMP interface is designed to transfer bits
betweem the Host and the IMP
A RFNM is returned from the destination IMP to the source IMP when
message reaches the head of the destination IMP's output queue to the
(i.e., just before a message is sent to the Host). If a destination
cannot then deliver that full message to the Host, at most one more
may possibly arrive at that IMP due to the premature release of the RFNM
The new message will subsequently take its place at the end of the
queue to the Host thus guaranteeing the preservation of the proper
arrival sequence
The NOP message is a special control message which is available for
during initiation of communication between the Host and its IMP. The
may, of course, decline to send NOP messages during this period, but
first received message after IMP startup or after the Host ready
has gone on, may be discarded by the IMP. We do not require a Host to be
prepared to repeat transmissions into the network
R. E.
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
