Re: smarter seqno handling?

[Osma Suominen]

On Fri, 6 Jun 2003, Chris Kemp wrote:

> All seems sensible to me.  Would be worth doing the test to check whether
> phones generally ignore a second message with recently used sequence number
> though.

I did some more investigation and it seems my 3110 indeed ignores
duplicate messages - that is, it acks them, but doesn't react with a
reply message (since it has already done that). However, this doesn't
apply to 0x15 init messages, which the phone will respond to in any
case. All in all I think the phone reacts very sensibly to these odd
situations. I decided that the fbus-3110 driver should be as sensible -
that is, keep the seqno intact when resending a message, and ignore (but
ack) received duplicates.

I figured out that there is actually a better way to keep the seqno the
same than to add a parameter to the send function in the link: only
increment the seqno when an ack frame is received. This way, if either
the sent message or the ack from the phone is lost, the resulting resent
message will have the same seqno as the previous (failed) one.

This seemed to work pretty well so I implemented it in fbus-3110 code
and committed that change today. Another patch I committed makes the
link code ack but ignore received duplicate messages, just like the
phone does.

The only problem is that when doing things like this, the phone driver
has to "collect" each incoming ack by calling one of the sm_block*
functions each time a message is sent. Otherwise the link code never has
a chance to read the ack from the phone (in the loop) and forgets to
increment the seqno.

As I've pointed out before, not all drivers call sm_block* every time,
for various reasons. If this kind of solution is used for other link
drivers (which I think would be a Good Thing, provided that the
respective phones are as sensible as my 3110), the phone drivers have to
be cleaned up a bit so they really collect all acks.

-Osma

-- 
*** Osma Suominen *** address@hidden *** http://www.iki.fi/ozone/ ***