.....
> Well, I think if is for the retransmission handling. You can track the
> changes -- they were made in 1.40 version of the file (2003-02-11). It
was
> fixing the bug described in
> <http://lists.gnu.org/archive/html/gnokii-users/2003-01/msg00085.html>
> with the problems described in more detail in
> <http://lists.gnu.org/archive/html/gnokii-users/2003-01/msg00165.html>
That's right. Older phones responded quite slowly and we had two choices:
increase the retransmission timeout or implement a more correct retrans
policy. Increasing the timeout was a dead end: the communication was
slow like a hell. We noticed that the phone responds the command with an
acknowledge at once, so we transferred the simple retransmission scheme
into a two phase one. The first phase is to retransmit the command until
you got an ack. This timeout is quite small. Sometimes the phone responds
with an ack, but the final result get lost. This is the second phase:
repeat the whole first phase.
> I can't tell you at the moment from reading the code, why exactly it is
> correct, but I think Bozo will :-)
>
> > - if for some reason it doesn't change from GN_SM_MessageSent, it
retries
> > sending the last message (after a timeout) - but resending the
message is
> > never going to make the status change from GN_SM_MessageSent, so
seems
> > very pointless.
When the link layer receives an ack, it'll call
sm_incoming_acknowledge().
This will move the statemachine into the GN_SM_WaitingForResponse state.
If the protocol doesn't contain ack messages, the driver should call
sm_incoming_acknowledge() right after the send operation.