1.0 Introduction


Broadly there are two types of Inter process Communication (IPC) Techniques , Synchronization and Message Passing. Each of these has its own drawbacks  and advantages. If Synchronization is faster then Message Passing renders simpler code. Many implementations of these types are available on UNIX , e.g Shared Memory and Semaphores, Pipes and Message Queues etc.[7].

             On Linux and almost all flavors of UNIX we have , Pipes, FIFO , Sockets, System V Message Queues and POSIX Message Queues as major Message Passing techniques. Again all of them have their own merits and demerits. Our purpose is to design and implement a new message passing IPC technique which combines the good features of these  techniques and also provides a set of new aspects so that the user processes can get a more flexible, adaptable and easy to use means of communication. We go by explaining the merits and demerits of the available techniques, justify the need of a new message passing scheme and present the design of the implementation.

            Where behavior is an aspect of a system facility a user might be mainly interested in, a good architecture plays an important role to make the behavior adaptable and extensible. Modularity and flexibility are the properties of a good architecture, which can be achieved by using object – oriented languages , Design Patterns and Frameworks. Aspect Oriented Software Development (AOSD) is a new emerging technology which allows us to achieve our goal of a good  architecture. There are different ways to use AOSD e.g using tools like AspectJ and AspectC. But for this project we are using an AOSD framework for system software development. We also provide a brief description of AOSD in a following section, Aspect Oriented Software Development. 



2.0 Motivation


In this section we justify the need of a new IPC technique by specifying the requirements and then we explain a little about the architectural aspects.


2.1 Requirements


 Our purpose is to implement a connectionless message passing IPC technique called “Mailslots”. A mailslot is a resource created by a process called its owner in which discrete messages are stored.  Multiple  processes including the owner can send or receive messages to each other through that mailslot depending upon their rights decided by the owner. Different message sizes are supported to improve the efficiency. Many features like security, deadlock handling, signaled I/O are supported which are described in detail in entailing sections. As you go through these features you can refer to some examples of  communication sessions under section Example Sessions.


2.1.1 Ownership:


A process which creates a mailslot will be the owner of the mailslot. The concept of ownership is very central to "Mailslots". Ownership should not be confused with security, although security uses this feature extensively.   Once a mailslot is created with a set of attributes e.g the maximum size of a message and access privileges to other processes, no other process except owner can change these attributes. Of course this is related to security but there is more to ownership.  Without its owner the mailslot is orphan. A mailslot can be orphan if its owner dies or closes the descriptor explicitly. This state of mailslot is called Closing State. Once a mailslot is in its closing state no process can open it. Once all of its open descriptors are closed the mailslot will be removed. A mailslot can be removed without going into closing state. This will happen if the owner is the last process closing it.  Ownership to mailslot can not be transferred  (see section Role Based Access) and Example Sessions. Many features of "Mailslots" use ownership e.g security or role based access.. Access privileges (security) are described in detail under requirement section Role Based Access.



2.1.2 Formatted Messages:


Mailslots is not stream oriented. UNIX‘s  “pipe/FIFO” and “sockets” do not support formatted messages. These are stream oriented channels with no message boundaries. If a receiving process needs to interpret the data in forms of records then sender and receiver must agree upon a protocol. In this protocol the maximum size of message must be decided beforehand. Also there may be a need of a pre-specified delimiter character or otherwise the length of the message has to be sent along with the message[7]. Stream channels are efficient when the bulk of data in the form of a stream is to be transferred. But to make a request/reply channel in which the maximum message size, the size of sent message and message classification play a major role, the support of discrete messages should be provided. System V and POSIX message queues support formatted messages so as Mailslots.

            Like System V message queues Mailslots provide support of typed messages. It means you can assign a type number to a message and a receiver can block for a particular message type. This is very useful in creating client/server applications. This feature is missing in POSIX message queues.   


2.1.3 File Descriptor Based Interface:


