Channeled multicast for group communications.
Multi-agent systems can benefit from the possibility of broadcasting messages to a wide audience. The audience may include overhearing agents which, unknown to senders, observe conversations and, among other things, pro-actively send suggestions. Current mainstream agent communication languages however lack adequate support for broadcasting. This paper defines the requirements for a form of broadcast that we call channeled multicast, whose distinguishing features include the ability to distinguish streams of messages by their theme, and to address agents by their characteristics. We present an implementation based on multicast IP, called LoudVoice. We show how channeled multicast could be used in alternative to matchmaking, and present in some detail a broadcast-based version of the English Auction Interaction Protocol. Finally, we discuss how we use the ability to overhear conversations in order to build innovative applications and we present a case study which is a testbed for various types of agents and multi-agent systems.
INTRODUCTION
While developing some collaborative, distributed applica-
tions, we realized that many multi-agent systems would ben-
et from the possibility of broadcasting messages to a wide
audience, which may include overhearing agents unknown
to the senders. We even based an abstract architecture [5]
on the ability of observing conversations without being in-
volved. However, it has been convincingly argued that current
mainstream agent communication languages, in addition
to poorly supporting broadcasting, lack an adeguate
group communication semantics [15].
The goal of this paper is to present a communication frame-work
that supports a form of broadcast which we call channeled
multicast. We developed an implementation of channeled
multicast, called LoudVoice, based on multicast IP.
We will discuss how we used this framework for rethinking
some traditional protocols and supporting an innovative approach
to multi-agent system design. As mentioned above,
a cornerstone of this approach is the ability to \overhear"
conversations and indeed, this has eectively dictated the
requirements for channeled multicast.
This paper is organized as follows: Section 2 denes the
requirements for channeled multicast. Section 3 brie
y introduces
one of the main drivers for channeled multicast, the
overhearing architecture. Section 4 describes our implemen-
tation, LoudVoice. In order to demonstrate the eective-
ness of the proposed framework, Section 5 shows how to implement
matchmaking and the English Auction Interaction
Protocol (standardized by FIPA) using channeled multicast;
the latter protocol is examined in detail. Section 6 speculates
on how channeled multicast enables certain classes of
innovative applications, while Section 7 presents, as a case
study, a part of a larger testbed that we are developing.
Finally, Section 8 points to some related work.
2. CHANNELED MULTICAST
For our applications, we need a communication infrastructure
able to support what we call channeled multicast. This
is based on the concept of channel, dened as a stream of
messages (typically corresponding to speech acts) that may
be listened to by many agents simultaneously. 1 The goal
of channeled multicast is to support observable, real-time,
one-to-many communication, and has the following characteristics

