WHATSNEW in 5.3
===============

The documentation was updated.

DHID can now be executed under any user (not only root) without
changes to the code.

The pid file default location was changed to /var/run/dhid.pid

WHATSNEW in 5.2
===============

BUG: Client crashes when server reply comes from a different IP address
than that to which the initial packet had been sent. Fixed.

BUG: SIG_CHLD set to SIG_IGN but wait() used. Fixed. SIG_IGN was removed. 


WHATSNEW Since Release 5.0
==========================

1) OnCmd and OffCmd options now are executed with the hostid parameter,
the local IPv4 dynamic IP address and additional parameters specified
in dhid.conf

WHATSNEW Since Release 4.0
==========================

1) Mail relay commands are no longer implemented (CTL4_MXSTART, CTL4_MXEND)
2) Interactive mode is no longer possible
3) The client now supports multiple servers on multiple addresses and/or
   multiple ports (see dhid.conf.sample)
4) The client now is able to update multiple clients within one server
   (see dhid.conf.sample)
5) The client may now propose how often it wishes the server to verify
   connectivity with CHECK_REQs. (see refresh option in dhid.conf.sample)
6) For each record updated (a host entry withing dhid.conf) it is possible
   to execute external scripts at the times of online and offline transitions. 
   (see OnCmd and OffCmd options in dhid.conf.sample)
7) Pid file can now be specified on command line using the -P option
8) The -p command line option now permits changing of the local UDP port.
9) Server port can now be specified individually in dhid.conf for each 
   record (see ISAddr)
10)ISAddr now accepts an FQDN as well as an IP address


WHATSNEW Since Release 3.1
==========================

Two major changes. Release 3 clients can however still connect to 
an R4 server.


1) The protocol has been redisigned. The old simple broadcast packet
has been replaced by a full message exchange process. The client now
sends an ECHO_REQ to the server with no information and expects an
ECHO_ACK reply (a connection has been established).

The client then issues an AUTH_REQ and expects an AUTH_ACK or
AUTH_DENY. If insecure mode is used the password is inserted 
in the AUTH_REQ packet. Otherwise, please see below.

When the online stage is achieved the client stands in listening mode.
Unlike in DHIS R3, it does not send a broadcast packet, but expects 
instead a query (CHECK_REQ) from the server, upon which must
reply with a CHECK_ACK. If the server doesn't receive CHECK_ACKs 
for a period of time the host is considered to have become offline.
If the client doesn't receive queries for a period of time it 
returns to poll mode (ECHO_REQs are sent again).

2) Public key security has been introduced (QRC). If selected,
after an AUTH_REQ the client expects an AUTH_SY upon which 
replies with an AUTH_SX for successful authentication.

The algorithm is as follows:

	The client holds a pair of private keys, P and Q.

	These are long integers both prime and congruent to 3 mod 4. 

	The server keeps the client's public key generated
	by P * Q.

	Upon an authentication request the server generates a
	random number X (relatively prime to N) and calculates
	its square (mod N) Y. Y is sent back to the client.

	The client then has to prove that it is able to calculate
	its square root (mod N) (X) which may only be performed
	with the two prime factors P and Q. In order to do it,
	the client calculates the square root mod P and mod Q
	of Y and applies the Chinese Remainder Theorem to calculate
	the square root mod N. Having done this, the calculated
	X is sent back to the server for comparission with the 
	original value.