I am using PHP to connect to apns to send some notifications to multiple devices, although the question is more conceptual so it doesn't have to be specific to PHP. I will be sending to about 7000 devices (and growing) all at the same time. My process runs ONCE per day and broadcasts to all devices, so I am not constantly re-opening a connection.
open connection to apple
loop over device tokens
create payload aggregating all devices
end loop
write to socket ONCE with whole payload for 7000 devices
close connection
Can I do like above pseudo-code?
That is a correct approach but you need to check for APN Feedback and remove the "stale" devices. Apple will give you a list of tokens that they think are no longer valid. You should prune your database and never send to those tokens again.
Correct Approach here is,
you can open the connection.
perform as many writes as you like.
just make sure you check the connection status after each write
close the connection.
As each write is considered as a message specific to device, you can write one message at a time. But you can open a connection once and write as many you can.
Related
I have an Arduino based device interfaced to a 3G modem which I use to record data from several sensors in a remote environment. I would like to be able to send commands and stream some data from the device every now and then back to my standard network connected PC. If the remote device was connected to a WIFI or other local area network this would be relatively straightforward, but as the device connects over 3G this means that it is behind the 3G carriers NAT and so establishing a connection to the device becomes difficult.
The device can, of course, open a TCP connection to my host PC any time it wishes, the problem is telling the device when i want it to do so. I need some way of getting some kind of message to the device to notify it that I would like it to initiate a connection to my PC.
I've been reading up on NAT traversal techniques that app developers use to initiate P2P comms between 2 devices both behind NATs such as UDP and TCP 'hole punching' but this method seems rather too complex for my arduino system. Another general idea is to have the device polling a web server periodically looking for a signal to initiate a connection, but I'm not sure how much traffic (and data usage costs) this would generate as the device would have to poll every 10 seconds or so in order to make sure it initiates it's connection within a reasonable time frame of the request being set on the web server that it polls.
Is there any commonly used method of achieving something like this? Any general ideas or insight would be much appreciated
Thanks,
James
I think the solution will depend largely on your particular applications and requirements.
There are several ways to achieve this type of functionality and it looks like you have covered some of them already. The most common are:
have the device poll the server. This may be ok depending on the response times you need. If you need to poll as regularly as you suggest above then I imagine power may be more important to you than data rates, especially if you are battery connected. With a typical 3G data plan the polling itself will have a negligible data overhead, I would think.
have the server send a SMS which then triggers the device to contact the server. You need to make sure the SMS variable delivery time is ok for you and you also have to be aware that SMS delivery is not guaranteed so you would have to build in some sort of check for delivery at a higher layer (or into your application).
use some low cost Android based device for your 3G connectivity and leverage the Google push notifications mechanism
It is worth noting that server polling typically gets very bad press as it is seems intuitively wasteful to have the client and the server constantly checking for messages, especially when the actual messages are fairly infrequent. However, underneath most push solutions there is still a pull mechanism in the background, albeit generally a very efficient one that may, for example, piggy back on other messages between the network and the mobile device and hence have minimal power and data overhead. Personally, I would say that if you do not have major concerns with battery/power or with the load polling might generate for your servers, then it is worth exploring if the simplicity benefits of a polling solution outweigh its other disadvantages.
I'm using the sockets api to communicate with the Apple Push Notification Service, although I'm not confident I'm using it correctly...
I have an initialization function where I establish my connection to APNS. However when is the correct time to call Close() on the connection? Or do I just leave it open and keep reusing it?
Thanks!
Apple specifically request that you don't close the connection with APNS and keep reusing it as long as possible.
Keep your connections with APNs open across multiple notifications; don’t repeatedly open and close connections. APNs treats rapid connection and disconnection as a denial-of-service attack. You should leave a connection open unless you know it will be idle for an extended period of time—for example, if you only send notifications to your users once a day it is ok to use a new connection each day.
(Source)
However, Apple will close the connection if you send them invalid data (such as notifications with invalid device tokens), so your code must be able to detect that and create a new connection when necessary. You should also read error responses from Apple, since those responses will let you know if you should re-send some of the notifications after you re-open the connection.
That's a good answer from Eran but you may also check out java-apns-gae.
It's an open-source Java APNS library that was specifically designed to work (and be used) on Google App Engine.
https://github.com/ZsoltSafrany/java-apns-gae
From my understanding you cannot socket a connection between two iPhones (correct me if I'm wrong). So what I would like to do is have one server sitting between the client application that accepts messages and redistributes them to the appropriate person(s). Essentially the application is going to allow people to have a shared map that has their locations and everyone can annotate it.
1) I have been reading and researching into the CFStream class, but I'm curious to know if it might be better to just use the C send() and recv() functions. They almost seem much easier to use. What does CFStream offer over the native C socket functions that make it a better option?
2) Since I need the phone to actively listen for updated shared user locations/new annotations from other users, my plan was to periodically have the phone poll the server for any "news" from other users (say every minute or two). Is there anyway the phone could spin off a new thread in the application that is constantly waiting for incoming traffic? It would make life easier to be able to have a user annotate the map, push that to the server which then immediately updates the appropriate users maps.
I have been using example socket code from Jonathan Zdziarski's iPhone SDK book from O'Rielly Media to just try sending messages between a server and iPhone emulator (the classic knock knock joke server/client). However, after sending 1 or 2 messages the server gets stuck "receiving." The code runs perfectly when not sent from an emulator, as I can seemly spam the client send function and get a response from the server each time. Could the server be hanging because I use send() and recv() instead of the CFRead and Write stream?
You can socket iPhone applications using bonjour, or even GameKit (which is what I use because it manages all data for you).
I'm creating an application for a mobile device (Windows Phone 7) that opens a socket on a server.
Should I :-
Open the socket and hold it open for the application lifetime
Open and close on each request
I found this question IPC: Connect for each request or keep socket open? which is related but I wonder if the answer changes given the constraints on a mobile device
It depends.
If you don't need to hold the connection open to receive a message from the server then you may want to close it after you've finished using it.
You may, however, want to keep it open if you're making lots of requests in quick succession and the overhead of opening and closing the connection would cause an unwanted delay.
As a general rule for mobile app development is that you shouldn't use resources (including keeping connections open) for any longer than is absolutely necessary.
It depends on how your OS manages resources. If your app is the only one using the internet connection, then closing the socket could let the OS totally extinguish used network interface, which definitely will reduce power consumption.
Anyway, if you don't need to constantly send or receive something, I'd recommend you to close the socket.
I want to write an iOS app that can act as a client and a server to other iPhones over the cellular data network (i.e., without a typical centralized server). The goal is to share series of about 200 short event messages, one at a time, from the iPhone server to multiple iPhone clients by some means of notification. Apple Push Notification service would be fine for such notifications, but there is no need to use it specifically.
I think sending push notifications from one iPhone to another is possible by connecting to gateway.push.apple.com from the serving iPhone as described in the Local and Push Notification Programming Guide, but I can't find anyone else discussing this approach (maybe it's too obvious?).
The reason for all this is an attempt to avoid the overhead of infrastructure. If this isn't feasible, alternatives which minimize or avoid additional hardware are welcome.
Requirements:
Communication must be [strictly] over cellular data network
Wi-Fi isn't available
Bluetooth doesn't have enough range
Unidirectional communication with an iPhone server multicasting to many iPhone clients
No jailbreaking
Ideally the serving phone's battery will be able to handle this without a recharge
Update 5/4/11 2:12 AM EST: Just to be clear, I don't have any particular requirement to use APNs; I thought it may have been feasible in this setup, but from the discussion below, it sounds like that's not the case. However, I'm still interested in any other system that could help me achieve the same end result with some type of message passing or similar form of communication.
Theoretically you should be able to write a iOS app that can connect to the APNS and send notifications to other devices running your applications. However, your main problem will be to actually acquire the 'tokens' of other devices. When you have a centralized server doing the job, its always online and thus, the clients can 'talk' to it via http and register them self (giving their tokens to the server in the process). Thus the server knows the client token and it can use them to send notifications to the clients via APNS.
However this is not possible in the scenario you are talking about. But this is not to say its impossible. May be you could use an email account X, to store all client tokens. Every client will send a email to this account with their token in it. So when a another 'client' want to send a notification to another client, it can find out the token by reffering to the inbox of the email account (you can cache this stuff and optimize it in a zillion ways of course).
But the point is some how a (third party(ex: email service provider)/your own) server that is online 24/7 will be involved in the process.
Let us know how you progress with this. It would be interesting to know.