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

[Dan Corkill]

> 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 blackboard 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.

You could back the send and processing received changes (as you suggest 
above) or you could have them asynchronous (keeping the original control 
loop above).

> 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 blackboard as part of the control shell loop.

GBBopen's Agenda Shell handles asynchronous events.  At the start of the 
cycle, the events that have occurred since the last cycle are processed for 
the current cycle.  New events are buffered until the next cycle.  (Note 
that it is possible to have an event cause early termination of an 
executing KSA--see the :abort-ks-execution-example "demo" module for a 
simple example of this.)

Keeping replicated objects synchronized is a big issue (and it is not 
necessarily desirable depending on the underlying reasons for having a 
distributed BB-system application).  Sometimes it is better to share 
"findings/information/ideas" rather than try to maintain synced objects.
In other words: "I know the last thing that you told me about X, but I 
don't have a copy of your X object.  At some point, you might tell me some 
updated information about X (or someone else might tell me more about X); 
but I don't have a copy of either of those X objects.

> 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).

The NetGBB product did support such direct-object mirroring/manipulation (a 
copy of the documentation can still be found on-line at the BBTech 
Corporation's web site: http://BBtech.com/).  However, there are often 
better ways of structuring a distributed BB application.  In addition to my 
"Design Alternatives..." book chapter, I'd recommend the following:

"Functionally Accurate, Cooperative Distributed Systems," Victor R. Lesser 
and Daniel D. Corkill. IEEE Transactions on Systems, Man, and Cybernetics, 
SMC-11(1):81-96, January 1981 
(http://dancorkill.home.comcast.net/~dancorkill/pubs/smc-fac.pdf).  This 
article described the advantages of not maintaining distributed consistency 
in some types of distributed applications.

"Distributed Interpretation: A Model and an Experiment," Victor R. Lesser 
and Lee D. Erman. IEEE Transactions on Computers – Special Issue on 
Distributed Processing, Volume C-29, Number 12, IEEE Press, pp. 1144-1163. 
1980 (ftp://mas.cs.umass.edu/pub/lesser/LesserIEEE1980.pdf).  The very 
first distributed blackboard-system application.

"Collaborating Software: Blackboard and Multi-Agent Systems & the Future," 
Daniel D. Corkill. In Proceedings of the International Lisp Conference, New 
York, New York, October 2003 
(http://dancorkill.home.comcast.net/~dancorkill/pubs/ilc03.pdf).  This 
invited ILC'03 talk includes a discussion of the relationship between 
blackboard systems and multi-agent systems (especially about multi-agent 
systems where the agents are each a complete blackboard system--some of the 
first "software agents" we're exactly that).

-- Dan





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