B) "why can't" <- I did not claim they cannot... I stated that they don't (they don't even use the same frequencies in the air), and that even if they did, you wouldn't charge the same due to the QoS differences.
Text messages are an interesting one. Essentially, they cost nothing to the carrier in that they get transmitted as part of the control channel. However, there is a cost to supporting a phone idling on a network. The control channel has to be in communication with it using up bandwidth. So, the SMS gets put in with the control channel instructions and so its marginal cost is 0, but there's still a cost. Beyond that, your carrier has to pay a termination fee to the receiving carrier when you send a text message to them and that is a cost. So, when you send a text message off-network, there is a cost to your carrier.
Voice similarly travels a different path. In CDMA systems, the voice channel and data channel are physically separate. Even with UMTS where the voice and data traffic travels over the same channel, there have been significant advancements for data transmission (HSPA, HSPA+) that allow for greater efficiency.
Even with VoIP, a real distinction can be made. Like texting, the carrier of the receiving party charges a termination fee to the carrier of the calling party. So, if you're on Verizon and call a user on Sprint, Sprint charges Verizon to connect the call (http://en.wikipedia.org/wiki/Termination_rates). That means that while VoIP would use network resources in the same way as data, the carrier would face a higher cost because of the termination rate. This is also why many free VoIP services won't let you call those free conference call services (http://bits.blogs.nytimes.com/2009/09/25/att-says-google-voi...). They're usually set up with a carrier who charges an absurd termination rate that pays for the service.
While they are travelling through the same towers, they're taking different paths and those different paths do have different costs. Part of it is regulatory: termination fees are meaningful costs to carriers even if one considers them artificial. Part of it is the current time: in 3-5 years, we'll probably be on VoIP. Part of it is that data transmission (wired or wireless) has low marginal costs, but decent fixed costs: it doesn't cost the carrier much to support you as a marginal user, but they have put tens of billions into their network even if your phone just idles on it. Right now, wireless is priced in a "consumer" way. We don't pay for what we use, but rather some awkward approximation based on what they think consumers will accept charges for. This is in contrast to, say, utilities which usually have a fixed charge for being on the network (to cover fixed costs) and then a usage rate (which covers marginal costs).
I don't really have a conclusion. Carriers are trying to make more money off you in a way that's objectionable, but they aren't the same. I won't defend the pricing, but I want to point out the difference.
That was true at one point, but the popularity of SMS has completely swamped the capacity of the control channels.
I'm not at all familiar with GSM, so I can't say how it works. I expect it's similar, though.
The reason we want this to happen is the same reason the carriers don't want it to happen: it's a lot harder to make margins on being a dumb pipe.
Carriers will not voluntarily give up this incremental revenue. I live in Boston, when my choice of cable carrier are Comcast and errr... ummm.. Comcast.
Until there are more competing vendors, I think this transition away from arbitrary labels to one single dumb pipe will be much slower that we all hope.
1000 SMS * 160 chars * 2 bytes each (arbitrary) = 320000 bytes. Thats just 320KB. Thats cheap isn't it? Can you type more than that per day?
I've been trying to access the voice settings to modem-dial for a while, but I didn't think to (ab)use SMS this way.
Why T-Mobile only, though? In theory, you should be able to use this to talk to any SMS gateway, but you're going to end up paying on the gateway side ;(
Of the four major US providers, T-Mobile and Verizon are the only ones with MMS gateways (I use MMS to send the responses) that don't require a sign in by a customer (I only have T-Mobile myself). I tested Verizon's MMS gateway with my friend who has Verizon cell service, but it didn't seem to work for some reason.
The responses are sent back to the phone via MMS, in up to 5 (I think?) segments. I download the webpage along with all resources (stylesheets, images, etc.) and put everything in a zip file. I encode the zip file as a PNG (each RGB pixel is 3 bytes of the zip file) and send the PNG in the MMS.
I display a warning when the user tries to navigate to an HTTPS URL that messages sent to/from Smozzy aren't encrypted and it's not recommended that you proceed. I had a general idea for an encryption scheme (hardcode Smozzy's certificate's public key into the application and use it to encrypt a randomly generated string with each request and then send that encrypted string with the request and use the unencrypted string as a symmetric key to encrypt the rest of the request/response), but I was kind of too lazy to implement it for the initial release.
You are obviously welcome to block my domain/IP (not that I could stop you). I don't currently plan to expand beyond a single host. Even in the midst of all this coverage my single VPS seems to be working fine. Sorry in advance if I cause problems for you or any other admins...
The motivation behind the scheme I came up with is that it could be done with no pre-communication, hence why my RSA public key would be hardcoded into the client.
The png optimizers you see (optipng, pngcrush, etc)? What they do is carefully pick the optimum filters to get the best file size. So I'd say those filters were the most important part of the compression.
Probably not for long!
This is so impressive.
You'll be surprised about all the boxes that have been erected for people to think in, as soon as you have discovered the world outside the particular box you've grown up in.
Now, if only people at US T-Mobile saw your app the way I see it - an alternative way of accessing and browsing the web in cases of emergency - not only would you not get shut down, but you'd be given extra resources to develop this further, public praise on creative use of their services and so on.
Of course, if I was Verizon - whose service you say did not work - I wouldn't wait for T-Mobile to get their hands on you first. I'd contact you immediately and I would make sure Verizon's network worked like a charm.
There's ton of completely free PR to be gained here.
However, unfortunately I don't think emergency use when data services aren't up is a legit use case, since webpages are sent from my server to your phone via MMS and I think MMSes are downloaded via a data connection.
I hope it doesn't get shut down TOO fast. I think it has a chance since the userbase will probably be very small, since the number of people who have Android phones without a data plan with US T-Mobile is probably on the order of thousands...
Check this. If this is based on SMS/MMS, then I should be able to text you an address and have you return the pages as MMS.
You could fetch a number of pages at once and read the response even on a feature phone. This can also be combined with a web interface to bundle pages or feeds together and associate them with a shortcode.
Useful side-effect: if the OS crashes, your phone call will typically remain alive. (You probably won't be able to hang up without powering off, though, and definitely won't be able to dial another number.) Or, if you have an original iPhone 3G like mine that's sluggish at the best of times, it doesn't affect the phone call. :)
Never underestimate the bandwidth of a truck loaded with hard disks :)
Although to be fair, doing the backups took considerably more time - a usb external hard disk doesn't copy 1TB that quickly...
I can't help but wonder what kind of speed you actually get through that- would it be sufficient for day-to-day use, or just enough for a few patient page loads now and then?
For personal reasons, I do not browse the web from my computer. (I also have not net connection much of the time.) To look at page I send mail to a demon which runs wget and mails the page back to me. It is very efficient use of my time, but it is slow in real time.
Granted I'm just releasing this now, so if it gets any users at all we'll see how my cheap VPS holds up...
Let me know if you need a hand with hosting (VPS, dedi, etc). Don't worry about cost (no strings attached). Feel free to drop me a line at firstname.lastname@example.org
P.S: We've recently deployed a several 24-core SAS nodes so there's plenty of capacity to spare.
How is that possible? I thought the whole point of SMS was that it resided in the wasted bytes towers use when they "ping" phones. The reason text messages aren't instant is that these pings aren't sent frequently. I could be way out to lunch on my understanding, but this seems to be a latency killer (not to mention the limitations of packet size).