Re: sm_block_timeout

[BORBELY Zoltan]

Hi,

Sorry for the big delay, I'm quite busy these days... :-(

On Mon, Dec 06, 2004 at 10:59:18PM +0100, Pawel Kot wrote:
> On Wed, 1 Dec 2004, Christopher Kemp wrote:
> 
> > Can anyone explain the code for "__sm_block_timeout" in
> > gsm-statemachine.c?  I think it's changed from my original and it looks a
> > bit silly to me:
> 
> > *  __sm_block_timeout has an inner loops which "waits" for the state to
> > change _from_ GN_SM_MessageSent.  The only way this can happen is with a
> > call to sm_wait_for, which should have been called before sm_block.  So
> > this inner loop seems pretty redundant to me.
> 
> 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.

Bye,
Bozo