Description of the internal structure of core 0.85.4:
-----------------------------------------------------

Technically, the core of the version 0.85.4 and previous version has only minor
changes. Changes are so small that it is possible to do what the new core does
using a dummy client.

With previous version, one DCTC is chosen from the set of running DCTC to be the
master. Now, the first started client automatically creates a master
(dctc_master program). If no change is made in the UI, that's the only visible
difference, dctc_master will just act as a dummy_client and everything just
works as in previous version. 

Note: when a dctc_master is created, it inherits the configuration flags from
the DCTC creating it (connection port, port range, proxy, ...)

Things to change in the GUI:
----------------------------

To have a full feature GUI, you must have at least 2 connections with DCTC. One
with the hub you want to use (named 'A') and 1 with the master (always
$HOME/.dctc/running/master) (named ('M').

Send all usual commands to the connection 'A' ... as usual except the /GDL
command. /GDL commands have to be sent to connect 'M' thus all the download will
be handler by the master. With this structure, all existing commands have to be
sent either to 'A' or to 'M'. There is however exceptions. Some commands have to
be sent on both 'A' and 'M'. Thes commands are the command listed in the part IV
of the 'commands' file. Even if sending the commands on both connection is not
mandatory, it is strongly advisable, dctc_master will automatically ignored the
one it does not need.


Why a such complex structure ?
------------------------------

It is a good question. Initially, I have planned to rewrite DCTC nearly fully to
have a single process handling all hub connections and transfers but I have
encountered an unexpected problem: the profile. Adding a profile to each hub
connection is not hard even with a single process... however, when a connection
request arrives, with a single port (a logical choice for one process), it is
impossible to know on which hub the user making the request is thus it is 
impossible to know which share list DCTC must use. Yes, yes, you can tell me
we can find it by searching the nickname in the hub user lists... but what if
the user is connected to both hub you are ??? Using more than one communication
port is fairly heavy, that's why I use this structure.

