-------------------------------------------------------------------------------------
TODO List:

  * ivyprobe is a bit touchy about being fed somethin on standard input
    try echo "coucou" | ivyprobe ... -> use IvyDaemon instead
  * document the extension to the API
  * document the IVY_PING feature
  * mêmes commandes que sous perl et C.
  * write a domain checker

-------------------------------------------------------------------------------------
Known bugs:

-------------------------------------------------------------------------------------
Fixed:

1.2.2
  - java fr.dgac.ivy.Probe
  - ivyprobe, quitte ivyprobe
    il restait une thread IvyClient qui boucle  en lecture. Bug reported by Damien
    Figarol
  - JDK1.1.7A (Sun) Method add(java.lang.Object) not found in class
    java.util.Vector. -> replaced by addElement , the add(Object) was included
    in jdk1.2. The System.setProperty was included in jdk1.2. I switched back
    to the old constructs

1.2.1
  - bus.start(null)
  - java -DIVY_PING -DIVY_PING -classpath ../lib/ivy-java.jar:. BenchLocal -t 2 -d 100
    créé une nullpointerexception java.lang.NullPointerException
    at fr.dgac.ivy.Ivy.stop(Ivy.java:157)
    at BenchLocal$RML.receive(BenchLocal.java:87)
    at fr.dgac.ivy.Ivy.callCallback(Ivy.java:348)
    at fr.dgac.ivy.IvyClient.newParseMsg(IvyClient.java:361)
    at fr.dgac.ivy.IvyClient.run(IvyClient.java:191)
    at java.lang.Thread.run(Thread.java:484)
    fixed a condition when a bus was requested to be stopped even before
    having started its thread

1.2.0
   - implement .die in Probe ( to get the same behavior as ivy-c ivyprobe ) .
     Done
   - Probe doesn't send empty strings -> it does now
   - the Unitary test fr.dgac.ivy.Ivy main() fails with jdk1.3, but succeeds with 1.4
     it means that when a remote client disconnects brutally, the IvyClient and IvyWatcher
     Threads are still hanging, ready for a new connexion !
     In jdk1.3.0, it works whithin jdb but not as a single application
     -> fixed with a new setSoTimeout(TIMEOUTLENGTH) on each socket.

   - jdk1.4 DEBUG TCP socket reader caught an exception Socket closed on Ivy.close()
   - if a remote client disconnect brutally ( broken pipe ), the BufferedReader
     takes time to propagate the IOException. It means we are not aware of the
     problem before 2 or 3 messages ( Alexandre Lemort )
     there is a fix in IvyClient, but this is part of the TCP protocol. I will
     receive the timeout when I try to write on the client. To circumvent this, I
     have implemented an extention in the Ivy protocol with 2 new messages, Ping
     and Pong. This is Ivy-java only, and and experimental feature.
   - when a Ivy bus sends a die message, he dies instead of making the other leave
  * 1.0.11: received an exception: IvyClient.sendBuffer.write failed: Relais brisé (pipe)
  It happens while sending messages once a remote client has disconnected
  ( fixed in 1.0.12 )

-------------------------------------------------------------------------------------
Not a bug ?

  if you send a msg just after the start, it is possible that the message
  won't be sent. this is *not* a bug, but, hmmm, a feature. In fact, when you
  do start(), it triggers different threads, the broadcasts are sent, and it
  is possible that nobody has answered this broadcast by the time you start
  sending messages. Try adding an IvyApplicationListener with a callback on
  connect(IvyClient) to trigger the launching of messages

  bus domain shortcuts ( 10:3456 instead of 10.255.255.255:3456  ) doesnt work
  for UDP broadcast on my development environment. It's okay in multicast (Yannick Jestin)
  In fact, it's a matter of network topography, not of shortcut processing.


  Using the regression tests on the following platforms:
      - Solaris: I've got a problem to make it run on the default local Domain
        (127:2010). But this is not limited to the java ivy port !
	success with jdk1.1.7A, on jdk1.2 , j2sdk1.3 and 1.4 with a multicast domain or a valid
	UDP broadcast domain . I guess it's a routing problem once again :-\
      - GNU/linux: ok with jdk1.3 and jdk1.4
      - windows:  I don't know how to write tests