用Java代写一个Simple Chat Application，需要同时使用TCP和UDP编程，完成后需要和TA的Server端进行联调测试。
Requirement
In this project, you will implement a simple chat application, including the chat server that keeps track of online users and relays messages between them, and a chat client, which a user starts up in order to participate in a chat. Both the server and client must be written in Java using TCP and UDP sockets as discussed below.
The Client
You will implement client app that takes input from, and displays messages to, the user utilizing a terminal window. Upon starting the client app, the client will prompt for the hostname and port number of the chat server to connect to.
Once the client establishes connections to the server, the user can input either control messages to the server or text messages to another user. The control messages need to include the following:
a. Specify the user name of the user running the client. This can be a new or previously used user name. The client will send the user name to the server, which will maintain an ongoing TCP connection with the client and associate this connection with the user name provided. The server will keep track of the user names that have currently active TCP connections (i.e., of the users who are currently online). A user can have only one active connection to the server at a time.
b. Specify the user name of a correspondent the user wishes to chat with, or use a special name “Listener”. The user can enter this command any time while being online and while the client is accepting user input. Entering a new correspondent name completes the chat with the current correspondent and switches to chatting with the new correspondent unless the new correspondent is already chatting with someone else. Thus, a user can only chat with one other user at a time.
c. Specify a sequence of characters (e.g., “-1”, or “Escape”) that delineates the end of the message. Do provide, as the default, “Enter” as such delimiter. Make sure your terminal output cannot interleave your message you are typing and the message being received from the correspondent.
- d. Finish the chat and exit the client app.
Unless the input identifies one of control commands, the input is assumed to be a text message to be sent to the correspondent. If the user is a “Listener”, the message goes back to the remote user that initiated the chat.
The server must provide feedback to the user on the result of the execution of the commands. Specifically, it must alert the user if
a. The user attempts to enter a correspondent’s name but the correspondent is already chatting with someone else, is not a “Listener”, or is not online.
b. The user attempts to enter its user name but there is already an active connection associated with this user.
c. The user attempts to send a text message to the correspondent but the correspondent is no longer online or switched to chatting with someone else.
d. The correspondent switched to chatting with another user instead of entering a response message to the user. The user would receive this notification in place of a usual message that would have been sent by the correspondent.
325 students
The application enforces a strict one-for-one message exchange between the users in a chat session: once a user enters their message, the user cannot enter another message until the correspondent responds with theirs.
425 students
The application must allow a user to enter multiple messages in a raw without having a message from the other side in-between. Still, the application must ensure that the message being typed by the user and the message from the remote user being displayed do not interleave (which would result in a garbled output).
Hint: note that this stipulates a multi-threaded client because the client must be ready to get input from both keyboard (if the user enters another message) and from a socket (if the next message arrives from the correspondent), and both reads are blocked operations.
Some instructions
While in reality your server will run on a separate host, you can develop it on your own machine. To test your server, you can run both the client and the proxy on the same machine (e.g., your laptop). Once everything seems to work, you must deploy and test your server on a departmental machine. We will be testing your server on the departmental machine. Do make sure it works there.
The machine is a linux server; you should have an account on it on Monday (use your Case network ID and password). You will need to pick a port on which your server will listen for client communication. Since everyone is sharing the same machine, we need to avoid port collisions. Please refer to the 325 and 425 student lists, find your order number N, and then pick port 5000+N if you are in the 325 list, and 5500+N if you are in the 425 list.
Please use Java for this project (to make grading feasible). Please use TCP sockets directly; do not use high-level methods and classes for communication.
For 325 students: note that your server has to be multi-threaded because it may receive communication from multiple users who are concurrently online (in fact, it typically will have at least two users as there are two parties in a chat!). For 425 students: your client must also be multi-threaded because a correspondent is not required to reply to a message for the application to make progress: the user may enter another message of their own. However, the threads that echoes the typed message back on the terminal and the thread that outputs the message from the remote correspondent to the terminal must be synchronized to avoid a possible interleaving of the two messages, resulting in a garbled outout.
Remember that when you write something to the output stream, this data does not necessarily go out to the wire immediately: the kernel can buffer it to assemble a larger chunk. This often creates a “hanging” effect, where for instance your server sends the last portion of the response to the client but the client never receives it until the server sends enough bytes or closes the socket. To make sure your last portion of communication is sent out, flush your sockets after you write out the entire message (by calling flush() on the output steam associated with the socket).
Please put all necessary files into your home_directory/project1 on host. name your server “chatd”. We will start your server server by first compiling it by invoking “javac chatd.java” in the “home_directory/project1/src” directory and then executing the command “java chatd - port 50025” (for student # 25) from the same directory. Make sure your program has the above name and accepts the above argument, (and also compiles!).
Deliverables
Well-commented (within source code, no separate class documentation needed) code + README with
- (a) which port you are using
- (b) instructions to operate the server and client
- (c) any notes on residual bugs or weird behaviors you were unable to chase down. In addition to uploading/deploying all of the above as a single zip or gzip file to blackboard.
Make you test your application by running your server, as well as both chatting clients. This will be the first test we will conduct. We will also try your application by running the clients on other machines, also running linux, and we will read your code.
We will use the following grading instructions:
- The server handles new user registration and associates TCP connections with clients.
- Multiple instances of client application can run on the same machine (note: each instance will have to register a different user name to comply with our restriction that a user can only have at most one active connection at a time).
- The application handles sequences of requests without interleaving the local and remote message on the terminal output. The message boundaries are properly detected
- The client is able to switch from chatting with one user to another
- The server provides proper feedback to the user
- Control messages are distinguished from the data messages
- Code is logical and understandable, with inlined comments
- (425) The application allows a user to enter a sequence of messages without waiting for a response