A HIERARCHICAL DISTRIBUTED COMMUNICATION

ARCHITECTURE FOR REAL-TIME AUCTIONS

Ilhem Abdelhedi Abdelmoula, Hella Kaffel Ben Ayed, Farouk Kamoun

CRISTAL Lab, ENSI -National school of computer science, University of Manouba, Tunis, Tunisia

Keywords: real-time auctions, e-commerce, distributed architecture, IRC protocol, theory graph algorithms.

Abstract: This paper presents a new hierarchical distributed communication architecture, called AHS (Auction

Handling System), based on clusters. This architecture uses the IRC (Internet Relay Chat) channels and

protocol facilities in order to support real-time auction applications (RTA). Coordination between

distributed auction servers is needed to exchange and update some relevant auction information and to

resolve the winning bid within a cluster. The problem is how to determine the best location of the auction

server coordinator. For this purpose, we suggest the use of the Floyd-Warshall’s algorithm, which is a graph

theory algorithm.

1 INTRODUCTION

Actually, online auction sites are divided into two

categories: the non-real-time auctions (NRTA) and

the real-time auctions (RTA) (Liu and al., 2000).

The most popular online auction sites currently

available on the net are NRTA (Liu and al., 2000)

and (Bougouris and al., 2000), such as eBay,

Amazon, AuctionWatch. These auction sites remain

still different from the conventional face-to-face

auctions. Indeed, they have many limitations: they

suffer from sustainable hardly controlled

information delays; they have usually a long cycle

time which might be risky (Bougouris and al., 2000)

(e.g. an airline company may want to auction the

remaining seats of a flight a few hours prior the

departure); they allow the phenomenon of collusion

among bidders (they have enough time to cooperate

and reach agreements not to outbid each other)

which has the overall effect of lowering the wining

bids (Liu and al., 2000); and they do not allow real-

time bidding (Bougouris and al., 2000) (a bidder

cannot make quick response to market dynamics

even if some pseudo-autonomous bidding).

Besides the real-time features, there are also

distributed concerns that must be taken into

consideration. Indeed, the most well-known auction

web sites, such as eBay (Ezhilchelvan and

Morgan,2001), (Ezhilchelvan and al.,1999) and

(Ezhilchelvan and al.,2000), Amazon (Ezhilchelvan

and al.,2000), FishMarket (Esteva and Padget,

1999), AuctionBot (Wellman and Wurman, 1998a),

(Wellman and al., 1998b) and (Wellman and al.,

1999), Priceline, CNET and E*Trade (Ezhilchelvan

and Morgan,2001), which user domains are typically

large, geographically distributed, rely on only one

central auction server. These auction sites have

serious problems: they are restrictive and non

scalable (Ezhilchelvan and Morgan,2001),

(Ezhilchelvan and al.,1999) and (Ezhilchelvan and

al.,2000) (too many bidders could easily overload

the central auction server). This could result in

performance degradation and perhaps bottlenecks,

which would make the whole auction process

unresponsive and unavailable. Further, an

unreplicated central server would constitute a single

failure point (Ezhilchelvan and al.,1999). These

considerations make decentralisation in auction

system design not only a desirable option but also an

essential requirement.

In this paper, we consider the issues related to

communication services required to support real-

time auctions among distributed auction servers,

which were developed and presented in a previous

study (Kaabi, BenAyed and Kamoun, 2003) as a

distributed communication architecture, called AHS

(Auction Handling System). To support real-time

auction communications, we suggested using IRC

channel and protocols under the AHS architecture.

The communication protocol which supports

interactions between an auction server and many

Abdelhedi Abdelmoula I., Kaffel Ben Ayed H. and Kamoun F. (2005).

A HIERARCHICAL DISTRIBUTED COMMUNICATION ARCHITECTURE FOR REAL-TIME AUCTIONS.

In Proceedings of the Second International Conference on e-Business and Telecommunication Networks, pages 5-15

DOI: 10.5220/0001418200050015

 SciTePress

bidders is defined and implemented in a previous

work (Kaabi, BenAyed and Kamoun, 2003). Here,

we focus on the definition of the architecture of the

distributed auction server system (ASS), which

supports interactions between a set of distributed

auction servers that cooperate in conducting a real-

time auction.

This paper is divided as follows: Section 2

presents a definition of RTA and summarizes their

principal requirements in terms of communication

issues. Section 3 introduces the AHS architecture

and its functional elements and communication

protocols. Section 4 presents a possible architecture

of the distributed Auction Server System (ASS).

Section 5 describes the extended architecture of the

AHS based on clusters and presents a “potential

solution” for the designation of an ASA coordinator.

Section 6 discusses relevant related work. Finally,

section 7 provides some concluding remarks and

future work.

2 REAL-TIME AUCTIONS

2.1 Auction process

Traditionally, an auction process involves three

types of entities: the initiator (I), the bidders (B

) and

the auctioneer (A). It is decomposed into three

principal phases (Kaabi, BenAyed and Kamoun,

2003): the starting phase, the bidding phase and the

settlement phase.

The starting phase begins with the initial buyer

