PA 1 - Named Pipes

#processes #pipe

Class: CSCE-313

Notes:

Introduction

In this assignment you'll write a client program that connects to a server using named pipes and uses the exported API of the server to realize client functionality. The server hosts electrocardiogram (ECG) data points of 15 patients suffering from cardiac diseases. The client communicates with the server to complete two tasks.

The client has to send correctly-formatted messages to the server using a communication protocol defined by the server.

Starter Code

Server Specification

The client requests a service from the server by sending it an appropriately formatted message through a FIFORequestChannel class. In response, the server executes the correct corresponding functionality, prepares a response, and sends it back to the client through the same channel.

The server is in an loop in handle_process_loop doing the following.

while(1) {
  read request from inbound fifo
  service the request
  write response to outbound fifo
}

There are four message types:

The first two correspond to data classes datamsg and filemsg.

There are subtelties to be considered in the request-response protocol between the client and the server. For e.g., if the client writes two requests into the channel in succession, and the server provides a buffer larger than the first request to read a message, it could read the first request and part of the second request. If that happened, the server would have to account for it. Thankfully, our protocol is strictly request-response driven, so the client never sends another request until it receives a response from the server.

3.1 Connecting to the Server

You will see the following in the server's main function.

FIFORequestChannel* control_channel = new FIFORequestChannel("control", FIFORequestChannel::SERVER_SIDE);

The first argument in the channel constructor is the name of the channel, and the second argument is the side (server or client) that is using the channel.

To connect to the server, the client creates an instance of FIFORequestChannel with the same name but with CLIENT_SIDE as the second argument:

FIFORequestChannel chan("control", FIFORequestChannel::CLIENT_SIDE);

The two lines above belong to the FIFORequestChannel class, and set up a communication channel over an OS-provided IPC mechanism called a FIFO or a named pipe. Named pipes are created by the system called mkfifo.

They are used by processes to receive (using the read system call) and send (using the write system call) information to one another. The client uses the cread and cwrite functions appropriately to communicate with the server. For more on “named pipes”, refer to fifo.7.html.

After creating the channel, the server goes into an  loop processing client requests. The client and the server can connect with each other using several channels.

3.2 Data Point Requests

The server contains the BIMDC directory which includes 15 files (1.csv-15.csv), one for each patient. The files contain ECG records for a duration of one minute, with a data point every 4ms, resulting in a total of 15,000 data points per file. A particular row (data point) in any of these CSV files is represented using the following format:time(s), ecg, ecg

You will find the request format in common.h as a datamsg. The client requests a data point by constructing a datamsg object and sending this object across the channel through a buffer. A datamsg object is constructed by specifying the following arguments to the client.

The message type field MESSAGE_TYPE is implicitly set to the constant DATA_MSG. Both the message type and its possible values are defined in common.h.

The following is an example of requesting ecg2 for patient 10 at time 59.004 from the command line when you run the client.$ ./client -p 10 -t 59.004 -e 2

An appropriate datamsg object constructed would therefore be the following.datamsg dmsg(10, 59.004, 2);In response to a properly formatted data message, the server replies with the ecg value as a double. Your first task is to prepare and send a data message to the server and collect its response.

3.3 File Requests

Let us first understand the role that buffer capacity plays in file requests. If, for example, we transfer a large file of 20 GB in one transaction, the message sent across the channel or the physical memory required will also be 20 GB. That may not be possible given the limit of a messagewrite in a fifo.

To circumvent this, we set the limit of each transfer by the variable called buffercapacity in both client.cpp and server.cpp. This variable defaults to the constant MAX_MESSAGE (256 Bytes) defined in common.h.

The user can change this value by providing the argument -m to any command. In the example below, the buffer capacity is changed to 5000 bytes.$ ./client -m 5000

The change must be done for both the client and server to make it effective (e.g., seeing faster/slower performance). We can request the file in segments through chunks referenced by the corresponding byte number intervals in the following wayT4:

