送信者: Wayne Cannon 宛先: alan whitney ; tetsuro kondo Cc: 件名 : Comments on VSI-S draft document 日時 : 2001年3月10日 5:24 Dear Whitney-san and Kondo-san: The following are some further comments on the draft VSI-S spec from SGL in response to the comments from Dick Ferris. Please distribute them by the usual means and feel free to get back to us with any comments or queries. Best wishes, Wayne Cannon ******************************************************************************** >There appears to be no problem with the DTS reporting a checksum failure. >Since its exact cause in the line is unknown, no part of the line can be >acted on, and the controller will necessarily repeat the whole line, >whereupon processing resumes. Reporting the failure provides useful >information to the controller, and distinguishes the event from a true >timeout due to communications failure. We can accept having the DTS report a checksum failure, but that does open up a small amount of room for problems. For example, suppose a single command gets garbled so that it appears to contain several extra carriage returns. Then the DTS would send several checksum error responses, when strictly it should only ever send one or no responses. One possibility is to make the checksum error response optional -- a DTS could choose to send no response and still achieve fully correct functionality. >Note that the line parser cannot determine the identity of until it >finds an immediate . Otherwise these characters could be part of a >command. In the case of missing or corrupt the DTS must time-out, and >must do so before the controller gets bored and sends a repeat, since any >new characters must necessarily be appended to the current buffer and thus >create chaos. Right, this might be a problem. In the S2 RCL protocol it's solved by having both message-start and message-end characters, with the receiver discarding any incomplete message when it receives message-start. However introducing a timeout in the DTS receive side code might be tricky. We could accept not having any special handling for this situation (missing or corrupt ), the result being that two retries are needed instead of one. The first retry clears the partial message, the second retry gets through. >Omit Comments: disagree >- >The comment is a valuable tool in our environment as a means of injecting >information into the log file. This in turn is about the only reliable >means of making (DIM) operator's reports available at the DPS at >processing time. The most obvious example is the regular use of SNAP's >comment facility to report impromptu local editing of the PCFS command >file, and to report minor (and not so minor!) run-time disasters. Sorry, but we disagree on the disagreement... This statement seems to be at odds with the insightful paragraph on the role of VSI-S which follows. Comments might be an appropriate part of a command file format, but VSI-S is a control interface specification, so the concept of a comment is equivalent to a NOP (no operation) and is not needed. The analog in the world of SNAP is that while certain SNAP commands such as 'et' result in specific action over the MCB/MAT/RCL control interface, SNAP comments result in absolutely no action over the control interface as far as we're aware. The comments are only part of the file format, not the control interface protocol. >A significant number of suggestions to date (including some at the >beginning of this epistle) are actually aimed at facilitating direct >(manual) interaction with the DTS at the cost of complicating the >protocol, and as such might be better avoided. We agree, but any user-level support features which are easy to do and don't seriously impact the machine protocol should probably be left in. >The need for time flow control mechanisms such as 'act