Re: statemachine flaws/weaknesses

[Pawel Kot]

>>> address@hidden 25 February 2003 13:47:21 >>>
> > Sorry, I don't buy it. If I understand you correctly, you say that
> > phone sends the reply twice when it takes too long because we
> > retransmit the request. Am I correct? If so we set *incorrect*
timeout
> > value in the initial request.
> 
> Ok. And what will be a correct timeout value? 3 seconds? 5 seconds?
> 1 minute? If we increase the timeout value it will slow down the
> communication badly when you lost a frame.

It should be defined in the caller, so it may vary between various
frames.

> > But I agree that some retransmission schema is *required* but at
the
> > moment it is *unconditional*. And that's *bad*. Probably the fbus
> > and mbus drivers do need it. But other link drivers (atbus for my
> > knowledge so far, and 3110-fbus and cbus according to Ladis and
> > Osma) do NOT need it. Moreover they are broken with such policy.
> 
> AT can use it if it want. I think moving the sm_incoming_acknowledge
> to a better place is the best solution. If you move it into the send
> function of the link driver you will get back the original
retransmission
> method.

No. Every driver waits for ack. There's no need to move them to the
link
layer as it would result in the code duplication.

> If you don't like it we can use Chris's solution to introduce
> a boolean variable in state which is set by the link driver.

I like the Chris idea but not with the boolean value. Se can stick
with
just one sm_block() function. Retrying with no ack or no answer would
be done internally depending on this variable mask.

> But implementing sm_block_no_retry_and_no_ack_retry and friends is
an
> unneccessary complication.

But there's no need to do sm_no_retry_and_no_ack_retry() or whatever.
What I want to do is get rid of all these similiar functions.

> Moving the sm_incoming_acknowledge into the appropriate place is a
two
> line modification and in this case sm_block_no_retry() won't cause
> any retransmission. The problem is that we should move the
retransmission
> engine into the link layer but it's a big move, which can be a 0.5.0
> thing.

Agree partly. The proper fixing is post 0.5.0 issue. But I really think
we can
fix it for now in a neat way.

pkot