Academic Projects

.

Academic Projects

Real-time Scheduler for Linux Operating System

This scheduler provides a facility to convert a normal process into a real-time process by calling sched_setscheduler. This real-time process can fork child process, which is also considered as real-time process. If any process fails the admission criteria then an error is returned by sched_setscheduler.

The real-time scheduler that I have implemented works on credit basis. At the end of the period, a process is offered with the additional credits of value C i.e. computation time of that process. The process should consume these credits during next period. If any process fails to consume these credits then it is considered as a deadline miss.

[Top]

RMI Library

Introduction

The implemented set of rmi library, socket library and code generator provides the application writer with a generic interface, which is completely independent of application's code. Application implementer only needs to define the idl file which defines the classes he has implemented and the methods supported by those classes. This information in turn is used to create the stub and skeleton code with the help of code generator. This generated code uses rmi library for marshalling and unmarshalling the parameters and results. Socket library is used by the stub or skeleton to establish the connection with the application server.

RMI Library

Rmi library mainly consists of marshalling & unmarshalling code. Stub can pass arguments of type integer, string, vectror of integer and vector of string to the marshalling code using class Type defined in marshalling. The object of class Type is taken as input for mashalling and the data contained in this object is converted into char * packet. This packet is further passed to socket library.

Socket Library

Socket library consists of a code which establishes connection with the server and sends the data packet received from the marshalling code. Meanwhile the server waits on the select. After the packet is received by the server, server calls the generic skelton and hands over the packet. Same procedure is followed while returning the result of the function from server to client side. Generic skeleton returns the result packet in char * format. Which is sent to the client.

Generic Skeleton

Generic Skeleton maintains the list of all the types (classes) and their instances (objects). This information is used to direct the method call received from socket library to the appropriate derived skeleton object, which has been generated by the code generator. To call the desired skeleton object, generic skeleton maintains the repository of the object pointers and object references. After receiving call from the socket library it unmarshals the packet and compares the object reference in the packet to the same in the object reference repository to decide the target skeleton.

Code Generator

Code generator is responsible for generating stub and skeleton per object of the class in the application server. It uses .idl file to generate these classes. On the client side an object of a stub is created and object reference received from the server side is passed in the constructor of the generated stub. On the server side, application server declares the object of the generated skeleton in the code. Skeleton generates the object reference of the application server object and prints it on the console. Skeleton is also responsible for appropriate method according to the received packet.

[Download] [Top]

      Distributed Hash Table

Introduction

The implemented distributed hash table is based on the basic fundamentals of the CHORD distributed hash table. The implemented distributed hash table provides the user following features. Insertion of key and associated data, Deletion of key, Look-up of a key, Joining of a new node to the existing distributed Ring of nodes, Handling the failure of a node in a distributed ring, Multiple rings of Distributed hash table can be created on the same machine.

Insertion of key and Data

First we take the hash of the given key and then we check if the hashed digest should be inserted on the local node , if no, then we search the finger table and find the suitable successor or the closest predecessor. And repeat the same steps again until the hashed digest has found a suitable successor in which it is to be inserted.

Deletion of key / Lookup of the key

First we take the hash of the given key and follow the same steps as specified in the insertion and delete / lookup the key from the node that owns it.

Joining of a new node

For this we specify the server node in the ring which should be contacted to add the new node. The sever node could be any of the existing node in the ring. Then the server node helps find the suitable successor for the new node. And once that is done we move the keys that belong the new node from the successor node and update the predecessor and successor of the new node and also its predecessor and successor. And then we call the fix finger table on each of the nodes in the current ring.

Leaving of a Node

When a particular node in the existing ring is leaving, we copy the keys of the leaving node to its successor and update the new predecessor and successor values and fix the finger tables of all the nodes in the ring.

[Download] [Top]

Device Driver Framework for Capital OS

Project Pyramid is Device Driver Framework for Capital. Capital is a 32-Bit, Multithreaded, Virtual Memory, Object-Oriented Operating system. Previously the Capital kernel had no provision for the driver to register a handler for its device interrupts and to defer lengthy tasks within the interrupt handler. Project PYRAMID aims at providing the facility for drivers to register their handlers, defer lengthy procedures within a handler by dividing them into two halves.

[Top]