Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p><code>Socket</code> is a TCP socket. Broadcasting is not possible with TCP. If you want to use TCP, you cannot broadcast, you must have a connection open to each client and send the data over each connection separately.</p> <p><code>DatagramSocket</code> is a UDP socket. Broadcasting is possible with UDP. However, the caveat is that UDP does not guarantee that your message will actually arrive. To guarantee that your message arrives you must implement some kind of acknowledgment/retry protocol, but if you do that, you might as well use TCP, since that's what it does.</p> <p>Edit: Another question and my responses from the comments below. OP wrote:</p> <blockquote> <p>then how i'll get the IP's of listening devices in LAN in order to make connection separately? </p> </blockquote> <p>The subject here is device or service discovery, a not uncommon challenge. There are many options. Here are <em>some</em>, in no particular order:</p> <ol> <li>Specify the server IP address in the client device's configurations and have them connect to you. </li> <li>Specify a list of the client IP addresses in the server device's configuration and have it connect to all of them.</li> <li>Implement some kind of UDP discovery protocol where you broadcast a discovery request over UDP and devices respond with information about their IP address, etc. Same caveat as above.</li> <li>Have your server broadcast UDP messages announcing its presence and its IP address, have your clients listen for these and establish TCP connections to server. Same caveat as above.</li> <li>Check out an existing service discovery protocol, e.g. <a href="http://jmdns.sourceforge.net/" rel="nofollow">jmdns.sourceforge.net</a> (compatible with Bonjour/zeroconf). This is actually quite a common issue and many protocols exist to solve it.</li> <li>Have your server scan all IPs in its subnet and attempt to establish a TCP connection to each. Very time consuming, but may be appropriate.</li> </ol> <p>Options 1-2 are the simplest to implement but require manual configuration by the user. </p> <p>Options 3-5 have a common theme: Avoid manual configuration requirements by using UDP and its broadcast capabilities to automatically exchange configuration information. Use that information to establish TCP connections, and then use TCP for reliable data transfer. Keep in mind that UDP broadcasts are limited in scope to the subnet, so you could not use broadcast-based discovery to discover machines on other LANs -- for that you'd have to do some kind of central service registry with TCP based registration and a well-known registration server.</p> <p>Option 6 avoids manual configuration at the expense of extremely poor discovery performance and potentially high usage of system resources. Options 3-5 seek to optimize the discovery process.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload