Re: statemachine flaws/weaknesses

[BORBELY Zoltan]

Hi,

On Tue, Feb 25, 2003 at 10:29:54AM +0100, Pawel Kot wrote:
> 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.

> 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. 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. But
implementing sm_block_no_retry_and_no_ack_retry and friends is an
unneccessary complication.

> really nice to have them working properly again), but I *do* care
> about atgen driver.
> 
> Try to send an SMS (quite long SMS, when the network is busy)
> with AT driver and the current policy. You'll get an error and a
> message sent twice when you have unluck.

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.

Bye,
Bozo