In this particular example when transferring the chunk of data in the range [10000...15000) bytes, our offset is 10,000 and the length is 5,000 bytes. Therefore, instead of requesting the whole file, you may request each portion of the file where the bytes are in the range [offset...offset + length). As a result, you can allocate a buffer that is only length bytes long but uses multiple packets to transfer a file.

To request a file, you (the client) will need to package the following information in a message.

The message type field MESSAGE_TYPE is implicitly set to a constant FILE_MSG. Both the message type and its possible values are defined in common.h. For example, to retrieve 30 bytes from a file at an offset of 100 you would construct a filemsg object:filemsg msg(100,30);

Here, offset is the first parameter and length is the second parameter. You can also set the offset and length by setting msg.offset and msg.length to the desired value. The type filemsg in common.h encodes this information. When sending a message across the channel to the server, we can then send a buffer that contains the filemsg object, and the name of the file we are attempting to transfer (as a NULL-terminated string) following the filemsg object.

The server responds with the appropriate chunk of the contents of the requested file. You won't see a field for the file name, because it is a variable-length field. To use a data type, you need to know the length exactly, which is impossible to determine at compile time. You can just think of the filename as variable-length payload data in the packet that follows the header, which is a filemsg object.

Also, the requested filename is relative to the BIMDC directory. Therefore, to request the file BIMDC/1.csv, the client would put “1.csv” as the filename. The client should store the received files under the received directory and with the same name (i.e., received/1.csv). Furthermore, take into account that you are receiving portions of the file in response to each request. Therefore, you must prepare the file appropriately so that the received chunk of the file is put in the right place.

Consider this case: the client attempts to transfer a file of size 400 bytes, and the buffer capacity is 256 bytes. In our first transfer we would set the offset to 0, and length to 256. In the next transfer, we would have to set the offset to 256 and the length to 144. The client would have to know the size of the file prior to the transfers so it can make appropriate adjustments to the length in the last transfer. Therefore, it must initially send a message to the server asking for the size of the file.

To achieve this, the client should first send a special file message by setting offset and length both to 0. In response, the server just sends back the length of the file as an __int64_t, which is a 64-bit integer and is necessary for files over 4GB in size (i.e., the max number represented by an unsigned 32-bit integer is . From the file length, the client then knows how many transfers it has to request because each transfer is limited to buffercapacity.

The following is an example request for getting the file “10.csv” from the client command line:$ ./client -f 10.csv The argument -f specifies the filename.

3.4 New Channel Creation Request

The client can ask the server to create a new channel for communication. The flag (-c) used to create a new channel can be used with any other command. All communication for that execution will occur over the new channel.

The client sends a special message with the message type set to NEWCHANNEL_MSG. In response, the server creates a new request channel object, and returns the channel name back, which the client uses to join into the same channel. This is shown in the server's process_new_channel function.

The following is an example of a new channel being requested to transfer file “5.csv”:$ ./client -c -f 5.csv

Your task (2 parts)

The following are your tasks.

4.1 Run the server as a child process (15 pts)

It would be beneficial to implement this functionality first so that the autograder works; however, you can run them separately on two different terminals to locally test your client functionality.

#include "common.h"
#include "FIFORequestChannel.h"

using namespace std;


int main (int argc, char *argv[]) {
	int opt;
	int p = 1;
	double t = 0.0;
	int e = 1;
	
	string filename = "";
	while ((opt = getopt(argc, argv, "p:t:e:f:m")) != -1) {
		switch (opt) {
			case 'p':
				p = atoi (optarg);
				break;
			case 't':
				t = atof (optarg);
				break;
			case 'e':
				e = atoi (optarg);
				break;
			case 'f':
				filename = optarg;
				break;
		}
	}

    // give arguments to the server
    // server needs './server', '-m', '<val for -m arg>', 'NULL'
    // fork
    // In the child, run execvp using ther server arguments.

    FIFORequestChannel chan("control", FIFORequestChannel::CLIENT_SIDE);