Going through the logs generated by my 'CoreBluetooth' state machine and have noticed on occasions a didDisconnectPeripheral is being called while the peripheral is in CBPeripheralStateConnecting and before a didConnectPeripheral. The code is immune to this strangeness however I would like to understand what is happening.
Anyone else experienced this or anything similar? I cannot find any logical explanation.
in iOS6 when CoreBluetooth was rather less mature I adopted the connection strategy of requesting a connection, if connection didn't result in the next 2 seconds, I would then call cancelPeripheralConnection and then issue another connectPeripheral this cycle would continue 3 further times before terminating and informing the user that something is wrong.
It would appear that the calls to didDisconnectPeripheral, even when not first connected, were a result of the intermediate calls to cancelPeripheralConnection.
Now with the stability of iOS7 and having learned that connectPeripheral never times out I have removed the complexity of intermediate cancelPeripheralConnection & connectPeripheral calls and just wait for the connection, with a timeout.
No more mystery didDisconnectPeripheral calls!
Related
looking here it seems it is possible, but I'm not a Java guy.
https://developers.google.com/+/hangouts/api/gapi.hangout.telephone
I have an ongoing issue with my incoming phone lines not working and I have no way of knowing until someone calls my cell and says your number has been busy for hours what's up...
I'd like to make a simple extension/app that will dial my number once an hour, log the outcome of the call, and notify me (email/sms doesn't matter) if it was busy or other error. If the lines are working it will ring always and go to VM if I'm on the phone. When it dies, the caller either gets a busy, fast busy, or just dropped after 30 sec.
The phone company has been of no use in fixing the issue, so I want to log the status to prove just how often it happens.
Been trying to find the issue here (Unity devs make it seem it's a design choice somehow), but I've been trying to simulate lag to see how my game works over the internet (I've also tried connecting a client from a tethered hotspot and it disconnected as well) and found that any amount of packet loss (even just 1%) will eventually lead to a disconnection within a couple minutes.
My game receives data just fine, as you can see the remote players moving around just fine until the disconnection. I think it has something to do with UNET's heartbeat packets not being resent for some reason, and has soon as it drops the first one you get disconnected.
If this is a design choice, I can't see how Unity would think you could have a rock solid connection when you obviously have some who could be playing off a cellular connection. Anyone know anything about this? I've tried asking on the Unity forums as well, and there's been no replies for over a week now.
Thanks
Error code:"
The request channel timed out while waiting for a reply after 00:09:59.6320000. Increase the timeout value passed to the call to Request or increase the SendTimeout value on the Binding."
This error occurs infrequently when calling a Wcf service methods. It doesn't matter what method is. I have created test methods that returns simple strings. Sometimes it times out, sometimes it works perfectly. The strange thing is that when the WCF service is published on one server(for testing purposes)- there is no timeout. When I publish it on another server(live/public) there occurs these timeouts infrequently. I have set the timeout to 10 min as you could see above.
The webconfig setting should be correct, because it works for the one server. The only change made is the ip address. I know this is very difficult to answer and a bit ambiguous.
I'm sure this problem is too high level for me to solve, or maybe I'm making a simple mistake and it is too obvious for me to notice. If you could give me a pointer or just friendly advice on this problem I would really really appreciate it. I am shooting in the dark here. I thank you for your interest, proved by you reading up to here.
does it happen first time you call the service? if not, but does subsequently, it could be that the service instance has been locked by the calling thread - look into multiple instances or allowing concurrent use, obviously taking into account the thread safety requirements of your code
I'm new to driver programming in general and also to USB. However, I managed to write a driver for Windows CE (6.0) and I also had access to an USB-Sniffer to read all traffic between the host and the device.
The problem now occurs on some boards (2 out of the 3 I have):
When the device has no data to send and I issue an Interrupt-In-Transfer the device sends an ACK.
So far this is expected. However, something (I guess either the USB-Controller or WinCE) seems to automatically issue more IN-Transfers (3 on one board, 4 on another) and I get subsequent ACK. This isn't a problem so far either.
But the next IN-Transfer will also result in an ACK, no matter if there is data to send or not, I receive zero bytes in the driver.
Yet, when I look at the USB-Sniffer the proper telegram was send, however 2 more IN-Transfers are automatically issued and are responded with an ACK. So it seems like the data is overwritten by the ACK.
I tried everything that came to my mind so far: Reset the pipe, close and reopen the connection, but nothing seems to work out properly. Resetting the Pipe solves the problem in about half of the cases though. I really ran out of ideas for solving the problem.
Is there a way to tell the USB-Controller (or WinCE or whatever causes this behaviour) to always only issue one single transfer?
EDIT
Turns out it was a threading issue. Unfortunately I wasn't the one who fixed it and I have no access to the working solution, thus I cannot give further details.
Scenario:
I have a Distributed-objects-based IPC between a mac application and a launchd daemon (written with Foundation classes). Since I had issues before regarding asynchronous messaging (e.g. I have a registerClient: on the server's root object and whenever there's an event the server's root object notifies / calls a method in the client's proxy object), I did long-polling which meant that the client "harvests" lists of events / notifications from the daemon. This "harvest" is done through a server object method call, which then returns an NSArray instance.
It works pretty well, until for a few seconds, the server object's process (launched thru launchd) starts being labeled red with the "(Not responding)" tag beside it (inside Activity Monitor). Like I said, functionally, it works well, but we just want to get rid of this "Not responding" label.
How can I prevent this "Not responding" tag?
FYI, I already did launchd-based processes before and this is the first time I did long-polling. Also, I tried NSSocketPortNameServer-based connections and also NSSocketPort-based ones. They didn't have this problem. Locking wasn't also an issue 'coz the locks used were only NSCondition's and we logged and debugged the program and it seems like the only locking "issue" is on the harvesting part, which actually, functionally works. Also, client-process is written in PyObjC while server process was written using ObjC.
Thanks in advance.
Sample the process to find out what it's doing or waiting on.
Peter's correct in the approach, though you may be able to figure it out through simple inspection. "Not responding" means that you're not processing events on your event queue for at least 5 seconds (used to be 2 seconds, but they upped it in 10.4). For a UI process, this would create a spinning wait cursor, but for a non-UI process, you're not seeing the effects as easily.
If this is a runloop-based program, it means you're probably doing something with a blocking (synchronous) operation that should be done with the run loop and a callback (async). Alternately, you need a second thread to process your blocking operations so your mainthread can continue to respond to events.
My problem was actually the call for getting a process's PID using the signature FNDR... that part caused the "Not responding" error and it never was the locks or the long-polling part. Sorry about this guys. But thank God I already found the answer.