Fall CSEE W4119 Computer Networks Programming Assignment 1 - Simple Online Bidding System

Transcription

1 Fall CSEE W4119 Computer Networks Programming Assignment 1 - Simple Online Bidding System Prof. Gil Zussman due: Wed. 10/24/2012, 23:55 EST 1 Introduction In this programming assignment, you are required to implement a simple online bidding system (think ebay) using the UDP protocol. The users of this system include sellers and customers. Sellers can post item entries on the Server and all customers can view the item list. If a customer is interested in one of the items, he can directly contact the seller to request more information or to place a bid. The system should use the common client-server model, which means you have to write two different programs - server end and client end. Sellers and customers all act as clients, and the server keeps track of all information such as client information, item list and off-line messages. Clients should also be able to send messages to each other, so that a customer can contact a seller directly. The functionalities and specifications of the program are described in detail below. This assignment is meant to be done on your own; do not collaborate with others as this is cheating! Please start early, and read the entire homework before you start! 2 Functionalities The whole bidding system can be broadly classified into five functions. Each function involves either the client part or the server part or a combination of both. The different functionalities and their respective parts in both the server and the client are explained in depth in the upcoming sections. Notice that while the writeup is long, each functionality only contains one or two commands, and the long descriptions are for providing clarity. 2.1 Sign In & Sign Out After the server starts, the clients should connect to the server and sign in with a username (As a simple version, we do not require passwords). A client can only get access to server information when it has signed in. It should send commands to the server to manually sign in or sign out. Server starts: The server should be started using the following command: $ sobs -s <server-port> The command takes two arguments, specifying that we want to run the server and the port number the server is going to listen on. The port number should be an integer value in the range Proper errors should be prompted if the given port number is out of range. The server does not have to display anything after it has been started. We will not put any requirements on the output of the server, as we assume that the server program will run as a daemon on a remote machine, and we could evaluate your program only through the client output. You can let the server display anything you like to help you debug your programs. Client starts: 1

2 The client has to communicate with the server using the IP address and the port number of the server. $ sobs -c <server-ip> <server-port> This command requires three arguments described as follows: -c indicates to run as a client. <server-ip> and <server-port> are the server information (assume all clients by default know the server information). If the server is running in the same machine with your client, the <server-ip> could be or localhost, otherwise, it should be the IP address of the server machine. <server-port> should be the same number as is passed in when starting the server. You should check if <server-ip> is a legal IP address and if <server-port> is an integer value in the range If not, print an error message and simply exit the program. If all arguments are taken in a proper format, a prompt should be displayed: sobs> Note that we do not need to explicitly specify the port number for a client. You program should automatically pick any current available one. [HINT] You can do this by simply passing a 0 to function bind (C/Python) or to the socket class constructor (Java). To exit or close a client use: sobs> ctrl + c Assume a client once exited does not return. Sign in & sign out commands A client should send a command to sign in before it can use the system. To sign in, the client should support the command: sobs> register <user-name> <user-name> is the ID that represents a particular seller or customer. As a simple system, we assume that there will be no malicious clients. You do not have to consider security cases such as forgery. And you should only guarantee that the <user-name> is a string of less than 64 bytes. A string longer than 64 bytes can be simply truncated. When a client signs in, it should send all the client information to the server, including <user-name>, the IP address and port number of the client program. The server should maintain a list of client information (three items for each entry) with <user-name> as the entry ID. If the <user-name> already exists in that list, the server simply replaces that entry with the new information (A client may have forgot to sign out last time). If the <user-name> is new, the server just makes a new one with that name. The server will send back ACK (acknowledgement) after receiving the information. ACK can be anything, but we recommend that it should be a welcome message. When the ACK arrives, your client program should display the message: sobs> [Welcome <user-name>, you have successfully signed in.] To sign out, the client should support the command: sobs> deregister When getting the ACK, it displays: sobs> [You have successfully signed out. Bye!] After signing out, a client can NOT send any packets (except sign-in command) to the server or receive any packets from the server. It can only send and receive messages after signing in again. Local client information 2

