retransmission policy and the phone breakage (was: Re: sm_block_timeout)

[Pawel Kot]

On Mon, 13 Dec 2004, BORBELY Zoltan wrote:

> > > *  __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.

Bozo, this made me thinking. After chatting with leOn, who broke his 6100
with the serial connection, on irc I belive the retransmission may cause
problems. I think this is the only non standard thing we do during the
communication. My first shot would be what we did avoid on the first
place: always exit on timeout (either ack or the response). The behaviour
would be configurable in .gnokiirc with "exit on timeout" policy and long
timeout by default. What do you think?

take care,
pkot
-- 
mailto:address@hidden
http://www.gnokii.org/