UDP doesn't require an IP address for listening. You can just bind to a socket using a port, and you will pick up all multicast traffic for that port, which shows up as 0.0.0.0:<port>. If you join a multicast group with a specific IP address, then you will filter on that IP address, but the implementation can vary depending on the OS. For example, on Windows, the OS handles the filtering before it hands you messages, but on other operating systems, it may still give you all of the messages for a given port even if you subscribed to a specific multicast address.
The way I'm currently implementing the connection is I broadcast an identification message from the tablet while no active TCP/IP connection is available. This message is truly a broadcast message in that it goes over 255.255.255.255, which can sometimes be blocked by certain routers. If you are experiencing a problem with this, I can switch to using an arbitrary multicast address that could optionally be set in an advanced section of the configuration. I could also make the TCP/IP settings configurable as well. After the initial broadcast is received, the companion app does a TCP/IP connect to the tablet, which has a ServerSocket that is listening for connection requests (I call serverSocket.accept()). Once this accept is processed, everything works. I have never seen a connection problem past this point. Usually, if a connection problem occurs, it's because the connection is refused or times out, so the companion app tries to connect again, and then gives up after a certain number of tries. For reference, in the companion app, I just use the Socket class set up with Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp), and call connect to the PC IP address.
I have found that connection attempts seem to always be successful going from the tablet to the PC, so I am considering reworking the code so that the companion app will broadcast information that the tablet can use to connect to it, instead of the other way around. If you guys have any insight based on what I've written, let me know, otherwise I will try to fix the code for an upcoming release.
Mike
The way I'm currently implementing the connection is I broadcast an identification message from the tablet while no active TCP/IP connection is available. This message is truly a broadcast message in that it goes over 255.255.255.255, which can sometimes be blocked by certain routers. If you are experiencing a problem with this, I can switch to using an arbitrary multicast address that could optionally be set in an advanced section of the configuration. I could also make the TCP/IP settings configurable as well. After the initial broadcast is received, the companion app does a TCP/IP connect to the tablet, which has a ServerSocket that is listening for connection requests (I call serverSocket.accept()). Once this accept is processed, everything works. I have never seen a connection problem past this point. Usually, if a connection problem occurs, it's because the connection is refused or times out, so the companion app tries to connect again, and then gives up after a certain number of tries. For reference, in the companion app, I just use the Socket class set up with Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp), and call connect to the PC IP address.
I have found that connection attempts seem to always be successful going from the tablet to the PC, so I am considering reworking the code so that the companion app will broadcast information that the tablet can use to connect to it, instead of the other way around. If you guys have any insight based on what I've written, let me know, otherwise I will try to fix the code for an upcoming release.
Mike