RubyAgent

Operations that access a blackboard to retrieve information, i.e. operations read and take, have a second parameter that defines how long should this operation wait until there will be a matching n-tuple or, simply, timeout. A value of the parameter specifies number of second.

Example:

• To read a tuple and if there is no such tuple, to wait 4 seconds for it:

  ts.read [nil, nil], 4
  

• Or to take a tuple and if there is no such tuple, to wait 1 minute for it:

  ts.take [nil, nil], 60
  

There are two special values that you may use as a timeout value:

• 0 (zero) - an operation would not wait at all. It is useful for checking, if a n-tuple is stored in the blackboard or not.
• nil - an operation would wait endlessly. Of course, there is not difference if you would call an operation without a specified timeout value or with nil.
  Actually, to be more precise, an operation would wait 2³¹ - 1 seconds, that is approximately 30 years. ;)

But what would happen, if we specify a timeout value and an n-tuple would not appear on the blackboard in the specified time(out)?
Rinda throws the Rinda::RequestExpiredError exception.

The handling exceptions in Ruby is very comfortable (esp. with the command retry). An example follows, where a tuple is taken with a timeout 5 seconds. This allows to inform an user about the state, that the application is still waiting for a message:

puts "Waiting for a message."
begin
  t = ts.take [:message, nil], 5
rescue Rinda::RequestExpiredError
  puts “Still waiting for a message.”
  retry
end

The timeout functionality allows to:

• create a responsiveness application - to inform other components or users about its state (e.g. waiting for a message - processing a message).
• end an application normally - to break waiting for a n-tuple every so often and check if the application should end.
• check for different n-tuples - it is possible to wait in deferent intervals for different n-tuples. Of course, a better solution is to create for each n-tuple an own thread that performs a blackboard access operation for this particular n-tuple.
• create an application that does not access a blackboard all the time (e.g. only every hour for 1 minute).

Tags: Introduction, Rinda, blackboard, timeout

Now, we have enough knowledge to create a simple example: a calculator.

The example shows how to:

• Create an agent.
• Locate the blackboard.
• Write a tuple (a calculator operation).
• Take a tuple (a calculator operation result).
• Differentiate between different operations (plus and minus).
• Handle a simple ID.

The calculator agent will be able to handle two kinds of operations: plus and minus. It will receive an operation request tuple, where one item will be an operation identifier (to handle two operations) and two items with numerical values (to transmit values).
The agent will produce a result tuple, where one item will be a numerical value (to transmit back a result value).
To track a result, each operation request tuple will have an ID, that will be inserted back into a result tuple.

To sum up, there will be two tuple types:

• operation request [:calculator, id, operation, a, b], e.g.
  [:calculator, id, :plus, 1, 2] or [:calculator, id, :minus, 6, 2].




• result [:result, id, value], e.g.
  [:result, id, 4].

To run this example, we will need three files: rinda.rb to start the environment, calculator.rb the calculator agent and client.rb to send requests and display results.

The calculator agent source code, calculator.rb:

require 'rinda/ring'
require 'rinda/tuplespace'

# A simple calculator example.
#
class SimpleCalculator

  def plus(a, b)
    a + b
  end

  def minus(a, b)
    a - b
  end

  def main
    DRb.start_service
    ts = Rinda::RingFinger.primary

    loop do
      t = ts.take [:calculator, nil, nil, nil, nil] # take an operation request

      # assign values
      id = t[1]
      operation = t[2]
      arg1 = t[3]
      arg2 = t[4]

      puts “Calculator recived operation ##{id} #{operation} with arguments #{arg1} and #{arg2}”

      res = operation == ‘plus’ ? plus(arg1, arg2) : minus(arg1, arg2) # perform the received operation
      #sleep 1 # to pretend that an operation takes longer

      ts.write [:result, id, res] # send a result back
    end
  end
end

SimpleCalculator.new.main

And the client source code, client.rb:

require 'rinda/ring'

DRb.start_service

ts = Rinda::RingFinger.primary

t1 = Time.now #the start time

# sending operation requests

id = 1 # the ID
for i in (1..5) # plus operations
  puts "Sending operation ##{id} plus with arguments #{i} and 1"
  ts.write [:calculator, id, :plus, i, 1]
  id += 1 # an unique ID value
end
for i in (5..9) # minus operations
  puts “Sending operation ##{id} minus with arguments #{i} and 1″
  ts.write [:calculator, id, :minus, i, 1]
  id += 1 # an unique ID value
