Android: Find peers on Wifi Network

Question

I'm trying to figure out how to search for other devices logged into a wifi network that are hosting the application on a specific port.

How can I detect the presence of these other devices without knowing their address or even necessarily the port they are hosting on?

Once discovered, I should be able to contact the device and establish a client-server connection with it using SocketChannels.

Note: This application is meant to work with Android devices pre-ICS. So no Wifi-Direct.

Answer 1

You can definitely send a probe packet to broadcast (255.255.255.255) on a well-known port on which all peers listen. This is a good old technique for easy discovery. Others incluse SSDP or UPnP.

Be aware that 255.255.255.255 works only for UDP broadcasts

[Add] I prefer expanding my answer rather than commenting.

1. Who should initiate a broadcast?

You can choose your favourite broadcast model. They are all interchangeable.

Model 1 is "job offering" and in my opinion is my favourite. You open a listening socket on your server application and then periodically send an advertising or better announcement broadcast message telling everyone that an open service is available at a certain IP/port (the port is not required to be static). Any peer interested in communication simply connects to the specified endpoint to use the service.

Model 2 is "job seeking", in which the server remains silent. When a client wants to connect, it broadcasts a generic seek message. Any server available receives the message and either replies (unicast) or else broadcasts the above mentioned announcement message.

Model 2a is "reverse job seeking" where a client broadcasts a request for service not as a generic message but including its endpoint. The server then connects to the client endpoint but the protocol continues as the client node is requesting a service from the server node. They act as reverse-roles TCP peers.

2. How often?

It depends on several factors. I'm not able to help you choose the final number of milliseconds, but I can show you all of the factors. First, how long should a client wait to tell the user that the scan for available services is "finished"? You may think "instantly", or "1 second", but bear in mind that broadcast packets tend to overload the network according to the number of servers available in a community.

If you choose model 1, start listening for available services ASAP (ie when application starts) and then periodically remove from the list those services whose heartbeat (another technical name for the broadcast packet) is not received within T*2 or T*3 timeframe where T is your timeout. A manual scan is generally supposed to be completed within T*1.5 or T*1.2 depeding on how large is T