gutman@manta.NOSC.MIL (Lewis M. Gutman) (06/21/88)
I am looking for information about the delta-t protocol. I've heard that it is used for real-time communications, not much more. I would appreciate any references. Thanks. Lew Gutman Naval Ocean Systems Center San Diego, Ca.
dennis@rlgvax.UUCP (Dennis.Bednar) (06/28/88)
In article <363@manta.NOSC.MIL>, gutman@manta.NOSC.MIL (Lewis M. Gutman) writes: > I am looking for information about the delta-t protocol. I've > heard that it is used for real-time communications, not much more. > I would appreciate any references. Thanks. There was an article published by Fletcher Watson about five years ago, but I cannot remember where. The delta-t protocol is based on the notion of timers being used for deciding when to do a new handeshake between a pair of machines. The idea is that if the sending machine has recently sent or received data, then the existing connection can be re-used. Otherwise, a new connection must be established, and this can be achieved simply by sending the data outright (it serves as a connection request). When the connection goes idle (neither side sends or receives any data for a period of time) both sides will implicitly close the connection, because the send and receive timers for that connection on both ends will expire. The Fletcher Watson paper goes into a lot of theory into using suitable timers so that this scheme will work. If I recall correctly, he states that the local machines send timer (for that particular pair of machines) must be twice as long the the remote machines receive timer. Each machine maintains both a send timer (for data sent) and a receive timer (for data received). The overall idea of the delta-t protocol, is that you don't have to do connection-opens (such as X.25 SABM-UA's, or TCP/IP SYN/ACK's), nor explicit connection closes (such as X.25 DISC/UA or TCP/IP FIN/ACK's). Rather, by implicitly using timers, you can achive the same results, at the expense of having more software timers. I have seen a software implementation of this, that was done at Mitre Bedford. Basically the protocol was as a link-level protocol over a LAN. It served as a reliable-retransmission protocol. So, in addition to the delta-t aspects of reusing existing connections, this implementation also did timeouts, retransmissions, used sequence numbers, expected ack packets (like X.25 RR's), and generated RR's in response to received data. As an example: No connection between machine A and machine B A has new data to send to B: A allocates a new connection-control-block. A sends packet to B, tagged as DATA, sequence number 0, DATA PS=0. A starts his send timer. A starts his retransmission timer (in case B does not RR it in time). B receives it. B sees that he has no connection control block, so he allocates one. B sends an ack (RR PR=1) to A, meaning B expects #1 next, in effect, acking DATA PS=0. B starts his receive timer (1/2 as long as A's send timer). B saves the receive sequence number of the next expected packet (1), this is so that if B receives a duplicate of DATA 0, B will ack it, but will not pass the duplicate data upstream. This can occur if the RR ack is lost. A receives the RR. A cancels his retransmission counter, and bumps his send variable to 1, so that the next packet sent will contain PS=1. No new data for a short period of time. B's receive timer expires. Since B's send timer is not running, B deletes his connection control block. [NOTE: The send timer is running when DATA has been recently sent, it does NOT apply to the sending of RR ack's.] A gets some new data to send before A's send timer has expired. Remember, A's send timer is twice as long as B's receive timer. So A sends DATA # 1 to B, starts his send timer, and starts his retransmission timer. B receives the packet #1, finds no CCB, allocates one, sends an RR PR=2 to A, and passes the data upstream, records that PS=3 is expected from A next time, and starts his receive timer. A gets the RR ack, and cancel's his retransmission timer. Neither side has any data to send to each other, this time for a long period of time. So B's receive timer expires first, and B deletes his CCB, since B's send timer is not running. A's send timer expires, and since A's receive timer is not running, A deletes his CCB. The connection has been implicitly closed down at both ends now. .... I could go on, but I hope you get the picture. -- FullName: Dennis Bednar UUCP: {uunet|sundc}!rlgvax!dennis USMail: CCI; 11490 Commerce Park Dr.; Reston VA 22091 Telephone: +1 703 648 3300