[Top][All Lists]

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

smarter seqno handling?

From: Osma Suominen
Subject: smarter seqno handling?
Date: Thu, 5 Jun 2003 23:03:39 +0300 (EEST)

Hi all,

continuing my crusade to find weaknesses in gnokii and writing reports
about them in the hope to inspire someone ;)

This time I noticed that handling of sequence numbers in gnokii is
currently suboptimal (IMHO). The problem is when messages have to be
resent because there was no ack or no reply message. This is done in the
sm_block*() family of functions.

When a message times out, it is automatically resent. However, when it
is sent again, the new message gets a new sequence number. I think this
is bad. One example where things can go wrong: if the send times out
because no ack was received from the phone, but the problem was that the
ack was corrupted, the phone actually gets two different copies of the
same message and may react twice. This can cause all sorts of problems,
like a storm of messages from the phone.

I've seen this a few times when testing the 3110: I do something with
command line gnokii, and then try it once again, and the first thing
that happens is that spurious messages appear from the phone. They were
requested by a duplicate message in the previous session, and the phone
keeps resending them until they are acked by gnokii - which only happens
on the second run, and then it can confuse gnokii.

I did some tests and noticed that when I leave a message from the phone
unacked, it resends the exact same frame i.e. keeps the sequence number.
I think the phone also ignores a frame if it has the same seqno as the
previous frame, but I haven't tested this.

I think there should be a way for the statemachine to tell the link
driver that the message is a resend and thus the seqno should be kept
the same. The link drivers may ignore it if that seems more correct.

On a related note, the link drivers probably should discard duplicate
frames i.e. those having the same seqno as the previous message. I don't
think any link drivers currently do this. I'll hack fbus-3110.c to do
this soon.


PS. The addition of sm_block_ack() to the statemachine has so far seen
zero replies (posted on Monday). I'd like to apply the patch, if no one
disagrees. Much of my recent 3110 work is stuck waiting for this

PPS. The charset encoding issue is also still unresolved. No hurry, but
just don't forget it... (mainly targeted at Pawel - hi there!)

*** Osma Suominen *** address@hidden *** ***

reply via email to

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