I am developing in iOS.
The App call the function in library , and send the packet via wifi.
When the App is running , I push the power button(not home button) on iPhone 5C and push again to open it. But it crash...
And it did not show which line is error , it only show the error like the following picture:
How to analyse this crash log via above picture?
Thanks in advance.
As mentioned by Apple, in Avoiding Common Networking Mistakes, you need to handle or disable SIGPIPE:
Use POSIX sockets efficiently (if at all).
If you are using POSIX sockets directly:
Handle or disable SIGPIPE.
When a connection closes, by default, your
process receives a SIGPIPE signal. If your program does not handle or
ignore this signal, your program will quit immediately. You can handle
this in one of two ways:
Ignore the signal globally with the following line of code:
signal(SIGPIPE, SIG_IGN);
Tell the socket not to send the signal in
the first place with the following lines of code (substituting the
variable containing your socket in place of sock):
int value = 1;
setsockopt(sock, SOL_SOCKET, SO_NOSIGPIPE, &value, sizeof(value));
For maximum compatibility, you should set this flag on each incoming
socket immediately after calling accept in addition to setting the
flag on the listening socket itself.
Related
I keep running into a strange issue when running AKMIDI on IOS. I also think it may be an IOS problem and not necessarily from Audiokit. I can connect a MIDI controller to IPad and receive messages as expected using the MIDI listener protocol after I open the input. If I disconnect the MIDI controller by cycling the power or unplugging it from the IPad and then reconnect it, I then start receiving two identical messages at each event. If I cycle the power again I start getting three messages, etc. I should also mention that when I detect the device is removed I close the input and clear the listeners. When I detect the new connection I open the input and start over. Does anyone know what can cause this to happen?
I think I have found a workaround for this:
If I only open the midi in and midi out one time, when my device is first detected, it seems to work correctly. I now only close the in and out when the app is terminated. You can cycle the power on the midi controller and it will still communicate with the app when it reconnects. I am also now using the more generic calls openInput(), addListener(self), openOutput().
Here is a weird thing, I create two sockets and bind them to the exactly same address(INADDR_ANY) and port.
When SO_REUSEADDR is set to both socket, the second bind will fail with error EADDRINUSE.
When SO_REUSEPORT is set to both socket, all bind call will succeed, but only the first socket could receive data, the socket which bind later will never receive any data.
I'm currently working on iOS 10, and I believe it works differently on Android.
Anyone has seen the same problem? Is this an iOS intended behavior? How could I receive data for the second socket without release the first one?
With a simple demo I can confirm that this is intended behavior of iOS(and similar BSD based systems) , and Linux/Android will behave oppositely.
I have a navigation application that works with both CoreLocation (Backgrounding mode Location updates) as well as GPS data provided over a UDP connection from an external sensor.
I've noticed that when I background the app the socket goes down (which likely makes sense).
What is the procedure to keep the socket open in backgorunding?
Idea
I thought perhaps to register as a VoIP app - would keep the socket open but it looks like that works differently now.
The documentation suggest implementing setKeepAliveTimeout:handler: but this appears to be deprecated.
I'm not sure exactly how to proceed. Any ideas? The best I can come up with is a hack to have my location-update handler run a check on the socket so see if there is new data - but I'm assume there is a legitimate way to do this.
When the phone goes in stand-by all the UDP socket are closed and only TCP connection can be used. Yes probably with VOIP app you can use the UDP but in that case your app will be reject because your don't use a real VOIP service. I had the same problem ... In my case, even if the phone is in background, I want to send UDP message to a domotic system but is not possible.
I've searched the web extensively but haven't found a good answer to this.
Im writing a socket based application in C++ using posix sockets on iOS/Android.
When switching from wifi->3g, SOMETIMES the socket goes dead without giving any errors when reading/writing.
I can use the reachability API on iOS (and similar on android) to detect when the network switches.
I am destroying/recreating the socket when this occurs. The problem is if the socket is alive, the server will receive the signal when I close the socket. If the server receives the close signal, it will assume the client disconnected intentionally and notify others about this, which is not what I want. If the socket is dead, the server doesn't receive this signal and everything is OK.
How do other people handle this scenario? I really don't want to use a timeout to detect this.
Why does it only sometimes die too? And how can I tell the socket is actually dead?
Just to close this issue, this is the approach I'm taking.
When switching networks, I'm sending a ping-and-reconnect packet to the server, AND creating a new socket.
Which ever responds first, I close the other connection.
Required a bit of server side changes to handle this correctly too
I am trying to write an iOS application that connects to an OBD-II Interface over WiFi (specifically the OBDLink MX WiFi Scan Tool). I have written some basic socket code taken and I am able to open a socket to 192.168.0.10:35000. I receive the NSStreamEventOpenCompleted for both input and output streams.
The first event that fires shortly after is the NSStreamEventHasBytesAvailable. I attempt to read the stream, but the length comes back 0. My question is what is the flow of execution for communicating with these devices? I have tried to issue an ATZ\r command, but nothing is happening (no stream events are firing).
How do I know if if I am connected and the OBD-II interface is ready?
The usual command terminator is ˋ\r\nˋ, so first try sending ˋATZˋ with this command. Only send, after you have received the HasSpace notification from the ˋNSOutputStreamˋ.
Another alternative to communicate with this device would be this Car Diagnostics API, access to the API can be found on
https://github.com/HellaVentures/Car-Diagnostic-API