jade-develop mailing list archive: RE: [jade-develop] Ordered S

Subject: RE: [jade-develop] Ordered Sequence of Agents and their behaviours
From: David (amdawong@cyberway.com.sg)
Date: Tue Mar 04 2003 - 04:58:40 MET

Many thanks to all for the insights given. In fact, I am so thrilled by
the advice because I have to implement both Fabio and Elias model of
multi-agent auctions.

I agreed Elias with your point but the solution you propose solves a
slightly different problem, i.e. synchronizing until at least 1 seller
and 1 buyer is registered with the DF, not synchronizing until exactly
those 20 sellers and those 20 buyers are registered which was what I
understood David wanted to do.

Yup, that was exactly what I had wanted to do. I need to implement this
in the PoolCo model of a Electricity Market. It is a model that everyone
submits their reserved price and quantity of sale to the PoolCo Manager.
To be fair to the rest of agents ( who has not submitted yet), the
PoolCo Manager will not process the bids until either

1. all the 20 sellers and 20 buyers are registered with the DF (
and thus with the PoolCo subsequently) OR,
2. the deadline for all auction submissions are due.

This is because if the PoolCo manager were to process the bids of those
who submitted earlier, it would be an unfair advantage for those who
submit earlier. These agents who submitted earlier and get an earlier
reply from the PoolCo Manager will have more time to strategise their
next round of bidding ( using JESS) price and quantity. This system is
somewhat similar to application to universities where applications MAY
NOT be process until the deadline is up OR they know that no further
applications ( ie similar to the situation where all buyers and sellers
have registered) will be received.

However, Elias has got a very strong point on

"The requirements specification problem rears its head yet again...
Regardless, I should think that the most desireable overall system
behavior is one where buyers and sellers are 'introduced' to eachother
as soon as their respective matching interests are identified by the
AuctionManager. It then becomes the responsibility of the buyer and
seller to negotiate an acceptable exchange"

I need to implement ANOTHER model for these auctions which is called the
Bilateral Contracts model.
In this model, any sellers or buyers is free to approach each other to
arrange their contracts independent of the PoolCo bidding system.
In this case, Elias's model would be ideal since we would want the
buyers and sellers to introduce themselves to each other as soon as
their interest matches.

Many thanks to both's feedbacks and comments. I will make the relevant
implementations for each of my auction/contract negotiation model.
In my opinion, both suggestions of implementing the 20 sellers and 20
buyers are equally good. It is depends which model of auction/contract
negotiation that one is trying model using agents.

Once again, many thanks.

Cheers!!

Regards
David

-----Original Message-----
From: jade-develop-bounces@sharon.cselt.it
[mailto:jade-develop-bounces@sharon.cselt.it] On Behalf Of Elias
Sinderson
Sent: Tuesday, March 04, 2003 3:04 AM
To: jade-develop@sharon.cselt.it
Subject: Re: [jade-develop] Ordered Sequence of Agents and their
behaviours

Hello again,

I agreed Elias with your point but the solution you propose solves a
slightly different problem, i.e. synchronizing until at least 1 seller
and 1 buyer is registered with the DF, not synchronizing until exactly
those 20 sellers and those 20 buyers are registered which was what I
understood David wanted to do.
The requirements specification problem rears its head yet again...
Regardless, I should think that the most desireable overall system
behavior is one where buyers and sellers are 'introduced' to eachother
as soon as their respective matching interests are identified by the
AuctionManager. It then becomes the responsibility of the buyer and
seller to negotiate an acceptable exchange...

Of course the second problem is not really a loosely coupled problem.
:-)
Fabio.

P.S.: In your solution I would suggest to change the "fall-off algorithm
which increases the wait duration between retrievals" with simply a
subscription with the DF (see fipa-subscribe and
jade.proto.SubscribeInitiator/Responder protocols).
You are, of course, correct. It is clearly too easy to fall into the
dominant paradigm of synchronous computation...

-----Original Message-----
From: Elias Sinderson [mailto:elias@cse.ucsc.edu]
Sent: 03 March 2003 19:10
To: jade-develop@sharon.cselt.it
Subject: Re: [jade-develop] Ordered Sequence of Agents and their
behaviours
Bellifemine Fabio wrote:

This is a typical synchronization problem between 21 threads where you
want 1 agent A to synchronize with 20 other agents, i.e. A cannot start
its execution until the remaining 20 agents have completed some activity
(in this specific case registering with the DF).
The only way to solve this typical problem is that you use a kind of
rendez-vous agent R where
- A asks R to be informed as soon as the 20 agents have completed their
activity; and then A blocks until R informs A
- the 20 agents inform R that they have completed their activity by
simply sending a message
- R informs A when all the 20 agents are ready by sending a message
again.
I disagree. I'm new to this area, but it seems obvious to me that
agent-based architectures are best designed as loosely coupled,
asychronously driven systems of independent behaviors. Leveraging the
asynchronous nature of agents to build a loosely coupled systems
architecture allows for the maximum scalability possible. Sequential
behaviors, while useful to specify in a single agent (i.e. agent A must
complete behavior b1 before attempting behavior b2), are the antithesis
of scalable distributed systems architectures.

One should attempt to make no assumptions about the presence of other
agents or the availability of services within a system. To do so simply
invites problems such as deadlock that can be very difficult, if not
impossible, to reason about formally in any system of interesting* size.

