This weekend is barcamplondon, so another chance for me to ramble incoherently about a technical topic of my choice. 🙂
My presentation started as a bit of a cop-out. I was ill last week and weekend when I was planning to prepare a new presentation, so I decided to give the same talk I did at Over The Air last month and hope that I didn’t get any of the same attendees.
But then I started tweaking it to suit the different audience. Over The Air is an event for mobile developers, so my presentation was pretty much aimed at mobile devs, which wasn’t quite right for a general event like barcamplondon.
Then I started updating it to reflect the feedback I got, both on the day at Over The Air, and through comments and tweets since.
My talk at OTA was a technical “Introduction to MQTT” session.
My presentation for barcamplondon became a broader look at mobile apps that rely on data from the Internet, and the challenges and choices facing mobile app developers who write them.
And I think it’s better for it. I hope it didn’t come across as pimping MQTT. I still talked about MQTT, but this time it was to use it as an example of one of a broader set of choices:
- polling
- network-supported built-in push support
- e.g. iPhone, BlackBerry
- network provided SMS or WAP Push API
- intercepting incoming SMS messages using mobile OS API
- making an IP connection and leaving it open
- e.g. MQTT
The aim of the talk was to discuss the pros and cons of each approach.
I still reused a bunch of slides from OTA, so it was still a bit of a cop-out. But I’m glad I got the chance to revisit this nonetheless. 🙂
I’ve put the slides up on SlideShare. As always, they make next to no sense by themselves, but I did add some speakers notes which are included if you download the presentation file.
Tags: barcamplondon, barcamplondon7, bcl7, mobile, mqtt, push, push notification
[…] (24/10/2009): I revisited this presentation to address some of the feedback that I got on battery life implications of using […]
Hi Dale
I read your article on MQTT and enjoyed it and had a question for you. I saw that you had created an Android client and was wondering if this worked equally well for iPhone, J2ME and windows mobile clients?
thanks
Nick
I’ve done MQTT client stuff for Windows Mobile, and J2ME. Never tried iPhone, but I imagine it would be more complicated.
I have a question.
I think that the push notification using MQTT needs a lot of connection between mobile phone and server. For example, If 10,000 clients subscribe some topic, the server keep 10,000 IP connections concurrently. Is it correct?
Can the mobile carrier allow such connections?
If you mean – how does a server handle large number of concurrent clients? I believe that this is not in the protocol specification. Which means that this will depend on which implementation of the MQTT server protocol you use.
For example, I would imagine that the free, lightweight RSMB will handle this differently to the enterprise-scale WMB.
Sorry that this isn’t a very helpful answer – but if you have a particular server implementation in mind, I might be able to help get you an answer.
I’m not sure what you meant by “Can the mobile carrier allow such connections?” though.
Thank you for your reply.
I think that MQTT is push notification based on IP connection.
A lot of connection for notification will impose a heavy burden on mobile carrier.
So there is some doubt whether mobile carrier allow a lot of connection for notification. That’s my question.
Do you mean a burden if a large number of mobile subscribers all used an app that requires them to hold a connection open?
It’s an interesting point, but there are enough existing apps around that use this approach that I would hope that it would be okay. Would need to talk to someone from an operator to confirm that, though.
[…] written before about why you might want to do PUSH at all. And in this post, I’ve aimed at someone who has decided that they want to use MQTT on […]
Hi Dale,
I saw iphone, blackberry’s solution is under ‘network-supported built-in push support’, how is it different to the way of ‘making an IP connection and leaving it open’? how about Google’s solution?
thanks,
Harry
Hiya Harry
The IP stack that you use for emails, web browsing, etc. isn’t the only networking technology built-in to your mobile.
The best example is to think of SMS messages. Your phone isn’t getting text messages from a web service. It doesn’t have to poll an API call to see if you’ve got any new messages waiting for you.
It has a much smarter way that has been built into the spec of mobiles for years – a separate signalling channel that your network operator can use to push a notification to your phone. This is very efficient – your mobile, and the network it uses, is optimised for it. Waiting for incoming SMS messages uses virtually no battery, and is just a part of being connected to the network.
BlackBerry takes this kind of idea and extends it to email. Unlike general purpose approaches (which try and layer push-notifications on top of the TCP/IP connection which isn’t always-on on your phone) this is very battery efficient. The downside is that it relies on both your mobile and your network operator supporting the blackberry-specific signalling protocol.
Does that make sense?
Kind regards
D