[contingencies]

I wrote a trilingual one (Chinese, Korean, English) circa 2005 which allowed fuzzy search and directory services.

The main issues are expense, per-message character limit (which is based on your character encoding; note Unicode UCS-2 is super-wasteful vs. other alternatives), latency, and questionable inter-network reliability.

If you're in Alaska, honestly, if you're not really hard up for money just get a satellite deal like the sailors use, they're getting way cheaper.

Don't even begin to dream about forcing IP down SMS. You could do a batched shell service if really desperate, but it would verge on unusable and you'd likely get rate limited at some point.

[lukeasch21]

Could you elaborate on why UCS-2 is so wasteful? I think that makes sense on the surface level, but if you encoded a message using all the characters available in the BMP that UCS-2 provides then each character has tens of thousands of options rather than <125 with GSM-7. Considering the difference is a little less than half (70 chars per message vs 160), with the right encoding, shouldn't UCS-2 be much more efficient? Or is it not possible to encode data like that?

[contingencies]

Can't recall specifics but I think I compared some languages (maybe an abugida like Thai) with UCS-2 vs native encodings and found UCS-2 was smackdown terrible. iconv is your friend for this. If you want efficiency skip charsets and use a binary PDU. Most phones with AT command sets used to support this. All GSM modems support this. These days, I am unsure if you can get a low enough level API to a smartphone to send and receive binary PDUs. I guess probably somehow, at least on Android, at least with root, but it's almost certainly a hassle.

[lukeasch21]

Good point. I was looking into a way to maximize efficiency on Android without low-level access (no root necessary), so I'm pretty much limited to the charset that I can receive from the Android APIs for encoding binary data into (36864 chars). I was wondering if even the limited character set offered by an Android SMS receiver would still be magnitudes more efficient than the standard GSM-7 character set for encoding binary data, even though the amount of characters is less for each SMS. I'm having a hard time understanding if I'm oversimplifying things by just looking at the ratios 160/128 to 36864/70, in which case I would assume there would be huge benefits to encode data with UCS-2 instead? I haven't the slightest idea in how to accomplish that, maybe iconv would be useful as you mentioned? That is something interesting to consider though, dedicated hardware could easily take advantage of UCS-2 and encode binary PDUs to the point where you could achieve a somewhat respectable speed for TCP over SMS. Though by that point, I would assume SMS throttling would be a much larger concern so any benefits are mostly theoretical.