A nice thing about “pipe/FIFO” and “sockets” is their file descriptor based interface to user processes. Due to file descriptor based interface the standard “read”, ”write”, “close” many other system calls can be used as an interface to user processes. It makes the user interface very simple. Also, the major advantage of file descriptor based interface is that it can be used with “select” and “poll” system calls[6][7]. It is very difficult to use System V and POSIX message queues with I/O multiplexer or “select” system call.  To use message queues with “select” system call we have to use a FIFO to signal the presence of a message. Mailslots has file descriptor based interface.        


2.1.4 Role Based Access:


Mailslots has role based security model. In a system, a process plays the role of a user. For example when you run the “passwd” program to change your password the “passwd” process plays the role of root for you so that you can change your password by requesting it. This idea of role can be further extended and a process can play a role of a “child process”, “a process in the same process group”, “a process in the same session” and many other. Depending upon the role a process playing at any time the access to a resource of that process can be decided. A role can be represented as a domain as shown in figure 1.0.

 The domain of a mailslot and its access permissions are set by its owner, who gets all the access privileges, at the time of its creation or at any time later in the program. Only the processes that have their domain equal to or less than the domain of mailslot can get the specified access to the mailslot. For example a Process P1 creates a mailslot M with domain SESSION and access rights RDWR. Now process P1 spawns a process P2, so P2 is child of P1. In start P2 will get the read/write access to M because it will be in the same session as of P1. But later at any time if P2 changes its session and becomes a session leader then it will not get any access to M because now its SESSION domain is different from M’s. But if P1 changes the domain of M to CHILD then P2 will get the read/write access again. Check section Example Sessions for some more examples.

It means the processes can go in and out of the domain of mailslot and their access to mailslot will be decided at the time they perform any operation on the mailslot. This must be kept in mind that although a process may not be getting access  to mailslot because it changed its domain , it is still maintaining the file descriptor to that mailslot and it is counted towards the usage of mailslot.So if a process is not willing to use that mailslot then it should explicitly close it. In case, which is not uncommon, if owner of a mailslot dies then domain and access rights of mailslot are set to , ANY and RDWR respectively. It means any process, which is having an open descriptor to that mailslot, in the system will get RDWR access to mailslot from now, but no other process can open that mailslot after this point. This state of mailslot is called closing state as described in section Ownership.  Please refer to section Example Sessions for detail. As a reminder, an owner gets all the access privileges to its mailslot and it can not be changed.


                    SESSION           PGROUP     USER      UGROUP        CHILD     ANY





ANY            :      Any Process in the System.

UGROUP     :     A Process with the same effective user group id.

USER           :     A Process with the same effective user id.

CHILD         :     A Child process.

SESSION     :     A  Process with the same session id.

PGROUP      :     A Process with the same process group id.


Access Permissions

 O_NONE    :     No Access

RDONLY      :     Read Only Access. 

WRONLY      :    Write Only Access.

RDWR            :     Read/Write Access.


                                                                                Figure 1.0  Roles as Domains


2.1.5 Signaled I/O:


            In signaled I/O, most of the times confused as Asynchronous I/O, if a process registers for a POSIX real-time signal then the registered  signal is delivered to the process on arrival of a message. POSIX message queues support this functionality but the signal is delivered when a message arrives in an empty queue. Support of signaled I/O is very helpful especially in case of request/reply channels where the messages are not so frequent  and it is not worth making the process to wait for a message. Signal is not delivered to the process if it goes out of the security domain of the mailslot, see Role Based Access.     


2.1.6 Deadlock Handling:


 All IPC techniques have high risk of deadlock. Deadlock is mainly caused by formation of cycles of wait calls among multiple processes or within one process. Let's take the example of above described closing state of mailslot. Process P1 creates a mailslot M and grants its access to CHILD domain. Some time later it forks two processes P2 and P3 which get the access to M. Processes P2 and P3 go to block for a message and at that time P1 dies without transferring the ownership of M to anyone. Now since M is in its closing state no other process can open M , which leaves P2 and P3 always blocked waiting for a message to arrive. There are many situations like this which have high potential for deadlock.

