Re: statemachine flaws/weaknesses

[Ladislav Michl]

On Mon, Feb 24, 2003 at 09:07:44PM +0200, Osma Suominen wrote:
> On Mon, 24 Feb 2003, Pawel Kot wrote:

Hi Osma,

(sorry for previous mail, next time i'll try to be more precise and i'm
going to do it right now)

> > Anyway, these do not solve Osma problems yet. But that's
> > a big step forward.
> 
> Actually half of my statemachine problems would be solved by having a
> real sm_block_no_retry(). Not having one was the reason that I wrote
> expect_message() (though the real issue was not as clear for me at that
> time than it is now). So if the statemachine gets a function that never
> retries, I only need to add a sm_block_many(). It can reside in nk3110
> code if you don't want it cluttering gsm-statemachine.c.
[snip]

i vote for having it in gsm-statemachine.c. text bellow is only
suggestion how i would do it from scratch (and i'm ready to do it
myself if you find this solution reasonable - this should be post 0.5.0
issue and most of changes in driver code could be done without much pain).
final solution will be probably somewhat different...

following is true only if these assumptions are right:
  o there can be only one unconfirmed packet
  o phone will always reply with the same and defined packet order

from my current understanding QUEUE is a solution. having these functions
seems to be enough:
  1) sm_message_send     - we already have it :) [1]
  2) sm_message_send_ack - send message and wait for ack. this assumes
                           retransmiting when ack doesn't arrive before
                           given timeout expires
  3) sm_wait_for         - push expected message to queue
  4) sm_block            - block until all messages from queue are
                           received or timeout occures (in this case
                           queue is discarded [2])
  5) sm_block_no_retry   - do what name says
                           
[1] if sm_message_send or sm_message_send_ack is called and there are
some messages left in queue you have bug in code.
[2] if reply doesn't arrive before timeout (specific to message we are
waition for [2a]) expires sm_block will retransmit last message (acked
or non acked version depending on which was called last) and starts
expecting messages from the begining of queue, but only ones which
wasn't seen before are passed back to driver. queue is released after
all messages we were waiting for are received or retrying was not
successful.
[2a] phone drivers will encapsulate sm_wait_for giving it some timeout
value into driver specific function in phone driver level. i don't like
to see any default timeouts in statemachine. maybye would be better to
define timeout as "time of silence", ie time when no activity is seen on
link. this should also lead to faster responses.

i hope i din't miss anything (highly likely, i'm not too familiar with
nokia phones)

        ladis