送信者: Alan R. Whitney 宛先: B Carlson ; Wayne Cannon ; Dick Ferris ; Dave Graham ; Nori Kawaguchi ; Tetsuro Kondo ; Sergei Pogrebenko ; Misha Popov ; Jon Romney ; Ralph Spencer ; Alan Whitney ; 件名 : Re: Strawman VSI-S spec 日時 : 2001年2月21日 7:46 Gentlemen, Included below is the first two responses I have had (coming within minutes of one another!), from Brent Carlson and Crestech, regarding the draft VSI-S I floated last week. I have taken a crack at a common response to the concerns and questions they have raised, and would be interested to hear from anyone else with comments. Thanks, Brent. Thanks, guys at Crestech. Regards, Alan -------------- A. Whitney's responses to comments and suggestions by Brent Carlson and Crestech: - 1. Communications Reliability Both set of comments address the issue of communications reliability and suggest a similar approach to increasing robustness. The folks at Crestech suggest a specific extension to the draft VSI-S syntax which looks good to me. I also agree that it should be possible to enable/disable the serial#/checksum as needed. The suggestion to 'discard the data and wait for a retry' seems well thought out and reasonable, as well. - 2. Unsolicited Responses I must admit I struggled with this one, so am glad to have some other input. I have no problem adopting the Crestech suggestion to eliminate unsolicited responses. - 3. Comment Handling Crestech suggestion OK with me. - 4. Multiple Commands Crestech suggestion to limit to 4096 command bytes total before a seems reasonable to me. - 5. Additional Standard Command Keywords Both Brent and Crestech bring up this issue. Crestech suggests adding 'ident' and 'version' queries, as well as a 'diag' command for a POST. Perhaps should be added a unit serial number query ('serial_num?'). Brent suggested adding a 'media_type?' and 'media_ID?' queries. I had not included these because they are DTS-specific ('media ID' may make no sense in a real-time link, for example), but it probably good to include them a part of the VSI-S set. Brent also suggests a 'station_ID' query. This may be a bit more complicated since there is no requirement that a DTS know anything about station ID or that it be in any specific format if it does. Some DTS's may only know their serial number, for example. Suggestions? - 6. Position command This is another one I struggled with. At first, I thought along the same lines as Brent. But the more I thought about it the more complicated and DTS-specific it became, so I just sort of punted. For example, real-time recording time can have a problem if the data-rate changes during the session, which is allowed by some systems. Another possibility is to specify a byte position, but that also can become problematic in some systems since it may also be dependent on past mode history. So I finally decided that each DTS should simply report its position in some integer units that make sense to it (could be time or byte position or footage or whatever). This seems satisfactory to me because these positioning numbers are really just for media positioning and don't necessarily have to have a common unit from one DTS to another. Therefore I would argue to keep position as defined, without even specifying the meaning of zero, though zero could mean beginning-of-tape to certain DTS's. - 7. Ethernet Control Port Number Crestech suggests assigning a 'standard' port number to use with VSI-S. OK with me. Any other opinions? - Alan - ----------------------------------------------------------------- - At 01:12 PM 2/20/01, B Carlson wrote.... >Hi Alan: > >I've had a chance to look at your first go at the VSI-S spec and, for better >or for worse, here are some initial comments: > >1. The syntax of the communications protocol does not appear to contain any >error checking. This seems a bit dangerous to me since it could me that the >commandee may unwittingly execute bad commands and the commander may get bad >responses. Perhaps something like two hex digits (encoded as ASCII) just >before the ending semi-colon that are a checksum of all of the preceeding >characters in the command/response? I know that if this is done it will not >be possible to enter commands by hand using a VT100 terminal, but it should be >possible to produce a terminal emulator that calculates and inserts these >characters when someone types in the semi-colon. > >2. If error checking is implemented (like in 1. above), what happens when a >receiver detects an error? Does it ignore the message? (probably...what else >would it do?). If this message was a command and the initiator is expecting a >response, how long does it wait before it sends a repeat command? (or, does >this even need to be in the spec?) > >3. In the DOM commands, should there not be a query that allows the DPS >(correlator) to determine the media id (i.e. tape ID)?, as well as station ID, >and things like source ID etc.? > >4. Can it just be stated that the position command use standard units such as >real-time (UT) recording time since BOM (beginning of media?), or is that too >restrictive? > >5. I think there should be some DOM command (and DIM command) that allows the >DPS (and DAS) to determine what it is connected to. This will allow the DPS >(and DAS) to execute (a richer set of) machine-specific commands that are not >within the VSI-S specification (except that the command/response syntax would >be the same as VSI-S). This allows more generality in the machines that can >be supported in the future and makes the VSI-S spec less restrictive and less >prone to having to be updated to support some new machine's requirements. > >I hope these are constructive... > >Regards, >Brent. - ----------------------------------------------------------------------- - At 03:24 PM 2/20/01, Wayne Cannon wrote.... - Here are some comments from SGL on the draft ``straw man'' VSI-S specification. Please feel free to get back to us with any comments or queries. Best wishes, Wayne ******************************************************************************** VSI-S COMMENTS General Comments We like with the overall VSI-S design. It does a good job of remaining generic while incorporating elements made necessary by the VSI-H specification. We also agree with the idea of an ASCII protocol, which makes debugging and testing easier. - Protocol Reliability - Our main concerns relate to protocol reliability. There is currently no checksum mechanism to ensure that commands and responses have been received correctly. This is important mainly in the case of RS232 control connections, although it might also be important with socket connections in the event of broken connections or other unusual socket behaviour (any experienced socket programmer has seen plenty of this). - A suggested solution is to add an ASCII checksum character which is located before the but after the (last) semicolon. To maintain the spirit of ASCII-only, the checksum must a printable ASCII character from 0x20 to 0x7E. It can be a simple additive checksum calculated by summing all the ASCII values of the preceding bytes and then calculating: ((sum % 0x5F) + 0x20) where % is the modulo operator. We might want to exclude some special characters from the allowed set, but more possibilities is better in the case of checksums. - Action on bad checksum: According to data communications theory the safest action to take when a bad checksum is detected is to discard the data and wait for a retry. In our case we discard everything up to and including the character. The reason for this is that the extent of the data loss is not known, so we can't reliably return an error saying "the checksum was bad". For example suppose it was a semicolon, or the character itself which was garbled, then we don't even know how many commands have been received and thus how many error responses to send. Another reason "discard-and-wait-for-retry" is better is that the lost/garbled data could have been the response itself, in which case the command was executed but the client side doesn't know the result. Note that both the server and client discard anything with a bad checksum, and the client retries the command after a specified timeout period. Exceeding the maximum allowed number of retries means that the server is "dead", or the connection has been broken. - This brings up another "pathological" situation to avoid: the case of repeated non-idempotent commands. Examples of non-idempotent commands include status reads that result in status conditions being cleared, or incrementing/decrementing quantities. If such commands are repeated via retries then double execution is possible but undesirable. To solve this problem we must also include a sequence number along with the checksum. This is simply an ASCII byte value that increments by one for each new command, but stays the same on retries. The server should ignore multiple commands with the same sequence number (the response to the client uses the original sequence number). Therefore we end up with a revised command/query/response syntax as follows: - - Where and are the sequence number and checksum (both in the range of ASCII values 0x20 to 0x7E). To allow for easy manual testing, a command should be provided to enable and disable checksum/sequence number checking, for example keyword 'cscheck' with values 'on' or 'off'. We also need to define a timeout period and maximum number of retries. In the S2/S3 RCL protocol we normally use 0.5 seconds timeout and max. 2 retries, although some commands allow a longer timeout. Note that certain commands should be exempt from automatic retries, specifically commands which contain information that is time-sensitive -- for example time setting commands like 'dotset'. If such a command fails it should be resent by the user or higher-level software with an updated time value. - Unsolicited Responses - The straw-man VSI-S protocol allows unsolicited responses from the server to the client. For example, delayed completion responses, unsolicited error responses, and periodic responses. We feel that unsolicited responses should be avoided. The main reason is that it is difficult to ensure that unsolicited responses were properly received by the other side -- there is no "backwards" error return mechanism and putting one in would be clumsy. Also eliminating unsolicited responses is more in line with client/server philosophy, since the client is not obligated to listen to the server except immediately after a request is initiated. A simple way to work around this issue is to use the empty command (just ) to "trigger" the next unsolicited response to be returned. If none is available then the server still sends a response indicating this (for example a new VSI-S return code 3 could be used). Using the to trigger unsolicited responses still allows relatively easy viewing of such responses under manual control of the VSI-S link. Another possible approach (used in the S2) is to return this kind of information (delayed completion, unsolicited errors) in response to a periodic 'status' request. We in fact distinguish between error codes and status codes, where error codes are conditions which result immediately from a command and status codes indicate delayed actions or problems which are not connected with a particular command. The key is that there is a one-to-one correspondence between messages sent to, and messages received from, the server. A final, additional advantage of eliminating unsolicited responses is that it allows the communication channel to be half-duplex, and makes it possible to control multiple devices on a common channel. While this is not needed for socket or RS232 links, it at least doesn't rule out multi-drop links. - Some of these points may seem like nit-picking, but we have found it very valuable to design a robust, reliable protocol from the outset. - Comment Handling - The handling for comments described in section 4.3 seems a bit unnecessary. It is probably better to eliminate comments before they are even transmitted. Then they are simply not part of the protocol, just part of the handling for prepared ASCII command files. We should make an important distinction between the VSI-S protocol, which is a machine-to-machine protocol, and any user-level interfaces that derive from it, such as prepared command files. The command file syntax could be made nearly identical to the VSI-S syntax, but it would have certain important differences: -Comments and possibly other "readablity" extensions allowed in command file. -No checksum/sequence number in the command file. - In any case we feel such a command file definition is outside the scope of the VSI-S document. - Multiple Commands - In Section 4.4 on multiple commands, it states that "Any number of commands/queries may be concatenated in this manner". In the interest of limiting buffer sizes we should probably specify a hard (but generous) limit, say 4096 command bytes total. - Additional Standard Command Keywords - We suggest the addition of these commands which should be standard on all systems conforming to VSI-S: - Keyword Function ------- -------- ident Returns a device type string so that the client can recognize the type of device it is talking to and perhaps also adjust its command set for DTS-specific features. Example response: 'S3-REC' version Returns a software version string from the device, e.g. ROS version 3.2c [162] (compiled Wed Jul 19 15:17:49 EDT 2000) diag Initiate self-test (POST or other standard internal test sequence). Useful to run or repeat the self-test, if available. - Position Command (6.1) - We suggest defining parameter value 0 to mean rewind to BOT (beginning of tape) in the 'position' command. - Ethernet Control Port Number (5.2) - Yes, the VSI-S spec should suggest a "standard" port number to use. Port number assignments are handled by the Internet Assigned Numbers Authority; check at http://www.iana.org/numbers.htm under 'Port Numbers', which has links to both a full list of all currently assigned port numbers, and the application forms for new numbers. We would want a 'user/registered' number for this in the 1024-49151 range. Ports from 0-1023 are for system or well-known protocols and require a full standard submitted to the Internet Engineering Task Force, while ports 49152-65535 are reserved for dynamic allocation or private purposes. Some systems use everything from 32768 on up for dynamic purposes, so the 1024-32767 range would be best. There are still plenty of unassigned numbers in that range. Note: The S2/S3 RCL link uses port number 1025 (not registered with the authority), so that number should be avoided.