File: rfc17a.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (115 lines) | stat: -rw-r--r-- 3,159 bytes parent folder | download | duplicates (5)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115






Network Working Group                                            R. Kahn
Request for Comments: 17a                    Bolt Beranek and Newman Inc
                                                             August 1969


                Re: Some Questions Re: HOST-IMP Protocol

   THE FOLLOWING COMMENTS ARE IN RESPONSE TO JOHN KREZNAR'S QUESTIONS
   WHICH WERE RAISED IN 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's site.  Let us distinguish between non-use of a link in-
   between messages and non-use of a link due to Host program delays in
   the middle of transmitting or receiving a message.  When the Host
   transmits a message on a link for which an entry is not in the link
   table, one will simply be 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 table becomes full
   immediately after an entry is deleted (a situation we do not expect
   to occur) is there a possibility of resulting delay.

   Arbitrary delays introduced by Host programs are also not
   inconsistent with the link entry deletion procedure.  A link is
   blocked when the first access of the link table is made during
   transmission from the source IMP and is unblocked when the RFNM
   returns.  Only non-blocked transmit link entries are deleted after 30
   seconds of disuse.  The statement on page 23 referencing arbitrary
   delays was only intended to have hardware implications insofar as the
   Host/IMP interface is designed to transfer bits asynchronously
   between the Host and the IMP.

   A RFNM is returned from the destination IMP to the source IMP when a
   message reaches the head of the destination IMP's output queue to the
   Host (i.e. just before a message is sent to the Host).  If a
   destination IMP cannot then deliver that full message to the Host, at
   most one more message 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 output queue to the Host thus
   guaranteeing the preservation of the proper message arrival sequence.

   The NOP message is a special control message which is available for
   use during initiation of communication between the Host and its IMP.
   The Host may, of course, decline to send NOP messages during this
   period, but the first received message after IMP startup or after the






Kahn                                                            [Page 1]

RFC 17a         Re: Some Questions Re: HOST-IMP Protocol     August 1969


   Host ready indicator 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. Kahn
   BOLT BERANEK AND NEWMAN INC.


         [ This RFC was put into machine readable form for entry ]
          [ into the online RFC archives by Marc Blanchett 3/00 ]









































Kahn                                                            [Page 2]