Re: 3110 statemachine handling (NEW patch)

[Osma Suominen]

On Tue, 25 Feb 2003, Christopher Kemp wrote:

> Ugh, what an annoying sequence!!
>
> Clearly one way of dealing with this is to do it in the phone code and not
> use sm_block (which in my eyes is perfectly acceptable).

This was actually my solution some time ago. I wrote a function
expect_message() which was used instead of sm_block() in this awkward
situation. But I think Pawel didn't like the solution and wanted it in
statemachine code instead. Both ways are OK to me.

>  If this is a
> common situation and we know in advance how many sms data packets to expect
> we could have a sm_block_queue function which is passed a (linked?) list of
> responses to wait for.  For the above this would be:
>
> - wait up to 100ms for 0x2c
> - wait up to 200ms for 0x27
> - wait up to 200ms for 0x27
> - wait up to 200ms for 0x27
>
> The list structure could even be augmented with a flag to indicate whether
> on not to start from step 1 if a timeout occurs.

AFAIK this awkward situation actually happens only on one operation -
requesting a SMS from the phone. And there may be between 1 and 3 data
packets, depending on the length of the SMS. The length can be decoded
from the header that comes first, but I don't think the link code really
should do that. (It happens the other way round when saving or sending
SMS's, with the driver sending a header plus up to 3 data packets for
the phone, but this is not a problem currently.)

In all other operations (at least those documented in
Docs/protocol/nk3110.txt) the 3110 gives one-packet replies so the
problem doesn't arise.

> However, if we don't know in advance how many data packets there will be we
> _have_ to handle things in the incoming phone code which can deal with
> things as it decodes the packets.

I think this is one of the right ways to do it.

But I also have another solution. Since the problem is that sm_block
waits for an ack unconditionally, it can quite easily be made to wait
for an ack only when a message has actually just been sent. This can be
seen from state->current_state. Here's a patch for current CVS.

Note that the problem of sm_block_many still resides, and also other
flaws/weaknesses in current sm_block code have been pointed out.

-Osma

Index: common/gsm-statemachine.c
===================================================================
RCS file: /cvsroot/gnokii/gnokii/common/gsm-statemachine.c,v
retrieving revision 1.44
diff -u -r1.44 gsm-statemachine.c
--- common/gsm-statemachine.c   21 Feb 2003 20:51:57 -0000      1.44
+++ common/gsm-statemachine.c   25 Feb 2003 20:18:27 -0000
@@ -227,6 +227,9 @@
                err = sm_wait_for(waitfor, data, state);
                if (err != GN_ERR_NONE) return err;

+               /* if no message has been sent, don't wait for ack */
+               if (state->current_state == GN_SM_Initialised) break;
+
                timeradd(&now, &timeout, &next);
                do {
                        s = gn_sm_loop(1, state);  /* Timeout=100ms */


-- 
*** Osma Suominen *** address@hidden *** http://www.iki.fi/ozone/ ***