71
Let‘s assume that station A sends frame number 3 to station B. Station B does not
receive the frame and therefore no acknowledgment is received by station A. With
version 1, the entire packet is retransmitted (with the same frame number) to station B
and this continues until station A receives an acknowledgment from station B. This
acknowledgment can take two basic forms. The first time station B receives frame 3 he
will send an acknowledgment of the form ―ready to receive frame 4‖ <rr4>. If this
acknowledgment is sent, and station A did not receive it, station A will again send frame
3. Since station B already received frame 3, he would acknowledge it with the form ―I‘ve
already got that frame, send me number 4‖ <rej4>. This is also known as Reject Frame
sent. This process would continue until the retry count is exceeded when, under version
1, the sending TNC will initiate a disconnect and discard the packet. (The monitoring of
the commands shown in < > depends on the settings of MRESP, MCON and MCOM.)
Now let‘s look at the same conditions under version 2 (AX25L2V2 ON). Station B does
not receive frame number 3 from A and therefore sends no acknowledgment to station
A. This time, station A sends a POLL or question to station B saying, in effect, I‘m
expecting frame number 0 from you; what frame are you expecting from me?"
<<RR0>>. Since station B did not receive the frame, station B would respond with
<<rr3>>, saying ―I‘m ready to receive frame 3.‖ At this point, station A, upon receiving
the rr3 would immediately resend the entire frame. If station B had already received
frame 3 once but the acknowledgment never got to station A the question from station A
for the retry would be the same. Station B‘s response however, would be different. He
would respond with ―ready to receive frame 4‖ <<rr4>>. If station A does not receive
station B‘s reply, this ―POLL/REPLY‖ sequence would continue for the number of retries
set in the sending TNC; if no response was received, and the RELINK parameter is ON,
the TNC at station A would then begin to issue connect requests to station B since there
is still an outstanding packet of information. This is the major difference between version
1 and version 2. The connect attempts would then continue for the number of retries set
in the TNC, and if no response was received from station B after all of the above, station
A would disconnect and discard the packet. The parameter RELINK is defaulted OFF to
avoid the reconnect attempt.
Flow Control
The flow control commands insure that the TNC gets everything that is sent to it by the
computer and that the computer gets everything the TNC sends it. When the computer
sends the TNC data, the TNC stores this data in a buffer until it can packetize it, send it,
and get acknowledgments. Similarly, when the TNC sends the computer data, the
computer stores the data in a buffer until it can be processed, stored to disk, sent to
printer, or whatever.
This buffer area is of limited size; if more data is sent than will fit in the buffer the extra
data will be lost. To make sure each device gets all the data it should from the other
device, the two devices can tell each other to start and stop sending data. This is called
Flow Control and it can be accomplished in either of two ways, via software or via
hardware.
Which way you implement this depends on the capabilities of your computer
communications program and personal preference. The cable between your computer
and TNC must also be wired appropriately.