Despite working earlier, my socket chat app now refuses to write to socket on the iPhone!
It works fine on the simulator and again, used to run fine on my phone. I don't really know where to start troubleshooting this issue --- just seems weird. My server doesn't detect anything trying to connect.
Any ideas on how to start troubleshooting this?
Thanks tons.
I did run into a problem where using sockets on the iPhone would not open up the cell phone network unless something else opened it first. I had to run an http call to a generic web site first, and then the sockets would communicate normally. Try putting a call, like sendSynchronousRequest, to a generic web site, like www.apple.com, before opening your socket, and see if it works in that case.
I need to stop wasting all you nice peoples' time.
Long story, my friend updated to iOS 5.1. Now the 3G network reads 4G on iOS 5.1. So I turned off my (5.0) wifi to see if mine cell network was "4G" (which, of course, it wasn't).
But yeah, having turned off wifi my app could no longer join my locally hosted server...
I grabbed Charles though, and it looks handy, so thanks for that anyways. Also Owen's comment about the cell network originally made me think about checking my wifi, as my app shouldn't even be using the cell network yet. But I'll keep in mind what you said for the future.
Thanks everybody!
Related
I have a method in an iOS project that calls avformat_open_input(), it runs very well in the simulator, however, when I try to run it on the device it hangs up and just stays there.
Has anyone seen this before?, Any help would be much appreciated.
That method establishes a connection to the source via URL, RTSP, RTP, etc, if it's hanging up:
Make sure that the source is in fact streaming data at that address and port
Make sure that you are connected to the right network if this is a local connection.
Please let me know how it works out.
I have an iOS app that publishes a Bonjour service. On my network, the Mac app recognizes the service and everything runs smoothly. On some networks however, the Bonjour service is not "seen" by the Mac. I can't reproduce this on my own network. I have had users check for the service using Bonjour Browser and it's not found. Is there a way to diagnose this problem further? I thought it might be a firewall / router issue but some users have very simple Apple-based networks (Airport). Any ideas on what could be causing this?
Have you tried implementing the
- (void)netService:(NSNetService *)sender didNotPublish:(NSDictionary *)errorDict
method? it can occasionally provide useful information although I have found the NSNetService to have strange behaviour sometimes also. Stopping the NSNetService and re-publishing is an ugly option which seemed to work for me to some extent.
Make sure you implement ...didNotPublish... as above. Some routers filter out multicast packets, and unfortunately if you don't control the network there's not an awful lot you can do about it.
Another followup: modifying the device name seems to resolve the issue. One user noted that his iPad was discovered but not his iPhone. Bonjour Browser confirmed the presence of the iPad service with no iPhone service. Renaming the iPhone resolved the issue. This is truly an odd behavior.
Can someone please point me in the right direction to create a Mac/PC server app that runs in the background and connects to an iPad app over the local WiFi network?
No matter how I phrase a search on Google it just brings up various apps like Remote Mouse and whatnot and no tutorials or even a hint of where to start.
I just need to send simple commands from iPad to computer over local wifi. A point in the right direction and I can likely fill in the blanks.
Thank you.
Thomas
EDIT: I am using web languages for the iPad version that I will build as a native app using open source tools.
OK, then. It actually depends on what you really need. I made the assumption you need real-time and perhaps binary data transfer.
Your best bet is to write your server application using standard C or C++ so it compiles on both as simply as possible.
If you want to avoid all the burden of writing a protocol for service discovery or asking users to enter the ip address of your server you will use a mDNS implementation for your server and your iPhone app.
If I were you I would try bonjour: http://www.apple.com/support/bonjour/
on iPhone You could start here: http://developer.apple.com/library/mac/#documentation/Networking/Conceptual/NSNetServiceProgGuide/Articles/PublishingServices.html
Once you have your sockets you will have to implement a networking protocol between your server application and your iPhone app.
You will have to be careful about byte ordering and little subtle problems with latency, disconnections and other problems inherent to networking and WiFi.
In windows you will want to register your application as a service and in Mac OS X/UNIX you'll probably want to deamonize it.
Good luck!
I am trying to get a simple sockets program working on the Ipad.
To do this I am using the CFStreamCreatePairWithSocketToHost command.
It works fine on the simulator.
The problem is that it does not work on the iPad (I checked connectivity issues using the iPad's safari, and everything seems fine).
What I want to do is have the iPad open a connection to a PC. The reason I used CFStreamCreatePairWithSocketToHost was that I found a simple 10 line sample program which does this.
My questions:
1 - Does CFStreamCreatePairWithSocketToHost work on the iPad
2 - Can anyone direct me to a simple sample for ipad socket communications (I tried apple dev, and google. No sample that I found could be considered simple (less than 50 lines of code...))
Update:
Also tried sockets and NSHost, both withAddress and withName.
The results were the same: works perfectly inside the simulator, but does not work on the iPad.
I would suggest to use the socket-wrapper AsyncSocket. The download comes with a sample project.
edit
the most recent version can be found here
The low level APIs don't turn on the cellular radios. Use a very high level API to connect, then after the radios are turned on, disconnect if necessary, and (re)connect via BSD sockets.
An HTTP request to a server near the same destination IP would probably be sufficient.
Found the problem...
There was a "rouge" proxy problem in my organization, which was forwarding the saffari, but not my program (even thoughthe safati was not on an http port).
Solved, and thanks for your help.
Building a desktop version of my mobile app and providing the user syncing over wifi. Everything works great in the simulator - no problems resolving net services (which are published by the desktop app) or noticing when services become unavailable.
The problem is when I run the app on the phone services are discovered and resolved (sometiems) but the NSNetServiceBrowser never notices when a service becomes unavailable. When this happens the net service browser constantly finds a net service (that is no longer published) resolves it but then can't connect to it. After several failed attempts the service browser delegate's "didRemoveService" is finally called and the app begins to behave correctly again.
I'd post my code but I've discovered the same issue is happening in Apple's WiTap example. Services are published and discovered but once they are made unavailable the client running the service browser doesn't update - and repeatedly tries to resolve a service that "shouldn't" exist.
I've discovered that running WiTap with wifi turned off (so Bonjour uses bluetooth) everything works fine. I can't find anyone complaining about WiTap not working and can't find this issue anywhere else online. Any reason - possibly with iPhone OS or my wireless network - why a net service browser can find and correctly resolve (but can't connect to) services that are unavailable?
Bonjour/NSNetServiceBrowser on the iPhone/iPod Touch will utilize both Wifi and Bluetooth for service discovery--at least on supported devices. Each time you begin browsing for services, it will search both WiFi and Bluetooth (which you can verify in the iPhone's Console, in Organizer). Since your Simulator "device" cannot use Bluetooth, your iPhone discovers it over WiFi. However, if you are using NSNetService to publish on your iPhone, then you are publishing over both WiFi and Bluetooth as well (if supported and enabled). NSNetServiceBrowser, when running on BT-capable hardware, will dutifully find that both instances, and report both via delegate callbacks.
Bluetooth PAN setup takes longer than publishing via Wifi, so the BT-discovered services often show up well after all the Wifi-based services have been discovered and resolved. When testing two real devices, I've even seen both services show up in my UI (usually only after the other phone crashes).
It does make for some frustrating coding, though. Your best bet is to utilize netService:didNotResolve: to either (i) retry resolution, or (ii) invalidate the netService instance and wait for the other phone to relaunch their app.
Also, there are a couple of other areas things can go wrong. Since the NSNetService instance provided to you is autoreleased, you need to retain it. Most people add it to an NSMutableArray or NSMutableDictionary. If that's the case, make sure that you have properly initialized it before adding the object. Since messages to nil are perfectly ok, if you send addObject: to nil it will appear as though everything is working fine. Except that it isn't. This crops up very often in Bonjour troubleshooting, and happens to the best of us. Make sure that your NSNetService gets scheduled into an actively running runloop, and one that is running in default or common modes.
There is an open bug filed with Apple (as of 10/4/09) whereby every so often, a Bonjour update will not result in a delegate method getting fired. I have only observed this occurring on a 3GS. The result is a client app that is out of sync with the network.
NSNetServiceBrowser should consistently notify when a service leaves the network (under nominal conditions). The bug above is only an intermittent one, and apparently, hardware specific. If you see it occurring consistently, then it's likely that your app is throwing an exception. If you are using background threads, this can occur without causing your whole app to crash. You may want to check your iPhones Console and logs for error messages. Make sure you have set a breakpoint on the symbol objc_exception_throw.
Here's another troubleshooting tip that I've found invaluable. Monitor Bonjour broadcasts on your dev machine via Terminal using the following command: dns-sd -B _serviceName. This will let you see all comings and goings on your local network for your service. If your app quits, but dns-sd does not show a Remove event, then your code needs revisiting. If dns-sd shows a remove event, but your other apps don't process it correctly, you may be seeing the above mentioned bug. It may also be the case that your code isn't doing what you think it's doing. And remember, this will only help you troubleshoot Wifi-to-Wifi service Bonjour. Bluetooth to Bluetooth is not supported from the iPhone Simulator.
Read the full article, Troubleshooting Bonjour Networking for the iPhone, at my dev blog.