or seller registration (authentication, exchange of

cryptographic keys, etc.), the setting up of an auction

event by the initiator and the auctioneer (description

of the item being sold, setting up the rules of the

auction, the asking price, etc.) and the access of

bidders to an auction event.

In bidding phase, goods are sold in multiple

rounds, governed by a clock (namely, the limited

time interval to make a bid). During each round, the

auctioneer collects bids from the bidders and

validates them according to the auction rules. Once

the clearing time expires, it evaluates all validated

bids and broadcasts back to all the bidders the new

price quote (PQ). At the end of a round, the

auctioneer can either decide to close the auction or,

to initiate the new round auction by quoting a new

PQ.

The settlement phase corresponds to the auction

result notification at the end of the auction. At this

point in time, the auctioneer broadcasts a transaction

notification (TN) to all the bidders and to the

initiator informing them about the “winners” and the

final result.

Here, we describe the most familiar type of

auction process, a multi-round English auction.

Figure 1 shows a message sequence chart for a

possible exchange of bids and price quotes messages

between the entities. In this type of auction, all the

bidders should have always the same view of the

items being sold by auction, and of the proposed

bids. Further, they should have the same

communication delays between them and the

auctioneer, and share the same notion of time

(Panzini and Shrivastava, 1999).

Suppose that if both bidder B

and B

see the PQ at

the same time and submit a bid, the bid from the

closer bidder (B

) may reach the evaluation process

several seconds earlier on the average. Figure 1

depicts a situation in which the remote bidder (B

)

submits its bid before the intermediated clearing

time but this bid is not delivered in time. This bid,

which may be higher than the others, will not be

evaluated by the auctioneer at the current round

auction and may cause a loss of extra profit for the

seller and a loss of ownership for the bidder. Hence,

this delay influences the auctioneer’s service quality

and leads to frustrated bidders who could leave the

auction site. Meeting the deadlines in an auction

activity is not just a quality issue but a correctness

issue (Peng and al., 1998). Our objective is then to

give to all the bidders a fair and equal access to all

of the exchanges.

Figure1

: An English auction process

Access

Bidding

phase

Settlement

hase

Starting

phase

Registrer

1st ROUND

2sd ROUND

3rd ROUND

Intermediate clearin

Final clearin

timeTN

PQ1

PQ2

ICETE 2005 - GLOBAL COMMUNICATION INFORMATION SYSTEMS AND SERVICES

2.2 Characteristics of real-time

auctions

Real-time auctions form a class of online auctions

which have to be processed time-and-price critical.

They include the most common trading models used

in real-life auctions, such as English, Dutch, Sealed-

bid, CDA, and their variations (Vickrey, Yankee,

etc.). Generally, they are present in all industry

market places (see table 1) (Kaabi, BenAyed and

Kamoun, 2002), where goods have a constantly

varying price and or availability; and in stock market

places (Peng and al., 1998) and (Maxemchuk and

Shur, 2001), where data information from the

business environment must be continuously

monitored and processed in a timely manner to

allow for real-time decision over the Internet.

Table 1: Examples for real-time auctions in industry

market places

Kind of

business

Type of

auction

Sector

Description

Forward Agriculture

Any

sectors

Cattle or fish

auctions

Any raw

material market

places

B2B

Reverse Any

sectors

Tenders/pitches

by public

institutions

B2C

Forward Art Art and antique

auctions

For bidders, these auction sites enforce real-time

competitions among them and allow real-time

decisions. For sellers, they prevent the phenomenon

of collusion, as bidders do not have enough time to

cooperate and reach agreements between them (Liu

and al., 2000).

RTA share the following common

characteristics:

- They shall be running in real-time manner (Rumpe

and Wimmel, 2001). Bidders always have current

bidding information visible and receive them in real-

time fashion (Liu and al., 2000). This would reduce

as minimal as possible the delay of transmission of

bids, PQs or the TN between bidders and the

auctioneer. A resource reservation protocol such as

RSVP could be used to guarantee a bounded delay

(Rumpe and Wimmel, 2001).

- They are all time-triggered systems (Wellman and

Wurman, 1998a)and (Panzini and Shrivastava,

1999), having inherent timing constraints as well as

autonomous features on when or how the operations

and interactions that the participants (auctioneer,

bidders or initiator) might perform. To meet

deadlines, such systems must provide a predictable

response time in order to guarantee the correctness

of time-critical transactions (Peng and al., 1998).

- They occur in a short period of time which may

vary from a few minutes (15 min) to a maximum of

three hours (Rumpe and Wimmel, 2001). For

example, a lot may take about 6 seconds to be sold.

This means that the frequency of bids is relatively

high.

- The time duration may consist of a main non

extendable part and an extendable part (Rumpe and

Wimmel, 2001)and 0. Indeed, the auction time is

extended whenever a bid arrives shortly before the

auction end. This allows other bidders to react. The

provided reaction may vary, e.g. starting from 3

minutes as an initial extension down to a few

seconds at the very end (Rumpe and Wimmel,

2001).

2.3 Communication requirements

Several studies have identified multiple

