MP6 (Wearable) Due: Monday, December 1, 2014 at 11:59pm

This MP will be graded as follows:

• Submitted by Mon Nov 24 11:59pm - 103%
• Submitted by Sun Nov 30 11:59pm - 101%
• Submitted by Mon Dec 01 11:59pm - 100% (standard)
• Submitted by Wed Dec 03 11:59pm - 75% (late submission)

Introduction

You are the creator of a new startup, WearIt, that creates clothing containing sensors to collect data from the user. This data includes 3 different data points, heart beats per minute, blood sugar, and body temperature. After years of prototyping you have created wearables that can collect and transmit all of the data. All that’s left is to create the server program, wearable_server.c, that a user can set up to hold their personal data. You have created a basic draft of how development should follow, and what you need to accomplish.

Your server will be run through command line, with two arguments that correspond to two port numbers - we will call these the ‘wearable port’ and ‘request port’ respectively. Your server must be able to handle numerous connections that can last an arbitrary amount of time, and as such should create a thread for each new connection on the wearable port.

TASKS

[Task 1] Setup the server

Before collecting data, you need to set up two servers to accept connections, on two ports (given by arguments 1 and 2 in the command line). The first port (‘wearable port’) will be used by the wearables to connect and send data to. The second port (‘request port’) will be used for an outside source to connect to and request a report on the current data collected; see task 3. Remember, your wearables may or may not connect all at once. We have provided the prototype open_server_socket() which you will need to implement. The code to setup the request server has been provided in the main function, but you must also accept continuous connections on the wearable port as well.

• What you need to implement-
  • open_server_socket(), main()
• You will need at least the following system calls and types
  • socket(), bind(), accept(), pthread_t
• What else you should know:
  • Your server socket should be able to queue at least 40 connections so you would use listen(..., 40). We have already called open_server_socket() for you, and set up the connection with the user. You just need to accept connection’s for the wearables through the server socket, denoted by the variable: int wearable_server_fd.

A reminder that setting REUSEPORT socket option can be useful.

[Task 2] Collect data

Once a connection has been established between a wearable and your server, the wearable will write to the file descriptor, in the form “<timestamp>:<value>:<type>”. Type will correspond to one of the three strings: "heart_beat", "blood_sugar", “body_temp", while timestamp and value will be an integer value. You are responsible for saving this data for later processing and analysis. We have provided the files queue.c and queue.h, which contain an implementation of a queue that stores timestamped data, and helper functions to get data between certain timestamp ranges (See queue.h on how to use the different methods). PLEASE NOTE: this queue is not thread safe so you will be responsible for synchronizing actions on it.

• TL;DR: What you need to implement:
  • wearable_processor_thread(), main() (initializing locks/queue(s))
• What system and library calls you will use:
  • read(), pthread_mutex_lock/unlock
• What have we provided:
  • queue_t: a queue capable of holding timestamped data, is not synchronized, you will use queue_init(), queue_insert()
  • struct SampleData: basic struct for holding each data sample from the wearable, it holds the type (either TYPE1, TYPE2, or TYPE3), and the value of the data received.
  • extract_key: method that takes a line of text, and parses the relevant data from it (Timestamp, SampleData)
