Socket-Programming

Compile and Execute:

Kindly run the following command in the terminal to compile the code and generate executable files.

make all

Since it is a distributed client-server application, we need five terminals and should run the following commands in each terminal in given order:

./scheduler --> Terminal 1

./hospitalA <location A\> <total capacity A\> <initial occupancy A\> --> Terminal 2

./hospitalB <location B\> <total capacity B\> <initial occupancy B\> --> Terminal 3

./hospitalC <location C\> <total capacity C\> <initial occupancy C\> --> Terminal 4

./client <Location of the client> --> Terminal 5

Note that the hospitals expect map.txt input file. Kindly provide your map file in addition to the valid input arguments for successfully executing the code.

 

Architecture Details:

 

• Implemented a computational offloading distributed system based on client-server architecture using UDP and TCP sockets.

• The backend server of hospitals parses input map.txt and performs computation based on Dijkstra's algorithm for given client location further passing the results to the edge server a.k.a scheduler.

• Edge server in turn does all the book-keeping to create customized resource allocation depending on the client queries.

 

Code Structure:

Client: client.cpp

This file consists of all the logic for client to successfully establish connection with scheduler for querying its location and to receive a response for the same. Note that client establishes a TCP connection with the scheduler, actively waits for response and terminates itself as soon as it gets a response for the queried location.

 

Server: server.cpp,   server.h

Designed a server class in order to ensure minimum repetition of code across 4 servers (three hospital backends and 1 scheduler acting as edge server).

Following are the public functions offerred by the server class:

1. createSocket
2. receiveUDPPacket
3. sendUDPPacket
4. receiveTCPRequest
5. respondTCPRequest

Above functions will be called by scheduler and hospital servers in order to communicate through UDP and TCP across the network. In addition to following DRY practice, this way of designing further helps to keep all communication related socket functionalities in one place so the respective server files (scheduler and hospitals) have to just take care of parsing messages and computing metrics.

 

Scheduler [Edge Server]: scheduler.cpp

Scheduler acts as an edge server taking request from clients further coordinating with the hospital servers to assign client at the best possible location. It relies on server class for communication but has the necessary functions for book-keeping, decoding messages and lastly deciding the assignment based on received scores.

 

Graph: graph.cpp   graph.h

Graph class would be responsible for all the computations related to graph, starting from reading and parsing the map.txt, creating a data structure to store graph followed by running Dijkstra's algorithm to find shortest path. Since all three hospitals rely on the same graph computations, it was necessary to have a separate class and which all hospital servers can rely on.

 

Hospitals [Backend Servers]:

Class: hospital.cpp   hospital.h

Continuing to follow DRY coding principle, designed a hospital class that in turn uses server class for communication, graph class for graph computations and takes care of all the things in between which are decoding the messages, computing the score and logging necessary statements. This method of design makes the code base scalable in true sense since the individual hospital servers ( i.e hospitalA, hospitalB and hospitalC) just need the driver code to call two functions which are:

1. listen
2. act

These two functions in turn takes care of all the code logic, computations as well as communication. Hence, using this class, we can scale up this logic not just to three but any number of hospital servers.

Driver: hospitalA.cpp   hospitalB.cpp   hospitalC.cpp

These files rely on above explained hospital class for its entire functionality. It just acts as a driver code to initialze the class with input location, capacity, occupancy along with its hardcoded UDP port.

The driver code infinitely calls the listen (blocking call) and act functions offerred by the hospital class infinitely until termination.

 

Communication Messages:

In order for the clients and server to decode the message successfully after every exchange, they follow a particular format for communication as described below:

Client -- Scheduler

1. Client --> Server:

   • "<Vertex Index>"

2. Server --> Client:

   • "Hospital <A/B/C>"
   • "Not Found"
   • "None"

Scheduler -- Hospital

1. Scheduler --> Hospital:

   • "Query:<Verted Index>"
   • "Assigned"

2. Hospital --> Scheduler:

   • "Hospital <A/B/C>:<occupancy>,<capacity>"
   • "Hospital <A/B/C>:<score>,<distance>"

Note, all messages are of type string.