Archive for the tag 'DRb'

Multi-agent System in Ruby

To build a (simple) multi-agent system, we need at least three functionalities: communication between processes, discovery service and blackboard.

Let’s explain each functionality and show how it is provided in Ruby:

  • Communication between processes. Agents need to communicate with the rest of the world. Otherwise, it will not be possible to say them, what they should do and we will not know, what they did, because they did not present their results. ;) In the previous post, we said that agents are, from the operating system point of view, processes; technically we need a communication between processes.

    This functionality is provided by the Distributed Ruby library. You can find two abbreviations: DRb, dRuby. Both of them refer to the same library..

  • Discovery service. An agent should be able to automatically find other agents or a blackboard.

    This functionality is provided by the Rinda library, by its class Ring.

  • Blackboard. A blackboard is a shared place for exchanging data. It has to comply with the following important requirement: atomic access. What does it mean? If one agent takes a message, another agent should not be able to take the same message, so it will not happen that two (or more) agents received the same message.

    It is provided by the Rinda library, by its class TupleSpace.

Good news: distributed Ruby and Rinda are included in Ruby 1.8. :)

Ruby on Blackboard

The most usual way how to build an application is to create a monolithic system.

The code inside may vary in complexity - from straightforward, a few conditions, to complex with threads.

The next level of complexity is to spread an application into more processes. Communication between processes is more complicated then between threads and usually there is a special layer dedicated to this, e.g. DRb in Ruby or RMI in Java.
And we are only a short remove from a possibility to communicate between processes on different computers. Often the dedicated layers handle this complexity level too.

But on both sides, there are still monolithic sytems, that are only deployed on different computers.

The dialog between processes looks like this:

A: I want to load data with Process 1 on the computer 192.168.0.45.
B1: No response. It seems that the process is busy.
A: I want to load data with Process 1 on the computer 192.168.0.73.
B2: John, 34 years old, London. Susanne, 25 year old, Stockholm.

What would you say, if a situation would look like this?

A: Writes a message “Please, can you send me data?” on a blackboard.
B1: Is busy, so it does not have time to check the blackboard.
B2: Is available, so it erases the messages (to not to bother others with it) and writes the data on the blackboard - John, 34 years old,

What is the difference?

  • In the first situation the communication is pointed and forced. If the answering process is busy, the requesting process has to wait or find another answering process. It has to act actively until a request is transfered.
  • In the second situation, processing are taking tasks, if they are available. The communication is not pointed and forced. The request process does not have to take care about the posted message.

You probably noticed a special word in the second situation - blackboard. It is a shared place for exchanging messages. It allows to post, check for and delete a message.

Applications A, B1 and B2 are autonomous applications performing a task; usually it is a specialised task, so the application is small and simple. These applications are called agents.

An environment that allows to execute agents and provides various functionality such as communication between agents or coordination is called a multi-agent system. (Sorry for a simplification.)

On this blog, you will find how to create agents, coordinate them, how to solve their problems and how to solve problems with them. Oh, I would forget: in Ruby! :)

Welcome to the Ruby Agent a.k.a. Ruby on Blackboard blog :)