LabVIEW
How to retrieve available (server)-IP addresses on a LAN
@tst wrote:
You're right, the LV TCP functions require that you open the connection to a specific server. I can think of two options: You can try polling the servers automatically by opening and closing connections all the time or, what sounds like a more elegant solution, use UDP to transmit that a server is up. I've never used UDP, so I'm not sure how this would work, but I'm sure you can find some examples in LV and probably more on this site. One additional option might be using third party code (like a DLL), if there is any available.
Scanning the network for available services on all the possible ports is treated by many network surveillance monitors as hacking attempt, logged and reported to its administrator and may even result in automatic disconnection of your network segment from the rest of the network to limit the security risk. So unless you have permission to do so by your network administrator I would refrain from such attempts.
Rolf Kalbermatter
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.)
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.)
