How to retrieve available (server)-IP addresses on a LAN

Question

Is there a method to get all/the available (server)-IP-address(es) on a LAN from the host program?
As far as I understood the samples (e.g. in tcpex.llb) the host (or it's operator) has to know the IP-address of the server to start communication. However it would ease the usage of a host-program if all/the available server(s) could be selected e.g. from a list-box.
I posted this question already yesterday with some additional explanations however couldn't find it in my "posted questions"-list. So I try again.

Answer 1

You don't tell us enought about the type of "servers" you mean. Are these all LabVIEW programs? In this case it should be relatively easy for them to keep each other updated at regular interval, e.g. via UDP multicasts.
Alternatively, your servers can announce themselves via a UDP packet to the subnet broadcast address and to a specific port.
If these are servers with code not under your control, you need to probe them. This is not such a big deal on your private LAN and I don't think it will trigger IDS systems. Keep a short list of all possible server IPs, then try to connect at the specified port at regular intervals using a short timeout.
Are you communicating with TCP or UDP?
In the absence of firewall code, you can have 3 possible responses for TCP:
(1) No response --> The server computer is down (or there is a stealth personal firewall running). You get a TCP timeout error.
(2) Active rejections (TCP RST packet) --> The server computer is up, but the server program is not running. Nothing is listening on the target port. You'll get an error.
(3) Accepted connection (SYN-ACK) packet. --> The server is up and listening for connections. The threeway handshake can be completed. No error.
UDP is a bit trickier, because it is connectionless. Many UDP services are one-way. For example a syslog server just receives packets, it never acknowledges anything.
It is easy to tell if the server computer is up, but the service is not listening. In this case you get an ICMP(3,3) response and an immediate error.
If the service is listening, you either get nothing or a specific response, depending on the type of server. If you are waiting for return traffic, you'll get a timeout error in UDP read either way.
(If you just want to check if the server computer is actually up, probe it on a unlikely high port that virtually guarantees an ICMP(3,3) response in the absence of a personal firewall program.)
LabVIEW Champion . Do more with less code and in less time .