requirements for real-time auctions. Given the fact

that potential participants are distributed globally

and each has a different computing capacity

(operating speed, network bandwidth, etc.), such

applications bring new challenges on

communication issues. In this section, we highlight

some basic requirements described as follows:

- Synchronous mode (Kaabi, BenAyed and

Kamoun, 2003): such as videoconferencing, chat,

etc. could enable real-time interactions between

sellers, bidders and the auctioneer, which results

in increasing the rapidity of decision-making

process.

- A multicast technology (Liu and al.,

2000) ,(Wellman and Wurman,

1998a), 0and (Maxemchuk and Shur, 2001):

enables one copy of digital information sent by

the auctioneer such as bid, PQ and TN to be

received by a group of bidders. Hence, it would

require identifying the group of participants and

broadcasting to them all bid messages. This

would significantly minimize the number of

messages sent regardless of the density and the

dynamic of group membership and would also

optimize the way the bandwidth is used. Still,

there is no guarantee that messages would be

received simultaneously and instantaneously by

all members, which may cause unfair

competitions. Therefore, a RTA requires using a

fair multicast communication protocol.

A HIERARCHICAL DISTRIBUTED COMMUNICATION ARCHITECTURE FOR REAL-TIME AUCTIONS

- Fairness (Peng and al., 1998), (Rumpe and

Wimmel, 2001) , (Kaabi, BenAyed and Kamoun,

2003) , (Ezhilchelvan and Morgan,

2001), (Banatre and al., 1986) and (Maxemchuk

and Shur, 2001): allows bidders to have the same

chance to place their bids, which should be taken

into account fairly by the auctioneer. However, a

bidder who is close to the central server may

have faster access than a remote one, leading to

unfair competitions among bidders.

- Timely delivery and processing (Peng and

al., 1998): the real time bidding process is

interactive: the auctioneer must efficiently and

timely process incoming bids and send the PQ to

all bidders. Each bidder has to make real-time

decisions to submit rapidly a higher bid. This

entails timing constraints for processing these

operations on both sides as well as real-time

communication between them. In the reality,

these messages can take arbitrary time to reach

their destinations and auctions have no control

over data transmission delays (Liu and al.,

2000) ,(Panzini and Shrivastava, 1999)and

(Kaabi, BenAyed and Kamoun, 2003).

Therefore, it would require guaranteeing the real-

time delivery and processing of messages

exchanged between bidders and the auctioneer.

- Time-message validity (Kaabi, BenAyed

and Kamoun, 2003) : usually a bid is considered

time related information where is valid until a

certain time and then becomes obsolete. As a

result, the concept of time-message validity

should be taken into consideration within the

communication protocol. This would allow a

waiting time while the bid is still valid.

- Clock synchronization (Wellman and

Wurman, 1998a) ,(Peng and al., 1998)and 0: In

RTA, the synchronization of client and server

times is essential. For example, the server does

not close the auction if a participant still believes

it is still open. Moreover, in a distributed

environment, clock synchronization is essential

for many real-time and fault-tolerant operations.

Hence, an appropriate protocol must ensure the

temporal flexibility issue, so that bidders’ clock

must be synchronized to auction server’s clock

as well as among auction servers clocks.

- Scalability (Panzini and Shrivastava,

1999), (Ezhilchelvan and Morgan,

2001) ,(Ezhilchelvan and al.,1999), (Ezhilchelvan

and al.,2000) and (Banatre and al., 1986): an

auction system must be extensible and capable of

supporting an increasing number of users (easy

insertion and removal of bidders and/or sellers),

specifically in the last minutes. For example,

more than two-thirds of eBay auctions had bids

submitted less than an hour before the scheduled

end time (about ten minutes) (Ockenfels and

Roth, 2002a)and (Ockenfels and Roth, 2002b). It

must also be able to provide end-users with

satisfactory Quality of Service (QoS), regardless

of their increasing number and their geographical

distance.

- Reliability (Banatre and al., 1986)and

(Maxemchuk and Shur, 2001): a reliable

auctioning protocol should have a bounded and

predictable responsive time. It must deliver the

same message reliably and simultaneously to all

receivers anywhere in the net. When a failure

occurs, bidders and sellers must be able to

continue their participation in the sales; the

transaction time may be lengthened.

- Availability (Panzini and Shrivastava,

1999): The auction service must be

“available”(operate consistently and correctly)

under specified load and failure hypothesis. In a

distributed system context, high availability is

essential; otherwise, the system is doomed to

continuously leak users to other similar systems

with better availability.

All these requirements are highly correlated, but

there are further features that are not described in

this section which relate to issues such as security,

load balancing, concurrency, anonymity, privacy,

etc. Such requirements are considered important in

some specific RTA applications.

3 THE AHS ARCHITECTURE

OVERVIEW

The AHS (Auction Handling System) is a distributed

communication architecture providing real-time

auction applications with specific communication

services, independently of the auction rules.

3.1 Functional components

As shown in figure 2, the AHS architecture is

composed of three functional elements: the BSA

(Buyer/Seller Agent), the ASS (Auction Server

System) and the BS (Bids Store) 0.

