Our agent opens a TCP/IP connection, and then authenticates itself with the AuctionBot. It can then submit bids, get information on other agents' bids, find out about clearing prices, and determine the transactions it has been involved in. The agent can continuously check its bidding status by polling the auction server.
For example, to find out about its transactions, the agent sends the string
transid?order="time"
This returns a list of transaction IDs, ordered by time, such as
transid?id=123&id=124&id=125...
The agent then parses this result to get the ID of the latest transaction, say 125, and asks for more detailed information by sending
transinfo?transid=125
to which AuctionBot responds
transinfo?id=125&auction=789&cleartime= 886015200&buyer=782&seller=121&price=3.14 &quantity=1&status=0
This means that in auction number 789 which cleared at the specified time between user 782 and 121, one unit was bought for $3.14. The status of zero indicates no error.
The most difficult design issues in the communication with the AuctionBot are timing issues and network delays. Since the auction that the agents are bidding in is synchronized, the agents need to submit their bids and then check the bids of other agents before the auction clears. After waiting for the clear, they check to see if they transacted and update their endowments and utilities accordingly before submitting another set of bids and repeating the cycle. Figure 2 illustrates this process.
