[Gbbopen-list] Multi-node support in GBBopen?

[Christian Lynbech]

Since this can of worms has been opened, I would like to present some
ideas I have for how to construct a multi-node blackboard
application. Any kind of feedback is very much appreciated (even if this
is just the dumbest approach you have ever heard of :-)

MMy interest in a multi-node setup is both scalability (distributing
computation) but just as much robustness (handling failiure of
individual nodes). The underlying assumption is that both the necessary
internode communication and that the number of distributed objects will
be reasonably small.

The idea is basically to make a distributed blackboard such that each
node in the application would run a separate blackboard engine and all
changes to a distributed blackboard would be broadcast to all other
nodes on which instances of that blackboard would be distributed.

If we assume the standard control shell loop looks as follows:

  +-> compute enabled KSs
  |   select KS
  |   run KS
  +---+

then the loop would be changed to something like the following, for the
control shell in each black board instance:

  +-> integrate changes from other nodes
  |   compute enabled KSs
  |   select KS
  |   run KS
  |   compute changes
  |   broadcast changes to other nodes
  +---+

This way, all objects on the distributed blackboards would effectively
be duplicated on all other nodes while each KS can still run against a
local blackboard as usual. Since objects are duplicated, the information
would live as long as just one node is alive.

Obviously there are many problems in this, including: the broadcast
mechanism would need some sort of reliability, the KSs operating on the
distributed blackboards would need some protocol to ensure who will
operate on what objects, we need to be able to track what changes a KS
makes to a distributed blackboard, some sort of conflict resolution is
necessary when multiple nodes tries to update the same (distributed)
object. I am also unsure what would happen if more changes are added to
a black board as part of the control shell loop.

Some of these issues would be coded up in KSs, such as object grabbing
and conflict resolution, not that it would be directly easy but it
should be doable.

I do not really know how this compares to the options outlined in
"Design Alternatives..." but as I remember the GBB documentation, the
idea was more to have a direct "remote object" manipulation protocol
where a KS on one node would explicitly manipulate objects on other
nodes where I think the approach outlined above makes a least the
distribution more automatic (the complexity obviously just crops up in
other places).


------------------------+-----------------------------------------------------
Christian Lynbech       | christian #\@ defun #\. dk
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
                                        - petonic at hal.com (Michael A. Petonic)

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.