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
Related
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 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.
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
My app communicates with an external device via EA Framework. I would like to do a "soft disconnect", i.e. a software disconnect without actually physically disconnecting the device. The only way I see for a soft disconnect is to close the EASession's inputStream and outputStream. Question: Will the external device know I have closed the streams so it doesn't attempt to communicate further? Is there another way to do soft disconnect?
i think that actually is impossible to do a real soft disconnection.
i say 'think' cause you never stop learning on EA Framework (One week ago i found the showBluetoothAccessoryPickerWithNameFilter for example, maybe is useful for you for inApp-connection).
I use a EASession(s) manager to easily switch between connections. so forgot the word 'disconnection' and replace it with 'switch' :D
If you need disconnection, implements some function on btdevice-side and execute this to disconnect as soon as you receive a command from the iPhone.
How do I transfer a file from one BlackBerry device to another over WiFi like I've done with blue tooth?
In Bluetooth, each device can easily become aware of one another because the protocol supports this. In Wifi (which is just a medium for generic networking... TCP/IP in many cases), it's generally expected that one machine already knows how to locate the other... so this is the problem you need to solve.
One option is that you can have one of the devices (or even both) periodically broadcast a message when it wants to connect to something; this message would be on a pre-defined port but as a broadcast, it's open to all receivers. Then the other device (or even both) needs to have a broadcast receiver looking for the message on the right port. One benefit here is the broadcast receiver will not only receive the message, it will also receive the IP address of the sender -- this is your missing component.
Once the receiver has the IP address of the sender, it needs to open a connection to the server port running on the device that sent out the broadcast. Of course, that first device needs to have its server task running at this time also.