Fix Discovery

[JayThomason]

Discovery right now is a problem and it needs to be fixed before we can launch the application.

The way that we are currently performing discovery is unacceptable. Right now we are using a central server for this task. The master phone creates a jam on the server and the jam is just associated with the wifi network's SSID/name. Phones on the same network can query the server for the IP address/port of the master phone.

This will not scale well, requires us to maintain a server, requires keep alive messages to the server and has more problems. I would definitely prefer if discovery were just performed over the local network.

I previously tried the following with minimal success:

• UDP broadcasting
  • Impossible because the Nexus 5 cannot receive UDP broadcast messages.
• NSD
  • There are outstanding bugs with Android's implementation, see here.
• Bluetooth
  • I recently thought that bluetooth might be the solution to this problem, but there are a bunch of issues with being unable to easily enable/disable whether the Android device is discoverable or not.
• Wifi Direct/P2P Discovery
  • I have tried this before and had issues but I am willing to give it another shot.
• mDNS
  • I tried using jmDNS and it didn't work.

[JayThomason]

RE: Wifi Direct/P2P

The main issue I'm having right now with wifi direct is that once you begin peer discovery in wifi direct you must explicitly stop it. If you simply close the app then peers might appear to be there even when they are not. They do seem to disappear after a few minutes, but we would need to deal with these potentially stale peers.

[JayThomason]

After doing some more testing, I think that I might have one workable solution:

• Master phone registers a wifi p2p service as seen in this example.
• Client phones discover local services.
  • Clients parse the list of services looking for services with names that start with "TuttiJam" or a similar string.
  • The name string will include the ip address and the port number.
• The master has a new server endpoint called /ping or something similar (assuming /ping is different from the client ping endpoint). This endpoint always returns a 200 OK response.
• The client pings all seemingly valid jams and if it gets a 200 OK response from that jam then it adds it to the list of local jams displayed on the UI.

The downside that I see to this is that in order to use it we need to raise the Android required API to 16 (from 14) and require all phones to be Wifi P2P enabled.

[JayThomason]

One potential upside to using WifiP2P to do discovery is that the user will be able to enter the join jam activity before the master phone creates the jam and the new jam should show up without the user refreshing the activity.

Edit: I'm not actually sure if this is true. We might need to regularly cancel/restart discovery.

[JayThomason]

As of here I have implemented basic discovery using the DNS Service Discovery and the Wifi P2P framework.

However, it seems that the master phone only broadcasts its service for a short period of time because the Wifi P2P library does not necessarily work as expected. I have fixed this with a strange hack where I call discoverServices on the master phone every 5 seconds (https://github.com/JayThomason/Tutti/commit/fbc81fe423a3be806f058f5e94beb05d0673ea47)

[JayThomason]

After a little bit of testing this seems to be a functional solution.

Local discovery works.

Everyone celebrate.

[hwray]

Huge shout-out to @JayThomason for crushing this super tricky problem. After a quarter of work-arounds, it feels awesome to have this working in its final form. I probably created and joined 50 Jams while testing tonight, and discovery worked flawlessly every time.

[JayThomason]

[avptv]

Woohoo!! Awesome work getting this working Jay!