text: Q:
  
  Multiple ServerSockets, multiple devices and sending to multiple sockets
  
  My company creates their own custom android hardware for our system.
  We currently have 2 android devices that need to communicate together and sync up the sqlite databases inside of them.
  I started writing a custom socket protocol to fix this problem. This was based on a server client model. However as I did more development I found that each device needs to have a server socket running and it is possible to communicate 3 or more devices in the system and also there is a possibility that the server could die or reboot or crash.
  So my idea is to have each device search a set of ports that I store in an array and bind to one that is currently available when the device checks and create my ServerSocket around that.
  This means that maybe device1 has ServerSocket(1111) and device2 has ServerSocket(1112), etc.
  Each device then sends a message through multiple ports. 
  Ex: device1 iterates through the array and opens a client socket and sends a message for each port:
  Socket socket = new Socket(IP,1112);
  sends message...
  Socket socket = new Socket(IP,1113);
  sends message...
  etc
  Ofcourse I have already made this multithreaded (ran by an android service) so no blocking of the UI thread in the android device.
  My question is, am I doing this right? Or is there a better way in Java to do this?
  EDIT:
  I decided to add some code to explain my problem.
  I have multiple android devices connected together through TCP/IP and I create a ServerSocket on each device like this:
  ServerSocket serverSocket = new ServerSocket(4000);
  
  Now when the second device tries this, it gives me an error in Java  because the socket is being used by another device. Their IP addresses are something like 172.23.3.128 and 172.23.3.127. 
  So even having different IP addresses I am getting an error from Java saying that I already binded to that port/IP which is true. This is what I don't understand.
  
  A:
  
  You could also:
  
  have the clients listen on a specific UDP port
  have the clients also broadcast to that port, annoucing their presence
  once clients receive a broadcast, they can initiate a direct connection from an ephemeral port to a pre-determined secondary port -- either over TCP or UDP.
  
  This is how it's usually done at least.
  
  