• What else you should know:
  • a slight simpliciation for this MP, you can assume that data will always arrive in 64 byte packets because the wearable clients are actually running on the same localhost. Thus you can read socket data in in blocks of 64 bytes and parse each result as a new data item. A real server might have to stitch read results together because the packets can arrive in arbtirary sizes as they are routed around the Internet - (see http://stackoverflow.com/ questions/7122972/buffering-byte-data-in-c-sharp for an example of buffer stiching).

[Task 3] Analysis of data

Your server is useless if others cannot query it, so we will also open up a port where a user can send a request to. A request to your server will be done by the following:

• A client opens a socket on the request port which is handled in its own thread. For simplicity, this will be the only connection to this server, so you can safely close the server socket after the client closes the connection. This portion of code is provided already
• A client sends a singular request by sending the string “<timestamp_start>:<timestamp_end>” (where the timestamps are both integers).
• Your server parses the request and collects all data received between those 2 timestamps. Data should be collected in the inclusive-exclusive range (<timestamp_start>:<timestamp_end>) (look at the bounds!). If any wearable connection has not received up to that timestamp yet (and has not closed yet), you must wait until that wearable thread receives a timestamp greater than or equal to the given timestamp, before sending request data to the user. Further, if a wearable thread has finished collecting data and closed its respective socket, you still need to include its data. You will need to use some sort of synchronization to ensure that you do not send out the data too early (before every thread has received past the given timestamp, or finished).
• While you will receive no credit for sending data out too early, you may be thinking that you can just service all requests from the user when all wearables have finished, eliminating the need for advanced synchronization. Solutions that do this will only receive 80% of the maximum possible score. The data should be sent as soon as it is available, but we provide a small tolerance for network delay.
• When you have received all the data, you will send out the median and mean of the data for each type. We have provided the method write_results(), which (given a file descriptor, char* type, and results set) will write out the required statistics. You should call this method for each type IN ORDER, ie write_results(fd, TYPE1 …), write_results(fd, TYPE2 ....), etc. Further, you must write the string “\r\n” to the file descriptor after your 3 calls to write_results. To gather information about queue events within a timestamp range you can use the given function queue_gather() - see it’s documentation for more details.

• TL;DR: What you need to implement:
  • user_request_thread(), main() (initializing lock(s)/queue(s))
• What system and library calls you will use:
  • read(), write(), pthread_mutex_lock/unlock, pthread_cond_wait()/broadcast()
• What have we provided:
  • queue_t: a queue capable of holding timestamped data, is not synchronized, you will use queue_gather()
  • write_results: given the results from queue_gather(), it will write out the analytics for a data set. You will need to call this 3 times for each user request (once for TYP1, TYPE2, TYPE3), followed by a write(“\r\n”);

Hints: Your initial implementation might try to use busy waiting (e.g. while a wearable has yet to send the server all of the data, do not send the request info). However it is relatively easy (and for this MP required!) to turn a busy-wait loop into a mutex and condition wait! If you do busy-wait you will not receive full points for this MP. We encourage you to review correct use of condition variables.

[Task 4] Close gracefully

Your server will stop accepting connections when you receive the interrupt signal (SIGINT), and will exit gracefully (ie freeing all memory and closing all ports) after all wearable connections have closed. In all of the tests you can assume the user has connected to the request socket and the SIGINT signal is only sent after the user has finished requesting all of its data.

• TL;DR: What you need to implement:
  • signal_received(), main()
• The system and library calls you may use:
  • shutdown (or close), close(), free()
• What have we provided:
  
  • queue_destroy()

A reminder that setting REUSEPORT socket option can be useful.

HOW TO RUN

While you will be responsible for creating the server, a simulator for wearables has already been created for you to test with. Recall that you server should take 2 ports, the first being wearable server, the second being the user server.

To compile, run the following commands from a command prompt on a Linux machine:

%> make clean
%> make

Starting your server should look like

%> ./wearable_server 8888 8889
Where 8888 and 8889 are arbitrary ports

Once your server has been started you can begin the simulator

%> ./wearable_sim 8888 8889 BASIC_TEST.ww

Where the 2 ports represent the ports you passed into your server, and the BASIC_TEST.ww is a test script. We have provided a few basic tests to check your output against.

While the simulator is running it will report back the data you sent from your server. Additionally it also generates the expected output, for you to compare against. After running the simulator you should see 3 files, _expected.rp, _received.rp, and _error_report.rp. _received.rp will hold the exact data sent from your server, so to see if your output is correct after running the simulator, you can use

diff _received.rp _expected.rp

Further, _error_report.rp will hold any errors that may have been encounter while running the simulator, (such as being unable to connect to your server)

The test scripts are human readable, so feel free to create your own or modify. Every command should be on its own line.

BEGIN - Signifies the beginning of a wearable definition.
START: - States how much time before this wearable begins transmitting information.
INTERVAL: - States the time delay between sending data points. <type>:<value> - One data point, where type is a string corresponding TYPE1, TYPE2, TYPE3. Value is an integer. Note all data points are transmitted sequentially by order in which they appear in a BEGIN-END wearable definition.
END - Signifies the end of a wearable definition

SAMPLE_INT:<wait time>:<timestamp1>:<timestamp2> - Simulates a user request. There can be multiple commands of this time, and the are simulated sequentially. <wait time> represents the time (in millis) to sleep before this request is sent. The timestamp values represent the range of timestamps requested.

A basic test that creates one wearable that starts 1 second after the simulator is started, with 3 data points (send every second) and requests timestamp between 0, 2000 (with the request started 2 seconds after) would look like:

SAMPLE_INT:2000:0:2000
BEGIN
START:1000
INTERVAL:1000
heart_beat:100
blood_sugar:104
body_temp:104
END

This test script would send the data:

1000:heart_beat:100
2000:blood_sugar:104
3000:body_temp:104

and the expected output would be:

Results for heart_beat:
Size:1
0 100
Median:100
Average:100
Results for blood_sugar:
Size:0
Median:0
Average:0
Results for body_temp:
Size:0
Median:0
Average:0