Most of you are aware that iOS and Android use push notifications to inform the phone of any arbitrary event. I am interested in how one would implement such a server-initiated notification system. As the clients most probable use NAT, the server can't open a new TCP connection to them.
As far as I can see, the phone only has TCP and UDP connectivity. TCP uses keepalive to terminate the connection on the server after some idle time. Although keepalive can be disabled completely, that would expose the server to all sorts of DoS attacks by creating lots of connection contexts.
So I think there is some kind of timeout involved after which the phone re-establishes the connection. Additionally, if using TCP connection with disabled keepalive, how are changing IP addresses on the phone handled? Or does the phone establish a new connection periodically? What are the used timers?
Hope somebody knows a bit more about it.
UPDATE to clearify: I do not want to use iOS or Android Libraries (APNS or GCMS). I want to know how Google/Apple implemented it on the lower OSI Transport- and Networklayer (APNS and GCMS are Application layer or at least above Transportlayer). This is a very TCP specific question, that has nothing todo with iOs or Android programming.
Related
Is it possible to establish a TCP/IP session between two smartphones? I know that a smartphone can connect to a server, but cannot respond to connection requests.
Is there a protocol out there to somehow establish this? Its OK for a server to be involved in the initial handshake
I actually don't know any way to establish p2p connection here, but I think approach with the server in the middle should meet your expectations. it's called socket-connections, at a glance it looks like a channel, that hosts on a server side, and any clients (devices) can join this channel (two or more, whatever you want). If device send a message to the server, it should broadcast the message toward all other participants (it can broadcast the message even to the sender itself, but with some meta-information so we can distiguish our own messages and ignore them).
Thereby first of all you need server with socket connection established, then you can implement any of already existing solutions (e.g. https://github.com/daltoniam/Starscream for iOS). Also you may want to take a look at AWS https://aws.amazon.com, as it has the socket connection service out of the box for the server side and required SDK for both Android and iOS platforms.
Before ask my question, I want to let you know what stage I am on. I have already implemented TCP/IP socket on my android app, it works fine(so far...).The connection between client(my android app) side and server side is short connection which is when a user submit information, a new thread will be created to send the message out, on the server side, once the server got the message, the server will respond "RCVD", after that the socket will be closed and then the connection is closed. My app has a lot of interactions between user side and server side, therefore it does many connect and disconnect between clients and server, so I always worry about the socket communications will drain phone battery and the performance will be affected.
Recently I find OkHttp on github and a lot of people suggest using it. Im not quite familiar with Http, only knows it is a higher level network protocol.
Can anyone tell me which way is better? which is more efficient for exchanging data(Object/Json/String) and media(Images)? Which is more faster and which use less battery?
Many thanks.
Basically, the comparison between Http and tcp socket is meaningless, But in your situation it really matters.
As you described, in your tcp socket way, you may create new connection each time receiving new push from server, which is not that efficient, If you use OkHttp, when your client exchange message with the same server, the same tcp socket is reused each time rather than make a new one.
By the way, As for the push service, use XMPP(over tcp) may be better cause Http is not optimized for such short message exchange model(You should use some extra strategy on the server side to keep the connection from being closed), but you may have to handle some implements about XMPP server and client.
I have a situation where I want my computer in my local network to send a notification (push notification, SMS or whatever) to either an IOS of Android device that is on this same LAN. The trick is that I want to send this notification only when the LAN connection to the internet goes down. This means of course that my LAN cannot communicate with email servers, it cannot communicate with any APNs or GCMs, etc.
Is there any way to do this? My computer (the sender) is a Linux box and it will know the local IP addresses for any IOS or Android devices locally.
Yes this is possible.
You either need:
A) A server on the LAN to connect to, that the app knows about (compile-time or runtime configurable). The apps can connect to the server to exchange data, including messages. The server might be HTTPS, and the clients might poll every 5 seconds, or something more refined - using WebSockets.
OR
B) A peer-to-peer scheme. This can get quite complex, particularly given the varying nature of networking for mobile operating systems. As an extreme, you could use UDP for multicasting to multiple devices.
These are just two general examples, and you would need to research how to implement them for your needs. You should start with [A] for prototyping.
I'm building a multi-OS mirroring system which I would like to implement using a hybrid client-server and p2p communication method (at least that's the best way I have of describing it).
My issue is that at some point I have a central server (appengine, so there are limitations to what I could do because of time and networking capability constraints) that would need to get a message to a host of different devices which are not necessarily running the same OS (Windows, Android, iOS, Linux, etc...).
Android and iOS (or any other mobile platform) are the main problems it looks like I will be having on 2 levels.
1 - They are both limited by battery power (more so than a laptop and desktops shouldn't have that issue at all), so whichever method I use needs to take that into account.
2 - NAT (harder because the user has relatively less control over their firewall than on a network that they are running). My central server will maintain a table of which device has what IP address, but from what I understand if there is NAT or a firewall it won't be able to get to it if the port was not forwarded.
Since I will be writing a specific client for each OS I prefer a solution that is more universal. I have been leaning towards writing an extremely simple HTTP server that sits on each client and takes requests (which appengine is able to send) and treats them as messages that alert the client to perform an action (either with the server or another client). However, I run into the issue of NAT/firewall. For instance if appengine needs to send a message to AndroidDevice1 it would grab its IP address from a table and make a request to it. However this doesn't work if the ports aren't forwarded correctly, and if the user is on 3g/4g the firewall is controlled by the data provider.
Because of this, I started thinking about using Android C2DM but I want a solution I could implement across platforms.
The only other method I could think of is to just have the client poll the server for messages. This has the battery and network consumption issue though.
Would there be any other way to implement this, and if not, which one of the above methods are best in terms of balancing usability, power and data consumption and user input (the less the user has to do to get the client set up (ie port forwarding, etc...) the better)? Please note that I do not intend for this to become a discussion/flame war but a logical presentation of facts.
Thanks in advance!
You can create a persistent TCP connection from the device to the server and then communicate over this open connection. This would be a very simple connection with keepalive packets for the most part.
In theory this would consume some battery through the radio, but in practice I have experienced that the battery is not affected much at all. Key is to keep the communication over this line to a minimum.
If AppEngine does not allow this approach, you can run your own socket server and then communicate between this server and the appengine server using REST. A socket server I have used is Apache MINA and had no issues with scalability.
Another problem you will have with this approach or any other approach is that on iOS (afaik) you cannot keep a tcp socket open when the App goes into background. The only thing to communicate with the iOS device is Apple Push Notification Service
I would prefer rather than having HTTP Connection you should create TCP/IP tunnel and make communication fast and reliable. I have one Chat application which runs perfact for me using TCP/IP. If you use this you will have same logic for multiple platforms. Only thing you need to write is different code for iOS and android.
I'm in the early stages of writing an app that will need to broadcast data to several other devices.
My first thought was using an UDP broadcast, however according to both
http://code.google.com/p/boxeeremote/wiki/AndroidUDP and
Android 3G UDP Broadcast
he UDP will not be able to push through the NAT when on the mobile network
(which is essential for my app).
I know that i could either use a server to broadcast however i'd rather avoid generating to much traffic on my home server.
The last alternative that i can think of is having several tcp/ip connections and looping through all connected clients and sending the broadcast. But since I'm counting on having at least 30 listeners I believe this will be to expensive.
I do not have any broadcast associated code yet, that's why I haven't posted any;)
Is there a way to break through the NAT? Will the phone be able to handle 30 simultaneous tcp/ip connections? Or should i look into some other method of broadcasting?
Any hint would be greatly appreciated!
Kind regards
Johan Risch
:::::::::::::::::::::::::ADDED::::::::::::::::::::::::::::::::
I will be sending strings of length 10-20 characters once every 30-360 seconds
(will be controllable by the user) containing geo points in string format. The order in which the data will be sent is not important, that's why I thought of udp first.
I've set up my server so that when a user logs in he/she updates my database with his/her current ip.
Preferably i'd like it to work globally, but as long as it would work within the mobile networks in the same country.
That's about all the relevant information i can think of, hope this clears some things up!
:::::::::::::::::::::::::/ADDED:::::::::::::::::::::::::::::::::
The NAT doesn't pass UDP through because UDP has no destination address, so technically UDP has to be sent to all subnetworks of the network. When the network is your home LAN, it's no big deal, but when the network is your ISP or university backbone or cellular provider, the UDP could be replicated to hundreds of thousands of subnets. That's a packet storm that will degrade network performance for everyone, and it's massive overkill for your particular app since you really only want to talk to a small number of clients.
This problem has been solved many times already. Instant Messaging clients have a similar situation as yours: want to do direct P2P messaging when possible, through firewalls. How do they do it? The original NAT traversal / firewall traversal solution was to set up a message relay server. All clients talk to the server, and the server echos messages from one client to the others as appropriate. It works with NATs and firewalls because the client initiates the outgoing connection to the server.
If the clients are able to establish a peer to peer connection, then the relay server can just give the clients each other's IP addresses and stop relaying messages.
UPNP is a protocol that enables clients to request a firewall to open a port for incoming traffic. BitTorrent clients use UPNP to enable clients to connect P2P for file sharing. Clients find each other via the torrent server. Most home LAN firewall routers support UPNP now, but it seems doubtful to me that a cellular network provider would provide UPNP support for over the air connections.
Another (remote) possibility is multicast TCP/IP, but as I recall this is really optimized for "push" content flowing from the server to clients rather than client-originated peer to peer.
Your best bet is to take a look at the open source IM clients out there, particularly ones with Android implementations, and see how they're doing IM. Jabber is one that comes to mind, I'm sure there are others. You could even use an IM system's messaging API as your data transport layer and more or less stay out of the wire level details completely.