Programming Network Applications in Java

Aims: • To practice and extend your Java programming skills. • To develop a network application using the sockets API (Application Programming Interface). • To define, test and document a simple application level network protocol for a client-server architecture. The Task To design and implement a Simple Group Location Service (SGLS). This will allow mobile/wireless use agents to report their geographical positions to a central server and to request services about the position of other individuals, groups and places. The first stage of the work, which forms the scope of this coursework, is to develop a server and a protocol to implement the group location service. In addition a command line based client is also required to test the service. You can imagine a second stage (that falls outside the scope of the coursework) would be to port the client side code to a suitable mobile/wireless PDA platform and to integrate an automated means of determining the device position (e.g. GPS) Development will be done using the standard edition JDK on desktop machines. An iterative approach to development is to be adopted. The developing the system is scheduled over 3 iterations. Each iteration extends the functionality of the implementation. At the end of each iteration the design and code will be frozen and documented. Use cases for the initial iterations are described in detail but later on just the protocol or functionality is outlined and you have the scope to design the interaction between the server and client as you see fit. PNAJ is 100% coursework assessed Summary of the Deliverables There are 3 main deliverables. No. Coursework Component Limits Assessment Criteria Marks 1 Code + Discussion of 1 aspect of the design per iteration Iteration 1 : Locating Individuals (25%) Iteration 2 : Groups (20%) Iteration 3 : Places & Relative positions (20%) For each iteration you should show:- • A screen dump of how a transaction proceeds for each use case you implement. • Full java source code is required for each iteration. • Select and discuss one key aspect of the design that you tackled during that iteration (e.g. how do you handle users and groups, how do you handle , how do you calculate distances, etc.). Important: at the end of each iteration, you should freeze the code for the client and server respectively and submit it separately as iterations 1, 2 & 3. Do not continuously refine the code and submit only the final version. consistent lay out, well commented, simple, appropriate use of java language features and Java class libraries. 65% 2 Summary of the SGLS protocol in the style of an IETF RFC. You should write a brief document in the style of an IETF RFC to describe the “Simple GLS” protocol you have developed. Include any additional functionality you feel the protocol needs to be complete (but do not extend it beyond the scope described here – keep it ‘simple’) 2000 word max concise, clear, complete 25% 3 Finally comment on what additions or changes you would suggest the server & protocol needs to be viable. For example timestamps, altitudes, security? 800 words max Relevant and innovative 10% Appendix A Iteration 1 – Locating Individuals In the first short iteration you are to create a primitive service to support individual users. The client issues commands and the server responds. 1-1 Use case: User Reports Location 1. A command line client opens a socket to a server. 2. The server responds by sending a message of the form: Welcome to SGLS Note: is the appropriate End-Of-Command signal that you will choose to indicate that this is the last character (or string) in the command you want to send! It can be any kind of special character (or string), e.g. a . You must document in the RFC. Tip 1: find the server-hostname with the aid of Java code. Tip 2: The server-version is declared in the Java code as constant and can take one of the values: 1, 2, or 3 depending on the Iteration you make. 3. The client sends a message of the form: USER LOCATED AT , Tip: is an integer and the position of the user is specified by two integers x & y. e.g. USER 1 LOCATED AT 10,10 4. The server records (stores) the position internally and responds OK Tip 1: create a User class to represent users. Tip 2: use a dynamic storage unit (e.g. a Vector) to store User objects 5. The client closes the connection. 1-2 Use case: Locate a user 1. The client connects to the server 2. The server responds with the welcome message (like Use case 1-1) 3. The client sends USER LOCATE 4. The server looks up the last known position of and responds USER IS LOCATED AT , Where x,y is the last known location of the user specified by integer e.g. USER 1 IS LOCATED AT 10,10 5. The connection is closed In this first iteration: • The server needs only hold the last reported position of an individual • No error checking or reporting is required • All requests relating to individuals begin with ‘USER’ • The interpretation of the position is not important at this phase of the design so you may adopt an arbitrary scale (i.e. not official grid references or GPS readings). Iteration 2 – Groups In this iteration we add functionality to deal with groups and some error conditions. 2-1 Use Case – Create a Group 1. The client connects to the SGLS server. 2. The client receives the welcome message and checks the version number of the welcome message 3. The client sends the message GROUP MAKE Where is an integer. e.g. GROUP 5 MAKE 4. The server creates an empty group identified by and responds OK or with an error code if it was unable to create the group (e.g. it already exists or has no space or is an invalid ). Tip: make a Group class to represent groups. 5. The connection is closed. 2-2 Use case – User joins a group 1. The client connects to the server and checks the version number of the welcome message. 2. The client sends a message USER JOINS e.g. USER 1 JOINS 5 3. The server records that is a member of and responds ok or with an error code if it was unable to add the user (e.g. unknown group, unknown user). 4. The connection is closed. 2-3 Use case – Locate Group 1. The client connects to the server and checks the version number of the welcome message. 2. The client sends a message GROUP LOCATE USERS 3. The server responds with a list of the users that are joined to this group in the form USER IS LOCATED AT , USER IS LOCATED AT , … Where x,y is the location of the user specified by integer a. If the group is empty the server responds ‘GROUP IS EMPTY’ 4. The connection is closed Similarly, implement the following use cases: 2-4 Use case – User leave a group Checks as in ‘join’ use case above but with message USER LEAVE GROUP 2-5 Use case – delete a group Checks as in ‘join’ use case above but with the message GROUP DELETE 2-6 Use case – delete a user Checks as in ‘join’ use case above but with the message USER DELETE In this second iteration: • There is no permission scheme restricting who can form, join or delete groups. • All requests relating to Groups begin ‘GROUP’ • All transaction are non-persistent. A connection is established, a single transaction occurs and the connection is closed Iteration3 – Places and relative positions In this iteration we add the concept of places (landmarks) & relative positions. 3-1 Use Case – Client reports a place 1. The client connects to the SGLS server. 2. The client receives the welcome message and it checks if the version is 3. 3. The client sends a message of the form: PLACE : IS LOCATED AT , e.g. PLACE Village:Cinema IS LOCATED AT 50,100 4. The server records the position of and responds OK 5. The connection is closed 3-2 Use Case – Find the absolute location of a place 1. Client connects and checks the SGLS version 2. The client sends a message of the form PLACE LOCATE 3. The server looks up the location and responds with PLACE IS LOCATED AT , e.g. PLACE Village IS LOCATED AT 50,100 or an error message if the title is not recognised. 4. The connection is closed 3-3 Use Case – Find relative location of a place 1. Client connects and checks SGLS server version 2. The client sends a message of the form PLACE WHEREIS RELATIVE TO USER 3. The server responds with is at relative , to 4. Where you calculate the distance and bearing using Pythagoras and simple trigonometry (we assume the earth is flat for a small region) with respect to the user. 5. The connection is closed 3-4 Use case – Locate Group Centre 1. Client connects and checks version of the SGLS server 2. The client sends a message of the form GROUP WHEREIS CENTER 3. The server responds with a list of the group members in the form GROUP CENTER is at absolute position Where x,y is the location of centroid (centre of gravity) of the group a. If the group is empty the server responds ‘GROUP IS EMPTY’ b. It responds with an error code in all other cases. 4. The connections is closed 3-5 Use case – Find group spread Client sends GROUP #GROUPID SPREAD Server responds with a list of the users USER #USERID is , from group centre … In this 3rd iteration • You can preload the server with some known landmarks either from a file or statically.