Design and Implementation of a Multi-Threaded Client-Server Application using the Java Socket API



Design and implement an anonymous chat system based on a connection-oriented TCP socket. The system should allow each client user to chat anonymously with another client through the server. The server will act as a proxy server for the clients of the system. The client will not be required to know the IP address for the user they wish to chat with. Using the system, the client user (or user) should be able to:

## Deliverables

_**The client should be able to**_

* Logon to the server by providing a unique user name (e.g. Jane2004). Log-off from the server.

* Query the server and receive a list of all currently registered users.

* Send a message to a user based only on the user name. The user will also obtain a unique number for each message sent to the server. The current date and time are also appended to each message (e.g. “[url removed, login to view] 16:45- Hello Jane!??).

* Receive notification from the server if the message has been rejected (e.g. “Message number 1234 has been rejected??).

* Reject or accept a message from another user.

_**The server should:**_

* Store the user name of each logged-on client in a VECTOR. Remove the user name of any client that has logged-off the system.

* Respond to queries from the client for a list of all currently logged-on users.

* Route a message to the appropriate client.

* Query an intended message recipient to ask whether the recipient wishes to receive the message (e.g. “Do you wish to receive a message from Jane2004???).

* Provide feedback on message rejection to the originating client. If the user rejects the message, the originating user is informed, and the message is discarded. If the message is accepted, the message is forwarded to the recipient.

The server must be a concurrent server, and should

* allow multiple clients to connect concurrently via threads

* provide a user-interface, in DOS, to allow the server to be instantiated.

_**Protocol Design**_

A protocol is needed to specify the rules that must be observed by the client and the server during a session of a particular service. Data may be exchanged either in the form of a text message. You will have to:

* define a protocol for client-server communication;

* define the format of each message type;

* define how to realize the functional requirements;

* define how to carry out the inter-process communication.

Once a protocol has been designed, document the protocol using a combination of narratives and diagrams. The documentation should include:

* an overview of the protocol used;

* a description of the format of each type of message;

* a description of the implementation of the functions required,

* the sequence diagrams describing the communication between the participating entities.

_**Software Architecture & Implementation**_

The client and server interfaces should support the functionality outlined in the previous section. A basic DOS interface only for both the client and server is required.

In the case of both the client and server you should include source code to handle errors (i) in user I/O, and (ii) general exceptions (using try-catch blocks).

For simplicity the system is not required to authenticate the users or provide any form of data security.


The application should be documented appropriately. You must include:

* execute instructions in the form of the appropriate command line arguments;

* an overview of the source files used together with an explanation of the various tiers (i.e. Application, Presentation, Session) employed in your design;

* source code should be commented and an explanation provided, where necessary.

_**You may assume the following:**_

the IP address of a client user is static for the duration of registration;

the IP address and port number of the server are known by all client users.

any information stored at the server is lost when the server program is terminated.

_**Submission Requirements**_

**The source code must be submitted in source code (*.java)** and compiled bytecode format (*.class).

1) Complete and fully-functional working program(s) in executable form as well as complete source code of all work done.

2) Deliverables must be in ready-to-run condition, as follows (depending on the nature of the deliverables):

a) For web sites or other server-side deliverables intended to only ever exist in one place in the Buyer's environment--Deliverables must be installed by the Seller in ready-to-run condition in the Buyer's environment.

b) For all others including desktop software or software the buyer intends to distribute: A software installation package that will install the software in ready-to-run condition on the platform(s) specified in this bid request.

3) All deliverables will be considered "work made for hire" under U.S. Copyright law. Buyer will receive exclusive and complete copyrights to all work purchased. (No GPL, GNU, 3rd party components, etc. unless all copyright ramifications are explained AND AGREED TO by the buyer on the site per the coder's Seller Legal Agreement).

## Platform

The system should run on Windows.

The chat system should be based on a connection-oriented TCP socket.

The Client List should be stored in a vector

**The source code must be submitted in source code (*.java)**

Skills: Java, PHP

See more: web design service support, web design overview, web design implementation, web design class, web application system architecture, vector security, vector remove, vector package design, user diagrams, user case diagrams, the n and o, the hire connection, system architecture of a web application, software design document, service providing agreement, service agreement format, service agreement document, sequence diagrams, security notification service, rules for web design, registration form web design, program data vector, process of package design, package used in the design, out source design

Project ID: #3071961