ICETE 2005 - GLOBAL COMMUNICATION INFORMATION SYSTEMS AND SERVICES

Figure 2: The AHS architecture

- The BSA is a user agent that can be associated

with a Seller or a Buyer. It helps a Seller to set up an

auction event and possibly to participate in the

bidding process. Or it helps the bidder to participate

in an auction event and submit bids. A BSA is

connected to one ASA (Auction Server Agent),

generally the closest one. However, several BSA

may be connected to the same ASA.

- The ASS is composed by a set of distributed ASA

involved in one or more auction events

simultaneously. Each ASA is associated to an

auction server that holds the auctioneer’s activities.

Cooperation between ASA is needed for the

resolution of the wining bid.

- The BS provides, when required, the capacity of

storing bids, PQs or TNs for further use (message

tracking requirement). The physical location of the

BS is not already specified: it can be situated within

an ASA or a BSA or constitutes a separate entity.

3.2 The IRC protocols

A previous study [18] has compared some Internet

application protocols like HTTP, IRC, E-mail and

NNTP according to basic negotiation requirements

in terms of communication services. It showed that

the IRC protocol is best suited for real-time auctions.

Further, IRC presents many advantages with regard

to real-time auctions:

- It is based on a distributed architecture that

defines two functional components: IRC-Server and

IRC-Client (IETF, 2000a).

- It provides real-time text based conferencing

between IRC clients (IETF, 2000a). This may reduce

considerably the end-to-end transmission delay

between the auctioneer and the bidders.

- Communications are running in a synchronous

mode with a push mechanism (IETF, 2000b).

- IRC channels support multicast group

communication (IETF, 2000c).

- It provides a fair distribution of messages to all

IRC Clients since IRC servers set for them the same

response time (2 seconds) so they are all served

fairly (IETF, 2000b).

- An IRC network configuration is a spanning

tree defined by a group of servers connected to each

other. This logic tree-based structure allows

scalability (IETF, 2000a).

- It can be used to reduce data transmission

delays between auction application layer and the

traffic on the Internet (Kaabi, BenAyed and

Kamoun, 2002).

3.3 AHS communication protocols

The AHS architecture is structured in three layers

(Kaabi, BenAyed and Kamoun, 2003) from top to

bottom, as shown in figure 3: the auction application

layer, the P-auction layer and the IRC layer.

Figure3: The AHS layered model

The P-auction layer provides the auction

application with the required communication

services. It uses the appropriate services provided by

the IRC layer.

As shown in figure 3, three communication

protocols are required to implement AHS

architecture: the BSA-protocol, the BS-protocol and

the ASA-protocol.

- The BSA-protocol specifies the allowed

interactions between a BSA and an ASA involved in

an auction event. This protocol is already specified,

implemented and validated in (Kaabi, BenAyed and

Kamoun, 2003)and (Kaabi, BenAyed and Kamoun,

2004). It is encapsulated within the IRC-Client

protocol.

- The ASA-protocol specifies the interactions

between a set of ASA involved in an auction event

within the ASS. It will be encapsulated within the

IRC-Server protocol.

- The BS-protocol specifies the request-response

interactions between a BS and a BSA. They concern

the storage and the retrieval of bids to/ from the BS

which induce end-to end exchange of messages

through one or many ASA. This protocol will use

the point-to-point communication mode provided by

the IRC protocol.

ASA BSA

ASA

Protocol

BSA

Protocol

IRC

P.auct

BSA

Protocol

ASA

BSA

ASA ASA

ASA

IRC

P.auct

IRC

P.auct

IRC

P.auct

A HIERARCHICAL DISTRIBUTED COMMUNICATION ARCHITECTURE FOR REAL-TIME AUCTIONS

4 THE ASS ARCHITECTURE

In a previous study (Kaabi, BenAyed and Kamoun,

2003), we suggested implementing the AHS over the

IRC architecture, which is a spanning tree (IETF,

2000a)and (IETF, 2000b). Every auction event will

use an IRC-Channel, a BSA/ BS will be

implemented over an IRC-Client and an ASA will

be implemented over an IRC-Server. Figure 4

depicts the logic structure of the AHS architecture:

Figure 4: The AHS logic structure

For example, in figure 4, we suppose that the

ASS is composed by 11 ASAs, supporting the

auctioneer’s activities and are simultaneously

involved in many auction events.

To access an active auction, a BSA must connect

to an ASA participant, if possible, the nearest one, in

order to reduce the data transmission delay. During

the bidding phase, every ASA (e.g. ASA

) must

serve and provide its local BSAs (e.g. BSA

, BSA

)

with the current auction information in which they

are participating. At the end of each round, all ASAs

must cooperate and exchange relevant information

(e.g. bids, PQs) in order to evaluate the wining bid

and calculate the newest PQ.

From the bidder’s side, the ASS represents a

“black box” where the auction process is opaque to

all BSA participants. However, inside the ASS, the

control of the auctioning process is disseminated

among a set of distributed ASAs, which will

cooperate in order to determine together the result of

