I was thinking about this the other day as a technical challenge.

Assuming their SMS system handles tens of thousands of texts per second, each of which needs to be tested against this user-definable dictionary of 1600 words, is it even possible for the platform to keep up? Are there sophisticated search / pattern matching algorithms for testing a message against 1600 substrings? I can think of a very naive way to do this, but I'm sure it would not scale.

How would one implement this kind of high-speed pattern matching??

If you have an older unit that needs service, Sony won't railroad you into a newer unit.

I recently sent in a 60GB backward compatible PS3 for repair (wouldn't power on). They gave me the option of a $129 repair, or for $99 I could swap it for one of the newer models instead. The Sony rep left the choice up to me but she definitely understood why I wanted to stick with the older model, in fact almost encouraged me to go that route (I would have anyway).

I paid the $129... they ended up swapping mine for another 60GB backward compatible console. I got my replacement a week after I shipped my old one. The unit I received looked brand new. It was shiny... clean... still had the vinyl cling film. It was a different serial number... but the same model number (CECHA01). It may have been a refurbed unit, but regardless, Sony definitely took care of me.

In what ways is it more complex to administer an email server vs. an SMSC? Have you ever operated an SMSC?

One big difference between email and SMS is the way that messages are delivered to the recipient.

With email, it is up to the client to pull messages from the server periodically. The server doesn't need to worry about the client being unreachable -- if the client is logged in, the POP3 / IMAP transfer is likely to succeed. Thus, the server doesn't need to do anything special to handle retries to millions of clients -- that is all handled client side.

Unlike Email, SMS uses a push model for delivery. The push model minimizes the use of the phone's transmitter, which helps preserve handset battery life. Also, server push allows for immediate delivery of messages (rather than waiting around for the client to log in a few minutes later).

The problem with server push is that it is difficult to scale it to handle thousands of messages per second / millions of oustanding messages, especially when the recipients are often unavailable to receive messages. Sure, a large percentage of SMS messages go through on the first attempt, but definitely not all. There are a number of reasons why SMS delivery might fail (handset powered off, poor signal, overloaded cell site or network, etc).

It is up to the SMSC to implement the retry mechanism. It must handle a large number of queued messages, destined for possibly millions of recipients. The retry mechanism must be effective, minimizing messaging delays. At the same time, it must not be wasteful (SS7 and control channel bandwidth are a finite resource). The carrier may incur SS7 network charges for every delivery attempt, successful or not. In other words, scheduling retries to maximize success, minimize bandwidth demands, and minimize delay is a difficult thing to get right. Blindly retrying everything in the queue every couple of minutes will not fly.

The server push architecture of SMS is one of the main things that makes SMS so much more complex than you seem to think it is. I don't deny that email can be surprisingly complex too, but SMS is far from the simple packet pipe that many people seem to confuse it with.