There are well known ways to tackle deadlock these being Deadlock prevention, Deadlock detection, deadlock avoidance and ignorance [3]. We are following the approach of Deadlock avoidance to handle deadlocks in Mailslots. Deadlock avoidance is a policy to avoid going in the state of deadlock or in an unsafe state. So the checks are performed at points which have potential of deadlock and if any problem is found appropriate action is taken.    


2.2 Example Sessions







       The example in figure 1.1 below shows the concept of ownership and closing state. In this example the security aspect is ignored and we assume that all the processes have the read/write access to mailslot M.  In  figure 1.1(a)  it is shown that process P1 is owner of mailslot M and two other processes P2,P3 have got the RDWR access to M. This model can be used as a message queue like communication between the multiple processes. Now if process P1 dies or closes the mailslot M then M goes in the closing state, this is shown in figure 1.1(b). In figure 1.1(b) it also shown that  process  P4  which is  trying  to open M in its closing state, is not successful.  



                                                         Figure 1.1 Ownership and Closing State




Let's take another example in which two processes communicate in a more secure way. This is depicted in figure 1.2  below, where P1 and P2 create their personal mailslots and set thier access rights to WRONLY (write only) for other processes. Now P1 can read and write messages to M1 but P2 can only write to M1 and vice versa for M2.

                                                Figure 1.2




As our last example we discuss the domains or role based access to mailslots, shown in  figure 1.3.  Consider the figure 1.3(a) in which process P1 creates a mailslot M and sets SESSION domain for it. It means the processes in same domain as of P1 can access M now. P2 is child of P1 and P3 is any other process, both of them are in the same session as of P1, so they have access to M. Now if P1 being the owner of M changes the domain of M to CHILD then P3 will no longer have any access to M. This scenario is shown in figure 1.3(b).  As an alternate to (b) if P2 changes its session and and becomes its own session leader, then it will not have access to M. This case is shown in figure 1.3(c).



                                                                           Figure 1.3 Role Based Access 



2.3 Architecture

            In this part we will discuss the architectural aspects of  this project. Architecture of  "Mailslots"  is designed on an AOSD framework for system software development. In the next section we give a brief introduction to AOSD and then the architectural design of "Mailslots" is presented.


2.3.1 Aspect Oriented Software Development:


Aspect Oriented Software Development (AOSD) is an emerging field in Software Engineering. It is not completely different from Object Oriented Software Development but in fact is based upon it. The purpose is to make the Object Oriented software more adaptable and more reusable by overcoming the drawbacks of this design technique. Objects have proven their worth in modular designing, but they are not able to capture some of the concerns, which crosscut the different parts of the software. These crosscutting concerns get intermixed with the basic functionality of the code and make it too specialized to be reused. Examples of these concerns are, Security, Concurrency, Deadlock Handling, Debugging, Resource Allocation, Scheduling, Fault tolerance etc. These crosscutting concerns are well known as the aspects of the software.   


Most of the above-discussed concerns are found in System Software Development. It can be either user level system software which makes extensive use of the Inter Process Communication techniques for synchronization to handle concurrency or the kernel level device driver development in which the similar hardware devices need the resources in different ways. All of these are concerns, which are not captured by the Object Oriented Design and make the software less expandable and less reusable.


A number of Research Groups are working on AOSD and have chosen different ways for it. Gregor Kiczales and his research group at Xerox PARC have done the major work in this field. They have developed an Aspect Oriented extension to JAVA, which is called AspectJ. Our research group, The Concurrent Systems Group (www.iit.edu/~concur ), at Illinois Institute of Technology (IIT), is also working on this. This group has given a Framework for the Aspect Oriented Software Development, which has been published in ACM Computing Surveys, March 2000 [1]. We  are using this framework for our purpose.


