3.1. ServerThe server has the following responsibilities - User Authentication - When a new client requests for a connection, the server should prompt theuser to input the username and password and authenticate the user. The valid username andpassword combinations will be stored in a file called credentials.txt which will be in the samedirectory as the server program. An example credentials.txt file is provided on the assignment page. Username and passwords are case -sensitive. We may use a different file for testing so DO NOThardcode this information in your program. You may assume that each username and password willbe on a separate line and that there will be one white space between the two. If the credentials arecorrect, the client is considered to be logged in (i.e. online) and a welcome message is displayed. When all messaging is done, a user should be able to logout from the server. On entering invalid credentials, the user is prompted to retry. After 3 consecutive failed attempts, the user is blocked for a duration of block_duration seconds (block_duration is a command lineargument supplied to the server) and cannot login during this duration (even from another IPaddress). While a user is online, if someone uses the same username/password to log in (even fromanother IP address), then this new login attempt is denied. Timeout - The server should keep track of all online users. If the server does not receive anycommands from a user for a period of timeout seconds (timeout is a command line argumentsupplied to the server), then the server should automatically log this user out. Note that, to beconsidered active, a user must actively issue a command. The receipt of a message does not count. Pr esence Broadcasts - The server should notify the presence/absence of other users logged into theserver, i.e. send a broadcast notification to all online users when a user logs in and logs out. List of online users - The server should provide a list of users that are currently online in responseto such a query from a user. Online history – The sever should provide a list of users that logged in for a user specified time inthe past (e.g. users who logged in within the past 15 minutes). Message Forwarding - The server should forward each instant message to the correct recipientassuming they are online. Offline Messaging - When the recipient of a message is not logged in (i.e. is offline), the messagewill be saved by the server. When the recipient logs in next, the server will send all the unreadmessages stored for that user (timestamps are not required). Message Broadcast – The server should allow a user to broadcast a message to all online users. Offline messaging is not required for broadcast messages. Blacklisting - The server should allow a user to block / unblock any other user. For example, if userA has blocked user B, B can no longer send messages to A i.e. the server should intercept suchmessages and inform B that the message cannot be forwarded. Blocked users also do not getpresence notifications i.e. B will not be informed each time A logs in or logs out. 3.2. ClientThe client has the following responsibilities -Authentication - The client should provide a login prompt to enable the user to authenticate withthe server. Message - The client should allow the user to send a message to any other user and displaymessages sent by other users. The client should also allow the user to send a broadcast message toall online users. Notifications - The client should display presence notifications sent by the server about userslogging in and out from the server. Find users online - The client should provide a way for the user to obtain a list of all the userscurrently online from the server. Find online history – The client should provide a way for the user to obtain a list of all users whohad logged in within a user specified time period. Blacklist – The client should allow a user to block a user from sending any further messages. Theclient should also allow a user to unblock a user that was earlier blocked. 3.3 Commands supported by the clientAfter a user is logged in, the client should support all the commands shown in the table below. Forthe following, assume that commands were run by user A. Command Descriptionmessage Send to through the server. If the user isonline then deliver the message immediately, else store themessage for offline delivery. If has blocked A, then amessage to that effect should be displayed for A. If the isnot present in the credentials file (i.e. invalid user) or is self (A)then an appropriate error message should be displayed. The used in our tests will be a few words at most. broadcast Send to all online users except A and those users whohave blocked A. Inform A that message could not be sent to somerecipients. whoelse This should display the names of all users that are currentlyonline excluding A. Users can be displayed in any order. whoelsesince This should display the names of all users who were logged in atany time within the past seconds excluding A. Note thatthis, may include users that may currently be offline. If isgreater than the time since when the server has been running, thenall users who logged in since the sever initiation time should belisted. This suggests that you will need to keep a login historysince the start of the server. Users can be displayed in any order. block blocks the from sending messages to A. A messageshould be displayed to A confirming the blocking action. If is self (i.e., A) or is invalid, then an appropriate errormessage should be displayed. must not be informed thatA has blocked them. unblock unblocks the who has been previously blocked by A. Amessage should be displayed to A confirming the unblockingaction. If is self (i.e., A) or is invalid or was not alreadyblocked, then an appropriate error message should be displayed. logout log out user A. Any command that is not listed above should result in an error message being displayed to the user. Theinteraction with the user should be via the terminal (i.e. console). All messages must be displayed in thesame terminal. There is no need to create separate terminals for messaging with different users. We do not mandate the exact text that should be displayed by the client to the user for the variousmessages. However, you must make sure that the displayed text is easy to comprehend. Please makesure that you DO NOT print any debugging information on the client terminal. We also prefer that you do not print anything at the terminal running the server. We suggest thatyou use an optional debug flag (e.g. –d) for the server. When this flag is turned on, your server canprint debugging information to the terminal. Some examples illustrating client server interaction using the above commands are provided inSection 8. 3.4 Peer to Peer MessagingSome users may prefer to have some privacy during messaging. They may want to message theirfriends directly without all their conversation being routed via the server. A peer-to-peer messagingclient is a good solution for this scenario. In addition to the above functionalities, you shouldimplement peer-to-peer messaging (also referred to as private messaging). To implement this functionality your client should support the following commands (in addition tothose listed in Section 3.3)Command Descriptionstartprivate This command indicates that user A wishes to commence p2pmessaging with . The client should obtain the IP addressand port number being used by the from the server. Theclient should try to establish a TCP connection to this IP addressand port number combination. A confirmation message should bedisplayed to A. If has blocked A, then server should notprovide the IP address and port number and an appropriate errormessage should be displayed. If is offline, invalid or selfthen appropriate error messages should be displayed. private Send to directly without routing through theserver. If the user is no longer online at the address obtained viathe previous command then a message to that effect should bedisplayed for A. If A has not executed startprivate before thiscommand then an appropriate error message should be displayed. Note that, A may execute startprivate before hasblocked A. In this instance, A can still use this command to senda message to . Other error messages (e.g. offline, invalid, etc.) are consistent with those indicated in the above command. stopprivate This command indicates that user A wishes to discontinue thep2p messaging session with . A message to this effectshould be displayed on the terminal for . The TCPconnection established between the two end points should beclosed. An appropriate error message should be displayed if theredoes not exist an active p2p messaging session with 3.5 ExtensionOnce you have your P2P messaging in place, the next logical step is to utilize the setup to transferfiles in a distributed manner (similar to BitTorrent). Assume that a user ‘A’ has a file (assume abinary format) that they are willing to serve to oServer代写、代TCP connection编程、代写Ither users in a P2P manner. User A divides the fileinto N chunks (we will use N=10 for this part of the assignment) and registers the details of the file(name, size and number of chunks) with the server. Any client can search for the availability of aspecific file name in the system from the server. The server will reply back with either ‘Notavailable’ or ‘Available’ along with list of online users that have one or more chunks of therequested file name. A client can also search for specific chunks of a file. The client will then select peers that have chunks and request the transfer of the selected chunks. Once a chunk has been downloaded, the client will also register the availability of this chunk withthe server. The algorithm to select the peers for downloading the chunks is for you to decide. Theobjective is to finish the download in an efficient and distributed manner. As a rule of thumb, youcannot download all chunks of a file from a single peer, if other peers have some chunks of that fileavailable for download. You need to provide the following additional features in order to support the file transfer. Command Descriptionregister This command indicates that user A wishes to register a with the server. contains names, number & size of chunks. The server will respond with ‘Ok’ ifthe file is successfully registered. A confirmation message shouldbe displayed to A. If the file is already registered, the server willrespond appropriately and registers the availability of chunks atuser A. searchFile User A wishes to search for the availability of a filename in thesystem. The server will reply back with either ‘Not available’ or‘Available’ along with list of online users that have one or morechunks of the requested . searchChunk User A searches for the availability of specific for a in the system. The server will reply back with either‘Not available’ or ‘Available’ along with list of online users thathave one or more requested of the . private The client should obtain the IP address and port number being used by the from the server. If has blocked A, thenthe server should not provide the IP address and port number andan appropriate error message should be displayed. If isoffline, invalid or self then appropriate error messages should bedisplayed. The client should try to establish a TCP connection tothis IP address and port number combination. Once theconnection is established, it requests the download of a of a specific . An appropriate error message should bedisplayed if there does not exist an active p2p messaging sessionwith . When running all clients and server on the same machine, make sure that a client only has access tochunks that it has currently downloaded from the system. Only the original owner has access to allchunks from the start. 3.6 File Names & ExecutionThe main code for the server and client should be contained in the following files: server.c, orServer.java or server.py, and client.c or Client.java or client.py. You arefree to create additional files such as header files or other class files and name them as you wish. The server should accept the following three arguments: ? server_port: this is the port number which the server will use to communicate with theclients. Recall that a TCP socket is NOT uniquely identified by the server port number. So itis possible for multiple TCP connections to use the same server-side port number. ? block_duration: this is the duration in seconds for which a user should be blocked afterthree unsuccessful authentication attempts. ? timeout: this is the duration in seconds of inactivity after which a user is logged off by theserver. The server should be executed before any of the clients. It should be initiated as follows:If you use Java:java Server server_port block_duration timeoutIf you use C: ./server server_port block_duration timeoutIf you use Python:python server.py server_port block_duration timeoutThe client should accept the following two arguments: ? server_IP: this is the IP address of the machine on which the server is running. ? server_port: this is the port number being used by the server. This argument should bethe same as the first argument of the server. Note that, you do not have to specify the port to be used by the client. You should allow the OS topick a random available port. Each client should be initiated in a separate terminal as follows:If you use Java:java Client server_IP server_portIf you use C: ./client server_IP server_portIf you use Python:python client.py server_IP server_portNote: When you are testing your assignment, you can run the server and multiple clients on thesame machine on separate terminals. In this case, use 127.0.0.1 (local host) as the server IP address. 8. Sample InteractionNote that the following list is not exhaustive but should be useful to get a sense of what is expected. We are assuming Java as the implementation language. Case 1: Successful LoginTerminal 1>java Server 4000 60 120Terminal 2>java Client 10.11.0.3 4000 (assume that server is executing on 10.11.0.3)>Username: yoda>Password: wise>Welcome to the greatest messaging application ever!>Case 2: Unsuccessful Login (assume server is running on Terminal 1 as in Case 1)Terminal 2>java Client 10.11.0.3 4000 (assume that server is executing on 10.11.0.3)>Username: yoda>Password: weird>Invalid Password. Please try again>Password: green>Invalid Password. Please try again>Password: password>Invalid Password. Your account has been blocked. Please try again laterThe user should now be blocked for 60 seconds (since block_time is 60). The terminal should shutdown at this point. Terminal 2 (r eopened befor e 60 seconds ar e over)>java Client 10.11.0.3 4000 (assume that server is executing on 10.11.0.3)>Username: yoda>Password: wise>Your account is blocked due to multiple login failures. Please try again later Terminal 2 (r eopened after 60 seconds ar e over)>java Client 10.11.0.3 4000 (assume that server is executing on 10.11.0.3)>Username: yoda>Password: wise>Welcome to the greatest messaging application ever!>Example InteractionsConsider a scenario where three users Hans, Yoda and Luke are currently logged in. No one has yetblocked anyone else. In the following we will illustrate the text displayed at the terminals for all threeusers as they execute various commands. Some other examples with different users are also provided. 1. Hans executes whoelse followed by a command that is not supportedhans’s Terminal yoda’s Terminal luke’s Terminal>whoelse > >>yoda>luke>whatsthetime>Error. Invalid command2. Hans messages Yoda and then messages an invalid userhans’s Terminal yoda’s Terminal luke’s Terminal>message yoda Hey Dude>hans: Hey Dude>message bob party time>Error. Invalid user 3. Hans broadcasts a messagehans’s Terminal yoda’s Terminal luke’s Terminal>broadcast vader sucks>hans: vader sucks >hans: vader sucks4.Luke blocks Hans followed by a few interactions that illustrate the effect of blocking andunblocking. hans’s Terminal yoda’s Terminal luke’s Terminal>block hans>hans is blocked>broadcast I rock>Your message could notbe delivered to somerecipients>hans: I rock>message luke You angry?>Your message could notbe delivered as therecipient has blocked you>block hans>Error. Cannot block self>unblock yoda>Error. yoda was notblocked>unblock hans>hans is unblocked>broadcast stormtroopers>hans: stormtroppers >hans: stormtroppers5. Assume that Vader was logged in 5 minutes ago but logged out 2 minutes ago and that R2D2 waslogged in 10 minutes ago but logged out 5 minutes ago. hans’s Terminal yoda’s Terminal luke’s Terminal>whoelsesince 200>hans>yoda>vader>whoelsesince 500>hans>luke>vader>r2d26. Now assume that Hans and Yoda are logged on but that Luke is currently offline. Luke joins inlater and receives a stored message from Hans. It also shows presence notification. Later, Yoda logsout and the corresponding notification is shown to others. hans’s Terminal yoda’s Terminal luke’s Terminal>message luke Let’s rock (Assume that luke logs inafter this message)>luke logged in >luke logged in >hans: Let’s rock>logout>yoda logged out >yoda logged out7. Assume that Hans, Yoda and Luke are currently logged in. Hans first tries to send a privatemessage to Yoda without first executing startprivate. This is followed by the correct sequence ofcommands for private messaging. Observe that a non-private message (i.e. through the server) canalso be sent by a user engaged in a private conversation. hans’s Terminal yoda’s Terminal luke’s Terminal>private luke hey dude>Error. Private messagingto luke not enabled>startprivate luke>Start private messagingwith luke>private luke hey dude>hans(private): hey dude>private hans hello>luke(private): hello>message yoda force isstrong>hans: force is strong>logout>hans logged out >hans logged out转自：http://www.3daixie.com/contents/11/3444.html
