With the discovery parts of the logic, there has been suggestions to skip the Peer discovery part and go strait to the Service discovery, for example P2Feed says that “For the purposes of a peer-to-peer app, service discovery is more useful.“, while this can be completely true, its could also be source of additional problems.
The first issue which comes to my mind, is the way the the WiFi Direct API is designed, its doing the peer discovery in background in all cases, thus skipping the peer discovery does not really do any savings on the API point of view, though if it makes your logic work better, then go for it.
Second issue, which I do not fully understand, is that when doing the connect to other device, it must be on some discovery list. Supposing that it must be at least in current Peers list (since we can do connection without service discovery). Have not seen any docs for this, but stumbled upon a post at Stackoverflow. As I assumed that the Peers discovery is done automatically, this should not be any issue really, just remember not to stop any discoveries, until you are connected (or at least connecting).
Then also p2Feed use case of course is rather simple, you do quick discovery and connect, with Thali, we would need to do continuous discovery over extended periods of time, thus to be able to know whether the method would be suitable, we would need to do some testing with it.
With first test I modified the original power tests application to not make any Peer discovery request and let it run for few hours. Results for started service discovery events and actual services discovered can be seen from the image below:
Basically what you can see from there, is that we get really low number of services discovered, and on some point of time we stop discovering any services, and after that point, no services are discovered anymore. There is also a strange increase on the rate of services discovered shown in the graphs. And the reason for this behavior is that, for some unknown reason the device starts giving higher rate of Peers changed events as can be seen from the following image:
So, that would indeed indicate that we might do better if we would do Peer discovery also, and not just service discovery. Thus the next trial was then starting Peer discovery each service time-out timer caused a reset (will fire if we don’t get services discovered within 10 minutes), as well as every time we get Discovery stopped event. Thus the Peer discovery should indeed be active at all times.
The service discovery behavior can be seen in following picture:
As we can see from the graphs, the number of peer discovery requests is starting to raise as we get into the situation where we don’t get any services discovered anymore. Anyhow, the peer discovery requests alone are not fixing the issue, and the app never gets any new services discovered after it hits the problem.
Note also that all Peers discovery as well as service discovery requests were succeeding, and there were no error indications that could be used in apps logic to figure out what goes wrong.
The Peer changed events are again, received just fine:
So I would summarize that, using the service discovery as only approach for finding peers does not work, if the logic needs to run over extended periods of time.
Then I wanted to see whether I could recover from the situation, and decided to try a new approach. With the latest versions of the modified power tests app, I implemented a new reset logic. Now when there has not been any services discovered in last 10 minutes the reset logic will turn the Wifi off, and once we get event that its off, it will be turned back on, and the logic for discovery is started again. With this test, the peer discovery was used same way as was with the second approach.
In general this approach appears to work really well, and it appears that we do get the service discovery going on normally by doing the reset with Wifi. the results can be seen from the image below:
As seen from the graphs the service discovery started, generally generates nearly same amount of actual service discovery events, which is what we would want to see there indeed.
The Nexus 5 with 4.4.4 Kitkat though does stop working on one point and never recovers, but before going deeper, lets see how the battery consumption alongside the Peers changed events went:
The point here is that when all goes well, we get the battery drained in 24 hours in all devices (same with Kitkat and Lollipop), exception being the Nexus 5 with 4.4.4. Kitkat, which nearly stops consuming battery as well as getting Peers changed events at the same time it stops discovering services. With other devices there were nearly no errors reported with discovery requests, but with the problematic Nexus 5 we see following:
Basically what we see there is that all Peer requests as well as service requests are failing, and after seeing the battery status graph, I would strongly suspect that the reason for this behavior is that the WiFi Direct API service crashed, and only way to recover then would be rebooting the device.
So to summarize my findings, Firstly I would not suggest utilizing Service discovery only without using Peer discovery first.
Secondly, Turning WiFi off and then back on will help on recovering from situations where no services are discovered.
And thirdly the API is really not as stable as it should be for the workaround and using the workaround can lead into situations where device reboot is required to recover.