3 There are cases where clients directly communicate with each other (packets not going through the server), such as when a customer wants to contact a seller directly to query information or to buy a item. Therefore, your client programs have to maintain a local copy of all the client information from the server. Hence each time the client signs in or signs out, the server will broadcast the client information table to all the currently online clients. After receiving the client information table broadcasted, clients need to update their corresponding local table. And when the local table has been successfully updated, the client should display the message : sobs> [Client table updated.] 2.2 Sell an Item Once the clients are set up and registered with the server, the next step is to implement the sale feature. Clients should be able to send a message to the server to post a new item up for bidding. The seller will also indicate to the server how many transactions to process before automatically selling the item. Think of this as an easier form of a time limit. The server will be maintaining a table of all of the items that are currently available for bidding and how many transactions each has left before it is sold to the highest bidder. Client: The client has to provide the server the name of the item for sale, how many transactions to allow, what price (in cents) to start the bidding at, and for what price (in cents) to sell the item immediately. sobs> sell <item-name> <transaction-limit> <starting-bid> <buy-now> <description> This command requires three arguments described as follows: <item-name> is the name of the item for sale. It should be a string with no whitespace. A string longer than 64 bytes (max length) can be simply truncated. <transaction-limit> is the number of times the item may be bid on before the server should sell the item to the highest bidder. It should be a positive integer value. For example if it is set to 2, then the first bid raises the current bid by the specified amount. When a user completes the second bid on the item the server will sell that item to him/her. <starting-bid> is the initial bidding price in an integer number of cents that the item should be initially listed at. <buy-now> is the price at which another client could immediately buy the item. It s an integer number of cents. <description> is the detailed description of the item. It is the last argument and could contain long sentences with whitespaces. The max length is 1024 bytes. You can truncate the string, if it is longer than the max length. After sending the message to the server, the client can expect a response from the server as described below in the Server section. The client should display the response: sobs> [<server-response>] Server: The server is responsible for acknowledging submission of an item for sale. The server needs to maintain an ID number for each item added to the items for sale table. The number starts from 1, and only increments by 1 when there is a new item. You do not have to decrease the number if any item (including the last one) is deleted. And we assume that the item number will never grow greater than MAX INT. Then the server should add the item and its corresponding information to its table and respond to the client with: <item-name> added with number <item-num> 3

4 If the server finds that there is something wrong with the arguments, it should not add anything to its table and respond to the client with: Error: arguments 2.3 Get Items For Sale At this point the clients should be able to send items to the server to put them up for bidding. The other clients need a way to ask the server what is for sale. You will now be implementing a way for clients to ask the server for either all of the items currently for sale or for just a specific item. Client: Clients (both customers and sellers) can send requests to the server for updated information of all on-sale items: sobs> info [item-num] This command has only one optional argument, which is the number of the item that the client wants information about. If there is no [item-num], information of all items on the server will be returned. A customer can see the whole list so as to choose interesting items among them. But a client may prefer to specify a particular [item-num], because he/she may only want to see the information for a specific item he/she is interested in. Server: 4

5 The server will be receiving the info command from the clients. It is then responsible for replying to the client with an appropriate response. If the client sent the info command with no extra argument the server should reply with a listing of all items currently listed for sale. The response message should look like as follows: <item-num> <item-name> <seller-name> <current-bid> <buy-now> <description> <item-num> <item-name> <seller-name> <current-bid> <buy-now> <description>... Each line should contain all the public item informtion including the number and the name of the item, the <seller-name> which is the <user-name> of the client who is selling it, and the current bid (in cents), the buynow price (in cents), and lastly the description of the item. Notice that the <transaction-limit> should not be shown in this response message. If the server was asked for all items (by sending just info) and the server has NO items yet listed it should respond as follows: Error: empty If the client sent the info [item-num] command with an item s number and the item EXISTS in the server s table, then the server should respond with one line: <item-num> <item-name> <seller-name> <current-bid> <buy-now> <description> If the client sent the info [item-num] command with an item s number and the item DOES NOT EXIST in the server s table, then the server should respond with one line: Error: <item-num> not found 2.4 Place Bid Your system should now be set up such that your clients can list items to be sold with the server as well as find out what items are on sale from the server. We now want to add the ability to allow a client to place a bid on an item. A customer may bid however much he/she likes on any item (except his/her own items) and may not bid twice in a row for the same item. What this means is if customer A is already the highest bidder on item 5, he/she may not bid on item 5 until a new customer is the highest bidder on item 5. Also note that the customer is allowed to bid over the direct buy amount. It is the customer s responsibility to contact the seller directly if it wants to purchase an item at the <buy-now> price. 5

