---------- Messaggio inoltrato ----------
Subject: Re: I became a member of SF.
Date: Tue, 27 Nov 2001 00:11:07 +0100
From: Giancarlo Niccolai <gi...@ni...>
To: "jason" <jay...@ho...>
Il 09:06, luned=EC 26 novembre 2001, hai scritto:
> Dear Sir.
>
> Sorry that I am so late.
> My username of SF is "jayjungkr".
>
> Nowadays I am studying how to use CVS.
> I am just wondering if I can ask about that.
>
> Take care.
> Sincerely.
Ok, you're in. If you log in, you will see "geneticd" among your active
projects.
The first thing you shoud do is to cvs-out genetic daemon tree, so you ha=
ve a
working directory on your own; you can edit files in that working dir to =
test
new features or bug patches you add;
The CVS system will take care to sync your changes with mine (or other
developers'es).
To get out the CVS tree, you have to install the CVS system on your box
(already in if you have a linux box), and then enter the following comman=
ds:
cd /MY_CPP_DIRECTORY
cvs -d:pserver:ano...@cv...:/cvsroot/geneticd l=
ogin
cvs -z3 -d:pserver:ano...@cv...:/cvsroot/geneti=
cd\
co geneticdaemon
cvs -z3 -d:pserver:ano...@cv...:/cvsroot/geneti=
cd\
co gd_plugin
If you have already downloaded the .tgz distros, delete them, or CVS won'=
t be
able to detect changes you make.
You'll have two CVS directories. They contains almost the same file as th=
e
.tgz. Feel free to edit them.
Now, I think that the first issue I will focus on is parallel processing
among different servers, and thus process limitation (in both memory and =
CPU
consume). I'll add one variable to the genetic_egine class (int max_cpu) =
that
will be 1/1000 of CPU timeshare for engine running. I have already a func=
tion
that handles this: implementing it in the genetic engine will be easy. An=
d
I'll have to implement a command to assign cpu shares. I will do that.
Now, I would discuss with you on how to implement populations spreading a=
mong
different servers on the internet. The mechanism to send agents around is
already in: "sage" and "lage" commands (even if it must be tested and
upgraded in some way. I only tested it in GD to disk and back session, no=
t GD
to client or GD to gd. And I have to implement a binary oriented data
transmission; the one it's in now shoud work well in a lot of cases, but =
a
lenght-run indication in the status response before starting sending bina=
ry
data, as in HTTP, is necessary. It's a minor change, we'll discuss it bel=
ow).
I would opt for a master-slave structure, in which a GD (master) splits
population around to other GD (slaves). Slaves can get population descrip=
tion
=66rom master, and they will transfer agents to other GDs on master reque=
ts.
The master-slave structure is (or should be? the point is open) hierarchi=
cal:
fi the AGD sends a pop-slice to BGD, BGD can re-slice its population to a
CGD. BGD will be a slave for AGD, but will be a master for CGD.
The master-slave architecture should be focussed on engines, not on the w=
hole
GD. A GD could serve as a slave for some engines, but could be a master f=
or
other engines; there can be the case where a AGD can send pop-slice to BG=
D
and BGD will have pop-slices running on AGD.
Pop allocation must be decided on a resource availability (cpu power and =
cpu
consumed) and can be finetuned with server commands both on master and sl=
ave
side.
Potential slaves (GDs willing to accept master connections) will signal t=
heir
presence and disponibility to masters using commands as
"slave <address> <cpu-power> <free-cpu> <free-engine>"
This discussion is whole opened, and can be changed.
Another simpler topic is lenght of binary data do be transmissed:
we have to implement a pre-serialize routine whose task is to calculate t=
he
lenght of the resulting stream of a seralize() request. We'll put the out=
put
of this function to the status line of geneticd. Example:
sage 0 1 //saving agent 1 of engine 0
+201-Ok, sending "2053" bytes.
asdfakjsdfhajklsdhfajksdfhklajdhflkjasdf
.... 2053 binary data ...
asdfadfasdf
. //<--- we still continue to put the <CR><LF>.<CR><LF> sequence at the e=
nd.
// not included in the count above.
This is a simple task. If you want, you can familiarize with CVS and
geneticdaemon doing this.
A third "urgent" topic is a strong protocol for reply codes. I just used =
-5xx
for error codes, -501 for command parameter mistakes and +2xx for ok resu=
lts.
We can change it completely, but BEFORE to start programming clients. You
could rationalize this error codes putting them in a .h file (#define
GD_ERR_PARAMS -501 etc.) and reprorgram status replies in the corecmd.c=
pp
file for using this. In the beginning, I did not have an advanced class a=
s
the GStream for output, and I did not had the variable lenght method
GStream::print. So, a reply was just a write(file_descr, buffer,
str(buffer))... using something like "%d error: can'tdo", ERR_CODE, was a
waste of time... now it's necessary. If you want, you can start from here=
, to
familiarize with GD command parsing system.
A fuorth topic is on new engines, to be put in separate plugins.
A fifth topic is about supporting cooperatives population types: I just
developed a population that can evolve a "BEST" agent among the others. B=
ut
we can have an higher degree of powerful engines if we develop a "colony"
based genetic system. We'll discuss them later.
Enough for now.
=46rom now on, we'll use the mailing list provided by source forge (I'll =
tell
you when it will be ready, but will be SHORT), so our discussions will be
recorded, and readable for other developers joining later.
Let me know if you want to take care of 1) pre_serialize() method and '+x=
xx
"xxx" bytes to be sent in' replies and / or #define REPLY codes, so I won=
't
do that.
Let me know about your ideas for 1) sharing populations and 2) cooperativ=
e
engine types.
And finally, let me know if you want to develop or just have an idea for =
new
plugins.
Great to have you in my project,
Giancarlo Niccolai.
-------------------------------------------------------
|