2.3.2 Dynamically loadable kernel modules in Linux (LKM's):


Figure1.4a Traditional System Decomposition                     Figure 1.4b  Aspect Oriented System Decomposition



 The Linux kernel has a modular design. At boot time, only a minimal resident kernel is loaded into memory. Thereafter, whenever a user requests a feature that is not present in the resident kernel, a kernel module is dynamically loaded into memory. If that functionality is not  needed later the respective module(s) can be removed. Nowadays almost all the device drivers  for Linux are developed using LKM's[2].      

Mailslots is also developed using LKM's. But we have taken the aspect oriented  approach in decomposing the design. Traditional approach to modular design in systems is two dimensional in which components (e.g IPC) are divided along  Layers axis only, as shown above in figure 1.4(a). Device drivers are created by dividing the functionality among layers and stacking the respective modules (LKM's). But in aspect oriented approach one more axis called Aspects is added, as shown in figure 1.4(b). Now we divide the components not only along Layers axis but also along Aspects axis. These aspects are features of the system software which crosscut it at different points. One or more aspects can be captured in a separate LKM from the main functionality LKM's. In this way we get a more structured and adaptable system. Some of the aspects like security can be made optional which can be removed upon user's request or in some cases the same aspect can be reused by some other functionality.     



 2.3.3 Design Of Mailslots:


  In this section we will talk about the architectural design  of Mailslots. From above discussion we know that aspects  are the features of a program which crosscut it at different points. Our purpose is to separate these aspects and capture them in their own local space, so that the resulting software is adaptable. In Mailslots we have recognized three main aspects ; Security, Scheduling and Deadlock Handling. Figure 1.5 below, shows the architecture of Mailslots. This architecture is clearly based upon the aspect oriented framework [1].              



                                                 Figure 1.5 Architecural Design Of Mailslots


The client or user process communicates with the IPC module called Mailslots Moderator, which has registered itself to file system, through API (Application Program Interface). API talks with Moderator through Proxy, which is a part of the same LKM as is Moderator. Proxy,  which is an interface to Moderator, arranges the received request and passes it to one of the Moderator's functions called pointcuts. Each pointcut is a set of joinpoints where different aspects crosscut in a particular context. A pointcut transfers control to different aspects and main functionality (Mailslots) depending upon its function e.g open. Each aspect and main functionality is implemented as a separate  LKM.  Moderator is attached to an aspect through interface aspect factory. Together aspect factory and aspect form a  brigde pattern, which makes Moderator independent of aspect's interface. For more information please refer to [1].    



3.0 Implementation:

(working on it)


 4.0 References


  [1]     P. Netinant, C. A. Constantinides, T. Elrad. Supporting the Design of System Software Using Aspect-Oriented Frameworks.
           Object-Oriented Programming, Systems, Languages and Applications (OOPSLA 2000),  http://www.iit.edu/~concur/publications.html


  [2]     A. Rubini and J. Corbet, " Linux Device Drivers", 2nd Edition, O'Reilly Publications, June 2001.     

  [3]     A. Silberschatz and P. B. Galvin, "Operating System Concepts", Fifth Edition, John Wiley & Sons, 2000.


  [4]     D. P. Bovet and M. Cesati, "Understanding Linux Kernel", O'Reilly Publications, October 2000.   


  [5]     D. J. Hatley and I. A. Pirbhai, "Strategies for Real-Time System Specification", Dorset House Publishing, 1988.   


  [6]     W. R. Stevens, "Advanced Programming in the UNIX Environment", Addison Wesley, 1999.


  [7]      W. R. Stevens, "UNIX Network Programming Volume 2 : Interprocess Communications", 2nd Edition, Pearson Education,1995.     






     Hitesh Kumar (kumahit@iit.edu


     ( For Source code visit  http://mailslots.sourceforge.net )

SourceForge Logo