I'm trying to create an iOS application that sends data over UDP continuously over wifi/3G network.
I have an issue when I launch my app over 3G network after like 10 seconds I get this message :
sendto() : No buffer space available
It's not that a big deal because my app still works well BUT when I quit the app, I guess my buffer stays full because I can't use 3G anymore (I have to wait some time or reboot my phone)
Is there a way to flush this buffer before I quit my app ?
It sounds as if you're hitting the outbound bandwidth limit. If your app does this continuously while in use, isn't that going to make it very expensive for users to run? Most mobile users, I would guess, are on some kind of metered plan where they pay for transferred data.
I would guess that closing the socket normally before exiting should flush it first, since you've requested the data to be sent after all, but sometimes UDP sockets don't try very hard to deliver the data (since they are "lossy"), perhaps that's what's happening in your case too.
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.
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 need to receive data periodically through a BlueTooth External Accessory.
I implemented an event-driven model of EA's streams. However, the initial transmission from bluetooth is always delayed. For example, if each packet was 15 bytes long, the stream delegate would not fires until about 150 bytes.
Will polling help?
EDIT:
Also I found it hard to recover the session after the app switching back from background to foreground. Trying to open session again would fail. Any idea?
Read every bytes when NSStreamEventHasBytesAvailable arrives.
Did you develop your own Bluetooth accessory? May be the MCU only flushes after sending every 150 bytes.
Also you mentioned initial transmission. Do you know once the Bluetooth device is paired and connected to iPhone, it has to go through some identification process, handshaking some secret certificate. This may take few and even 10 seconds, depending on signal quality. This may be the cause of delay.
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.
Sometimes I am experiecing a delay while receiving APN , while at other times its working absolutely fine.
I am also connecting to the feedback server at ssl://feedback.sandbox.push.apple.com , but its not showing any data.
What are the possible reasons for the delay?
Thanks
Delay can happen if you've got a bad connection on 3G or Edge (iPhones use those, not wifi, for push unless they're totally unavailable). If the connection is dropped but the device doesn't know it, it'll wait until it does a heartbeat and realizes the connection is closed.
Also, if you're using an iPod Touch, the connection to the push servers will only be maintained while the backlight is on or you're plugged in via USB; otherwise the wifi connection will be dropped when the backlight goes off to save power, and it'll poll for new notifications every half an hour.