the auction. From this point, we assume that the

evaluation process is distributed between all ASAs

being part of the ASS. The problem addressed here

is how and when will the ASA participants

cooperate to resolve the winning bid and calculate

the newest PQ for a given auction event? Three

approaches are possible: the centralized approach,

the totally distributed approach and the hierarchical

approach.

4.1 The Centralized Approach

The centralized approach is to consider a centralized

auction server node, called “an ASA

evaluator”(ASA

). Thus, every ASA collects

validated bids from their respective local BSAs and

forwards them to ASA

. When the clearing time

expires, the application within the ASA

runs the

evaluation process to determine the wining bid

according to the auction rules, and then multicasts

back the new PQ to all ASA participants. Figure 5

illustrates the essence of this approach:

Figure 5: A Centralized approach

The advantage of this approach is the simplicity

of keeping track of the auction state. Only the ASA

will know the global auction state and the identity of

the winner’s BSA. The other ASAs would not have

to be involved within the evaluation process.

The drawback is that all communications must

go through the central node (ASA

), roughly 2N

messages are exchanged per round and per auction

event (N is the number of ASA participating to an

auction event). Hence, the complexity is about θ(N).

When the number of participants (BSA) and the

number of auctions grow, the ASA

would constitute

a single point of failure and may become a

bottleneck. This could lead to unfairness,

unresponsiveness and unavailability of the auction

system. Consequently, the ASS will be less scalable:

suited only to small scale auction systems.

For this reason, the best approach would be to

remove the central node and distribute auction

services among all ASA. Two approaches are then

possible: a totally distributed approach and a

hierarchical approach.

4.2 The Totally Distributed

Approach

In opposition to the above approach, no central ASA

evaluator (ASA

) exists. The evaluation process is

decentralized and controlled by all the ASA

participants. Thus, every ASA will act as an ASA

having a replication of all auction services. This

Time

Collection

of local

bids from

BSAi

Validated

bids sent

y ASAi to

ASAe

Evaluation

only on ASAe

ASAe

multicasts

PQ to

ASAi

broadcast

s PQ to

BSAi

START END

One Round

Phase 1 Phase 2

ASA 8

ASA

BSA

Initiator

ASA 3

ASA 7

ASA 2

ASA 4

ASA 5 ASA 6

ASA 9 ASA 11

ASA 10

BSA5

BSA

BSA1

BSA3

BSA 12

BSA2

BSA 4

ICETE 2005 - GLOBAL COMMUNICATION INFORMATION SYSTEMS AND SERVICES

would remove the reliance on the central node.

Figure 6 shows the phases of an auction round in a

totally distributed approach for each ASA involved

in an auction event:

Figure 6: Totally distributed approach

Hence, there are two clearing times per round

corresponding to two evaluation processes on every

ASA, as shown in figure 6. At the first clearing time,

every ASA must validate its incoming bids, evaluate

the wining bid and forward his Intermediate Price

Quote PQ

to all adjacent ASAs. At the second

clearing time, every ASA have to evaluate all the

incoming PQ

and calculate the Final Price Quote

In this approach, the global auction state is

known by all the ASAs being part of the ASS.

Consequently, it would generate a huge amount of

traffic on the Internet, approximately 2 N (N-1)

messages exchanged per round and per auction

event. Hence, the complexity is about θ(N²). This

would also raise the problem of data replication and

may require a high synchronization between the

ASAs because the PQ

has to be unique and identical

on every ASA at the end of the round.

However, this approach could easily achieve the

scalability, the fairness and the availability as the

total load is shared among a set of distributed ASA

rather then being concentrated on a single central

ASA.

Therefore, we suggest an intermediate solution to

reduce the number of unnecessarily sent messages

and enhance system performance: the hierarchical

approach

4.3 The Hierarchical Approach

In the hierarchical approach, we assume that we

have two types of ASA being part of the ASS:

- The ASA participants, who collect validated

bids from their local BSAs, evaluate them, calculate

their local PQ

and then forward it to the ASA

