[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: statemachine flaws/weaknesses
From: |
Pawel Kot |
Subject: |
Re: statemachine flaws/weaknesses |
Date: |
Tue, 25 Feb 2003 14:41:39 +0100 |
>>> 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