Peer-to-peer and agent-based computing Agent communication (Contd)

peer-to-peer and agent-based computingAgent communication

(Cont’d)

peer-to-peer and agent-based computing 2

Constructing Conversations• Conversations are patterns of message exchange:

– Order of messages and their inter-relationships– E.g., you can only say “yes/no” if you are asked!

• An engineer could give agents– Information on the semantics of messages in an ACL,

and– The planning capability to ensure that effective

interaction protocols arise spontaneously,but this is hard (impossible?) to do…

• Do the things we say always mean the same?


Contextual MeaningJohn: “Where will you put the garbage for me to take

out tomorrow morning?”Mary: “Behind the back door as usual.”

John: “Where did you put the garbage?”Mary: “Behind the back door as usual.”

• Are Mary’s commitments the same?


Protocol Specification• Conversation protocols:

– Avoid computational overhead of agents building conversations “on-the-fly”

– Provide contextual meaning of utterances• How do we specify conversations?

– Generic/expressive (i.e., capture large classes of conversations)

– Robust (i.e., allow for exceptions without breaking)• Let’s look at some proposals:

– Finite automata– Agent UML– Dooley graphs– Electronic institutions

• Sample conversation 1:1. Receive a number of offers2. Choose one of them and accept it3. Reject the others

• Sample conversation 2:1. There is an auctioneer w/ something to sell2. There is at least one buyer3. The auctioneer broadcasts a price to all buyers4. A buyer may accept the current price

– In this case, the conversation is over!5. If no-one accepts the current price, then the auctioneer

decreases it by 10%– In this case, the conversation carries on from step 3


Protocol Specification (Cont’d)


Finite Automata• A finite automaton (FA) is defined as:

– a finite set of input symbols I– a finite set of states, S (a subset of which are final states),– An initial state q0 S– a “next state” function next : S × I S

• FAs specify communication protocols – A state in S denotes the state of the protocol, and– The symbols in I are messages.


Finite Automata: Example 1I = {A:ask_if (q),B :tell (q),B :tell (q)},

– A and B are agent identifications– q is some proposition, that is, a fact about the world (e.g., “the

fish is fresh”).S = {1,2,3,4}, where 3 and 4 are terminal states, q0=1next(1,A:ask_if (q)) = 2 next(2,B :tell (q)) = 3 next(2,B :tell (q)) = 4

• Graphically:

1

2

A:ask_if (q)

B :tell (q)

B :tell (q)

3

4


Finite Automata: Example 2

1 2

B:counter(_)

B:accept(_)

A:propose(_)

3

4

5

A:counter(_)

B:reject(_)

A:accept(_)

A:reject(_)


Finite Automata: Strengths• Simple, natural representation of relationships

between utterances• Input symbols map naturally to speech acts.• Easy to detect (non-)conformance

– A conversation conforms to the protocol if, and only if, it represents a path through the graph from the initial state to a final state

• States through which dialogue progresses are clearly identified– Including initial and final states


Finite Automata: Limitations• Structure on input symbols to indicate who is speaking

– E.g., B :tell (q)• Difficult to model conversations involving arbitrary numbers

of agents– E.g., there should be 3-5 participants.

• No representation of evolution of conversation• Only captures “legal” messages

– No exception handling!• Scalability: Realistic conversations can be complex

– “Spaghetti” diagrams


Agent UML• www.auml.org (various contributors)• AUML Protocol Diagrams (PDs)

– Extension of UML sequence diagrams.– Specify partial order of messages of participants

• Participants may be – A role (all agents taking on that role) or– A specific individual

• PDs may represent multiple threads of interaction for each participant


Threads of Interaction• A participant may have

various choices in the messages it sends.

• The behaviour of the recipient depends on the incoming message(s).

• PDs represent this different behaviour through multiple threads (AND, OR or XOR).

query

proxy

inform

inform


Agent UML: Example

cfp

deadline

reject-proposal

accept-proposal

refuse

not-understood

propose

failureinform-done

inform-ref

Manager Contractor


Agent UML: Strengths• Familiar representation• Availability of UML design tools• Transitions map cleanly to speech acts• Easy to detect (non-)conformance• Participants involved clearly identified• Captures the inherently multi-threaded nature of

agent communication• Communication with all agents taking on some role

may be represented


Agent UML: Limitations• No existential quantification over agent groups

– “At least one agent must reply to this message”• No representation of evolution of conversation• Only captures “legal” messages

– No exception handling!• Scalability: Realistic conversations can be complex

– “Spaghetti” diagrams• Maintenance difficulties


Dooley Graphs• Proposed by R.A. Dooley (1976)• H.V.D. Parunak used for agent protocols (1996)• A Dooley Graph is:

– A set of indexes E denoting acts (speech & non-speech acts),– A set of participants P (the nodes)– A set of triples A (the arcs) connecting

the sender (participant pi sending utterance k) and the recipient (participant pj receiving k):

A = {pi, pj, k : pi , k S and k, pj R}– A relation M from S R to S R defining the vertices of the graph.

These represent the links between arcs (acts)


Relations Between Acts• M captures various forms of relation between acts.

– A question is intended to solicit a certain kind of response from the recipient.

