In the configuration file you provide a range of IP-addresses which LISa should check to see whether they are running.
In the most simple case this could be your network address/subnetmask, then LISa would check every possible host of your network to see if it is running.
The hosts are checked using ICMP echo
requests. To be able to send and receive ICMP echo
requests and replies the program has to open a so-called “raw
socket”. Therefore it needs root
privileges. This socket is opened
right after the start of the program, after successfully opening the
socket root privileges are dropped immediately (see
main.cpp
and
strictmain.cpp
).
If you configure LISa so that it also uses
nmblookup, it will popen("nmblookup
\"*\"")
and then parse the results.
Since the ICMP requests and the broadcasts can cause some network traffic if there are more than one such server running in one network, the servers cooperate with each other. Before they start pinging (or nmblookup), they send a broadcast on port 7741.
If somebody answers this broadcast, they will retrieve the complete list of running hosts via TCP port 7741 from this host and will not start to ping (or nmblookup).
If nobody answers, the host which sent the broadcast will start pinging the hosts (or nmblookup) and then open a socket which listens for the mentioned broadcasts. If the host received an answer to his broadcast, it won't have the socket for listening to the broadcasts open. So usually exactly one of the servers will have this socket open and only this one will actually ping (or nmblookup) the hosts.
In other words, the servers are lazy, they work like “I will only do something if nobody else can do it for me”.
There is another feature which reduces the network load.
Let's say you configured LISa to update every 10 minutes. Now you don't access your server very often. If nobody accesses the server for the last update period, the server will update (either itself or from the one which actually does the work) and then double its update period, that is, the next update will happen after 20 minutes.
This will happen 4 times, so if nobody accesses the server with update period 10 minutes for a long time, its update interval will increase up to 160 minutes, almost three hours. If then somebody accesses the data from the server, he will get an old list ( up to 160 minutes old). With accessing the server will reset its update interval to its initial value, that is, 10 minutes and immediately start updating if the last update is more than these 10 minutes over. This means if you get a very old list, you can try some seconds later again and you should get a current version.
This will have fast effect for the servers, which don't ping (or nmblookup) theirselves, since only one user usually accesses them, and it will have less effect for the server which does the pinging (or nmblookup), since this server is accessed from all other servers in the network.
This way it is possible that many hosts in a network run this server, but the net load will remain low. For the user it is not necessary to know wether there is a server (that is, a name server or fileserver or whatever) in the network which also runs LISa. He can always run LISa locally and LISa will detect if there is one, transparently to the user.
The first client for LISa is an ioslave for KDE 2, so the user
can enter there lan://localhost/
or
lan:/
, which will both contact LISa on the own
system.
If there is a machine which runs all the time and the user knows
that this machine also runs LISa, he can use his LISa client
directly with this server (would be with the mentioned ioslave
lan://the_server_name/
).
If you don't want that your LISa takes part in the broadcasting,
but always does the pinging itself, make it use another port with the
command line option --port
or -p
. This
is not recommended!
If you send SIGHUP to LISa, it will reread its configfile. If you send SIGUSR1 to LISa, it will print some status information to stdout.
The data provided over the socket has a simple format:
<decimal ip address in network byte order><one space
0x20><full name of the host><a terminating
'\0'><newline '\n'<
and the last line
0 succeeded<'\n'>
For example,
17302538 some_host.whatever.de
18285834 linux.whatever.de
17827082 nameserver.whatever.de
0 succeeded
This should make it easy parseable.
If there are very strict security rules in your network, some people might consider the pinging a potential attack. If you have problems with this, try the restricted version, resLISa.
Would you like to comment or contribute an update to this page?
Send feedback to the TDE Development Team