end

puts “Waiting for results…”

# receiving results

i = 1
loop do
  t = ts.take [:result, nil, nil], 2
  puts “Result ##{t[1]} = #{t[2]}”
  i += 1
  break if i > 10 # 10 request were sent
end

t2 = Time.now # the end time
puts “The operation took #{t2 - t1} seconds.”

See a screencast

To start the example, firstly start the environment ruby rinda.rb and then start the calculator agent ruby calculator.rb. Each execution of the client, ruby client.rb, will produce 10 operation requests that will be processed by the agent. The agent will produce 10 results, that will be read by the client.

There is a lot of log messages, so you can easily see when an agent instance received a request, when it send a result and when a client send a request and received a result. With the #id part of a log message you can track particular communication parts.

Execution time should be very short, approx. 0.06 seconds.


Let’s imagine that an operation processing would take longer, e.g. 1 second. Uncomment the 32^nd line in the agent source code calculator.rb and restart all parts of the example (rinda.rb and calculator.rb).
Execute the client and the execution time will be, as expected, 10.06 seconds.


And now, to show power of a parallel processing in a multi-agent system, start another calculator agent…

The logs of the started calculator agent instances show that the processing load was nicely shared between the agents.

The result? A half of time (of course), approx. 5.04 seconds.

I like it :)

Files to download: simple_calculator.zip.

Tags: Example, Rinda, take, write

To finish the overview of the backboard operations, let’s show how to use the read operation. It only checks, if a blackboard contains a wanted tuple (in the previous posts I used the term message, but now we are more experienced :).

The following functionalities will be shown:

• Creation of an agent.
• Locating the blackboard.
• Read a message.

The agent source code is stored in the read.rb file:

require 'rinda/ring'

DRb.start_service

ts = Rinda::RingFinger.primary

result = ts.read [:message, nil], 0

puts “[0]: #{result[0]}”
puts “[1]: #{result[1]}”

See a screencast .

Firstly, start the rinda.rb code (for more details see the post about starting multi-agent system environment), then, in a separate console, start the write.rb (for more details see the post about writing a message to the blackboard) and finally, in a separate console or in the same console where you started the write.rb file, type:

ruby read.rb

The agent connects to the blackboard, reads a tuple and shows two lines:

[0]: message
[1]: Hi there!

Of course, you could repeat this step any number of times, because this operation only checks if a tuple is there.

Files to download: rinda.rb, write.rb and read.rb.

Tags: Howto, Rinda, blackboard, read

The Rinda multi-agent system environment is already running, on the blackboard is written a message, so the last step is to read it :)

The following functionalities will be shown:

• Creation of an agent.
• Locating the blackboard.
• Taking a message.

Although a logical opposite operation to the write operation should be the read operation, it is not so in the blackboard system: the operation read only checks if a message is there (this will be shown in a post that will follow); the operation take takes a message from the blackboard.

The agent source code is stored in the take.rb file:

require 'rinda/ring'

DRb.start_service

ts = Rinda::RingFinger.primary

result = ts.take [:message, nil], 0

puts “[0]: #{result[0]}”
puts “[1]: #{result[1]}”

Firstly, start the rinda.rb code (for more details see the post about starting multi-agent system environment), then, in a separate console, start the write.rb (for more details see the post about writing a message to the blackboard) and finally, in a separate console or in the same console where you started the write.rb file, type:

ruby take.rb

The agent connects to the blackboard, takes a message and shows two lines:

[0]: message
[1]: Hi there!

Files to download: rinda.rb, write.rb and take.rb.

Tags: Howto, Rinda, blackboard, take

The Rinda multi-agent system environment is already running, so the next step is to write a message to the blackboard with an agent.

The following functionalities will be shown:

• Creation of an agent.
• Locating the blackboard.
• Writing a message.

The agent source code is stored in the write.rb file:

require 'rinda/ring'

DRb.start_service

ts = Rinda::RingFinger.primary

ts.write [:message, 'Hi there!']

puts ‘Message was sent.’

Firstly, start the rinda.rb code (for more details see the post about starting multi-agent system environment) and then, in a separate console, type:

ruby write.rb

The agent connects to the blackboard and writes a message Hi there!.

Files to download: rinda.rb and write.rb.

For running more processes it is necessary to open more consoles. Applications like screen or konsole on KDE can help you — I use konsole with more sessions.

Tags: Howto, Rinda, blackboard, write

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

Tags: DRb, Introduction, Rinda, blackboard