Air Compressor Bot
|
|
Home |
How it works |
Projects archive |
Contact Us Air Compressor Bot |
|
| The Career Path of Freelance Programming Jobs |
network application |
 |
Bidding Time: |
06/01/2005 21:24 - 10/01/2005 00:00 |
Budget: |
$100-500 |
Status: |
Closed |
|
|
|
Job Type: |
|
Description: |
Group Location Service Aims: · To practice and extend your Java programming skills. · To develop a network application using the sockets API (Application Programming Interface) and the JSP (Java Server Page) framework. · 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 4 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 latter 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. Summary of the Deliverables There are 3 main deliverables. No. Coursework Component Limts Assessment Criteria Marks 1 Code + Discussion of 1 aspect of the design per iterationIteration 1: Locating Individuals Iteration 2 : GroupsIteration 3 : Places & Relative positionsIteration 4 : Persistence and JSP status page For each iteration you should show:- · A screen dump of how a transaction proceeds for each use case you implement (or a print of the web page for the 4th JSP iteration).· Full java source code is required for each iteration.· Select and discuss one key aspects of the design that you tackled during that iteration.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 & 4. 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? 500 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 3. The client sends a message of the form: USER #USERID REPORT Where #USERID is an integer and their position is two specified by two integers x & y. 4. The server records the position internally and responds ok. 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 3. The client sends USER #USERID WHEREIS 4. The server looks up the last known position of #USERID responds USER #ID is at absolute position Where x,y is the last know location of the user specified by integer #USERID 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 'USER' · The GLS version reported for iteration 1 will be of the form 1.XX · 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 it checks the version is 2.XX if not it closes the connection, reports and error and stops. 3. The client sends the message GROUP #GROUPID CREATE Where #GROUPID is an integer. 4. The server creates an empty group identified by #GROUPID 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 #GROUPID). 5. The connection is closed. 2-1 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 #USERID JOIN GROUP #GROUPID 3. The server records that #USERID is a member of #GROUPID 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-2 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 #GROUPID LOCATE ABSOLUTE USERS 3. The server responds with a list of the group members in the form USER #USERID is at absolute position x,y USER #USERID is at absolute position x,y . Where x,y is the location of the user specified by integer #USERID 4. At the end of the list the server prints a blank a. If the group is empty the server responds 'EMPTY' 5. The connection is closed Optionally for completeness you can add use cases for: 2-3 Use case - User leave a group Checks as in 'join' use case above but with message USER #USERID LEAVE GROUP #GROUPID 2-4 Use case - delete a group Checks as in 'join' use case above but with the message GROUP #GROUPID DELETE 2-5 Use case - delete a suer Checks as in 'join' use case above but with the message USER #USERID DELETE In this second iteration: · The GLS version reported for iteration 2 will be of the form 2.XX · 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 the version is 3.XX if not it closes the connection, reports and error, and stops. 3. The client sends a message of the form: PLACE "title: description" REPORT 4. The server records the position of 'title' 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 WHEREIS 3. The server looks up the location and responds with is at absolute position x,y 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 #USERID 3. The server responds with is at relative to #USERID 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 #GROUPID WHEREIS CENTER 3. The server responds with a list of the group members in the form GROUP #GROUPID 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 'EMPTY' 4. The connections is closed Optionally you can add use cases for: 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 · The GLS version reported for iteration 3 will be of the form 3.XX · You can preload the server with some know landmarks either from a file or statically. Iteration 4 - Persistence and JSP status page In the 4th and final iteration we add the idea of persistence and develop a simple web interface to view the overall status of the GLS server. Use Case - User snapshots the system status 1. The client connects to the SGLS server. 2. The client receives the welcome message and checks the version is 4.XX if not it close the connection and stops. 3. The client sends a message of the form SYSTEM snapshot 4. The server writes the current user, group and place information it holds to 3 separate files and responds 'done' The user can then access a web page that is created on the fly using JSP to access and layout the current snapshot of the GLS system. 4-1 Use Case - View users A web page is build on the fly to show the users know to the system when the most recent snapshot was taken. 4-2 Use Case - View groups A web page is build on the fly to show the groups know to the system when the most recent snapshot was taken and there membership 4-3 Use Case - View Places A web page is build on the fly to show the places know to the system when the most recent snapshot was taken In this 4th iteration · The GLS version reported for iteration 4 will be of the form 4.XX · Although this is obviously meant to be a follow on from the initial 3 iterations. You may construct the files from scratch to show the JSP functionality if your implementation of the first 3 iterations is incomplete. STOPzilla! Anti-Spyware Software
 Soccer website Recording Studios Directory Recording Studios directory Banners for online poker site. I need a spider web graphic done up in .psdThis project is the proprietary information of .
Click here to remove this project from OUR database.
|
Operating System: |
(None) |
Database System: |
(None) |
| <<< back |
|
| Home | Projects archive | RSS | Resources | Links | Contact Us | © 2004-2009 ProjectsList.biz /0.093 |