I have an iPhone on a 3G cellular network and a server on the internet and I want them to be able to exchange messages bidirectionally. Sometimes the iPhone makes a request to the Server some other times the Server makes a request to the iPhone. Problem is that the iPhone is behind the NAT of the cellular network and it doesn't have a fixed ip:port , on every new connection the port changes.
I think I have to make a bidirectional socket SO_REUSEADDR/SO_REUSEPORT and make the connection persistent.
The other two solutions are Apple's Push notification and long polling, for now I need an answer for the P2P solution between the iPhone and the Server.
Can you advise me on what I have to do or provide me a working example code where an iPhone can receive messages from a host that is on the internet?
It is a pity that Java is not supported on the iPhone, because the JXTA framework would have solved your issue easily.
What you are looking for is a TURN like implementation of P2P. The Iphone has to initiate the connection to the server to punch the hole in the NAT and yes, it has to be kept alive (even if you investigate more sophisticated implementations like STUNT for NAT traversal).
With TURN, the server has to transmit messages between IPhones, with STUNT, messages are transferred directly between devices, but it is quite complicated to implement properly.
i've been doing a lot of reading up on these things and my understanding is that XMPP is the solution for you. use an open source XMPP server (like openfire) and XMPPframework (an ios module).
Related
There are some ios sip applications who are able to communicate with a UDP only SIP Server.
As I know iOS allows only TCP connection to remain open in the background but most of the SIP providers are supporting only UDP.
I have noticed that iOS application 3CXPhone has a "NAT helper mode" and it is able to keep the communication in background with a 3CX Phone system who is UDP only. Dose anyone know what trick do they use? I am developing an SIP app and I have to make it work for the UDP only SIP providers.
I know there are multiple questions regarding UDP socket in background on SO but none of them has a useful answer or the solution proposed there dose not work anymore (starting from iOS 6).
Until now I am aware of 2 possible solutions:
1. Use some GPS events and during that events maintain the socket communication too. After that try to trick apple and get your app in the store.
2. Use a SIP proxy in the middle (B2BUA). But in the 3CXPhone "NAT helper mode" I am not seeing any sip proxy configuration.
If you really need a UDP socket you will need a few things:
UIRequiresPersistentWiFi: to ensure that iOS connects to Wi-Fi and doesn't turn it off after some time (I'm assuming you want Wi-Fi as well, if not just ignore this one)
Play an empty audio in the background in a loop to keep your application active.
Have a timer that pops every ten seconds or so and sends a small (e.g. crlf) message to the server.
The last step is needed to keep the UDP connection open in the network. If you don't send anything often, someone in the network (e.g. a router) will close it.
The empty audio file is the only way to ensure you can do something in the background in short intervals (the ten second timer).
After writing all that: this will consume a lot of battery. Users will not leave your app running for long.
Most modern SIP servers support TCP. You should really spend your time on a TCP solution. The UDP one won't be accepted by your users.
Can anyone tell me, is it possible to create an iPhone chat app without using a server. I just need only two connections.
I guess it would be possible by the two devices have to be directly connected (i.e. bluetooth, wifi, etc.). They may therefore discover each other (at an application layers i.e periodically broadcasted UDP packets on a give port?), create a tcp connection (or UDP but in this case you should ensure at application level all the sent messages are actually received..) on the top of which the actual chat protocol can be realized
I am implementing an iPhone/iPad app that allows users to send each other messages using the bonjour protocol. Basically, a server publishes his service over bonjour and the clients connected to the same wifi can discover his service and connect to it to start sending messages. The problem I've found is that some routers seem to have problems with Bonjour. When running my app at home or at some other places it works perfectly. The publishing and discovering of the bonjour services works flawlessly. However when I tried my app at one of my friend's apartments, some (not all) of the clients were not able to discover the published bonjour service. I also noticed that other apps that use Bonjour (such as Apple's Remote app) were also having trouble on said network. After doing some digging I've found that other people have had similar problems with bonjour and some routers. Therefore I have 2 questions:
1) Does anyone know if this problem with Bonjour that some routers seem to have is a widespread issue? In other words, if my app relies on Bonjour in order to function at all, do I have to be worried that it won't work in 50% of the WLAN networks or do most routers not have any issues with bonjour. Obviously I can't expect anyone to know how every router out there deals with bonjour packets but maybe there are some Networking gurus that can point me in the right direction :-p.
2) Second, if bonjour is too risky of a protocol to build my app on, what are some alternatives with similar features? The features I would (preferably) need would be service publishing and discovery without users having to manually enter IP addresses of other phones.
Ok thanks for your help! I understand that this is kind of a broad question but any help is appreciated! :)
This is potentially a tough nut to crack. The problem causing devices not to find each other on certain networks is related to the underlying transport (i.e. multicast UDP) and not Bonjour (or mDNS or whatever else you wanna call it).
In high-level, non-rigorous terms, multicast data puts more load on routers. Large corporate and university networks sometimes like to drop Bonjour messages (i.e. UDP packets sent to the multicast group 224.0.0.251 on port 5353) because it means the network isn't inundated with thousands of clients advertising their iTunes libraries or whatever, and at scale this can improve general performance. At the other end of the spectrum, some domestic routers drop multicast packets out of the box for reasons known only to the manufacturer. There's not a whole lot you can do about either situation.
Try running a tcpdump on the network to see if the packets are actually coming through. I've not come across a home router that doesn't forward them for a while. If they're not, you'll have to come up with some central [internet-facing, perhaps?] lookup facility. If they're visible, then there's something up with your implementation.
There's nothing stopping you from writing your own simpler protocol for service discovery to be sent over multicast- it's just that there are loads of Bonjour clients in a ton of different languages already written and tested.
I'm just getting started with mobile development, and after considerable searching I'm still confused about sending a message from my iPhone to another or an Android. For instance, in building a simple Tic-Tac-Toe game, if I want to notify the other phone of a move, what is the best way to do so? Wifi, bluetooth, 3G? And how?
Many methods seem to point to communicating through a web server, but I'd rather send them directly from phone to phone if possible. (this is for native apps of course)
If you don't want to have a server (or even if you do! It depends!) it sounds like you will want to use TCP sockets. Apple doesn't have a generic bluetooth API to use with iPhone-to-android communication and you'll have TCP access anyway with 3G. A 3G network connection is very similar to wifi and you should be able to check for the difference as needed with little change to your overall networking code. I'm not sure if bonjour is supported on android, but I bet someone has ported it for similar reasons already, and it is supported in iOS. Apple has a networking section for iOS that you may find informative.
Additionally if you want to stay within the iOS device only realm you could use GameKit to communicate via bluetooth.
Hope that helps some.
The easiest way is to create a web server with an API and the clients poll the server for new moves (or the server pushes the client an update). This is the only way you're going to be able to do it over 3G unless you can figure out the IP addresses of both phones (do phones even keep the same IP address for a long period of time?) and open up sockets between them and let one phone be the server and the other be the client (could cause potential cheating).
WiFi is not always there - by limiting your users' options to areas with access points, you'll lose sales. Not sure about Bluetooth - how prevalent is it on handsets, how much of the API is exposed. Your best bet, IMHO, is 3G. With some kind of a central presence server (Web or otherwise), with optional proxying. Read up on peer-to-peer networking.
As far as i know does the iphone only support incoming messages over push notifications.
This means, that you have to update the information, by requesting it from web services etc.
The bluetooth API of the iphone doesn't support this either.
How do apps like Apple's "Remote" app control mac applications and send data?
is this via php with exec() commands or some other method? and how would I do it in c?
Also, how fast is this rate of transfer (can I use it to send real-time data like streaming video or audio?)
thanks to anyone who cares to enlighten me on this issue :-)
Apps generally communicate using a TCP/IP based protocol and the wireless LAN connection (the iPhone also has Bluetooth). In the case of the Remote app the communication is via with the Digital Audio Control Protocol. iTunes implements DACP so the Remote app can control it. Other common protocols are HTTP and FTP. There are classes in the iPhone SDK to connect to noth HTTP and FTP servers. There is also the Cocoa HTTP Server project which allows the iPhone to act as a HTTP server.
iPhone apps can also use Bonjour/mDNS/zeroconfig (they're different names for the same technology) so that the user doesn't have to be concerned with configuring IP address'.
The data transfer rate of the wireless connection is faster enough to stream video.
many of these remote applications work by installing client software on the computer and establishing a network connection. In the case of Apple's remote software, the client software is built into the networking capabilities of iTunes. You must authenticate using your iTunes sign in and be on local wifi.
The third party app "intelliremote" works very similarly only has it's own client software to install and can work across a WAN with proper port forwarding enabled on your network.
I haven't encountered any realtime streaming options as most of these utilities are designed to pass control messages and meta-info on media files.