gnokii-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: statemachine flaws/weaknesses


From: BORBELY Zoltan
Subject: Re: statemachine flaws/weaknesses
Date: Tue, 25 Feb 2003 01:10:56 +0100
User-agent: Mutt/1.4i

Hi,

I'm trying to summarize the reasons behind the current implementation.

There were some problems which I wanted to solve:
* The "moving and duplicating phonebook entries" problem. When the
  phone takes too long time to respond (it's more usual when you
  are using m2bus) the phone retransmits its reply. gnokii isn't
  able to suppress this message and it can cause a lot of very mystical
  problem. I managed to reproduce this bug: when I connected a 6110
  to a Sun with an mbus cable gnokii --monitor segfaults in a minute.
* The timeout was based on an iteration count instead of a pure
  time value. I think it interacted with the m2bus driver very badly too.
  m2bus will echo each sent character which caused a lost iteration
  from the timeout.

To solve these problems I implemented a better retransmit policy in
the statemachine. IMHO the link layer is a better place to retransmit
the unacknowledged frames but this algorithm is simpler and won't break
the last part of the layered architecture.

1) sm_message_send() sets the state to GN_SM_MessageSent
2) __sm_block_timeout() calls gn_sm_loop() until the timeout occures
   or state isn't GN_SM_MessageSent. It calls gn_sm_loop() to wait
   for the message.
3) sm_loop() calls the appropriate link layer function. If an acknowledge
   or a response frame received (depends on the link layer protocol) the
   link driver will call sm_incoming_acknowledge() function.
4) sm_incoming_acknowledge() sets the state to GN_SM_WaitingForResponse
   and returns.
5) __sm_block_timeout() will call sm_loop() again and waits until a
   response received or timeout occurs.

We cannot live with the previous implementation. It retransmitted the
message if there were no response in a given interval. It caused
duplicated responses which cannot be eliminated easily. This retransmit
policy should work correctly with the fbus or m2bus link driver. I added
the call of the sm_incoming_acknowledge() function into the other link
drivers but maybe not to the best place. If your (e.g. fbus-3110) link
driver don't support acknowledge frame you can move the call of this
function into the send frame function (it will disable this retransmission).

This modification eliminated the duplicated responses, but sometimes the
communication just stuck. The phone acknowledged the request but didn't
sent the response back. This is why I placed a second level retry function
into sm_block_timeout().

The current implementation isn't the best, but I think it's much better
than the previous one. We got positive feedbacks from users who hasn't
managed to run gnokii after the 0.3.x series (which didn't support
retransmission).

Bye,
Bozo




reply via email to

[Prev in Thread] Current Thread [Next in Thread]