6 Client: The client needs to indicate to the server which item it would like to bid on as well as how much it would like to bid. Clients will specify their bids as an integer number of cents that they would like to pay ABOVE the current bid price. The command should look as follows: sobs> bid <item-num> <amount> An example bid command could read as $ bid and this would mean that the client would like to bid 100 cents over the current bid for the item number 5. So if the item s current bid price was 500 (five dollars) its new bid price after this message should be 600 (six dollars). After sending this message to the server, the client can expect a response from the server as described in the following server section. The client should display the response in such format: sobs> [<server-response>] Server: The server needs to edit the current bid prices for the item that was bid on once it receives the bid message. It is also responsible for reporting any errors back to the client, such as if the item specified does not exist. If the client is already the highest bidder on the item, he/she is not allowed to bid more than once in a row. The server should respond to a client who is doing this with: Error: duplicate bid If the client has bid on an item that he/she has put up for sale the server should not count the bid and reply with the message: Error: owner If the item exists and the client has correctly specified the bid with a higher price, the server should add the bid to the current bid price and also store the username of the client with that item as the current highest bidder. It will then respond to the client with one line: <item-num> <item-name> <new-current-bid> It the item the client specified does not exist the server should respond with the line: Error: <item-num> not found If the bid price that the client is trying to place is negative, the server should not change the current bid and should reply: Error: negative bid If the server finds that there is anything wrong with the command arguments, it should not change anything in its table and respond to the client with: Error: arguments Also, the server has to maintain the number of bids that have been placed on each item. After a bid is successfully placed, the server needs to increment that number. When the number has reached the transaction limit, the server should regard it as the last bid for that item, and the customer that places the last bid should win. The server then sends messages to both the seller and the customer who wins: To the seller: sold <item-num> <item-name> <purchase-price> To the customer who wins: purchased <item-num> <item-name> <purchase-price> If the server times out when sending messages to clients, it needs to store the message in a list of off-line messages and send to the client next time it signs in. [HINT] The off-line messages can be simply identified by the <user-name>. You can see more instructions about off-line messages in Section - Direct Buy. 6

7 The following figure lays out the process. 2.5 Direct Buy As the seller has provided the buy-now price, a customer can send a direct-buy command to a seller to request an item. The command should be sent directly to the seller s client program, without notifying the server. The seller s client will then send a direct-sell command to the server and the server notifies the customer that it has successfully bought the item. We design the direct-buy process like this in order to test the client-to-client programming. 7

8 Client: A customer can directly send the buy command to seller, which is another client: sobs> buy <seller-name> <item-num> The first argument is the <user-name> of the seller. You should obtain the IP address and port number of the seller from the local client information table, and then send the message directly to the seller s client program without notifiying the server. When a seller s client program receives the direct-buy commands, it should display: sobs> [<customer-name> wants to buy your <item-num>.] The <customer-name> is the <user-name> of the customer s client. Then, the seller s client program replies with an ACK indicating the request has been successfully delivered. When the customer s client program receives the ACK, it should display: sobs> [<seller-name> has received your request.] If the the <seller-name> is not found in the client information list or the direct-buy command times out 5 times, the customer should assume that the seller is currently offline and send another command directly to the server instead (please find the details in the next section - Off-line Buy). The seller s client program can then automatically send a command to the server indicating that the item will be directly sold to that customer: sobs> direct <item-num> <customer-name> After receiving the ACK, the client displays: sobs> [<server-response>] Server: After receiving the direct-sell command, the server should delete the item from the item list and send the success message to the corresponding customer: purchased <item-num> <item-name> <purchase-price> ACK should be sent back to the seller: sold <item-num> <item-name> <purchase-price> If the item is not found the server item list, the server should respond to the seller with an errror: Error: <item-num> not found If the server fails to contact the customer after 5 tries, it deletes the client information from the client list and stores the message in the off-line message list. Whenever a client signs in, the server should search the off-line message list to see if there are off-line messages for that client. Then, it should send all the off-line messages to that client. The flow diagram of Direct-Buy is shown in the next section together with Offline-Buy. 2.6 Off-line Buy When a customer wants to send a direct-buy request to the seller, but the seller is currently not available, the client should send the direct-buy request to the server first as an offline-buy request, and the server will do the transaction and notify the seller when it signs in again. Client: A client sends the direct-buy request to the server in two cases: -When the seller does not appear in its local list of client information. (could happen when the seller signs out after advertising an item.) -When there is a time-out on a message sent to the seller. 8

9 The message sent to the server as an off-line buy command should be the same with what the seller will send to the server: sobs> direct <item-num> <customer-name> The server should respond with the same behavior described in the previous section. On receiving ACK from the server, the following status message should be displayed in the customer s client: sobs> [<seller-name> is currently offline. Request forwarded to the server.] Server: Same with the previous section. 3 General Requirements All data structures and packet formats can be designed by yourself. We only require you to fulfill the client behaviors and displays as described above. 9

