XSF Discussion - 2018-07-22

Ge0rG, why doesn't your client know? Don't you do local accounting too, so that you compare the expected handled count with the reported handled count?

flow: how is it supposed to? There is no corrective mechanism in 0198. You can only detect wrong x counting in one direction, not the other

Ge0rG, right, you can only detect miscounting of the other party. But that means the other party can detect miscounting of you. And both parties should terminate the stream if they detect it. win?

Obviously only works if the other parties count is too large, while in Georg's case it was too low, no?

exactly what Holger says

flow, if you missed counting a few stanzas, you wouldn’t know (and the other party wouldn’t know either). you’d just assume that the most recent N stanzas were lost and you have to resend them

ok, that makes sense. But is the counter still off after the resend on resume?

but how would you know?

assuming that all stanzas arrive and that the consuming client counts properly

it cannot distinguish stanzas sent due to resumption and stanzas sent normally

for all it knows, it just got a bunch of stanzas which might or might not be retransmissions

does it need to distinguish?

to detect a counter which is off, I think so

well, my question was if the counter would be still off after the resend on resume assuming that all stanzas arrive and that the consuming client counts them properly

uh, I somehow misunderstood that

I don’t even know what I did understand

I'm trying to figure out if the counter will be off for an extended period, or if it will sometimes/usually heal after the resumption

but the main problem is a broken SM implementation, and those are always an issue (see SM in latest openfire)

flow, I guess this depends on why the counter is off in the first place. If it is off for example because the client miscounts during resumption due to a race condition, it would (still) be broken after resumption.

but yeah, the duplicate stanzas are, I think, a symptom of re-synchronising the counters

so unless the counter gets disturbed again during the resumption, it should be in sync

For the record, we disabled the SM implementation by default in Openfire, while the issue persists.

flow: after the other party receives a bunch of duplicates, the counters are "synchronized" again.

Now I have logs from both sides when it happens with prosody vs yaxim, and I'm sure it wasn't a change in yaxim, because I did some heavy log analysis when implementing SM

I blame Link Mauve, for mod_cache_c2s_caps

Oh?

How could that trigger c2s 0198 miscount? :o

Especially in this direction.

eating stanzas before they enter the stream but after they were counted?

Luckily the client never receives the stanza in question, and the server doesn't log c2s out.

So I can't prove it

And of course I meant mod_auto_answer_disco_info

that seems realistic