University Project

**Job No. 1 - Java API sockets** **Job description:** The application is to be distributed in order to implement a support system votes. This system has multiple items to vote, and receives votes from sers. Items up for voting have a deadline after which the server does not accept more votes and calculates the total votes, and their percentages item inner. For voting, a user begins by making a log. In response, the server sends you a list of items that are in eligible, which enable the user to vote on a given item. In addition to the voting, there are also system administrators who have the ability to introduce items to vote and would send information notes for users. The first goal of the work should be implemented using the API Sockets in Java. All communication will be made using the unicast TCP sockets, while the whole multicast communication will be done using UDP sockets. The multicast will be used exclusively for the briefs submitted by system administrators. However, the implementation of multicast messages will be made with point-to-point, not placed with the use of multicast addresses. The server should be multi-threaded. Then it presents the key topics to be implemented in the application: ## Deliverables **Protocol of Communication:** With the exception of briefs on multicast, all communication between clients and server must be made through socket Stream. If you can find it convenient, use Object Streams to send objects. Please note that should define accurately the format of the messages of their distributed applications and must offer at least the following messages to client-server: (a) sign, (b) obtain list of items in vote; (c) vote. In order client-server, there must be at least the following messages: (a) sign valid or invalid, (b) list of items to vote; (c) response to a vote (for example, success or failure), (d) notification of termination of the vote. Pay special attention to synchronism messages from client / server and server / client. In addition the users should also consider system administrators, who also interact with the server, using for that purpose, the following messages: (a) sign, (b) list items to vote; (c) add a new item (d) sending informative notes. Moreover the server should respond with indications of success or failure to each of these messages. **Customer management and other information:** At this stage of the work the management of users could be done in a manual, through the manipulation of a file on the server side, where it stores the information of users in the application, their logins and passwords. It should also there be persistent information with existing items and the value of [login to view URL] information should be kept in a file apart, so that the server can recover all the necessary information to maintain the service in case of a transient fault. **Graphic interface:** The development of a graphical interface will not be subsidized. **Architecture of Service** The end of the service architecture will be built in pieces throughout the various goals of this work. The first goal to build the architecture will be composed solely by users / voter, an administrator and a server, which communicate by TCP (and also by UDP, in the case of multicast messages of briefs). This method is shown in Figure 1. **Treatment of Exceptions** Their implementation should be fault-tolerant temporary short-stay in the channel of TCP communication. That is, if the network or the server becomes unavailable for some moment, its application will receive an exception. This exception should be treated client-side in order to try again to open the socket with the server. The customer cannot view the occurrence of exceptions in his application. When there is no connectivity to the server, the client should simply state that awaits connection to the server. If after some time (e.g. 5 minutes) if you continue without connectivity to the server you should consider the connection to the server as lost. To simulate these situations you can turn off the server (ctrl-c) and re-start it. Note that during the period of time in which connectivity to the server is inactive all messages sent by customers and data released by users (users and administrators) must be kept in local buffers and not to be lost, so that will be sent to the server when it reverts to being active. ## Platform "Windows Xp/ Vista"+"Eclipse"+"Java"