One of the main principles of agent-oriented modeling is agent’s proactivness - living and acting continuously on its own. Technically, this means that the piece of code is running in a kind of loop receiving messages, acting upon them and sending out other messages. This is the heartbeat of each agent.

The most naive approach is to run a piece of code as a separate process (or thread). The code spins a loop where it receives messages, dispatches them and sleeps for some time. You could see such a pattern in some of the previous posts ( Pattern: Agent Life Cycle).

Another approach is to use scheduling. An agents schedules its next activities to certain times. This approach is usually advantageous for long- and sparsely-running agents. A good example can be monitoring agent, a news-sending agent, or even plain-old UNIX maintenance scripts, etc..
Here, again, we can choose from two methods of scheduling:

The agent determines only the very next time of its execution.

The agents uses a full static schedule - execution plan.

The former method is very dynamic, flexible allowing the agent adopt its behavior immediately. However, it can be vulnerable to possible errors. An error can cause the agent won’t register anymore. In fact it becomes dead. The later method is predictable and suitable for static environments.

In the rest of this post I demonstrate how easy it can be to operate a cron driven “agent” directly from your Ruby code.

Cron Scheduling

You can decide to use Ruby native scheduler (like rufus-scheduler), or rely on an external service (like Unix Cron, or other dedicated middleware). This time I show you how to engage with Unix Cron scheduling (next time I tell you more about other schedulers.) Well, for simple cases you can edit cron manually, i.e. install your schedule using crontab. But for more complex and dynamic cases this is a pain in the ass. Imagine you have dozens (or hundreds) of autonomous agents running on your system, or you have very frequent schedule modifications. The CronEdit library help us out here.
Install it as a gem:

CronEdit library associates each cron entry with an id. This makes it uniquely manipulable and not interfering with other entries. It is because the rest of the actual crontab is left unchanged. So you can manipulate the crontab as comfortable as it was a Hash. Your cron entry definition itself can have a standard cron text format, or alternatively you can use Hash notation. Let’s look at few simple examples.

The first line registers a cron entry in standard text notation under id ‘agent1 ‘. The second line registers entry ‘agent2′ using Hash notation. The last line deletes both entries. The changes are effective immediately. You can list all actual entries by:

p Crontab.List

Batch/transactional updates
In case you need to do more changes at once use the following approach

Bulk update/removal using file definitions
In more complex scenarios (communities of agenst) you often need to manipulate more agents at once with their definitions in files. Imagine you have a crowd of news-gathering agents and mail-analysis agents. The cron definitions for these groups are stored as files (previously generated by CronEdit)

The first line uses FileCrontab to read the cron definition of all news-gathering agents. The file crontab is merged in to the actual system crontab on the next line. Similarly the definitions can be ‘unloaded’ using ’subtract’ method.

The library allows you do even more (e.g. when you definitions are in DB; combining multiple definitions)
See more examples and documentation.

In the next posts I present another simple piece of the infrastructure helpful for this type of agents.

Solution: The solution is to set a timeout for a read or take operation, where the timeout value specifies how often a flag appearance should be checked, and if the flag is presented to perform the flag specific operation.

The Agent Life Cycle pattern is, of course, used too.

(life cycle and boolean flag patterns)

loop do
begin
read or take n-tuple with timeout t1

rescue Rinda::RequestExpiredError
begin
read the flag n-tuple with timeout t2
perform a flag specific operation
rescue Rinda::RequestExpiredError
perform an operation when the flag is not set
end
next # repeat the loop
end

Comments:
The method process should execute agent’s duty :), there is only questionable, if it should:

start a new thread, to process the loaded n-tuple, and immediately listen for a next n-tuple

or it should process the loaded n-tuple, and when the processing is finished, to start listening for a next n-tuple.

I would prefer the second way - it is more agent-like, it is not mixing threads and agents concepts (including managing agents vs managing threads) - if you would like to process more n-tuples in parallel, simply start another agent instance.

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 231 - 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:

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

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 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 32nd 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.

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

A blackboard is a place to share tuples; agents are writing, reading and taking tuples.

If you have a simple system, where agents are using only one kind of messages, it is enough to use a single, e.g. [1], ['Hello']. But what to do, if your system requires to differentiate more types of messages? Well, there is no problem with writing different types of messages, but there is a problem how to find the correct one to read or take it.

Basically there are two possibilities:

Every type of a message has different number of elements. The number of elements is the distinguishing sign.

Example: [1] is similar to [2] or ['Hello'], but it is different then [3, 'Hello'].

One of the parameters is an identifier. The number of elements and an identifier are the distinguishing signs.

Example: [:request, 1, 2] is similar to [:request, 24, 'John'], but it is different to [:result, 42, 'London'].

How are the blackboard operations using tuples?

The write operation writes a tuple (specified as a parameter).

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

Reading operations read and take use tuples in a slightly different way. It is possible to use the nil value as a wild card for the position, where it is used.

To read any single:

ts.take [nil], 0

To read any pair:

ts.take [nil, nil], 0

To read any :message type:

ts.take [:message, nil], 0

To read any pair, where the second element has value 4 (not very practical example :):

ts.take [nil, 4], 0

To read exactly the tuple [:result, 4]:

ts.take [:result, 4], 0

The second parameter says, how long (in seconds) should a read operation wait until a tuple appears on the blackboard. Zero means to not to wait at all.

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.