📄 rfc89.txt
字号:
which makes good use of them (in this case a PDP-1 which displays
them). (7) Then the MITDG program either terminates, returns
control back to the image (as in this case), or waits for more data
and/or program. The protocol was implemented in the hosts and used
to run a Harvard-assembled version of the E&S Aircraft Carrier
Program (written originally by Harvard's Prof. Cohen) at MITDG and to
display the resulting dynamic display on Harvard's PDP-1 driven DEC
scopes. The Carrier Program was 'flown' from MITDG and the changing
views thus generated appeared both at MITDG and Harvard. The picture
was observed to change (being transmission limited) on the order of
twice each second (perhaps less often). But all was not rosey:
First, it was observed that during the experiment prompting messages
to the IMP-Teletypes were often garbled. Most of the garbling can be
attributed to the ASR-33 itself, some cannot. There were no errors
detected during data transmissions not involving the IMP-Teletypes.
Second, during attempts to fly the Carrier from Harvard, we stumbled
across a yet undiagnosed intermittent malfunction of (presumably) the
MITDG hardware and/or software which caused our network connection to
be totally shut down by the system during bi-directional
transmission. This problem is currently under investigation.
Metcalff [Page 4]
RFC 89 SOME HISTORIC MOMENTS IN NETWORKING 19 January 1971
Third, the response of the total system was slow compared to that
required to do real-time dynamic graphics. One would expect that if
this limitation is to be overcome, higher bandwidth transmission
lines, faster host response to network messages, and/or perhaps a
message priority system will be required.
Metcalff [Page 5]
RFC 89 SOME HISTORIC MOMENTS IN NETWORKING 19 January 1971
36-Bit Words Transmitted
From Harvard's PDP-10 to
MITDG's PDP-10
+---------------+---------------+ Image control
| -count | origin-1 | word.
+---------------+---------------|-
Image: | start address of results | | Filled in by
+-------------------------------+ -Harvard's
Image+1: | end address of results | | program during
+-------------------------------+- its execution.
Image+2: | ---------unused----------- | +-- -+
+-------------------------------+ |Filled in |
Image+3: | program stop address |<-|by MITDG |
+-------------------------------+ |for return |
Image+4: | program start address | |of control.|
+-------------------------------+ +-- --+
Image+5: | |
+-------------------------------+
Image control word | |
and image arrive in | |
network size buffers | |
which are stripped of| |
marking and padding | |
and concatenated. | |
+-------------------------------+
36-Bit Words Transmitted
From MITDG's PDP-10 to
Harvard's PDP-1
+---------------+---------------+
| | count |
+---------------+---------------+
First word of results | |
Specified in Image+0. | |
| results |
| |
| |
| |
| |
| |
| |
Last word of results | |
specified in Image+1. | |
+-------------------------------+
Metcalff [Page 6]
RFC 89 SOME HISTORIC MOMENTS IN NETWORKING 19 January 1971
General Comments
In producing 'network ASCII messages' we were required to bend over
backwards to insert marking so that our last data bit could fall on a
word boundary. Surely there must be a better way. The double
padding scheme and its variants with or without marking should be
considered. Given the current hardware, it would seem that double
padding with marking would be an improvement. A simple(?) fix to
host IMP interfaces enabling them to send only good data from a
partially filled last word would permit a further improvement:
marking and host-supplied single padding.
In these initial experiments Harvard used the IMP-Teletype message
convention or what are call 'IMP ASCII messages' (without marking)
because it would allow them to use IMP-Teletypes for logging in and
testing. Multics, on the other hand, used the standard network
message format (with marking) to have Host-Host compatibility as per
accepted protocols. Both approaches have merit. The IMP-Teletype
message format should be changed to conform with the network standard
- it should have marking.
Finally, we would like to announce our readiness to participate in
experiments which will further extend our confidence and competence
in networking, especially experiments which, like the preceding, will
have very large returns with relatively small investment.
Roster of those participating
Ben Barker Harvard, BBN
Grenville Bingham MITDG
Howard Brodie MITDG
Dan Cohen Harvard
Tim Knight MITDG, MIT/AI
John McQuillan Harvard
Bob Metcalfe MITDG, Harvard
Ed Meyer Multics
Mike Padlipsky Multics
Tom Skinner Multics
Ed Taft Harvard
[This RFC was put into machine readable form for entry]
[into the online RFC archives by Lorrie Shiota, 10/01]
Metcalff [Page 7]
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -