vharisop/advdb

advdb's Issues

Sync next item with bidder after an item is discarded/awarded

In the current implementation, the client keeps an internal list of items which is supplied after a connect - acknowledge handshake (in a separate message). New items cannot be added to it throughout the whole auctioning process.
This makes it harder for new items to be added on the fly (possibly via bidder submission or an external source). A method for item synchronization which would allow dynamic modification of the auction list would consist of the following steps:

• send a stop_bid message after an item is successfully awarded or discarded.
• send the next item's information (item id, description, etc.) in a separate message.

Inform bidder on price change after timeout

Implement a control message that informs bidders about the updated price after a timeout.

Auctioneer timeouts not updated

Upon a successful bid on an item from a bidder, the auction server does not reset the item's timeout counter.
The counter should also be reset when receiving a SyncPriceMsg for the specified item.

Modify auctioneer to read items from file

The specification dictates that both auctioneers should populate their item list from a text file in the form

<L> # delay 
<Price 1> <Description 1>
...
<Price N> <Description N>

Control Messages Integration

For the client, those messages should be integrated:

• auction complete: results in closing the session
• start_bidding: received when the auction shifts to new item. Can possibly(?) be discarded, as the client's eligibility for bidding is updated automatically when receiving a stop_bid message.

For the auctioneer:

• i_am_interested: possibly obsolete, depends on interface implementation.
• quit: self-explanatory

Text interface for client

Implementation Pending

Create a separate log file for each server

Reentrant calls inside logging function

A RuntimeError is raised occasionally when the log() function is executing and a signal is delivered.

Configuration file

Implement a "driver" component - essentially a script that initiates the whole process. It should receive its parameters from a config file, possibly in XML or JSON format.

Auctioneer doesn't update registrar table on disconnect

This results to usernames of disconnected users being reserved incorrectly.

Documentation of the bidder client

Pending documentation about the bidder's backend and the Bidder class.

Multiple stop_bid messages on deletion

Upon deletion of an item due to timeout expiry, a stop_bid message is sent from each server to its clients and the other server. For sync reasons, a servers that receives a stop_bid message must forward it to its clients as well.

As a result, clients may receive more than 1 stop_bid message for the same item.
This is temporarily handled by putting the item deletion snippet inside try...except blocks (or using membership checks).

Client message parsing

Correctly parse the server responses, including error messages.

Update Readme

The current version is incomplete and lacks essential information about the auctioneers' synchronization scheme.

Implement AF_UNIX socket integration for bidder input

KeyError when connecting to "empty" auctioneer

The ItemsMsg received contains empty field for items but nonempty field for current item id, resulting in a KeyError in the client implementation.

Status attribute for bidder client

For effective use by the client user interface, the bidder client should contain a status data attribute with info relevant to the auction (current item, price, etc.).