Many channels can co-exist (an implementation may
even support on-the-
y channel creation). All messages
exchanged on a channel relate to a single theme,
identied by an expression in a language of choice of
the implementation. If we suppose that a logic-based
language is used and that the application is an auction
1 The choice of the term \channel" comes from the analogy
with radio { indeed, inspiration came from the idea of a
digital stream describing the contents of a sound stream
being broadcasted simultaneously.
system where channels are identied by the type of sold
items, a theme may look like: (contents (modernArt)
and (item (painting) or item (statue))), identifying
a channel dealing with modern art pieces, and
specically paintings or statues.
Every message contains its specic destination. This
may be one or a group of agents. A group address
may take dierent formats: (1) a simple list of agents
{ e.g., (painting-auctioneer, statue-auctioneer);
(2) the name of a team, or other type of identiable
community { e.g., Auctioneer Syndicate; (3) an expression
(in a language of choice of the implementa-
tion) of the characteristics of the intended audience
{ e.g., partipant(auction,#5) and country(Italy)
identies the set of all participants to a given auction
who live in Italy. In this paper, we represent \all listeners
currently tuned on the channel" with everybody.
Every message contains its sender and its private contact
address (i.e. the end-point of a standard point-to-
point network, such as KQML [8] and FIPA [9],[10]).
Agents can \tune" into as many channels as they like,
both to listen, and to send messages (speak ). An agent
tuned into a channel receives all messages sent on it, no
matter what their specic destination. Some form of
restrictions may be applied (e.g., message encryption),
for security or application specic reasons.
From what has been sketched above, it follows that { dier-
ently from blackboards or facilitator-based infrastructures
(e.g. [6]) { a channel is \neutral": it does not route messages
to their \best" destinations, nor does it help in coordinating
activities. Listeners must be ready to receive messages
that they do not know how to handle, and dispose of them
properly, in particular when they have been implicitly addressed
(e.g., messages sent to everybody). A proper choice
of channel themes alleviates these issues, and helps selecting
the \right" audiences.
Also, a channel is not generally required to guarantee deliv-
ery, nor to have store-and-forward capabilities, nor to alert
speakers of the absence of listeners (application dependent
considerations may require these features to be supported,
however). Finally, channeled multicast is not an alternative,
rather a complement, to standard point-to-point communication

As discussed in Section 4, channeled multicast can be implemented
on top of a distributed event service. What it
adds is an explicit distinction between the stream of communication
(the channel, equivalent to a set of event types)
and the destination of messages. A message can be heard by
everybody, but is normally addressed only to a subset of the
audience. This allows us to properly support the semantics
of group communication described by Kumar et al [15].
3. OVERHEARINGONCHANNELEDMUL-
The requirements for channeled multicast derive from the
abstract architecture described in [5, 16], based on the principle
of overhearing. Its objective is to enable unplanned,
so-called \spontaneous" collaboration in an agent community
by means of unobtrusive observations and unsolicited
suggestions.
For performance as well as a clean breakdown of function-
ality, the architecture identies a special agent role, the
overhearer, whose goal is to listen to one or more channels
on behalf of others, analyze the contents of all messages
being exchanged and forward whatever information is rele-
vant. To obtain this service, interested listeners subscribe
to overhearers by passing one or more queries on the message
contents. The query language depends on the chosen
may vary from simple pattern expressions, to
modal languages that enable temporal or knowledge-based
reasoning (one is described in [16]), to the specication of a
mental state (e.g., a belief) held by speakers as abducted by
the overhearer. Based on these subscriptions, overhearers
select and forward messages of interest to their subscribers,
even if the latter are not the intended destinations of the
messages.
Normally, communication between overhearers and their subscribers
is private, i.e. on point-to-point connections. Thus,
subscribing with overhearers diers from directly tuning on
channels for two main reasons. The rst is that messages
are ltered based on their contents. The second is that subscribers
do not need to access the underlying multicast net-work
(which may suer limitations, or simply be inconvenient
for mobile systems such as PDAs).
In the architecture described in [5], the main subscribers
are the so-called suggesters, which are agents whose role is
to give suggestions on the topics of the conversations being
observed. Suggestions are typically informative messages,
which can be sent either directly to the parties involved (via
point to point communication) or on channels, thus making
them public.
4. AN IMPLEMENTATION: LOUDVOICE
Channeled multicast can be implemented in several ways.
For instance:
by using a broadcast communication layer. This is
the solution we adopted, and that is discussed in some
detail below;
by adopting a star network topology with a \concen-
trator" in the middle: a speaker sends its messages
to the concentrator, which in turn forwards it to all
connected listeners. Note that this is just a simplied
variant of a facilitator-based architecture such as [6];
by means of a distributed event service system: common
object-oriented middleware based on RPC, such
as CORBA or Java RMI, provides services that de-couple
the communication between objects; see for instance
the CORBA Event Service [1] or the RMI Distributed
Event Model [3].
by using a messaging system with a publisher / subscriber
paradigm (a variant of the previous case). The
speaker sends a message to a destination \topic", and
the middleware redirects a copy of the message to
all the consumer that are \connected" to such topic.
Message-oriented middleware compliant with the Sun
JMS (Java Message Service) [4] specication can provide
this kind of service.
The choice is dictated by non-functional requirements, such
as the reliability semantics required by the application. For
instance, JMS or CORBA implementations may guarantee
\at most one" or \exactly one" delivery of messages.
For our applications, reliability is not a concern, while real-time
is. Our implementation, called LoudVoice, uses the fast
but inherently unreliable IP multicast and XML for message
encoding. LoudVoice is language-independent; we currently
have application programming interfaces (API) for Java, C
and C++.
Channels have an identier (a name), a theme and an IP
multicast communication address. For the current imple-
mentation, channel themes are used in a way that reminds
newsgroup subjects. A theme is just a list of strings taken
from an application-specic taxonomy of subjects; this taxonomy
is represented as an XML le accessible to all agents
via its URL. Agents discover which channels are available by
means of an API that has, as one of its optional parameters,
one or more taxonomy elements to be used to select chan-
nels. The taxonomy not only constrains the inputs, but also
allows an extended matching that includes channels whose
themes are either equal or hierarchically in relation (parents
or children) with those requested by an agent. The selected
channels are then returned in order of their closeness to the
input with respect to the taxonomy. For instance, given: a
taxonomy \sport > athletics > f running, marathon, high
jump g"; channel 1 on sport; channel 2 on athletics; and,
channel 3 on running, a client looking for marathon will be
returned channel 2 and channel 1, in that order.
Having discovered a channel, an agent can freely listen and
speak by means of another API. Messages, encoded as XML
documents, have a common header, which includes a per-
formative, sender and destination. In accordance to the
requirements, the destination is a list of strings that either
identify specic agents or teams, or, are elements of a taxonomy
of \topics of conversation". The latter type of address
is matched by listeners against their own private list of inter-
ests, using a variation of the algorithm for theme matching,
in order to understand if they are part of the intended audience

Figure

1 summarizes the sequence of steps carried out by an
agent to use LoudVoice.
Internally, LoudVoice utilizes a server which has various ob-
jectives: maintaining the list of channels, answering discovery
requests, broadcasting messages (optionally repeating
them periodically), and so forth. The server receives requests
from clients on UDP socket. Messages to be broadcasted
on a channel are sent to its multicast datagram socket
specied by a class D IP address. This means that each
message is received by an arbitrary number of clients. This
mechanism is inherently unreliable. The order of delivery
is not guaranteed, and messages may be dropped. Also,
broadcasting is limited by the conguration of the routers;

Figure

1: Using LoudVoice
this limitation, though, should be overcome by the diusion
of IPv6 [2], which will include multicast addressing over Internet

LoudVoice also includes overhearer agents, in order to support
the architecture mentioned in the previous section. Currently
we have only one type of overhearer: a simplied version
of the Ontological Overhearer described in [16]. The
language for subscription is based on simple taxonomies,
rather than the more complex ontologies described in [16].
Taxonomies are passed by subscribers with their subscription
query, and describe the possible contents for messages
the subscriber is interested in; matching is performed against
the full message contents by using another variation of the
algorithms adopted for channel discovery. As an extension
to [16], subscribers can also dene lters on senders and
destinations of messages.
5. RETHINKING TRADITIONAL PROTOCOL

Well-known multi-party protocols can be eectively implemented
by means of broadcast communication (such as channeled
multicast) and overhearing. We elaborate here on two
cases: matchmaking and the English Auction Interaction
Protocol.
With channeled multicast, matchmaking { a traditional cornerstone
of many agent communication infrastructures [18]
{ may be easily implemented without a centralized match-
maker. Thanks to the capability of service providers to listen
to all the request messages on the channels, they can
autonomously reply proposing their particular service fea-
tures. A simple, but by no means only, way to do this is
to have service providers subscribe with an overhearer by
providing the attributes of their services as the pattern to
be matched. Thus, matchmaking happens when an agent
needing a service sends a request for providers with certain
expected attributes to everybody. Matching providers, no-
tied by the overhearer, reply by proposing themselves. The
requester subsequently chooses which one to use.
Moreover, if replies to service requests are sent back on
the channel rather than privately, an observer may trivially
build up a database of existing providers, and possibly
enrich it with further observations on the following interactions
among providers and their clients. This could become
a base for a broker or a recommendation system. One
may envisage additional types of services beyond traditional,
ontology-based matchmaking or brokering, e.g. agents reformulating
requests when a requester's terminology does not
match with any of the services, agents helping with decompositions
of complex requests, and so on. All of these services
take leverage on the observability of communication,
on knowledge-level analysis of communication (in terms of
speech acts as well as message contents), and even on human
involvement when appropriate. Machine learning may also
be applied to deal with unknown messages and interaction
styles.
We used channeled multicast to implement a variant of the
English Auction Interaction Protocol standardized by FIPA
[12]. We present here our protocol, which is signicantly
more e-cient than the original, while Section 7 elaborates
on how overhearing can enrich the functionality oered by
an auctioning system.
Conceptually, the English Auction Protocol can be described
as follows: an auctioneer seeks to nd the market price of
an object by initially proposing a price below that of the
supposed market value, and then gradually raising it. Each
time a price is announced, the auctioneer waits to see if
any buyer signals its willingness to pay the proposed price.
As soon as one buyer indicates its interest, the auctioneer
issues a new call for bids at an incremented price. The auction
continues until nobody is willing to buy, at which point
the auction ends. The auctioneer then decides whether or
not to sell, depending on the nal accepted price.
For each round of the auction, FIPA prescribes that the auctioneer
rst sends a call-for-proposal message (\cfp act" in
FIPA terminology), with the proposed price, to each participant
(i.e., potential buyer); then, everybody interested
sends back a \propose" message for declaring its bid; nally,
before moving to the next round, the auctioneer replies to
each \propose" specifying whether a participant's bid has
been accepted or not.
Since FIPA assumes point-to-point communication, the auctioneer
has to identify all potential participants before-hand,
and it has to keep them informed on the state of their bid.
The latter requirement arises because each participant needs
to know if it is competing against someone else { ideally,
even against who one is competing, which may be important
in a competitive scenario { in order to decide whether
it is necessary to increase its bid to win the auction.
Using channeled multicast oers two main opportunities:
rst, reducing the total eort (including the number of mes-
second, increasing the social awareness of an auc-
tion's progress. Indeed, when the auctioneer starts the pro-
cess, it can assume that everybody potentially interested is
tuned into the channel; after participants have placed their
bids, they know that everybody knows how many competitors
{ and who { are involved in the auction. Of course,
channeled multicast alone cannot guarantee common knowledge
(as dened in [13], i.e. perfect distribution of infor-
mation). However, the protocol we describe below is meant
to approximate common knowledge for most practical engineering
purposes. Most importantly, the two-phase termination
not only closely mimics human auctions, but signi-
cantly reduces the chances of uncorrect termination due to
lost messages.
Our protocol prescribes that, for each round of the auc-
tion, the auctioneer sends a single call-for-bid message over
a channel. This call contains the proposed price, as well as
the name of the winner of the previous round (normally, the
rst participant to submit a bid), so everybody is updated
with the current situation of the auction. After receiving
the call, a participant can propose its bid for the current
price by replying on the same channel.
The auctioneer waits to receive bid proposals from partic-
ipants. After that at least two bids have been received {
which means that there is competition among participants
{ the auctioneer sends a new call-for-bid at a higher price;
any further bids for the previous price that arrive late are
simply ignored.
If only one, or no bid has been received within a certain
amount of time, the auctioneer resends its call-for-bid and
waits again. The reason for this repetition is to prevent a
wrong termination of the auction due to loss of messages,
either from the auctioneer or a participant: if the probability
of missing a message in a round is p, this two-phase
termination process reduces this probability to p 2 . At the
end of the second phase, if still nobody or only one participant
has sent its bid, the auction ends and the auctioneer
announces the winner, which is the only one bidding at the
current round, or the winner of the previous round if none. 2
Overall, the protocol requires only four types of messages:
Init Auction, sent by the auctioneer to declare the start
of an auction and to give information about the item being
sold; Propose Bid, sent by the auctioneer with the current
price and the winner of the previous round (nobody
at the rst); Accept Bid, sent by a participant accepting
a price; End Auction, to proclaim the winner. Figures 2
and 3 contain the nite state machines for auctioneer and
participant in UML-like format. For simplicity, the rst is
shown without states and transactions needed to implement
the two phase termination.

Figure

2: English Auction - Auctioneer FSM (sim-
plied)
For the sake of completeness, let us compare the semantics
dened by FIPA for one of their messages with ours. In
2 If there is only one bidder, i.e. no competition, it is not
rational to go to another round, since it will go deserted {
the only bidder will not run against itself. If the price is too
low compared to the auctioneer's expectations, the latter
will refuse to sell, and possibly start a new auction from a
higher price.

Figure

3: English Auction - Participant FSM
the FIPA specication [12], Accept Bid is represented by
a propose act, whose semantics { formally dened in [11] {
includes the following eect:
I j
i.e., if the agent j (who did a previous call for proposal)
commits to the intention of having i doing act, then the
agent i (performing propose) commits to the intention of
doing act. In our case, i is the bidder, j is the auctioneer,
and act is purchasing the item being sold at the currently
proposed price.
Our protocol also uses propose for Accept Bid, but its
semantic is extended as follows (terminology and formalism
are a simplication of Kumar et al. [15]):
where, interpreted in our specic example:  represents the
bidder,  represents the auctioneer,
represents all the
agents tuned on the channel, e represents the event of
being announced as auction winner, and q represents the
intention of  of buying the item from  at the currently
proposed amount of money. Informally, the semantics is:
(i.e., the bidder) informs  (the auctioneer) that it is willing
to commit to q (the intention of buying this specic item at
the current price) conditional to e (i.e.  declares that
is the winner). At the same time, a group belief is established
within
(all listeners) about the commitment of  to
q conditional to e.
In summary, in this simple case the semantic dierence between
FIPA and our protocol is that the belief about somebody
bidding at a certain price is a group belief rather than
a belief held by the auctioneer only. Of course, this saves us
the need for the additional messages prescribed by FIPA.

Figure

4 compares the number of messages exchanged with
the FIPA interaction protocol and ours as a function of the
total number of participants to an auction, assuming that,
at each round, 25% of the participants leaves the auction.
We tested our protocol using LoudVoice. Dierent channels
were used to run auctions for dierent types of items (cars,
art, etc. Every item was represented by a unique identier,
a description, its type, and had a base price. For our tests,
we developed an auctioneer agent whose goal was to sell
a list of items, and whose behaviour was represented by
a function that, given the current price of a type of item,
returned its incremented price for the next call-for-bid. A
participant agent had a list of types of items to buy, an
amount of money and, for each item type, a limit on the

Figure

4: English Auction - Msg for num of participant

price to pay and a \priority" value that determined which
items to buy rst.
Our benchmark consisted of an auctioneer handling 10 auctions
simultaneously, 4 participants and 4 channels; each
participant was tuned into two channels, and participated
to all auctions on them. We set the decision making time
to zero, that is, there wasn't any waiting time between receiving
a Propose Bid and replying with the corresponding
Accept Bid. The various software components involved were
distributed on four computers connected by a 100Mb Ethernet
LAN. Table 5 refers to a running test period of 20
minutes during which all the participants accepted the new
price of every call-for-bid (i.e., no upper bound on the money
to spend). The \message received" row reports, for the auc-
tioneer, all replies correctly received from participants and,
for the participants, all messages from the auctioneer as well
as those from other participants. Note that all the auctions
running regularly, in spite of some messages being lost;
this was possible thanks to the two-phase termination described
above.

Table

1: English Auction - Statistics
Auctioneer Partecipants
Messages sent 2307 9164
Messages received 9117 9197
Messages Lost 0.5% 0.3%
CPU Load < 3% < 3%
6. IDENTIFYING INNOVATIVE USES
The previous section focused on how to use channeled multi-cast
to deliver some traditional services. We speculate here
on some additional services that would be hard to implement
if only point-to-point connections were available; a case
study is presented in next section.
Some services that would greatly benet from channeled
multicast and overhearing come easily to mind. These include
monitoring (i.e., tracing an agent's actions), proling
(i.e., classifying an agent with respect to some criteria), and
auditing (i.e., making sure that no organizational rules are
violated). They are based just on the observation of other
agents, without need to interfere with the agents' activities.
Reports here are usually made to humans. Thus, it is possible
to add (or remove) these kind of services while the
system is running.
Some other services are less obvious: recommendation sys-
tems, enforcement of social rules (by inhibiting inappropriate
behaviour, or requiring approval prior to the execution
of certain tasks on behalf of other agents), and so on. As in
the previous cases, this class of services are made possible
throught the observability of communication, and somehow
facilitated by protocols based on speech acts, which allow for
simplied analysis of intentionality. There is a fundamental
issue, however: a recommender or rule-enforcer agent
must be able to interact with the agents being observed,
which in turn must be able to handle conversations that are
asynchronous with respect to their main interactions and
sometimes unforeseeable at design time. Designing systems
that adapt on-the-
y to unknown agents, functionality or
protocols and are able to revise their own mental attitudes
accordingly is non-trivial, of course. The abstract architecture
presented in [5] is a framework for dealing with these
challenges. Its cornerstone is the availability of public models
of agents interacting on a channel. Also, [5] speculates
on computational models that support intention revision effectively

There is one class of agents, however, that oers interesting
opportunities with a limited eort. We call these agents
user assistants. They have limited or adjustable autonomy,
and are typical of knowledge-driven business applications or
other systems often categorized under the accomodating umbrella
of \knowledge management" or \decision support".
Distinguishing feature of a user assistant is its sophisticated
human-computer interface, that allows its user to obtain domain
information and to perform actions based on what has
been found. The assistant acts as an \intelligent" intermediary
with other system components and agents. An example
is in the next section. We also built dynamic Web systems
based on the principles outlined below.
User assistants easily benet from overhearing because part
of the decision making is left to humans. To this end, a user
assistant must be able to handle a language for suggestions
directed not to itself, but to its user. These suggestions are
expected to be information, unsolicited and unforeseen in
their format and content, pushed by external observers as
relevant to the specic context in which the user is acting.
The language for the suggestions is meant to help the assistant
in ltering, categorizing and presenting suggestions,
and nally discarding them when no longer relevant. In the
system described in the next section, suggestions include
business intelligence reports on items and participants in active
auctions, and complement the information made available
to the user by her assistant.
Sophisticated agents may accept languages that { in combination
with appropriate computational models, descriptions
of organizational roles and other information { allow them
to in
uence their behaviour. For instance, a language may
contain statements that cause the suspension of an agent's
current operations until the human has acknowledged the
received information or otherwise acted upon it (e.g., by
obtaining authorizations from third parties).
7. AN EXAMPLE OF OVERHEARING
We elaborate on the English Auction Protocol presented in
Section 5, to show how auctioneers and bidders can ben-
et by somebody overhearing auctions. What follows is a
partial description of a testbed for on-going experimentation
on agents, overhearing, Web searching and publishing,
e-services, human/computer interfaces, and other related ar-
eas. Work is still in progress, and many components are in
their early stages of development.
The system supports human-supervised auctions. In other
words, auctioneers and participants acting on a channel are
special cases of users assistant agents, as dened in the previous
section. Each assistant shows to its user any relevant
information about current auctions (items being sold, prices,
and so on). The user then makes decisions and submits goals
to her assistant. For instance, auctions are started by providing
a description of the item being sold, its initial price,
the increment at each round of the auction, and other parameters
such as timeouts between rounds. In addition to
information on the progress of their current intentions, assistants
are able to show any suggestion that comes in.
The user interface of an assistant is a sort of control console
(Fig. 5), where information on the goals currently pursued
(e.g., participating to an auction) is always visible, while side
frames contain action buttons and summaries of incoming
suggestions. The user can browse the full text of any of
these as well as reports on the current state of the running
auctions. At any time, the user can stop the intentions being
executed by her assistant or change its goals.
To enable some of the functionality described below, we
require that, before selling or bidding, users declare their
identities to their assistants. In turn, assistants make their
users' identities public on the selected channels by means of
a \hello" message.

Figure

5: Screenshot { Auctioneer
We are implementing agents overhearing auctions with different
aims, focusing on dierents aspects and dierents
audiences (auctioneers, bidders, potential bidders). As a
running example, let us consider an auction for the famous
painting \The Kiss" by Gustav Klimt.
The Credit Rating Agent's main goal is to provide reports
on the nancial situation of participants to auctions. The
objective of overhearing by this agent is to help auctioneers
in understanding who is bidding, and possibly in selecting
a winner or refusing to sell. The Credit Rating Agent accesses
information either publically available or stored in local
databases. This information may include lists of bankrupts,
previous transactions in the auction system, articles on the
press concerning nancial situations, results of Web searches,
and so on. Suggestions by the Credit Rating Agent are reports
of ndings, written as Web pages whose URL and title
are sent privately to auctioneers via point-to-point connec-
tions. In a real system, suggestions by this agent and others
presented below may be paid for, for instance when accessing
the reports. In the example of the auction for the painting
\The Kiss" { a very expensive item { the auctioneer can
take advantage from a report by a Credit Rating Agent on
the fact that a certain bidder X is notoriously bankrupt and
has no known nancial support. The auctioneer can decide
to exclude X from the auction, or alternatively grant victory
to Z, which another report says to be a relative of Mr. Bill
Gates, or change the price increment between rounds if all
participants seems to be extremely rich, and so on.
On the opposite side, the Auctioneer Monitor observes the
activity of auctioneers in order to prole their tipical behaviour
or discover other information (for instance, the quality
of items on sale, price / performance ratio, press reports
on the items and auctioneer herself). The collected data
is used to create reports and is proposed as suggestions to
bidders for current auctions in the same way as done by the
Credit Rating Agent. In our auction for \The Kiss", participants
can benet from knowing that this painting is kept
in a museum of Vienna and cannot be on sale, or that the
painting was stolen from the museum just the day before the
auction, or, viceversa, that the auctioneer is a very serious
art expert often selling important pieces.
An Auctions Monitor uses overhearing to know which auctions
are active and to collect some basic statistics on recent
auctions, such as average price per class of item and average
time needed to conclude. It spontaneously sends a report
to any new user willing to participate or sell. Monitors may
specialize on specic classes of items. In our example, one
can envisage a situation where a very rich paintings enthusiast
has just tuned on the channel and declared her identity.
She receives a report from an Auction Monitor saying that
the sale of "The Kiss" is close to its conclusion, with information
on the current price and participants as well as other
trends of the auction. Our hypotethical art lover can then
quickly decide to participate.
Finally, an Opportunity Recognizer is an overhearer (as dened
in Section 3) specializing in analyzing auctions. Its
query language allows it to select Init Auctions and Propose
Bids based on the item being sold, their price and other
characteristics. Rather than connecting to a channel via a
normal user assistant, a user may activate a simple \spy"
agent (possibly running on her PDA, or even a latest generation
mobile phone) for subscribing to an Opportunity
Recognizer in order to be notied of auctions on items of
her interest. In our example, somebody interested in buying
just a reproduction of \The Kiss" for not more than 30$
probably doesn't want to tune on a channel for a long time,
let alone during the auction for the real painting. Instead
she may be ready to activate a user assistant when her spy
alerts her of a sale of a batch of prints by Gustav Klimt.
8. RELATED WORK
Some general purpose communication systems related to
channeled multicast have already been identied in Section
4. There is a plethora of agent communication infras-
tructures, but we are not aware of anything directly com-
parable, for two main reasons. Firstly, it is commonly required
that agent communication is somehow reliable (even
if many systems fall short of supporting common knowledge
[13] because their underlying connection-oriented pro-
tocol, TCP/IP, does not really guarantee anything apart
from the correct order of transmission of messages) while
channeled multicast is not. Secondly, channeled multicast
supports a feature shared only with broadcasting systems,
that is, unconstrained ability for authorized users to listen
to anything being communicated by anybody to anybody
else.
In our opinion, overhearing is widely applicable, even if this
requires some changes in the way multi-agent applications
are conceived. As a matter of fact, overhearing is already
being used in some domains, either implicitly or explicitly,
but supported via traditional agent communication systems.
An extended review is outside the objectives of this paper,
however it is worthwhile to give some examples just to explain
how channeled multicast can be benecial.
A rst example is monitoring the activity of other agents,
or even of teams of agents; see, for instance, [14, 19]. Monitoring
is critical, for example, for visualization [17], identication
of failures, or simply to trace teams activity. One
possible approach (report based monitoring) requires each
monitored agent to explicity communicate its state to the
monitoring system. Clearly, if reporting is done by means of
channeled multicast, the amount of communication needed
is xed, no matter how many monitoring agents (possibly
tracking dierent aspects) are active at any given time. System
performance is then unaected by monitoring, and for
the same reason monitoring does not interfere with dynamic
team changes (addition or removal of agents) since no registration
or similar activity is needed. In the same way,
other type of approaches to monitoring [14], based on the
observation of agent communication, can take advantage of
channeled multicast.
Another class of applications where channeled multicast can
provide advantages is human-computer collaborative sys-
tems, such as QuickSet [7], an agent-based, wireless, collab-
orative, multimodal system that enables multiple users to
create and control military simulations by using speech and
gesture. Sensor-to-application communication (e.g., speech
or gesture recognition) could be protably based on channeled
multicast, improving scalability especially when an unknown
number of applications may be interested in overhearing
(or overseeing) what users are doing in order to collect
information or provide suggestions.
9. CONCLUSIONS AND FUTURE WORK
We presented the requirements for a group communication
infrastructure that we call channeled multicast. Its distinguishing
features include the association of channels with
themes of conversation, and addressing groups by means of
some common agent characteristics. Our implementation,
called LoudVoice, is based on IP multicast. Communication
on channeled multicast is assumed to be unreliable (which
is especially true of LoudVoice); however, we have shown
that it is possible to design agent-level protocols that are
robust in the event of failure as well as highly scalable, as
demonstrated by our implementation of the English Auction
Protocol.
Our investigation into group communication has been triggered
by the idea of overhearing and unplanned collaboration
as an innovative paradigm for multi-agent system
design. Observable communication channels change some
of the traditional requirements of multi-agent system (e.g.,
the availability of a matchmaker), and make it easier to
build systems by incremental development, i.e. by adding
new agents whenever additional functionality is required
or new technology is available. We presented, as a case
study, an experimental environment built on top of Loud-
Voice where typical knowledge management operations intermix
with group activities.
For the future, our work will follow two main lines. The
rst focuses on engineering issues: for instance, supporting
group privacy and better APIs for LoudVoice. The second
line focuses on background research issues for overhearing,
including mental attitude recognition, languages for unsolicited
suggestions and intention revision.
10.

ACKNOWLEDGEMENTS

We thank Mattia Merzi, for helping with the experimentation
of LoudVoice; Mark Carman, for his accurate review of
the paper; and Paolo Avesani, for suggesting the idea from
which this work originated.
11.



--R

CORBA Event Service Speci
IPv6 Related Speci
Java RMI Distributed Event Model Speci
JMS (Java Message Service) Speci

An open agent architecture.
Multimodal interaction for distributed applications.

Foundation for Intelligent Physical Agents.
Foundation for Intelligent Physical Agents.
Foundation for Intelligent Physical Agents.
Foundation for Intelligent Physical Agents.
Knowledge and common knowledge in a distributed environment.
Monitoring deployed agent teams.
Semantics of agent communication languages for group interaction.

Visualizing and debugging distributed multi-agent systems
Brokering and matchmaking for coordination of agent societies: A survey.
Tracking dynamic team activity.
--TR
Knowledge and common knowledge in a distributed environment
QuickSet
KQML as an agent communication language
Visualising and debugging distributed multi-agent systems
Monitoring deployed agent teams
Design and evaluation of a wide-area event notification service
The JEDI Event-Based Infrastructure and Its Application to the Development of the OPSS WFMS
Extending Multi-agent Cooperation by Overhearing
Semantics of Agent Communication Languages for Group Interaction
Ontological Overhearing

--CTR
Francois Legras , Catherine Tessier, LOTTO: group formation by overhearing in large teams, Proceedings of the second international joint conference on Autonomous agents and multiagent systems, July 14-18, 2003, Melbourne, Australia
Stephen Cranefield, Reliable group communication and institutional action in a multi-agent trading scenario, Proceedings of the fourth international joint conference on Autonomous agents and multiagent systems, July 25-29, 2005, The Netherlands
Gery Gutnik , Gal Kaminka, Towards a Formal Approach to Overhearing: Algorithms for Conversation Identification, Proceedings of the Third International Joint Conference on Autonomous Agents and Multiagent Systems, p.78-85, July 19-23, 2004, New York, New York
Ben-Asher , Shlomo Berkovsky , Yaniv Eytani, Management of unspecified semi-structured data in multi-agent environment, Proceedings of the 2006 ACM symposium on Applied computing, April 23-27, 2006, Dijon, France
Adrian K. Agogino , Kagan Tumer, Handling Communication Restrictions and Team Formation in Congestion Games, Autonomous Agents and Multi-Agent Systems, v.13 n.1, p.97-115, July      2006
Oliviero Stock , Massimo Zancanaro , Paolo Busetta , Charles Callaway , Antonio Krger , Michael Kruppa , Tsvi Kuflik , Elena Not , Cesare Rocchi, Adaptive, intelligent presentation of information for the museum visitor in PEACH, User Modeling and User-Adapted Interaction, v.17 n.3, p.257-304, July      2007
auction protocols;group communications;overhearing;broadcasting;agent communication languages;multicasting