Movatterモバイル変換
[0]ホーム
[RFC Home] [TEXT|PDF|HTML] [Tracker] [IPR] [Info page]
UNKNOWN
Network Working Group T. P. SkinnerRequest for Comments: 58 MIT Project MAC June 1970Logical Message SynchronizationAt the last network meeting, the question of logical and physicalmessage distinctions was raised. An argument was made in favor ofnever running two logical messages together as one or more physicalmessages. Another method of stating this is that a logical messagemust begin on a physical message boundary. This did not, however,solve the problem of locating the end of a logical message. A ratherpoor technique was suggested by myself which consisted of using thefirst partial physical message as an indication of the last physicalmessage of the logical message. This technique was thrown out for anumber of very valid reasons. The solution that seemed most pleasingwas the inclusion of some sort of a bit count or data typespecification to precede the logical message. Most everyone seemed tolike this even though it was stated in a very general way.As of this writing it appears that it is desired to completely severthe relation between physical and logical messages. This certainly isaesthetically pleasing. However, we are now forced to view thenetwork as a virtually infinite bit stream with no physicaldelineations. It may well do to transmit a logical header and bitcount for each message as long as there are no errors along the line.If, however, a bit is dropped, the problem of synchronization iscompounded by the fact that we have no ability to search for thebeginning of a logical message other than brute force. An error ofthis type could be introduced by faulty host or user software/hardwareas well as the imp itself. This would involve the shifting of themessage bit by bit and seeing if the data looked reasonable. Thiscould certainly be time-consuming as well as introducing thepossibility of false synchronism.I can think of several solutions to the problem at the moment. Noneof them seems to be very good. Upon losing synchronism, a user couldsend some form of error message to the other host. The other hostcould then in return cease sending and wait for a message to continuefrom the troubled user. This would allow the troubled user to flushout all waiting input. He would then be assured that the next bitstarted a logical message. The problems here are in assuringsynchrony due to input/output buffering in the network and at bothhosts. How, for example, can the troubled host be assured he has allthe pending data? Once he is sure, he can then resume input assumingall is OK. [Page 1]
Another partial solution requires the original restriction thatlogical messages always start on physical boundaries. A user thenmerely has to examine the beginning of each physical message to see ifit fits the pattern of a logical message header. This technique is alot safer than examining the entire input stream as well as beingquite a bit faster.I have not intended to suggest a solution to the problem, but merelybring it to light. If we want to restrict logical messages to beginon physical boundaries we must plan this early in the game. (Itprobably works out that way in most cases anyway.) Other schemes canbe tried later. We must, however, face up to this problem fairlysoon. [ This RFC was put into machine readable form for entry ] [ into the online RFC archives by Carl Alexander 7/97 ] [Page 2]
[8]ページ先頭