gnokii-users
[Top][All Lists]
Advanced

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

Re: 3110 statemachine handling (patch)


From: Christopher Kemp
Subject: Re: 3110 statemachine handling (patch)
Date: Tue, 25 Feb 2003 19:33:39 +0000

On 2003.02.25 17:54 Osma Suominen wrote:
> First of all, I appreciate Bozo's explanation for the reasons why the
> current __sm_block_timeout() does resending of unacknowledged frames.
> This is a complicated issue and I think we are only now starting to have
> the whole picture of the situation, not only from the existing and
> working drivers' point of view but also for the nk3110 and dancall
> drivers.
> 
> On Mon, 24 Feb 2003, BORBELY Zoltan wrote:
> 
> > We should try to call sm_incoming_acknowledge() function in the send
> > function of the appropriate link drivers. It will disable this
> retransmit
> > feature. If we won't retransmit unacknowledged frames in the fbus
> > and m2bus drivers, the moving and duplication phonebook entries
> problems
> > will reappear.
> 
> This is _not_ a solution for the 3110. The situation in which the
> retransmission of non-acked messaged breaks the 3110 driver is when the
> phone sends several messages in a row. Like this, when requesting a
> large SMS message from the phone: (ignore the asterisk for now)
> 
> -> 0x25 request SMS
> <- ack 0x25
> <- 0x2c SMS header
> -> ack 0x2c
>    *
> <- 0x27 SMS data #1
> -> ack 0x27
> <- 0x27 SMS data #2
> -> ack 0x27
> <- 0x27 SMS data #3
> -> ack 0x27

Ugh, what an annoying sequence!! 

Clearly one way of dealing with this is to do it in the phone code and not
use sm_block (which in my eyes is perfectly acceptable).  If this is a
common situation and we know in advance how many sms data packets to expect
we could have a sm_block_queue function which is passed a (linked?) list of
responses to wait for.  For the above this would be:

- wait up to 100ms for 0x2c
- wait up to 200ms for 0x27
- wait up to 200ms for 0x27
- wait up to 200ms for 0x27

The list structure could even be augmented with a flag to indicate whether
on not to start from step 1 if a timeout occurs.

However, if we don't know in advance how many data packets there will be we
_have_ to handle things in the incoming phone code which can deal with
things as it decodes the packets.

Regards, Chris



reply via email to

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