📄 rfc61.txt
字号:
+-----------------+ +-----------------+ +-----------------+ | rendezvous site | | destination site| | source site | +-----------------+ +-----------------+ +-----------------+ | RECEIVE port | | RECEIVE port | | RECEIVE port | +-----------------+ +-----------------+ +-----------------+ | SEND port | | SEND port | | SEND port | +-----------------+ +-----------------+ +-----------------+ | | | source port | | | | | +-----------------+ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | data | | data | | data | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +-----------------+ +-----------------+ +-----------------+ transmitted transmitted received by SEND by Network by RECEIVE process Controller process Note: for a SEND FROM ANY message, the rendezvous site is the destination site. In the model time-sharing system it was possible to pass a port from process to process. This is still possible with a distributed Network Controller. [The reader unconvinced of the utility of port passing is directed to read the section on reconnection in [11].] Remember that for a message to be sent from one process to another, a SEND to port M from port N and a RECEIVE at port M from port N must rendezvous, normally at the SEND site. Both processes keep track of where they think the rendezvous site is and supply this site as a parameter of appropriate operations. The RECEIVE process thinks it is the SEND site and the SEND process normally thinks it is the SEND site also. Since once a SEND and a RECEIVE rendezvous, the transmission is sent to the source of the RECEIVE and the entry in the rendezvous table is cleared and must be set up again for each further transmission from N to M, it is easy for a RECEIVE port to be moved. If a process sends both the port numbers and the rendezvous site number to a new process at some other site which executes a RECEIVE using these same old port numbers and rendezvous site specification, the SENDer never knows the RECEIVEr has moved. It isWalden [Page 13] RFC 61 Interprocess Communication in a Computer Network July 1970 slightly harder for a SEND port to move. However, if it does, the pair of port numbers that has been being used for a SEND and the original rendezvous site number are passed to the new site. The process at the new SEND site specifies the old rendezvous site with the first SEND from the new site. The RECEIVE process will also still think the rendezvous site is the old site, so the SEND and RECEIVE will meet at the old site. When they meet, the entry in the table at that site is cleared, the rendezvous site number for the SEND message is changed to the site which originated the SEND message and both the SEND and RECEIVE messages are sent to the new SEND site just as if they had been destined for there in the first place. The SEND and RECEIVE then meet again at the new rendezvous site and transmission may continue as if the port had never moved. Since all transmissions contain the source site number, further RECEIVEs will be sent to the new rendezvous site. It is possible to discover that this special manipulation must take place because a SEND message is received at a site which did not originate the SEND message. Everything is so easily changed because there are no permanent connections to break and move as in the once proposed reconnection scheme for the ARPA network [10][11] that is, connections only exist fleetingly in the system described here and can therefore be remade between any pair of processes which at any time happen to know each other's port numbers and have some clue where they each are. Of course, all of this could have been done by the processes sending messages back and forth announcing any potential moves and the new site numbers.Walden [Page 14] RFC 61 Interprocess Communication in a Computer Network July 1970REFERENCES [1] L. Roberts and B. Wessler, Computer Network Development to achieve Resource Sharing, Proceedings 1970 SJCC. [2] V. Vyssotsky, F. F. Corbato, and R. Graham, Structure of the MULTICS Supervisor, Proceedings 1965 FJCC. [3] C. Carr, S. Crocker, and V. Cerf, Host/Host Communication Protocol in the ARPA Network, Proceedings 1970 SJCC. [4] F. Heart, et al, The Interface Message Processor for the ARPA Computer Network, Proceedings 1970 SJCC. [5] W. Ackerman and W. Plummer, An Implementation of Multi- processing Computer System, Proceedings Gatlinburg Symposium on Operating System Principles. [6] J. Dennis and E. Van Horn, Programming Semantics for Multiprogramming Computation, Proceedings of the San Dimes Conference on Programming Language and Pragmatics. [7] B. Lampson, Dynamic Protection Structures, Proceedings FJCC 1969. [8] B. Lampson, An Overview of the CAL Time-Sharing System, Computer Center, University of Calif., Berkeley. [9] P. Hansen, The Nucleus of a Multiprogramming System, CACM, April 1970. [10] S. Crocker, ARPA Network Working Group Note #36. [11] J. Postel and S. Crocker, ARPA Network Working Group Note #48. [12] B. Lampson, 940 Lectures.Walden [Page 15] RFC 61 Interprocess Communication in a Computer Network July 1970APPENDIX: AN APPLICATION Only one resource sharing computer network currently exists, the aforementioned ARPA network. In this Appendix, I hope to show that the system that was described in this note can be applied to the ARPA network. A significant body of work exists on interprocess communication within the ARPA network. This work comes in several almost distinct pieces: the Host/IMP protocol, IMP/IMP protocol, and the Host/Host protocol. I assume familiarity with this work in the subsequent discussion. [See references [1][3][4][10][11]; Specifications for the Inter-connection of a Host to an IMP, BBN Report No. 1822; and ARPA Network Working Group Notes #37, 38, 39, 42, 44, 46, 47, 48, 49, 50, 54, 55, 56, 57, 56, 59.] In the ARPA network, the IMP's have sole responsibility for correctly transmitting bits from one site to another. The Hosts have sole responsibility for making interprocess connections. Both the Host and IMP are concerned and take a little responsibility for flow control and message sequencing. Application of the interprocess communication system I have described leads me to different allocation of responsibility. The IMP still continues to correctly move bits from one site to another, but the Network Controller also resides in the IMP, and flow control is completely in the hands of the processes running in the Hosts although perhaps they use mechanisms provided by the IMPs. The IMPs provide the SEND, RECEIVE, SEND FROM ANY, RECEIVE ANY, and UNIQUE operations in slightly altered forms for the Hosts and also maintain the rendezvous tables including moving of SEND ports when necessary. It is perhaps easiest to step through the five operations again. SEND. The Host gives the IMP a SEND port number, a RECEIVE port number, the rendezvous site, and a buffer specification=20 (e.g., start and end, beginning and length). The SEND is sent to the rendezvous site, normally the local site. When the matching RECEIVE arrives, the Host is notified of the RECEIVE port of the just arrived receive message. This port number is sufficient to identify the SENDing process although a given time-sharing system may have to keep internal tables mapping this port number into useful internal process identifiers. Simultaneously, the IMP will begin to ask the Host for specific chunks of the data buffer. These chunks will be sent off to the destination as the IMP's RFNM control allows. If a RFNM is not received for too long, implying a message has been lost in the network, the Host is asked for the same chunk of data again [which also allows messages to be completely thrown away by the IMP networkWalden [Page 16] RFC 61 Interprocess Communication in a Computer Network July 1970 if that should ever be useful], but the Host has the option to abort the transmission at this time. While a transmission is taking place, the Host may ask the IMP to perform other operations including other SENDs. A second SEND over a pair of ports already in the act of transmission is noted and the SEND becomes active as soon as the first transmission is complete. A third identical SEND results in an error message to the Host. If a SEND times out, an error is returned also. RECEIVE. The Host gives the IMP a SEND port, a RECEIVE port, a rendezvous site, and a buffer description. The RECEIVE message is sent to the rendezvous site. When chunks of a transmission arrive for the RECEIVE port they are passed to the Host along with RECEIVE port number (and perhaps the SEND port number), and an indication to the Host where to put the data in its input buffer. When the last of the SEND buffer is passed into the Host, it is marked accordingly and the Host can then detect this. A second RECEIVE over the same port pair is allowed. A third results in an error message to the Host. The mechanism described in this and the previous paragraphs allows a pair of processes to always have both a transmission in progress and the next one pending. Therefore, no efficiency is lost. On the other hand, each transmission must be preceded by a RECEIVE into a specified buffer, thus providing complete flow control. (It is conceivable that the RECEIVE message could allocate a piece of network bandwidth while making its network traverse to the rendezvous site.) RECEIVE ANY. The Host gives the IMP a RECEIVE port and a buffer descriptor. This works the same as RECEIVE but assumes the local site to be the rendezvous site. SEND FROM ANY. The Host gives the IMP RECEIVE and SEND ports, the destination site, and a buffer descriptor. The IMP requests and transmits the buffer as fast as possible. A SEND FROM ANY for a non-existent port is discarded at the destination site. RFNM's are tied to the transmission of a particular chunk of buffer just as acknowledgments are now tied to packets and they perform the same function. If the Hosts allow the IMPs to reassemble buffers in the Hosts by the IMP telling the Host where it should put a buffer chunk as described above, chunks of a single buffer can be transmitted in parallel and several RFNMs can be outstanding simultaneously. Packet reassembly is still done in the IMPs. A final operation must be provided by the IMP -- the UNIQUE operation. There are many ways to maintain unique numbers and three are presented here. The first possibility is for the Hosts to ask the IMPs for the unique numbers originally and then guarantee theWalden [Page 17] RFC 61 Interprocess Communication in a Computer Network July 1970 integrity of any unique numbers currently owned by local processes and programs using whatever means the Host has at its disposal. In this case the IMPs would provide a method for a unique number to be sent from one host to another and would vouch for the number's identity at the new site. The second method is to simply give the unique numbers to the processes that are using them, depending on the non-malicious behavior of the processes to preserve the unique numbers, or if an accident should happen, the two passwords (SEND and RECEIVE ports) that are required to initiate a transmission. If the unique numbers are given out in a non-sequential manner and are reasonably long (say 32 bits) there is little danger. In the final method, a user identification is included in the port numbers and the individual time-sharing systems guarantee the integrity of these identification bits. Thus a process, while not able to be sure that the correct port is transmitting to him, can be sure that some port of the correct user is transmitting. This is the so-called virtual net concept suggested by W. Crowther [3]. Random Contents. Putting these operations in the IMP requires the Host/Host protocol program to be written only once, rather than many times as is currently being done in the ARPA Network. The IMPs can stop a specific host transmission (by not asking for the next chunk for a while) if that should seem necessary to alleviate congestion problems in the communications subnet. And the IMP might know the approximate time it takes for a RECEIVE to get to a particular other site and warn the Host to wake up a process shortly before it becomes imminent that a message for that process will be arriving. [ This RFC was put into machine readable form for entry ] [ into the online RFC archives by Katsunori Tanaka 4/99 ]Walden [Page 18] ⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -