送信者: Ed Himwich 宛先: Ari Mujunen Cc: Tetsuro Kondo ; Alan R. Whitney ; Wayne Cannon ; Brent Carlson ; Dick Ferris ; Dave Graham ; Nori Kawaguchi ; Sergei Pogrebenko ; Misha Popov ; Jon Romney ; Ralph Spencer ; Ed Himwich ; JUNICHI NAKAJIMA 件名 : Re: VSI-S draft 2 日時 : 2001年4月5日 23:59 Hi, I realize we seem to have fragmented off into multiple tangential approaches and we need to regroup somehow. However, I wanted to finish one issue along a particular tangent (start of transmission characters) before I forget it. Ari Mujunen wrote: > I'd expect that the typical VSI unit will prefer to use Ethernet and > TCP/IP in the very simple TCP fashion, "telnet style". TCP guarantees > error-free delivery of command/response lines without any sequence > confusions. I.e. the very basic TCP "socket server" can listen and accept > incoming connections on an agreed TCP port number, and whenever a line of > ASCII appears, it can reply with another ASCII line using a pretty short > timeout. (As an aside: Is this correct, that TCP provides sequencing information between the two ends of a connection? It seems that although it provides a reliable connection, there is no sequencing, i.e. both connections just appear as continuous connections. Or is this enforced merely by having the server never reply until a command is received, then the next response must be associated with the oldest unreplied to command. That seems fine, but what is a time-out and how is it handled in this scenario? Does a time-out make the connection fail and you have to establish a new one, or do you now have a situation where you have figure out how to associate replies with commands again. Or perhaps you have to keep track of how many commands have gone unanswered and skip that many responses. If I am merely asking for remedial education in TCP/IP, please reply directly to me rather wasting everyone else's bandwidth.) > If we wish to define any additional safeguards for a RS232 or RS422 > implementation I think this is best left to be handled on top of the basic > underlying "line in, line out" mechanism. As Ed noted, on RS232 it may be > useful to have an unambiguous "start of line" character. It may also be > applicable to append a checksum and/or sequence number, but this should be > done only as to "emulate TCP" on top of RS232---perhaps we can actually > leave this undefined since I'd be surprised to see any VSI devices > appearing which do not implement Ethernet and TCP/IP... The use of the start of transmission character for maintaining sequence for RS232 is a little different than I suggested. For typical transactions the controller can steam along assuming that commands and responses are correctly sequenced. There is no need to wait for the DTS output to be quiet before each command is sent to it. However, if a time-out occurs or when the connection is initially established a synchronization (or re-sync) strategy is needed. Both commands that the DTS is in the process of sending a response for and additional commands that may be in the input buffer of the DTS are of concern. You can deal with this by having the DTS listen for a start of transmission character from the controller at all times, even when it is transmitting (presumably not hard to do for typical UARTs). If this character is received, it would cause the DTS to stop sending output, flush its input buffer, and then listen for new input. Then after the controller detects a (or two?) per character time-out in the output of the DTS, it can be sure that the DTS is waiting for new input. The controller can then flush its input buffer and start the next transaction with the usual start of transmission character. I think this is really quite robust. The addition of a check-sum would further enhance the situation by greatly reducing the probability that an incorrect command was received as a corrupted version of a correct command. As I mentioned in my previous e-mail the use of sequence numbers for retries is not robust in all cases. Unfortunately /R retries I suggested aren't completely robust either. The problem is that the case of a transmission to the DTS being lost can't necessarily be distinguished from a lost response. Suppose you send a status request (that resets the bits as part of its operation) and the response time-outs. You don't know if it failed because the DTS didn't receive it or the DTS's response wasn't received. If it failed because the DTS didn't receive the request then the following status with /R would return the previous (i.e. not current) response, which is probably not what is wanted. Two ways to fix this come to mind: (1) have some time-out for /R commands so that they are assumed to be fresh requests after some period since the last command of that form (and of course you have to be careful about what you do if that command hasn't been received since the last reboot of the DTS) or (2) separate the functions of resetting the status bits and returning their values into separate commands. Option (1) seems to me cumbersome and possibly error prone. On the other hand option (2) won't be useful if you have to know for sure whether an error has ever happened. However, that could be handled by having a status request return both the current value and the value that existed at the last status bit reset. Then I think we don't need the retry feature for this command at all. Are there any other commands that would need a retry feature? Maybe we can eliminate retries completely. Of course trying again after a time-out would conceptually be a retry, but there wouldn't be any special protocol for this. The "retry" would stand on its own as a (new) regular transaction. Ed