📄 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 197136-Bit Words TransmittedFrom Harvard's PDP-10 toMITDG'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 TransmittedFrom MITDG's PDP-10 toHarvard'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 1971General 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 + -