Instead of taking the approach of mandating sequential relationships
between the AuctionManager and the Buyer/Seller agents, for example, I
would recommend that if the AuctionManager retrieves null lists of
Buyers/Sellers it simply wait a period of time for some to register. A
fall-off algorithm which increases the wait duration between retrievals
to some reasonable value until the Buyers/Sellers have registered, and
perhaps decreases the wait duration during periods of heavy use, would
be most appropriate in this scenario and more closely models the
behavior you are looking for.

* 'Interesting' being operationally defined as on the order of tens of
thousands of agents or more.

Many thanks to all for the insights given. In fact, I am so thrilled by the advice because I have to implement both Fabio and Elias model of multi-agent auctions.

Yup, that was exactly what I had wanted to do. I need to implement this in the PoolCo model of a Electricity Market. It is a model that everyone submits their reserved price and quantity of sale to the PoolCo Manager. To be fair to the rest of agents ( who has not submitted yet), the PoolCo Manager will not process the bids until either

all the 20 sellers and 20 buyers are registered with the DF ( and thus with the PoolCo subsequently) OR,
the deadline for all auction submissions are due.

This is because if the PoolCo manager were to process the bids of those who submitted earlier, it would be an unfair advantage for those who submit earlier. These agents who submitted earlier and get an earlier reply from the PoolCo Manager will have more time to strategise their next round of bidding ( using JESS) price and quantity. This system is somewhat similar to application to universities where applications MAY NOT be process until the deadline is up OR they know that no further applications ( ie similar to the situation where all buyers and sellers have registered) will be received.

However, Elias has got a very strong point on

“The requirements specification problem rears its head yet again... Regardless, I should think that the most desireable overall system behavior is one where buyers and sellers are 'introduced' to eachother as soon as their respective matching interests are identified by the AuctionManager. It then becomes the responsibility of the buyer and seller to negotiate an acceptable exchange”

I need to implement ANOTHER model for these auctions which is called the Bilateral Contracts model.

In this model, any sellers or buyers is free to approach each other to arrange their contracts independent of the PoolCo bidding system.

In this case, Elias’s model would be ideal since we would want the buyers and sellers to introduce themselves to each other as soon as their interest matches.

Many thanks to both’s feedbacks and comments. I will make the relevant implementations for each of my auction/contract negotiation model.

In my opinion, both suggestions of implementing the 20 sellers and 20 buyers are equally good. It is depends which model of auction/contract negotiation that one is trying model using agents.

Once again, many thanks.

Cheers!!

Regards

David

-----Original Message-----
From: jade-develop-bounces@sharon.cselt.it [mailto:jade-develop-bounces@sharon.cselt.it] On Behalf Of Elias Sinderson
Sent: Tuesday, March 04, 2003 3:04 AM
To: jade-develop@sharon.cselt.it
Subject: Re: [jade-develop] Ordered Sequence of Agents and their behaviours

Hello again,

Bellifemine Fabio wrote:

The requirements specification problem rears its head yet again... Regardless, I should think that the most desireable overall system behavior is one where buyers and sellers are 'introduced' to eachother as soon as their respective matching interests are identified by the AuctionManager. It then becomes the responsibility of the buyer and seller to negotiate an acceptable exchange...

Of course the second problem is not really a loosely coupled problem.

:-)

Fabio.

P.S.: In your solution I would suggest to change the "fall-off algorithm which increases the wait duration between retrievals" with simply a subscription with the DF (see fipa-subscribe and jade.proto.SubscribeInitiator/Responder protocols).

You are, of course, correct. It is clearly too easy to fall into the dominant paradigm of synchronous computation...

Elias

-----Original Message-----
From: Elias Sinderson [mailto:elias@cse.ucsc.edu]
Sent: 03 March 2003 19:10
To: jade-develop@sharon.cselt.it
Subject: Re: [jade-develop] Ordered Sequence of Agents and their behaviours

Bellifemine Fabio wrote:

in my opinion using timers, wakerbehaviours, ... is not a solution.

I agree.

This is a typical synchronization problem between 21 threads where you want 1 agent A to synchronize with 20 other agents, i.e. A cannot start its execution until the remaining 20 agents have completed some activity (in this specific case registering with the DF).

The only way to solve this typical problem is that you use a kind of rendez-vous agent R where

- A asks R to be informed as soon as the 20 agents have completed their activity; and then A blocks until R informs A

- the 20 agents inform R that they have completed their activity by simply sending a message

- R informs A when all the 20 agents are ready by sending a message again.

I disagree. I'm new to this area, but it seems obvious to me that agent-based architectures are best designed as loosely coupled, asychronously driven systems of independent behaviors. Leveraging the asynchronous nature of agents to build a loosely coupled systems architecture allows for the maximum scalability possible. Sequential behaviors, while useful to specify in a single agent (i.e. agent A must complete behavior b1 before attempting behavior b2), are the antithesis of scalable distributed systems architectures.

One should attempt to make no assumptions about the presence of other agents or the availability of services within a system. To do so simply invites problems such as deadlock that can be very difficult, if not impossible, to reason about formally in any system of interesting* size.

Instead of taking the approach of mandating sequential relationships between the AuctionManager and the Buyer/Seller agents, for example, I would recommend that if the AuctionManager retrieves null lists of Buyers/Sellers it simply wait a period of time for some to register. A fall-off algorithm which increases the wait duration between retrievals to some reasonable value until the Buyers/Sellers have registered, and perhaps decreases the wait duration during periods of heavy use, would be most appropriate in this scenario and more closely models the behavior you are looking for.

Cheers,
Elias

* 'Interesting' being operationally defined as on the order of tens of thousands of agents or more.