Kantronics KPC-4 - Page 23

Retries
AX.25
Level
2,
Version
1
vs.
Version
2
The
way
retries
are
accomplished
depends
on
AX25L2V2
being
OFF
or
ON.
To
A
this
we
will
follow
a
conversation
through
its
path.
First
lets
assume
station
|
T
connected
to
station
"B"
with
Version
1
protocol
(AX25L2V2
OFF).
When
station
se
sends
a
packet
to
station
B,
he
expects
to
receive
an
acknowledge
back
indicating
tha
station
B
has
received
the
information.
In
order
to
verify
that
the
proper
packet
(or
frame)
has
been
acknowledged,
each
frame
has
a
number.
This
number
is
sent
asa
part
of
the
frame
so
the
receiving
station
knows
where
this
packet
belongs
in
the
conversation.
The
frame
numbers
range
from
0-7
and
because
of
this,
we
are
limited
to
a
MAXFRAME
of
7
(we
do
not
want
the
same
frame
number
reused
in
the
same
transmission).
This
is
also
true
for
Version
2.
If
the
first
acknowledge
is
received,
there
is
really
no
difference
between
the
two
versions,
practically
speaking.
The
difference
shows
up
with
retries,
so
let's
assume
that
the
packet
did
not
get
through
on
the
first
attempt.
Let's
now
assume
that
station
A
sends
frame
number
3
to
station
B.
Station
B
does
not
receive
the
frame
and
therefore
no
acknowledge
is
received
by
station
A.
With
version
1,
the
entire
packet
is
retransmitted
(with
the
same
frame
number),
again
to
station
B
and
this
continues
until
station
A
receives
an
acknowledge
from
station
B.
This
acknowledge
can
take
two
basic
forms.
The
first
time
station
B
receives
frame
3
he
will
send
an
acknowledge
of
the
form
"ready
to
receive
frame
4”
<rr4>.
If
this
acknowledge
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
"T've
already
got
frame
number
3"
<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
dump
the
packet
into
the
air
UNPROTO.
(The
monitoring
of
the
commands
in
<
>
depends
on
the
settings
of
MRESP
and
MCON.)
Now
let's
look
at
the
same
conditions
under
version
2
(AX25L2V2
ON).
Station
B
does
not
receive
the
frame
and
therefore
no
acknowledge
is
received
by
station
A.
This
time,
station
A
sends
a
POLL
or
question
to
station
B
saying,
in
effect,
"did
you
receive
my
frame
number
3?"
<<RR3>>.
Since
station
B
did
not
receive
the
frame,
he
would
respond
with
a
"no
I
did
not"
<<rr3>>.
This
really
says
"I
am
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
acknowledge
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
and
if
no
response
was
received,
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
dump
the
packet UNPROTO.
The
parameter
RELINK
can
be
turned
OFF
to
avoid
the
reconnect
attempt.
In either version 1 or version 2 another interesting feature of packet is the ability
to automatically reestablish a connection. For instance, station Ais connected to
station B and has one frame outstanding. Station B disconnects without station A
knowing it (perhaps a power failure, double disconnect or even a timeout (retry count
exceeded)). The first time station B receives the outstanding packet from station A he
will send a disconnected message to station A. When station A receives this, station A
automatically issues a connect request to station B and the connection is reestablished
to pass the outstanding traffic.
PACKET 17
©
Copyright
1989,
Kantronics,
Inc.
All
Rights
Reserved.
A
Duplication
of
this
manual
or
the
firmware
without
Version
2.85
permission
of
Kantronics,
Inc.
is
prohibited.
Operations
Manual