coordinator (ASA

- The “ASA coordinator” (ASA

), who collects

all the incoming PQ

, evaluates them and multicasts

the PQ

back to all ASA participants.

For example, suppose that the ASS is composed

by 8 ASAs as shown in figure 7, and the ASA

represented by ASA

. The latter will receive

respectively all the PQ

from all the ASA

participants (ASA

, ASA

,.., ASA

) before the

clearing time. Then, it will calculate the PQ

and

multicast it back to them. As soon as the ASAs will

receive the PQ

, they will broadcast it respectively to

their local BSAs. The phases of this approach are

described in details in figure 7 below:

Figure 7: A Hierarchical approach

Similar to the second approach, there are two

clearing times per round: the first one is on each

ASA, and the second occurs only on the ASA

. Here

again, the global auction state is known by all the

ASA, yet it generates less traffic then that produced

in the totally distributed approach; nearly 2 (N-1)

messages exchanged per round. The complexity is

about θ(N). Moreover, since the auction services are

replicated on all ASA, the problem of data

replication is also addressed here and requires a high

synchronization between the ASA participants and

the ASA coordinator.

Compared to the first and second approaches, the

hierarchical approach achieves better fairness as the

distance between a BSA and the ASS is minimized.

Therefore, we choose to apply this approach for the

ASS architecture.

5 A HIERARCHICAL

CLUSTERED ARCHITECTURE

When the number of bidders grows wider

geographically and the size of the ASS raises, the

number of ASA sending the PQ

to the ASA

may

Collection

of local

bids from

BSAi

Evaluation

on ASAi

Sending

of PQ

ASAc

One Round

Evaluation

on ASAc

Phase 1 Phase 2 Phase 4

ASAc

multicasts

to all

ASAe

Phase 3

END

Time

roadcast

of PQ

local

BSAi

START

Collection

of local

bids from

BSAi

Evaluation

Multicast

of PQ

ASAi

One Round

Evaluation

Phase 1 Phase 2

Multicast

of PQ

local

BSAi

Phase 3

END

Time

START

BSA

ASA1

ASA 3

ASA 2

ASA 4

ASA 5

ASA 8

ASA 7

ASA 6

ASA Coordinator

A HIERARCHICAL DISTRIBUTED COMMUNICATION ARCHITECTURE FOR REAL-TIME AUCTIONS

become important. Hence, we could fall in the

situation of centralized approach as the ASA

would

constitute the failure point of the ASS. Therefore,

we suggest an extended hierarchical architecture for

the ASS based on clusters where the ASAs are

structured hierarchically in several clusters, as

shown in figure 8.

Figure 8: Hierarchical architecture based on clusters

So that, when the size of ASS becomes

important, it will be divided into many clusters,

where each cluster spans a limited network area

gathering a set of ASAs and one ASA

. The global

auction system would be constituted by a set of

clusters, shown as circles in figure 8, interconnecting

through their respective ASA

(ASA

, ASA

and

ASA

To the outside world, each cluster appears to be a

single system and thus the ASA-ASA

communications will be reduced. Indeed, each

cluster, through its local ASAs, will provide its end-

users with the auction services, which are in its

geographical zone. The rules fixing the number and

the size of clusters will be studied further.

One of the main ideas of cluster computing is to

offer load-balancing, high availability and

scalability. We suppose that this extended

architecture would facilitate the coordination

between all the ASAs being part of the ASS.

However, it would require an inter-communication

ASA-protocol between clusters and an intra-

communication ASA-protocol within each cluster.

The specification of these protocols is under study as

well as the experimentation and the simulation of the

three approaches.

Furthermore, we need to designate one ASA as a

coordinator within a given cluster. The problem is

then how to determine the best location of the “ASA

coordinator”?

5.1 How to designate the ASA

coordinator?

To designate the ASA coordinator- ASAc, two

approaches are possible: The first consists in

dedicating an arbitrary ASA as a coordinator; the

second is to assign an ASA as a coordinator. The

first approach is rejected for many reasons: the

location of the ASAc changes dynamically

according to the number of bidders and the number

of auction events which are drastically increasing.

Consequently, a dedicated ASA will certainly face

request congestion and may become a bottleneck.

That’s why we opt for the second approach. In

this case, we assign dynamically an ASA as

coordinator among all the ASAs being part of the

ASS and within a given cluster. The problem

switches to how to determine the best location of the

ASA coordinator?

5.2 All-pairs shortest-path problem

Based on the IRC architecture, the ASS is a

spanning tree. Hence, it can be viewed as a weighed

connected undirected acyclic graph, noted by G =

(V,E) where V(G) is the set of nodes (ASAs) and

E(G) is the set of arcs (communication links

between ASA).

We denote by (u,v), the arc that connects two

ASAs, u and v of V and we define the weighed

function W : V →IR which associates a weight to

each arc (u,v). We assume that each link joining two

ASA is weighted by the value of the round trip

time/2.

The minimum number of communication links

required to connect all the ASAs is |V|-1. Further,

the path of a message being delivered is the shortest

path between any two ASA on the spanning

tree (IETF, 2000b).

To find the best location of the ASA coordinator,

we consider one assumption described as follows:

within the ASS spanning tree, the ASA coordinator

(ASA

) must be the nearest node to all the other

nodes (ASAs). In other words, the ASA

must

always have the shortest round trip time with all

other ASA in the ASS. This means that we should

resolve a problem of all-pairs shortest-path.

In a dynamic programming domain, a variety of

algorithms can be applied to resolve the all-pairs

shortest path problem, such as Dijkstra's single-

source shortest-path algorithm, Floyd-Warshall All-

Pairs-Shortest-Path algorithm, Bellman-Ford

algorithm, a Slow-All-Pairs-Shortest-Path algorithm,

etc. For our purpose, we choose to use Floyd-

Warshall’s algorithm for several reasons (Corman

and al.,1994). Compared to other algorithms (Faure

and al.,2002), it uses an adjacency matrix

representation and has the best run time, roughly

θ(V

), which can be reduced down to θ(V²).

BSA 1

BSA 4

BSA 3

BSA 2

BSA 5

BSA 6 BSA 7

ASA 1

ASA 3

ASA

ASA 2

ASA 4

ASA 5

ASA

ASA 8

ASA 9

ASA 10

ASA 12

ASA 11

Cluster 2

Cluster 3

Cluster 1

ICETE 2005 - GLOBAL COMMUNICATION INFORMATION SYSTEMS AND SERVICES

Assume that we have an ASS composed of 7

ASA involved in a RTA, forming a spanning tree as

a logical structure, as shown in figure 9 below. The

nodes of the ASS graph are V = {ASA

, ASA

ASA

, ASA

.,ASA

,ASA

ASA

Figure 9: The ASS graph

G is represented by the D

’s adjacency matrix an

7x7 adjacency matrix with the weights of the arcs, as

shown in figure 10.

To determine the best location of the ASA

, we

apply the F-W algorithm to the ASS graph and we

assume that each link joining two nodes (ASAs) is

weighed by the value of the round trip time/2. The

demonstration of this algorithm is illustrated below

by the figure 10.

Figure 10: Demonstration of F-W’s algorithm

This algorithm permits to determine the optimal

node, which is the nearest to all other ASAs and has

the less weight with all nodes. For our case, the node

ASA

is then the optimal node so that it would be

designate as the ASA coordinator within this ASS.

6 RELATED WORK

Several studies deal with distributed system

architectures for online auctions. In the following,

we present two surveys that we think are most

closely related to AHS.

In (Panzini and Shrivastava, 1999), Panzieri and

Shivastra present a replicated auction service

architecture, duplicating the auction services across

a number of distributed auction servers. They define

two communication protocols required for the

implementation of their architecture, namely

Browser-to-Server Protocol (BSP) and Server-to-

Server Protocol (SSP). The former specify the

allowed interactions between bidders and an auction

server and the latter manages the information

exchange among auction servers. The

implementation of these protocols is not presented in

this paper; however several approaches of

implementing them are suggested. For the SSP, they

propose a transactional approach or a group

approach. They also show how they can achieve the

goals of data integrity, responsiveness and

scalability, but they do not discuss the fairness issue.

In (Ezhilchelvan and Morgan, 2001),

Ezhilchelvan and Morgan present a hierarchical

auction architecture for conducting auctions over a

set of distributed auction servers meeting the

requirements of scalability, responsiveness and

service integrity. Auction servers are hierarchically

structured into a number of interconnected local

market servers. This minimizes inter-server

communications and maintains fairness. Moreover,

auction servers are logically structured into a tree,

rooted on a single server in order to ensure the inter-

server communication scalable and the termination

detection efficient. They are partitioned into

multicast groups in order to facilitate dissemination

of shared data. Cooperation between auction servers

is needed to ensure data integrity. To achieve some

reliability issues, the authors propose a framework

for a fault-tolerant implementation of this

architecture by using replication and group

management techniques.

In both studies, the authors define similar

requirements for distributed auction architectures

and address the issues related to online auctions in

general without considering the real-time features.

However, we focus on distributed real-time auction

systems. Moreover, these architectures use the

HTTP protocol, which is considered as a poor

protocol for real-time auctions as discussed in

(Kaabi, BenAyed and Kamoun, 2003)and (Kaabi,

BenAyed and Kamoun, 2004). Furthermore, they

1 2 3

ASA2

ASA

ASA3

ASA 1

ASA 7

ASA 4

ASA 6

A HIERARCHICAL DISTRIBUTED COMMUNICATION ARCHITECTURE FOR REAL-TIME AUCTIONS

support some specific types of auctions such as

sealed-bid auction, open-cry auction and Dutch

auction while the AHS architecture is generic and

handles varieties of real-time auction protocols.

7 CONCLUSION AND OPEN

PROBLEMS

In this paper, we have presented a distributed

communication architecture, called AHS (Auction

Handling System) for real-time auctions. This

architecture is intended to be deployed in a large

scale network and to support real-time interactions

between bidders and a set of distributed auctioneers.

To reach our goals, we chose the use of the IRC

channels and protocol facilities in order to reduce

the data transmission delay and the traffic on the

Internet. Furthermore, we adopted a hierarchical

approach based on clusters because it is supposed to

offer scalability, load-balancing, client fairness, high

availability and reliability. This approach would

facilitate the collaboration between all the ASAs

being part of the ASS. Indeed, within a cluster, one

of the ASAs is designated as a coordinator, who

receives PQ

from ASAs for evaluation and

multicasts the PQ

. To determine the best location of

the ASA coordinator, we suggest using Floyd-

Warshall’s algorithm, a graph theory algorithm in

order to resolve an all-pairs shortest-path problem.

There are a variety of questions left unanswered

by the work described here. Below, we list few

directions for further work in this area. Work is

under way on the specification and the

implementation of the ASA communication

protocol. The interactions between different types of

ASA involved in a distributed real-time auction will

be clarified. The experimentation and the simulation

of the three approaches are under study.

The future direction of this study will include

time synchronization issue, the identification of load

parameters for the creation of clusters and the

implementation of the hierarchical approach.

REFERENCES

Liu, H., Wang, S. and Teng, F., 2000. Real-Time Multi-

Auctions and the Agent Support. Journal of Electronic

Commerce Research, VOL. 1, NO. 4, 2000.

Bougouris, C., Koukopoulos D. and Kallas, D.,1998. A

real-time auction system over WWW, from Internet at:

http://diogenis.ceid.upatras.gr/~koukopou/cnds.ps.,

visited in July 2004.

Wellman, M.P and Wurman, P.R.,1998a. Real time issues

for internet auctions. The 1st IEEE workshop on

dependable and real-time e-commerce systems

(DARE-98), Denver, CO, USA, June 1998.

Peng, C.S., Pulido, J.M., Lin, K.J. and Blough, D.M.,1998.

The design of an internet-based Real-Time auction

system. First IEE workshop on dependable and real-

time e-commerce systems (DARE-98), Denver, CO,

USA, June 1998, pp.70-78.

Rumpe, B. and Wimmel, G.,2001. A Framework for Real-

time Online Auctions, available at :

http://www4.in.tum.de/~rumpe/papers/RW01/RW01.p

df, visited in Marsh 2004.

Panzini, F. and Shrivastava, S.K.,1999. On the provision

of replicated internet auction services. Proceeding of

the 18th IEEE international symposium on reliable

distributed systems, Lausanne, October 1999, pp 390-

395.

Kaabi,S.,BenAyed,H. and Kamoun, F.,2003. Specification

of a communication protocol, based on IRC for real

time auctions. Sixth international Conference on

Electronic Commerce Research ICECR6, Dallas

Texas, pp 129-138.

Ezhilchelvan,P. and Morgan,G., 2001. A dependable

distributed auction system: architecture and an

implementation framework. Proceeding of the 5th

IEEE international symposium on Autonomous de-

centralized systems, Dallas, Texas, April 2001.

Ezhilchelvan,P., Morgan,G., Khayambashi,M.R. and

Palmer,D., 1999. Measuring the cost of scalability for

Internet-based server-centred applications, issued from

Internet.

Ezhilchelvan, P., Shrivastava, S.K. and Little, M.C.,2000.

A model and architecture for conducting hierarchically

structured auctions. May 2000. Available at

www.cs.ncl.ac.uk/people/paul.ezhilchelvan/home.for

mal/published/hierarchicFP.ps

Esteva,M. and Padget, J.,1999. Auctions without

auctioneers: distributed auction protocols, available at

http://www.maths.bath.ac.uk/~jap/Papers/amec99.ps,

visited in July 2004.

Wellman, M.P, Wurman, P.R. and Walsh, W.E.,1998b.

The Michigan Internet AuctionBot: A configurable

auction server for human and software agents. The 2nd

ACM International conference on autonomous agents,

pp.301-308.

Wellman, M.P, Wurman, P.R., Walsh, W.E.,and

O’Malley, K.A.,1999. Control architecture for a

flexible internet auction server.

Banatre,J.P.,Banatre,M.,LapalmeG., and Ployette, F.,1986.

The design and building of Enchere, a distributed

electronic marketing system. CACM Vol.29(1), 1986,

pp19-29.

Maxemchuk, N.F. and Shur, D.H., 2001. An Internet

Multicast system for the stock market. ACM

Transactions on computer systems, Vol 19 N°3.

Kaabi,S.,BenAyed,H. and Kamoun, F.,2002. Evaluation of

HTTP, E-mail, NNTP with regard to negotiation

requirements in the context of electronic commerce,

ICETE 2005 - GLOBAL COMMUNICATION INFORMATION SYSTEMS AND SERVICES

ICECR4-06, the fourth international conference of

electronic commerce research, Dallas, Texas.

Ockenfels, A.and Roth, A., 2002a. The timing of bids in

internet auctions: market design, bidder behavior and

artificial agents. Artificial intelligence magazine, July

2002.

Ockenfels, A.and Roth, A., 2002b. Last minute bidding

and the rules for ending second price auctions:

evidence from eBay and Amazon auctions on the

Internet. American Economic Review, September

2002, 92(4), 1093-1103.

IETF,2000a. Internet Relay Chat: Architecture,

www.ietf.org, RFC 2810.

IETF,2000b. Internet Relay Chat: Server Protocol,

www.ietf.org, RFC 2813.

IETF, 2000c. Internet Relay Chat: Channel Management,

www.ietf.org, RFC 2811.

Corman, T.H., Leiserson, C.E., and Rivest, R.L.,

'Introduction to Algorithms', section 26.2, p. 558-562.

1st edition Dunod, 1994.

Faure, R., Lemaire B. and Picouleau,C.,2002. Précis de

recherche opérationnelle, 5th edition Dunod 2002.

Kaabi,S.,BenAyed,H. and Kamoun, F.,2004. A Prototype

of a communication protocol for Real-Time Auctions.

Seventh international Conference on Electronic

Commerce Research ICECR7, Dallas Texas.

A HIERARCHICAL DISTRIBUTED COMMUNICATION ARCHITECTURE FOR REAL-TIME AUCTIONS