diff options
author | Thomas Voss <mail@thomasvoss.com> | 2024-11-27 20:54:24 +0100 |
---|---|---|
committer | Thomas Voss <mail@thomasvoss.com> | 2024-11-27 20:54:24 +0100 |
commit | 4bfd864f10b68b71482b35c818559068ef8d5797 (patch) | |
tree | e3989f47a7994642eb325063d46e8f08ffa681dc /doc/rfc/rfc58.txt | |
parent | ea76e11061bda059ae9f9ad130a9895cc85607db (diff) |
doc: Add RFC documents
Diffstat (limited to 'doc/rfc/rfc58.txt')
-rw-r--r-- | doc/rfc/rfc58.txt | 112 |
1 files changed, 112 insertions, 0 deletions
diff --git a/doc/rfc/rfc58.txt b/doc/rfc/rfc58.txt new file mode 100644 index 0000000..f310ff8 --- /dev/null +++ b/doc/rfc/rfc58.txt @@ -0,0 +1,112 @@ + + + + + + +Network Working Group T. P. Skinner +Request for Comments: 58 MIT Project MAC + June 1970 + + Logical Message Synchronization + + +At the last network meeting, the question of logical and physical +message distinctions was raised. An argument was made in favor of +never running two logical messages together as one or more physical +messages. Another method of stating this is that a logical message +must begin on a physical message boundary. This did not, however, +solve the problem of locating the end of a logical message. A rather +poor technique was suggested by myself which consisted of using the +first partial physical message as an indication of the last physical +message of the logical message. This technique was thrown out for a +number of very valid reasons. The solution that seemed most pleasing +was the inclusion of some sort of a bit count or data type +specification to precede the logical message. Most everyone seemed to +like this even though it was stated in a very general way. + +As of this writing it appears that it is desired to completely sever +the relation between physical and logical messages. This certainly is +aesthetically pleasing. However, we are now forced to view the +network as a virtually infinite bit stream with no physical +delineations. It may well do to transmit a logical header and bit +count for each message as long as there are no errors along the line. +If, however, a bit is dropped, the problem of synchronization is +compounded by the fact that we have no ability to search for the +beginning of a logical message other than brute force. An error of +this type could be introduced by faulty host or user software/hardware +as well as the imp itself. This would involve the shifting of the +message bit by bit and seeing if the data looked reasonable. This +could certainly be time-consuming as well as introducing the +possibility of false synchronism. + +I can think of several solutions to the problem at the moment. None +of them seems to be very good. Upon losing synchronism, a user could +send some form of error message to the other host. The other host +could then in return cease sending and wait for a message to continue +from the troubled user. This would allow the troubled user to flush +out all waiting input. He would then be assured that the next bit +started a logical message. The problems here are in assuring +synchrony due to input/output buffering in the network and at both +hosts. How, for example, can the troubled host be assured he has all +the pending data? Once he is sure, he can then resume input assuming +all is OK. + + + + + [Page 1] + +Another partial solution requires the original restriction that +logical messages always start on physical boundaries. A user then +merely has to examine the beginning of each physical message to see if +it fits the pattern of a logical message header. This technique is a +lot safer than examining the entire input stream as well as being +quite a bit faster. + +I have not intended to suggest a solution to the problem, but merely +bring it to light. If we want to restrict logical messages to begin +on physical boundaries we must plan this early in the game. (It +probably works out that way in most cases anyway.) Other schemes can +be tried later. We must, however, face up to this problem fairly +soon. + + + + [ This RFC was put into machine readable form for entry ] + [ into the online RFC archives by Carl Alexander 7/97 ] + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + [Page 2] + |