Remote File Memory Mapping

Question

I was given this task to implement an API with these definitions below which allow processes to memory map sections of a file located on a remote server. I am also required to implement a client/server example.

// Type definition for remote file location
struct fileloc {
    struct in_addr ipaddress; // Remote IP
    int port;                 // Remote port
    char *pathname;           // Remote file to be memory mapped
};
typedef struct fileloc fileloc_t;

// Create a new memory mapping in the virtual address space of the calling process          
// location: Remote file to be memory mapped
void *rmmap(fileloc_t location, off_t offset);

// Deletes mapping for the specified address range
// addr:   Address returned by mmap
int rmunmap(void *addr);

// Attempt to read up to count bytes from memory mapped area pointed
// to by addr + offset into buff
ssize_t mread(void *addr, off_t offset, void *buff, size_t count);

// Attempt to write up to count bytes to memory mapped area pointed
// to by addr + offset from buff
ssize_t mwrite(void *addr, off_t offset, void *buff, size_t count);

I am facing some design challenges. Here is what I have thought of:

• The client for the first time calls rmmap(), predefining the server location and the requested file, along with an offset.The server returns a fixed chunk of the file back to the client.
• the server will take note of which client requested which chunk of file. It will also keep a table of ClientIDs, rquested offsets, and flag status (locked or not). Conflict handling refers to this table.
• the read and write functions will be used locally on the client and will have no connection to the server. (although I'm wondering if it's possible connect to the server before writing such that a client can only write when no one is reading).
• The unmap() will be used to "commit" changes to the server.

I'm still not sure on locking files and solving conflicts, however am I on the right track?

Answer 1

I'm still not sure on locking files and solving conflicts

In addition to the API you will need to define a protocol for the transmissions, likely one that is internal (i.e., implemented within the library and not transparent to the user, the way that TCP is implemented internally relative to socket() ). The client will need to maintain a persistent connection and actively handle incoming messages from the server. These messages would correspond to writes made by other connected clients -- i.e., they are updates to the map.

When a client A sends a write to the server, if that location has just been written to by client B and client A has not acknowledged receiving an update regarding this, you return a failure to client A.

You could streamline this by dictating that a client cannot write to a location it has not read from the server yet, and thus the server need only send updates to those connected clients who have read whatever section of the file.

Answer 2

The task is open ended, so many possible implementations are valid. The main remark that goes against your choices is that in a real environment one wants to mmap a file that does not fit into system memory. If I were the teacher I would request that. So, modifying your design for this to work:

• the read and write will work locally when possible, or it will replace the local chunk with a new one if necessary, replacing many chunks as it goes through the whole read or write.

Locking behavior is completely "under defined" in the problem. The trivial case is that each client has an exclusive lock on each file, retrieved while mmaping. A less trivial case locks chunk ranges while reading and writing. Locking individual chunks is easy and can be implemented as a consequence of reading and writing from the server, but each read and write will not be atomic in the full range of chunks. Notice that advanced locking is not being requested. The API is insufficient for declaring exclusive or shared locks.