jsbruglie / psis Goto Github PK

Refine the implementation of the data structures so as to optimize performance. JNOS suggestion is to put the mutex locks inside the lists, without loosing abstraction.

The Front server is not necessarily in a separate file, but it is convenient to be so. In fact, the two servers should communicate via socket. The clients interact directly with the front client on 127.0.0.1:9999 which in turn redirects them to another port, that is being used by the Data server.
The Front server should obtain the number of the port by connecting to the Data Server each time a client initiates a connection.

The Front server should have 3 separate threads:

• Command-line
• Client redirection
• Making sure the Data Server has not crashed. If so, relaunch it. The Data Server may store a persistent indicator that it has been shutdown correctly. If it is not present, it assumes it has crashed, and it should reload the database from the backup files.

The hashtable is a vector of lists.
Each bucket should have it's own mutex, so as to maximize the profits from multithreading.

There is a lot of unnecessary sends and recvs that are handled by the connection interface.

kv_write

-Implement overwrite function
-The user is allowed to write a message with size <= MAX_SIZE

kv_read

-It should use a temporary buffer, that only reads up to DEFAULT_MAX_SIZE. It shouldn't leave garbage in the socket for the next operation.
-memcpy should be used as opposed to strcpy
-Returns an int that is the actual size of the element that the client is trying to read. The function to be implemented, however, only allows the client to read DEFAULT_MAX_SIZE chars, even though the actual value may be longer. This is a known problem with the specification of the problem, but it should be implemented like so nonetheless.
-OPTIONALLY, define an additional function that performs the memory allocation an is able to read the full size of the value stored

1. Fault tolerance
2. Thread exiting and memory leaks

If the server crashes, there should be a persistent backup of the data structure. Updating this file with each request is expensive, and so the solution should be to have a copy of the data structure that is updated either manually (from the command line) or automatically from time to time, but also a log of every write action that has been done afterwards.

Implement a pool of threads as part of the server core functionality.

Build a client app that randomly produces requests with a random interval between them. Also, wirte a bash script that starts a big number of clients for performance testing purposes.