[Pipet Devel] A couple o' BL questions

jarl van katwijk jarl at casema.net
Sun Jun 25 17:18:05 EDT 2000


>
> 1. Is the planned order of implementing things like you have specified
> in the numbering of the things to do (ie. first AAA, then Brokering,
> then Optimization/GA stuff)? It seems like this makes sense, since the
> AAA stuff is kind of what we already have in the idl, combined with
> the internal authentication system you've been talking about. Then we
> need to figure out what is going on with remote applications, etc. I
> was just curious about the development plan.

I planned my todo list in this order:
    1. Remove all fixed stuff in GMS, which I've finished coding and is being
debugged atm. (It had some consequences so it took a lot more work as I had
fought)
    2. Link to Overflow libraries (compiling GMS sources as C++, writing code
that communicates with Overflow, etc.)
    3. Debug \ extend the threading.
    4. Implement the AAA according to the Piper DL-BL idl.
    5. Write BL->BL communication code (plugins that are KQML compliant)

After these points there's more work todo, but I am not sure about the order
here:
    6. Batch code
    7. GAP engine

>
> 2. How does KQML, which you mentioned really wanting to use before,
> fit into this framework? Is this planned to be used for communication
> within the BL, remote communications, etc. etc. Just curious how this
> fits in.

See 5. of the TODO.

>
> 3. In the optimization section you wrote: "Note this system  requieres
> a network of SINGLE type nodes, the +/- 120 diff. node types of the PL
> can never be 'compared' to each other." Can you explain more about
> what you are talking about here? I don't really understand your idea
> for a 'single' type node, and how this will fit in with the framework
> on how things working in the PL right now.

With the term 'single type object' I mean a system that is based on ONE object
type,
opposing a system that consists of many different type.  GMS is based on the
object
(which OOP people would call a 'structure') messaging_object, and no other type
is used for node representation.

Why I do this? The BL will need to optimize resources like load \ space \ time \
bandwidth
etc. and NOT the actual data processing. In other words: the BL wont take heed
of
what is going on, but how things run. The 'value' of a node depends on the
resources it
consumes, not on what it does to the data it contains.
To compare these values they must represent the same node type. Nodes with high
values (weights) require less resources and will be scheduled on systems that
have
high load, and nodes with low weights are redirected to systems with lot of idle

resources. Each [time frame] the weights for all BL nodes are recalculated and
rescheduled accordingly.

So the BL will handle this situation:
(1) Network definition (UI\DL) -> (2) BL nodes resources consumption  ||  (3)
net system resources <- (4) gross system resources
('->' = 'results into' or 'simplicity', and '||' is the contradicting border
between two interests)

Recalculation of the weight will be based upon (2) and (3), but will be
influenced by (1) and (4) indirectly of course.


Am I being clear? I probably forgot some critical element that's obvious to me,
so feel free to ask more details if you're interested. I wont answer till
wednesday,
I'm gone now to catch my plane... and miss the Euro2000 match
TheNetherlands-Jugoslavia :((

bye,
jarl






More information about the Pipet-Devel mailing list