We first save the objects themselves as Items, which each keep an item's characteristics and type.

class Item {
private:
    string type;
    const NPoint character;
    ...
};

The NPoint is a representation of the Item's parameters, and functions as a point in an N-dimensional coordinate system.

In addition, our code implements the algorithm with three different possible distance functions: Euclidean distance, Manhattan distance, and Chebyshev distance, but to allow the addition of other distance functions in the future, we implemented generic code with an abstract distance class.

class DistanceCalc {
public:
    virtual double distance(NPoint p1, NPoint p2) = 0;
    td::string toString();
    ...
};

Finally we created a Classifier class. An object of this type, keeps training and testing data (both with their corresponding type answers), and makes it's own classification. We keep the answers to both the test and answers, so we can later calculate the algorithm's confusion matrix.

To make the addition of new commands easy and accessible in the future, we made a generic Command abstract class, of which all commands inherit.

class Command {
    ...
    string description;
    virtual void execute() = 0;
};

Each command has to implement two major things in order to be added to the server. First it needs to implement an execute command, which does whatever the command is supposed to do. Second, it needs to keep a description of the command, in order to add it as a valid option in the menu for the client to pick.

The current list of commands is as follows

• upload an unclassified csv data file - lets the client upload both a training data file and a testing data file.
• algorithm settings - lets the user view and change the k value and distance calculation method for the algorithm (accepted k values between 1 and 10, and valid calculation methods are "EUC" (Euclidean), "MAN" (Manhattan), "CHE" (Chebyshev)).
• classify data - asks the server to classify the data currently uploaded.
• display results - displays the results from the previous classification.
• download results - lets the user download the classification results from the previous classification to its computer.
• display algorithm confusion matrix - displays the algorithm's confusion matrix.

To make it easier to add more I/O services in the future, we implemented an abstract DefaultIO Class as follows.

class DefaultIO {
    ...
    virtual string read() = 0;
    virtual void write(string toWrite) = 0;
};

This makes sure each I/O service implemented and used in the future implements at least the minimum requirements it needs to (an input and output commands).

The main way to get Input and Output in this project is through sockets (because we need to establish working communication between the server and clients). And so, we'll further explore the SocketIO class.

class SocketIO : public DefaultIO {
private:
    int socket;
    int expected_data_len = 4096;
    std::string toSend;
    ServerProcess server;
public:
    ...
};

The SocketIO saves the socket it is in charge of, and the ServerProcess which created it (ServerProcess objects are explained in Server Code).

In addition, while working on the server, we found out sometimes the server sends the client multiple different messages in a row, without needing an input in-between (which can cause a problem as the client doesn't know when to send input or listen to more content from the server).

To fix this problem, we made the SocketIO keep a buffer of everything it needs to send, and the write function just adds a message to this backlog.

void SocketIO::write(std::string message) {
    toSend += message;
}

Then, Only when we call the read command, we will send a message to the client.

std::string SocketIO::read() {
    //Sending backlog
    ...
    
    //Clearing backlog 
    toSend = "";
    
    //Reading new Message
    ...
}

This infrastructure makes sure we only send a message to the client when we expect an input, which makes the communication more consistent.

The server code is divided to two different object files. First manages the CLI (Command Line Interface) and communication with a single Client. And the second handles the management of sockets and threads for the server as a whole.

Thanks to all of our previous work, the CLI Object is relatively small and simple. It has one function start, which enters a continuous loop of printing the menu, waiting for a command decision, and executing the corresponding command.

class CLI {
    void start() {
        while(true) {
            //print menu based on all the commands' descriptions
            string menu = ...;
            defaultIO->write(menu);
            
            //receiving user choice
            string choice = defaultIO->read();
            switch (choice) {
                ...
            }
        }
    }
};

Please note that this is merely a schematic representation of the algorithm, and there is more going on behind the scenes.

The ServerProcess, manages multi-threading and socket assignment for new users. In addition, It manages the timeout mechanism and makes sure there are no memory leaks.

graph TD;
    Listen-->Accept;
    Accept.->CLI1-->Wait_For_Users;
    Accept.->CLI2-->Wait_For_Users;
    Accept.->CLI3-->Wait_For_Users;
    Listen-.timeout.->Wait_For_Users;
    Wait_For_Users-->Close_Server;

• Listen: The server waits for a user to connect.
• Accept: The accept stage in the connection process.
• CLI: A communication is created between the server and the client in a different thread.
• Wait_For_Users: Once the listen reached a timeout, it waits for the remaining users to finish their communication with the server.
• Close_Server: Frees remaining data from the heap.