– An appropriate inform may resolve this question as well as being an appropriate reply

• Similarly, a commit or a refuse utterance may resolve and reply to a request

• The performance of the act to which an agent has committed completes that commitment


Dooley Graphs: ExampleI Act RT RE C1 Request: send

10 widgets by Friday

2 Commit: price is 50

1 1

3 Refuse 1 1

4 Ship 1 2

5 Pay 4 4 A

B

C

12

1

4

3

5

RT: Replies toRE: ResolvesC: CompletesI: Index

Participants = {A, B, C}


Dooley Graphs: Strengths• Extends advantages of FAs:

– Participants involved & states of conversation clearly identified

– Captures multiple threads of interaction– Relations between utterances not limited to precedence

• E.g. an utterance can resolve a commitment made by another– Potential for exception handling


Dooley Graphs: Limitations• No representation of agent groups

– No quantification over groups of agents– Specific utterances may be sent to multiple recipients,

though• Scalability: Realistic conversations can be complex

– “Spaghetti” diagrams• Maintenance difficulties


Electronic Institutions• Formalism to specify global protocols

– At the lowest level, it uses FAs– Sophisticated protocols are broken down into simpler

ones with some “coherence”– Simplest protocols are called “scenes”


Electronic Institutions (Cont’d)• Formalism for specifying MASs (and agents)

– Non-deterministic finite-state machine– Labels are illocutions

si sjinform(buyer,seller,ok)

inform(buyer,seller,not_ok)

inform(buyer,seller,offer(10))


Electronic Institutions (Cont’d)• Components:

– Scenes – where interactions take place– Transitions – connections among scenes– Roles (of a scene) – generic label for agents

• Sample scene (graphic format): agora room

0 1 23

w0 w1 w2

Entry point Exit point

Initial state Final state


Electronic Institutions (Cont’d)• Sample EI (graphic format):

t2Agora Room

Settlementt3Admission

t4

t1 Departure

Root Scene Output Scene

Transitions


Electronic Institutions (Cont’d)• EIs – rich, expressive formalism:

– Scenes provide self-contained modules– Transitions prescribe conditions for agents to move

among scenes– Roles are generic identifiers for agents


Electronic Institutions (Cont’d)A distributed implementation:

Tuple Space

Information Models

Electronic Institution

Rules of Behaviour

Externalagent

Externalagent

Externalagent

…

InstitutionManager

GovernorScene

Manager

TransitionManager

Governor

Governor

…

SceneManager

SceneManager

…

…TransitionManager

TransitionManager


Electronic Institutions (Cont’d)• Demo:


Resolved Limitations• Scalability

– Number of participants– Number of possible states

• Maintenance– Extending and combining existing conversation protocols

• Flexibility– Movement between conversations


FIPA ProtocolsFIPA protocol specifications:

– Request Interaction– Query Interaction– Request When Interaction– Contract Net Interaction– Iterated Contract Net Interaction– English Auction Interaction– Dutch Auction Interaction– Brokering Interaction– Recruiting Interaction– Subscribe Interaction– Propose Interaction

Available athttp://www.fipa.org/repository/ips.php3


FIPA Protocols (Cont’d)Request Interaction Protocol (IP)

– Two agents:• Initiator• Participant

– Initiator agent requests a Participant agent to perform some action

– Participant agent processes request• Decides to agree or refuse request• If decision is refuse, then “refused”

becomes true & Participant sends refuse

• Otherwise, “agreed” becomes true and Participant sends agree


FIPA Protocols (Cont’d)• The Contract Net (CNET) protocol:

– High-level protocol for cooperation through task sharing– Inspired by the way companies put out contracts:

1. Agent starts up the protocol when it recognises it cannot carry out some task.

2. Agent communicates with other agents and advertises a task announcement, then acts as a manager of that task

– Broadcast, a limited broadcast or point-to-point messaging3. Agents listen to the task announcements and evaluate them with

respect to their capabilities and resources– When they find a task suited to them, they place a bid– A bid indicates what the agent can do and the associated costs

4. The manager receives all the bids and selects the one(s) it prefers or needs and tells the agents of its decision.


• The Contract Net (CNET) protocol:Communication protocols (Cont’d)

I have a problem…

(a) Recognising the problem

(b) Task announcement

(c) Bidding

(d) Awarding the contract


FIPA Protocols (Cont’d)Contract Net Interaction

Protocol:– Standardised by FIPA– One-to-many protocol– Extended UML


Suggested Reading• Agent Communication Languages: The Current

Landscape. Y. Labrou, T. Finin, & Y. Peng. IEEE Intell. Systems, March/April 1999.

http://doi.ieeecomputersociety.org/10.1109/5254.757631 • Agent Communication Languages: Rethinking the

Principles. M. P. Singh. IEEE Computer. Dec. 1998.http://www.csc.ncsu.edu/faculty/mpsingh/papers/mas/computer-acl-98.pdf

• Agent Communication Languages. T. Finin & Y. Labrou. Tutorial ASA/MA. 1999.http://www.cs.umbc.edu/~finin/papers/asama99tutorial.pdf

Documents

Peer-to-peer and agent-based computing Agent communication (Contd)