4 ms·
A big problem to solve is that SMS is notoriously bad at delivery. You may have SMS's dropped for weird reasons, and delivery reports aren't exactly reliable.
by Systemic33 12y ago
A big problem to solve is that SMS is notoriously bad at delivery. You may have SMS's dropped for weird reasons, and delivery reports aren't exactly reliable.
- thaumasiotes 12y agoIsn't this notionally true of IP as well?
- bjackman 12y agoYes but delivery is guaranteed by TCP, which is the layer above IP. In this scenario, SMS is "above" TCP in the stack, so unless they add ACKs to their system (which would be pretty prohibitive when every text costs money), dropped SMSs would break their system.
- laumars 12y agoInstead of an ACK text, maybe an MD5 hash could be sent as part of the message. If the MD5 mismatches with the concatenated text message stream then you know you have a dropped or corrupted packet. Unfortunately that does introduce additional complications like knowing which packet failed (maybe there's a better method for checksuming for this type of situation?), but even in the worst case scenario, it only adds a small overhead to infrequently resend the entire stream than to double up each stream with ACK responses.
- inigoesdr 12y agoYou wouldn't want to use MD5 specifically because it would take up 32 characters of your message, but a simpler checksum might work.
- deleted 12y ago[deleted]
- laumars 12y agoMD5 was more a proof of concept than a design specification. However 32 characters is only 1/5 of an SMS so it's not beyond the realms of a practical (albeit lazy) fix. Ideally though, you'd be right that something more concise would be preferable.
- bjackman 12y agoGood idea - You'd also have to add a "length" header at the beginning. Otherwise if the final SMS (containing the hash) was dropped, you'd be waiting forever.