Cont. of the question: They can also query the system to find people within a given distance of their location.

Description: Overview. Each user in the system is uniquely identified by a string ID (e.g. a MAC address or cell phone ID). Only the user themselves knows their unique ID, the rest of the world only sees a friendly name that users get to choose themselves. You are building a Java servlet that provides the following functions:

• Update – Allows a user to update their current position. The user must supply their unique ID, their friendly name, and their current position.
• Delete – Allows a user to remove themselves from the tracking servlet. The user must supply their unique ID.
• Query – Allows a user to find the name, position and distance to all users within a given distance of the user. The user must supply their unique ID and the radius of interest (in meters).

Coordinate system. Mobile devices report their position in UTM coordinates. UTM coordinates consist of two float-point numbers, an easting and a northing. The easting specifies how many meters the device is to the east of a fixed grid reference location. Similarly the northing is how far the device is north of the grid reference. To calculate the distance between two positions in UTM coordinates, use the Pythagorean theorem. 

Web service input. You are building a servlet that provides a RESTful web service. The following GET parameters are accepted by the web service:

• command – Specifies the desired function, parameters is a string: update, delete, or query. Required by all requests.
• id – Unique string specifying the user making the request. Required by all requests.
• name – Friendly name the user wants to be displayed as. Required by the update command.
• northing – The northing coordinate of the device. Required by the update command.
• easting – The easting coordinate of the device. Required by the update command.
• distance – The radius in meters the user wants to search for users. Required by the query command.

Web service output. The web service returns results in JSON format. Every response always contains a string field status. The status contains the string “OK” if the request was successful. If their was an error, the string contains a human-readable description of what went wrong (e.g. “ERROR: unable to parse distance as a floating-point value!”). Your servlet should be robust to bad requests and always return a well-formed JSON result with a status field. 

The only command with an additional result field is the query command. This command returns a field near containing an array with 0 or more elements. Each element in the array contains information about a user within the queried radius. The fields returned in each element are:

• name – friendly name of the nearby user
• northing – northing coordinate of the nearby user
• easting – easting coordinate of the nearby user
• distance – the distance calculated between the user who made the request and the nearby user
• timestamp – when the nearby user last update their position, expressed as the number of seconds since Jan 1, 1970

Here is an example result from a query request:

{
    "status": "OK",
    "near": [
        {
            "name": "carol",
            "northing": 50,
            "easting": 150,
            "distance": 70.710678,
            "timestamp": 1362722508
        },
        {
            "name": "bob",
            "northing": 150,
            "easting": 150,
            "distance": 70.710678,
            "timestamp": 1362722494
        }
    ]
}

Pruning data. Users may disappear from the network without deleting themselves from the tracker. You need to implement a pruning mechanism. If more than 1 minute has elapsed since a user’s last update command, then you should delete that user from the tracker. This pruning should happen in a timely manner (i.e. within a few seconds of being over 1 minute stale, the user is deleted). 

Concurrency. Remember that only one instance of your servlet object will exist. This object may get called by multiple threads in parallel. This will almost certainly happen when I test your submission. Thus you should ensure that all access to non-thread safe variables is appropriately protected. You can test your program with the Apache benchmark utility ab with a concurrency > 1. 

Example implementation. The course schedule page has links to a working servlet implementation. You can experiment by directly typing in URLs with GET parameters to the servlet. There is also a HTML test client. The HTML client uses a PHP proxy page to avoid the cross-origin restriction of the AJAX requests (due to the different port numbers of the servlet and web server). 

Servlet details. You should build a Java servlet as an embedded Jetty application (see the Java Servlets lecture/links for example code). You will need to download a copy of Jetty v9. You can develop your servlet in Eclipse if you like or work on the command line. The schedule page has example unix scripts showing the JAR files you need on your CLASSPATH to compile and run an embedded Jetty servlet. You can obtain the handyjetty-all JAR file from /home/staff/vertanen/jetty/lib on katie. 

Your application should take a single command-line argument specifying the port to start the server on. You can assume any HTTP request to the server is for the servlet (i.e. the server does nothing but provide the web service).

P.S.: I will need the URL (and port) and the source files (codes).

More information: https://katie.mtech.edu/classes/csci470/assign/geotrack/