10 Whenever a client receives a message from the server, it should display the message with the following format: sobs> [<server-message>] The system should be stable enough. You should give error messages if something abnormal happens instead of simply crashing the system. The error message should be in format: sobs> [Error: <error-message>] Every time when a client sends commands, the client should wait for an ACK within 500 msecs. If it does not receive an ACK, the client should retry for 5 times. If they all fail, the client should stop trying and display some error message. Whenever the server sends messages to the client, it should also wait for an ACK within 500 msecs. If it does not receive, the server should retry for 5 times. If they all fail, the server should assume that the client has signed out, and then delete the client from the client information list and store the message in the off-line message list. Loss of ACK can be simply ignored in this assignment. 4 Testing Before submitting your work, please do test your programs thoroughly. Your bidding application should at least work with One instance of the program in server mode. Three instances of the program in client mode. An example (illustrative, not comprehensive) is provided below - SERVER: $ sobs -s Client1: $ sobs -c sobs> register matt sobs> [Welcome matt, you have successfully signed in.] sobs> [Client Table Updated.] sobs> info sobs> [Error: empty] sobs> sell frying_pan A nonstick frying pan with a diameter of 10in sobs> [frying_pan added with number 1] sobs> info sobs> [1 frying_pan matt A nonstick frying pan with a diameter of 10in ] sobs> sell drawing A lovely hand drawn picture of a mountain range sobs> [drawing added with number 2] sobs> info sobs> [ 1 frying_pan matt A nonstick frying pan with a diameter of 10in 2 drawing matt A lovely hand drawn picture of a mountain range ] sobs> sell frying pan A small frying pan with diameter of 5in sobs> [Error: arguments] sobs> deregister 10

11 sobs> [You have successfully signed out, bye!] Client2: $sobs -c sobs> register John sobs> [Welcome John, you have successfully signed in.] sobs> [Client Table Updated.] sobs> info 3 sobs> [Error: 3 not found] sobs> info sobs> [ 1 frying_pan matt A nonstick frying pan with a diameter of 10in 2 drawing matt A lovely hand drawn picture of a mountain range ] sobs> bid sobs> [purchased 1 frying_pan 1100] sobs> bid sobs> [Error: negative bid] sobs> sell pencil A half used, partially chewed #2 pencil. sobs> [pencil added with number 3] sobs> info sobs> [ 2 drawing matt A lovely hand drawn picture of a mountain range 3 pencil John A half used, partially chewed #2 pencil. ] sobs> deregister sobs> [You have successfully signed out, bye!] Client1: $ sobs -c sobs> register matt sobs> [Welcome matt, you have successfully signed in.] sobs> [Client Table Updated.] sobs> [sold 1 frying_pan 1100] sobs> info sobs> [ 2 drawing matt A lovely hand drawn picture of a mountain range 3 pencil John A half used, partially chewed #2 pencil. ] sobs> buy John sobs> [John is currently offile. Request forwarded to the server.] sobs> [purchased 3 pencil 300] sobs> deregister sobs> [You have successfully signed out, bye!] Client2: $ sobs -c sobs> register John sobs> [Welcome John, you have successfully signed in.] sobs> [Client Table Updated.] sobs> [sold 3 pencil 300] sobs> deregister sobs> [You have successfully signed out, bye!] 11

12 5 Submission Instructions Please use C, Java, or Python for developing the chat application. All are available at CS department CLIC or EE ILAB. Your submission package should include the following deliverables. Make sure that your program compiles and runs on these machines before you submit the package. README: The file contains the project documentation, program features, usage scenarios, brief explanation of algorithms or data structures used, and the description of any additional features/functions you implemented. Makefile: This file is used to build your application. If you have written the programs in C (Unix), the output file name should be UdpSobs. If you used Java, the file name should be UdpSobs.class. You do not need a Makefile if you used Python. Your source code. test.txt: This file should contain some output samples on several test cases. This would help others to understand how your programs work in each test scenario. It is optional to include this, as part of your README document. The submission should be made via Courseworks. Zip all the deliverables mentioned above, and name the zip file as <your UNI><CLIC or ILAB>PA1.zip (e.g. gz2136ilabpa1.zip for Professor Zussman). Upload the file in the Courseworks, under Assignments -> Programming Assignment 1. In the grading of your work, we will take the following points into account. The documentation clearly describes your work and the test result. The source code is complied properly by using the Makefile and generate appropriate output files. The programs run properly, including 1) take appropriate commands and arguments, 2) handle different situations and support required functions, and 3) display necessary status messages. Happy Coding and Good luck!! 12