There is no reason to discard anything in the queue. If you do, it's broken. I have in fact been told by my ISP something along the lines of, "Sorry about the emails not working, needless to say all emails will be held in a queue and delivered when we get the server up and running, no emails will be lost".
Why on earth would you think it better to discard queued texts than just deliver them all a bit late when your server is overloaded?
I've never heard of anyone losing one. And since I haven't it's clearly possible not to. If I lost a text, I'd complain to my provider. If it happened again, I'd change provider immediately.
AIUI apple messenger sends the message to an apple server over t'internet. The apple server then forwards it to the destination. I assume that if the destination is identified by an apple id it stays as apple messenger and if not it gets texted.
I would expect that apple messenger is more reliable than SMS as they should have designed it with an ack of some kind.
No, you are probably right, however, they can be used in the positive to suggest (assure?) that the message was at least delivered (couldn't you)?
I mean the chances of a message not being delivered and you getting a confirmation that it had would be fairly unlikely wouldn't you say?
So the chances of it actually being delivered and you getting a delivery confirmation would also be fairly trustworthy.
I would accept that you still might get the message delivered and not get the confirmation or not get the message delivered and (therefore) not get the confirmation. ;-)
In the instance I gave above (where I got a delivery confirmation 12+ hours later) is reasonable as I believe he often turns his (work) phone off in the evenings.
What do you think happens to and SMS/email when it arrives on a server just before it fails due to a hardware fault? Do you think there is some magic that recovers that message from the wreck?
That's just one example of how emails/sms get lost. For others look up SS7 signalling and look at the control channel protocols where you will find SMS signalling.
You might if you can't get a voice channel on your mobile or if you can't talk for some reason. The SMS uses the control channel and needs less signal to noise to get through so it may work when voice won't. You may not want the kidnappers to hear you talking so SMS would be a reasonable choice there.
Its OK to use SMS like that as long as you retry after a short timeout.
If you have no redundancy, your system is shit. Anyway that probably happens to 1 in several million texts. If it's more than that, your server needs modernising. And if the server doesn't send an ACK back, whatever sent it to it should retry or send a failed message back. Jesus Christ it's not rocket surgery.
I've had troubles with O2 to Orange/T-Mobile/EveryThingEveryWhere/EE or what ever they call themselves this week. Long delays or never being delivered.
Mobile phones are not reliable full stop. Not many cells have backup power supplies. Mains power off, cell is off and probably all networks so no "emergency calls only" on a different network.
Might not be too much of an issue in urban areas with a high cell density and a power outage from a single 11 Kv substation only affecting a small area. If a Primary Substation goes off (flooding?...) whole town and surrounding area is off.
Out in rural areas the coverage of a single cell can be huge and the only cell available. If that cell loses power those many miles from the local power loss don't have mobile phone service. That's assuming there is coverage even when the power is on.
Why do you accept shit excuses? If it loses messages, it's broken. Just because it was made poorly to begin with doesn't mean it hasn't been fixed since.
1 in several million is never to anyone without OCD. I'll never get hit by lightning for example.
Hint: do you send several million texts in your life?
Then it's broken. But funnily enough, that never seems to happen.
Oh and guess what, you get tell your phone to tell you if it worked or not, so clearly there IS an ACK.
And a system bewteen sender and recipient might also not be configured to pass on the *optional* headers requesting delivery/read receipt. And if they do so, they are still working perfectly *within the specification* .
All true. However I am very sensitive to SMS issues after working on a system which managed emergency calls for an energy provider. One day, a senior manager had a "great idea" that as well as emailing the relevant engineer (who had to log into the website to get his next job anyway) wouldn't it be a ^super^ idea if we also sent them a text ?
I agreed it was a nice feature, but noted how SMS was not guaranteed, and that explaining this to the Ops staff would be a challenge.
Fast forward a few months, and sure enough, Ops staff started logging calls about "SMS not received" along with grumbles from engineers that they "still had to log in, as the texts weren't getting through".
Luckily I had covered arse with a *massive* caveat in the spec. After we had wasted a few man-days "investigating" the missing SMSs, the SMS handler "broke" in an upgrade, and became unavailable.
They are probably still waiting for a fix.
Of course some posters in this thread probably think we should have changed provider every day :)
Way back when, before SMS was extant, one firm I worked for used a comms device (no idea how it worked) called "Cognito". It *was* reliable, and we had some fun in the office noticing the delay between message sent, received, and read.
HomeOwnersHub website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.