Attention is currently required from: pespin.
1 comment:
Patchset:
I'm not really involved into the big picture/roadmap regarding SMS, but I'd argue it makes more sens […]
From my experience in production and intensive testing of the smsqueue, I never have seen the scenario you describe and I believe it is extremely unlikely.
Anyway, if Bob is available when Alice sends "I'm late", but somehow or other "I'm on time" was not delivered, the latter will be queued and sent along with the former, (because the code I wrote will ensure to do that). I'm not "reordering" the SMS, I've explained at length in above comments where the delay comes from. What do you mean by "the specific subscriber"? Do you not mean precisely what I propose with this patch?
Do you want me to change it from:
WE just got an SMS for Alice. we dropped it in the database, the id is 5467, send SMS number 5467, now also look for other SMS for Alice and send them too.
We just got an SMS for Alice, we dropped it in the database, we don't care about the id, but we will now look in the database for all SMS for Alice and send them?
Sounds like the latter will keep you more happy, but it does essentially come to the same thing. OK, maybe, just maybe if Bob's SMS storage is full, but then he deletes one SMS, (and meanwhile, other relevant mechanisms fail, like notifying the network of storage availability) and then Alice sends "I'm late", then "I'm late" will be received first (and only) because Bobs SMS storage is now full again, so "I'm on time" remains queued. In your suggestion it actually works the other way round. Bob will receive "I'm on time" and never find out that Alice in late. So maybe the argument actually works the other way round. Is it not the MOST RECENT information that should have priority? Yes, on reflection, I think so.
Hmm. it becomes somewhat philosophical.
BTW, just to state it again, the delay problem is that Alice sends Bob "I'm late" and we drop it in the database and return to select(). we then go through this horribly complicated process of taking SMS from the database and putting them into the in-memory queue, and if there's enough SMS in there (for subs that are in the VLR) that cannot for whatever reason be delivered, then we simply WILL NOT get to Alice's message at all. And Bob get's nothing. He sits and waits at the cafe anyway, regardless of whether or not Alice is late... and well life somehow goes on and the world does not end, just like it was in 1980.
As an aside, SMS is simply NOT time sensitive. not even on commercial networks. There is ZERO guarantee of chronological delivery. It is up to the receiving UE to order the display of messages based on timestamps. I often have problems with 2FA not arriving before the sender has expired it. Or yes, indeed, as you say. requesting a 2FA, and not getting it, trying again, and getting the first 2FA which is now invalid and even getting to that point of 3 strikes. It's incredibly frustrating.
Anyway 2FA SMS should.. what's that hacker expression, "die in fire"?
To view, visit change 28342. To unsubscribe, or for help writing mail filters, visit settings.