FORM 2
THE PETITION ACT, 1970 (39of1970)
COMPLETE
Specification
(Section 10; rule 13)
A MESSAGE QUEUING SYSTEM FOR INTER PROCESS
COMMUNICATIO
TATA CONSULTANCY SERVICES LIMITED
of Bombay House, 24, Sir Homi Mody Street, Mumbai 400 001,
an Indian Company
THE FOLLOWING SPECIFICATION PARTICULARLY DESCRIBES THE NATURE OF THIS INVENTION AND THE MANNER IN WHICH IT IS TO BE PERFORMED:-


- This invention relates to a message queuing system for inter process communication.
FIELD OF INVENTION
The present invention relates to the field of message queuing and inter process communication (hereinafter called, "ipc") and more specifically to the field of high speed messaging between processes.
BACKGROUND OF THE INVENTION
Message queuing is a strategic component of any message-oriented architecture, by providing an encapsulated, asynchronous means by which different programs can communicate. It provides the distributed benefits of remote procedure calls, without many of their inherent problems. Robustness is introduced by , encapsulating requests into asynchronous, independent messages that are men handled by a designated queue manager. The queue manager oversees the course of those messages as they travel between different machines across a network, or between different programs within the same machine. The client application and/or machine originating the message can move on to processing other tasks as it awaits the message's response. Meanwhile, the message queuing application can manage and respond to a wide variety of networking or other problems that might otherwise hang up or crash the original requesting program.
Message queuing therefore allows an application designer to
o Increase program efficiency and system capacity by utilizing multiple
servers to execute applications o Design solutions that require a number of (possibly) incompatible programs

In the latter case, through their use of messages and message brokers, message queuing solutions allow an application programmer to provide methods and apparatus to provide for separate translation or bridging (that might run on separate servers) between two (possibly) incompatible programs. This allows the programmer to utilize the broadest possible array of methods in the final application, in a timely and easily manageable manner.
To provide this capability, message queuing clients and servers must be able to process a large number of messages per unit time, for the fall range of possible message sizes. A relatively lafge single client/server capacity to process messages implies an efficient processor execution path, which in turn implies less processor utilization consumed by the message queuing application software. This translates to better overall performance of simultaneously executing applications. Likewise, a higher server capacity implies greater system scalability, i.e., the ability to support increasingly larger numbers of transactions without an exorbitantly expensive increase in supporting resources. Furthermore, any message queuing solution should provide robust performance in the face of server congestion, especially due to the accumulation of un-retrieved messages.
One such message queuing system, which has been developed by the Applicants is shown in FIG1. Two applications Writer Process A and Reader Process B communicate through a message queue managed by a queue manager, which provides a first-come-first-serve order of delivery.
If Writer Process A wishes to send a message to Reader Process B, it simply writes the message to the queue and continues its other processing. The queue manager ensures that the message is delivered to Reader Process B, when it is in a position

- to receive the message. When Reader Process B wishes to read a message and there are messages in the queue, it reads the head of me queue in first-come-first-serve (FCFS) order and processes the message. On the other hand, if the queue is empty, it waits until a message is delivered. The send and receive calls to the queue take care of this asynchronous nature of communication in FCFS order, without the application components having to worry about the implementation.
Message queuing solutions have normally been integrated into Message Oriented Middleware (MOM) solutions. MOM solutions form like IBM WebSphere MQ by IBM UK Laboratories Ltd., Microsoft Message Queue (MSMQ) by Microsoft Corp. though provide distributed messaging and transaction protection, this leaves a lot to be desired in the performance aspect of message queuing. Likewise, TIBCO and Tuxedo provide components of high performance messaging with persistence and transaction protection.
However, each of these platforms has their limits. They have been benchmarked and are proven in environments that sustain a few hundreds to a few thousands of messages per second. When confronted with requirements mat span to tens of thousands of messages per second and beyond, with recovery from failures within a few seconds. There appears to be no real life system, that uses any of the standard messaging products in the market. To achieve these messaging rates one may need to significantly modify application architecture to use multiple queues instead of one (thereby violating FCFS property), and to achieve recovery from failure there may be no option but to go for (fault-tolerant) mainframes.
It is therefore clearly desirable to be able to use transaction protection along with very high speed messaging. Since writing of transaction logs to disk is impedance

to high speed messaging, this implementation of the queuing system does not include any form of transaction protection for messaging.
The object of this invention is to provide a message queuing system for inter process communication which provides a high performance and persistent message queuing library that can deliver tens of thousands of messages per second with split second recovery and which uses shared memory-mapped files with the locking optimization described for high performance.
According to this invention, there is provided a message Queuing system for inter¬process communication comprising of, a means for accessing the Queuing system, a means for managing the Queuing system and a means for storing data of the Queuing system, the said means for accessing the Queuing system consisting of, a Queue Library Application Programming Interface (API) and Queue utilities, wherein the said Queue Library API providing interface, for connecting to me queuing system, for disconnecting from the queuing system, for opening a Queue, for closing a Queue, for writing a message to a Queue, for reading message from a Queue and the said utilities providing means for creating a Queue manager, means for creating a Queue, means for deleting a Queue, means for modifying configuration of a Queue and means for viewing the current state of a Queue; the said means for managing the Queuing system having a Queue manager consisting of a Queue space, a Queue lock library, a connection manager, a remote sender and a remote receiver; the said means for storing data of the Queuing system consisting of a connection repository, a Queue repository, a configuration file and a XMIT log/transmission log; a means for delivering a message to a process and a means for reliable delivery of a message to a process.
5

Typically, the said means for delivering a message to a process, includes delivering a message to a process on a local node, i.e. where the message is originated or a remote node, i.e. a node other than local node.
Typically, the said means for delivering a message to a remote node consists of a means for delivering the message to the remote node and a means for receiving the message at the remote node.
Typically, the said Queue Library API includes a means for writing messages in bulk to a Queue in the Queuing system.
Typically, the said Queue Library API includes a means for reading messages in bulk from a Queue in a Queuing system.
Typically, the said Queue Library API includes a means to peek at a message in a Queue, for returning a copy of the message in a Queue, in the Queuing system.
Typically, the said Queue Library API includes a means to peek at messages in bulk copies of the messages in a Queue in a Queuing system.
Typically, the said Queue utilities includes a means to create a Queue manager identified by a name, which includes creation of one instance of the connection manager, remote receiver, remote sender, connection repository and Queue repository.

Typically, the said Queue utilities includes a means for iiutializmg the lock of the Queue in case of deadlock for a Queue, identified by a name under the Queue manager.
Typically, the said means for viewing the current state of a Queue includes means for viewing current depth of a Queue, number of messages written to a Queue and number of messages deleted from a Queue.
Typically, the said Queue space consists of a control block for storing the detafls of the Queue, its parameters and implementation, and a data block, containing the message and the message related information.
Typically, the said remote sender provides means for reading messages for the Queue space on the local node and delivering the messages to Queue managers on the remote node.
Typically, the said remote sender communicates with the remote receiver based on various parameters like window size, high water mark, low water mark, remote sequence number, local sequence number.
Typically, the said remote receiver provides the means to receive a message from the remote sender on local node and put the message in the Queue space of the Queue manager on the remote node and the remote receiver communicating with the remote sender based on the parameters of the window size.
The invention will now be described with reference to the accompanying drawings, wherein

FIG 1 is a high level block diagram for the message queuing system;
FlG 2 is a block diagram showing the different components of the message
queuing system;
FIG 3 is a block diagram showing the delivery of messages from a writer
process on the local node to a reader process on the local node;
FIG 4 is a block diagram showing the delivery of messages from a writer
process on the local node to a reader process on the remote node over
F 4 is block diagram showing the delivery of messages from a writer
process on the local node to a reader process on the remote node over Storage
Area Network (SAN) using sequential log files;
FIG 5 is flow diagram for writing a message to a queue in the message
queuing system;
FIG 6 is flow diagram for reading a message from a queue in the message
queuing system.
Referring to the figure 2, the message queuing system for inter process communication, according to this invention comprises means to access the queuing system, means to manage the queuing system and means to store data of the queuing system. The main components of each of the said means are as described below:
Means To Access The Queuing System:
The means to access the queuing system consists of Application Programming Interface (API) and Utilities developed using the APIs.
Queue Library API
The Queue Library API provides interfaces to

o Connect to the Queuing System: - This API connects a thread of control (e.g. a process or a thread in a process) to the queuing system identified by a queue manager and returns a connection handler for the thread of control. This API creates domain socket connection
o Disconnect from the Queuing System: - This API disconnects the process from the queuing system identified by a queue manager. Any attempt to interact with the queuing system after a call to disconnect will return an error.
o Open a Queue: - This API opens a queue for reading or writing in the queuing system for the thread of control and returns a handle to the queue object. A connection handler, returned on connecting to the queue manager, identifies the queuing system.
o Close a Queue: - This API closes a queue in the queuing system opened for read or write. Once a queue is closed, the handle to the queue object is invalidated. Any attempt to read, peek or write to the queue will return an error.
o Write a message to a Queue: - This API writes a message to a queue in the queuing system. A connection handler, returned on connecting to the queue manager, identifies the queuing system, while the queue object, returned on opening the queue, identifies the queue itself.
o Write messages in bulk to a Queue: - This API writes in bulk messages to a queue in the queuing system. With this means, multiple messages can be

written to the queue using one call to the queue library API, A connection handler, returned on connecting to the queue manager, identifies the queuing system, while the queue object, returned on opening the queue, identifies the queue itself.
o Read a message from a Queue: - This API reads a message from a queue in the queuing system. A connection handler, returned on connecting to the queue manager, identifies the queuing system, while the queue object, returned on opening the queue, identifies the queue itself.
o Read messages in bulk from a Queue: - This API reads in bulk messages from a queue in the queuing system. With this means, multiple messages can be read from the queue using one call to the queue library API. A connection handler, returned on connecting to the queue manager, identifies the queuing system, while the queue object, returned on opening the queue, identifies the queue itself.
o Peek at a message in a queue: - This API returns a copy of the message in a queue in the queuing system. A connection handler, returned on connecting to the queue manager, identifies the queuing system, while the queue object, returned on opening the queue, identifies the queue itself.
o Peek at messages in bulk in a Queue: - This API returns in bulk copies of the messages in a queue in the queuing system. A connection handler, returned on connecting to the queue manager, identifies the queuing system, while the queue object, returned on opening the queue, identifies the queue itself.

Queue Utilities
Utilities provide the users of the queuing system the means to o Create a queue manager: - This utility provides a means to create a queue manager identified by a name, which includes creation of one instance of the
o Connection manager
o Remote receiver
o Remote sender
o Connection repository
o Queue repository
o Create a queue: - This utility provides a means for creating a queue identified by a name under a queue manager. Creating a queue involves o Creating an entry in the queue repository o Creating the queue space
o Delete a queue: - This utility provides a means for deleting a queue identified by a name from the queue manager. Deleting a queue involves o Deleting the entry of the queue from the queue repository o Deleting the queue space
o Modiiy configuration of a queue: - This utility provides a means for modifying the configuration of a queue identified by a name and the queue manager.

o Initialize the lock of queue: - This utility providjes a means tor initializing the lock in case of deadlock for a queue, identified by a name under a queue manager.
o View the current state of a queue: - This utility provides means to view the I o Current depth of queue
o Number of messages written to a queue
o Number of messages deleted from a queue
Means for Managing the Queuing System:
The queue manager provides the means for managing the queuing system. The queue manager consists of
o Queue Space - Queue Space consists of two parts, a control block and a data block. Hie control block stores the details of the queue, its parameters and implementation. The data block contains the message and message related information. Increasing the size of the queue space can increase the queue depth. Irrespective of the type, each queue space is physically mapped to a queue file. So increasing the queue space also increases the size of the queue file. Only the queue manager can increase the queue depth.
The queue space is implemented through the following means:-
o As a shared memory mapped file between processes for fast and efficient access and persistence of data. The size of the queue space is fixed at the time of creating the queue.

o As fixed size disk based file for persistent writes in case of a system with low memory. The size of the queue space is fixed at the time of creating the queue.
o As a sequential file for fast and efficient read and write between the reader and writer. If the reader and writer are on two different servers, the same physical file can be a part of two different queue spaces associated with two different queue managers. The size of the queue space is only limited by the size of the disk space available on the node on which the queue has been created.
If the sequential file is created on a clustered file system (CFS), which supports concurrent direct media access from multiple systems, the queue space can be read and written from any of the nodes in the cluster. To be a cluster mount, a file system must be mounted using the cluster option.
If the sequential file is created on a file system mounted as a network file system (NFS), the access to the file system from the local node will be through the NFS daemon on both the local and remote node. The delivery of messages, security, data access locks will be handled as a part of the underlying NFS protocol.
o Queue Lock Library:- The queue lock library helps in efficient locking of the queuing resources for reading and writing to the queue. The locks are implemented as "shared mutex" in shared memory mapped files. Traditionally SVR4 or POSIX named semaphores are used to synchronize

between processes and threads. However, due to the superior performance of the shared mutex over the binary semaphore, the lock library uses shared mutex for implementing locks. Also, in case of multiple writers and single reader scenario, if throttle is enabled, the lock library minimizes lock contention between the reader and the writers. This results in very high rate of messaging across the queues. Throttle value can be specified as a percentage of the queue depth while creating the queue.
o Connection Manager:- The connection manager maintains a list of connections to the processes with the queuing system. If the process dies the connection manager invokes the lock manager APIs to clean any locks held by the process.
o Remote Sender: - Remote sender provides the means for reading messages for the queue space on the local node and delivering the messages to queue managers on remote node. The remote sender communicates with the remote receiver based on the following parameters:
o Window size: It is the number of packets after which the remote receiver on the remote node will send an acknowledgement packet to the remote sender on the local node. If a packet has been sent to the remote receiver and the remote sender has received no acknowledgement for the packet, the packet is said to be outstanding.
o High Watermark: It is the maximum number of packets, which can be sent to the remote receiver without receiving an acknowledgement packet. If the number of outstanding packets sent to the remote

receiver is equal to the high watermark, the remote receiver stops sending packets.
o Low Watermark: If the number of outstanding packets at the remote sender falls to the low watermark limit, the remote sender resumes sending of packets to the remote receiver. The difference between the low watermark and the high watermark is maximum number of outstanding packets between the remote sender on the local node and remote receiver on the remote node.
o Remote Sequence Number: It the number assigned to each packet received by the remote receiver on the remote. The remote sequence number is sent to the remote sender along with the local sequence number in the acknowledgement packet.
o Local Sequence Number: It the number assigned to each packet seat by the remote sender on the local node to the remote receiver on the remote node. The remote sender maintains a map of the local sequence number and the remote sequence number.
o Remote Receiver: Remote receiver provides the means to receive a
message from the remote sender on local node and put the message in the
queue space of the queue manager on the remote node. The remote receiver
communicates with the remote sender based on the following parameters:
o Window size: It is the number of packets after which an
acknowledgement packet has to be sent to the remote sender on the
local node. If multiple remote senders are writing to the same remote

receiver for a given queue, the minimum window size across all remote senders is taken as the window size for the queue on the remote node.
Means to Store Data of the Queuing System:
The means to store data of the queuing system consists of
o Connection Repository: - The Connection Repository is a file, which contains the details of the current active connections to the queuing system identified by the queue manager. The maximum number of connections in the system is a parameter and is limited by the value entered while creating the queue manager. The connection manager also keeps track of the number of queues opened by each active connection to the queue manager.
o Queue Repository: - The Queue Repository is a file, which contain all the details of the queues created in the queuing system identified by the queue manager. When any queue is created an entry is made into the queue repository describing the queue and its configuration. Processes can access only those queues that are present in queue repository. Every queue repository is related to a queue manager
o Configuration File: - The Configuration File consists of the mapping between the queues on the local node identified by the local queue manager with the queues on a remote node identified by a remote queue manager. It also consists information like network address, port, window size, high and low water-mark so that the queue manager on the local node is able to deliver messages to remote receiver on the remote node.

o XMIT Log: - The XMIT Log, also known as the transmission log is a file which stores messages delivered or received by a queue manager. It stores the messages sent by the remote sender of a queue manager on the local node and the messages received by the remote receiver of a queue manager on the local node. The transmission log is used as means for persistence and jecovery for messages m case of failure of either the remote node or local node.
In case, when the queue space is implemented as a sequential file on shared storage, no-separate transmission log is maintained either on the side of the remote sender and remote receiver.
Means for Rellable deliverv
The means for reliable delivery of messages from writer to reader processes is achieved through
o Persistence of Messages
o Recovery of Messages in case of failure of the queue manager Transmission logs in conjunction with the queue space is used for persistence and recovery of messages.
If the writer and reader processes are on the same node, reliable delivery can be
achieved in the following ways: -
o Define a queue as fixed depth and persistent. In this case, the queue space is implemented as a fixed sized disk file. Writing messages to the queue space and reading messages from the queue space are implemented through synchronous disk I/O. The messages are written to and read from the file in random access mode.

Incase the local node crashes, the queue space can be re-built using from the queue file. If the disk file is on shared storage, the queue can be re-buik from the queue file also on the backup server.
o Define a queue for a queue as continuous log. In this case, the queue space is implemented as a sequential disk file. The size of the file is only limited by the disk space available. The writer process writes the messages sequentially to the file. The reader process reads the messages sequentially from the file.
Incase the local node crashes, the queue space can be re-built using from the queue file. If the disk file is on shared storage, the queue can be re-built from the queue file also on the backup server.
If the queue is fully persistent, then the writes to the queue space is synchronous and full recovery of the messages in the queue is possible. However, if the queue is semi-persistent, then it may not be possible to retrieve the number of messages in the file system buffer.
If the writer process is on the local node and the reader process is on the remote node, reliable delivery of messages can be achieved in the following ways: -o Define a remote queue or an alias of the remote queue on the local node. The queue space is implemented as a memory mapped file. Messages are delivered from the local node to the remote over TCP/IP. The parameters that define reliable delivery are o Local Sequence Number (LSN) o Remote Sequence Number (RSN)

o Window Size o High watermark o Low watermark
To provide reliable delivery, each message sent to the remote node is logged in to a transmission log with a local sequence number (LSN) for persistence by the Remote Sender. The frequency at which the messages are flushed to the disk depends on the configuration parameter. The LSN is sent to the remote node as a part of the packet containing the message. On the remote node each message received is also logged into a transmission log with a remote sequence number (RSN) assigned at the remote node along with the LSN by the Remote Receiver. If more than one node is writing messages to the remote node, LSN represents the sequence at which the messages are generated at the local node and RSN represents the sequence in which messages are received at the remote node. If the number of outstanding packets at the remote node equals that of the window size, then a message confirmation is sent to the local node along with the LSN and RSN of me last packet received. This enables the local node to maintain a map of me LSN and RSN.
The messages sent to the remote node from local node without receiving any message confirmation is termed as outstanding messages at the local node. If the number of outstanding packets sent from the local node to the remote node exceeds the high watermark, the local node stops sending any messages to the remote node unless the number of outstanding messages at the local node reduces to the value of low watermark. Thus high watermark signifies the maximum number of messages that can be lost in transition HI

case of failure of the queue manager at the remote node. When the remote node recovers, the messages lost in transition can be delivered to the remote node by the local node based on the LSN-RSN map. The remote node sends a message with the LSN-RSN of the last message received. The local node sends all messages greater than the LSN sent by the remote node to the current LSN from the persistent transmission log. To make message delivery fully reliable
o Window size should be one
o High water mark should be one
o Low watermark should be zero What this signifies is that
o The local node will have a maximum of one outstanding message
o For every message sent, the remote node will send a message confirmation to the local node
o The local node will not send any message until the message confirmation from the remote node is received at the local node
Incase, the local node crashes, the messages written to the remote queue can be recovered from the persistent store at the local node. The local node then sends to the remote node with the last RSN-LSN received from the last message confirmation received from the remote node. The remote-node sends back the RSN-LSN of the last message received from the local node from the transmission log. All missed packets are re-sent to the remote by the local node.
o Define the queue as a sequential log file, on a shared storage. The shared storage can be a SAN or a NAS appropriately configured.

o If the shared storage is a SAN, the file system on which the queue space has been created must be mounted in a clustered mode. In this case, the persistence and recovery of the queue space is built around the behavior of the cluster file systems in conjunction with a SAN. Clustered file systems (CFS) generally support concurrent direct media access from multiple systems. Cluster file systems employ a master/slave protocol. All cluster file systems can read file data directly from a shared disk. In addition, all systems can write "in-place" file data. The single primary file system node can only perform operations that require changes to file system metadata, such as allocation, creation, and deletion. To maintain file system consistency, secondary nodes must send messages to the primary, and the primary will perform the operations.
Generally, the first node that mounts is the primary node and the remaining nodes are secondary. If the server on which the cluster file system primary is running fails, the remaining cluster nodes elect a new primary. The new primary reads the file system intent log and completes any metadata updates that were in process at the time of the failure. Application I/O from other nodes may block during this process and cause a delay. When the file system is again consistent, application processing resumes. Because nodes using a cluster file system in secondary mode do not update file system metadata directly, failure of a secondary node does not require metadata repair. CFS recovery from secondary node failure is therefore faster man from primary node failure.

o If the shared storage is a NAS device, the underlying storage fa-queue space is no longer an integral part of the server. The messages are still processes done by the local node while the NAS device delivers the data to the local node. The NAS device comprises a server, an operating system, plus storage which is shared across the network by many other servers and clients. The NAS server handles all aspects of security and lock management. If one user has the file open for updating, no one else can update the file until it is released. The file server keeps track of connected clients by means of their network IDs, addresses, and so on.
If the local node crashes, all data written to the queue space will be available to the remote node through the shared storage. When the local node recovers, it continues writing of messages to the queue space on the shared storage, which is read by the remote node.
If the remote node crashes, the local node continues to write the messages to the queue space on the shared storage. When the remove node recovers, all messages in the queue space greater the last RSN is read to bring the remote node in synch with the local node.
FIG 3 shows queuing system for inter-process communication between Writer Process and Reader Process on the local node where both Writer Process and Reader Process are connected to the same queue manager. In the above figure, Writer Process is writing messages to the queue and Reader Process is waiting on the queue to read the messages from the queue. Bom Writer Process and Reader Process maintain a connection with Connection

Manager component of the Queue Manager. When Writer Process writes a message to the queue using the Write queue API, the message is put into the Queue Space and the Reader Process is notified through a signal. Read queue API then reads the data from Queue Space and passes the data to the Reader Process.
When multiple Writer and Reader processes are on the same node, the time to acquire and release a lock becomes bottleneck to high speed messaging across the queues. To avoid this bottleneck, a means for co-operative locking between reader and writer processes, called throttling, has been introduced. Throttling is controlled by a throttle value, which can be enabled while creating the queue or by modifying the configuration parameters of the queue. Throttle value can be specified as a percentage of the queue depth. Throttling works by suspending the writer processes once the queue depth is full. This gives the reader processes full access to the data and locks in the queue space thereby reducing lock contention between reader and writer processes. As the queue depth falls below the throttle value, the writer processes are resumed once again. This mechanism drastically enhances the throughput across the queue when the number of concurrent writers is more than the number of concurrent readers.
The table below provides a sample benchmark results to validate the advantages of co-operative locking concept. Both the reader and writer processes were on the local node.

2 10 7,250 1,000,000 0
I 10 59,000 1,000,000 10
2 10 34,333 1,000,000 10
FIG 4 shows a queuing system for inter-process communication between Writer Process on the local node and Reader Process on the remote node.
In the above figure, the Writer Process is writing messages to the queue under queue manager QM A at Node A and the Reader Process is waiting on the queue, which is an alias of the queue at Node A, under queue manager QM A, on Node B. Writer Process maintains a connection to the Connection Manager component ©f the Queue Manager on Node A and Process B maintain a connection to the Connection Manager component of the Queue Manager on Node B. When the Writer Process writes a message using the Write queue API, the message is put in the queue space on Node A and the Remote Sender component of the Queue Manager is signaled. The Remote Sender at Node A sends the message over a TCP/IP connection to the Remote Receiver at Node B. Both Remote Receiver and Remote Sender write the message to the Transmission (XMTT) Log. The Remote Receiver at Node B sends a message confirmation to the Remote Sender at Node A. The Remote Receiver at Node B puts the message to the queue space at Node B and signals Reader Process, which is waiting on the queue to read the message. The read queue API in Reader Process read the data from the Queue Space and Hie passes the data to Process B.

In case of multiple writers on different local nodes, the Remote Receiver running on the remote node serializes the messages received from different Remote Senders. Hence, lock contention is low for messaging between writer and reader processes on local and remote node respectively.
The mode of delivery in case of messaging between a local node and a remote node depends on the following network protocols: -
o TCP/IP is used when the remote and the local queue space are different
physical files o NFS is used as the underlying protocol for message delivery if the queues space on the local node remote node denotes the same physical file and the file system is mounted as a NFS partition.
FIG 4a shows a queuing system for inter-process commumcation between Writer Process on the local node and Reader Process on the remote node. The local node and the remote node share a disk sub-system attached to a SAN. The queue space is implemented as a sequential file shared between the local node and the remote node. This means for message delivery between a local node and a remote node takes into account the high-bandwidth connectivity from the servers to the SAN. The file system on which the queue space has been created must be mounted in a clustered mode.
In the above figure, the Writer Process is writing messages to the queue under queue manager QM A at Node A and Reader Process is waiting on the queue, which is an alias of the queue at Node A, under queue manager QM A, on Node B. Writer Process maintains a connection to the Connection Manager component of the Queue Manager on Node A and Reader Process maintain a connection to the

Connection Manager component of the Queue Manager on Node B. When Writer Process writes a message using the Write queue API, the message is put in to the queue space (logical) implemented as sequential file on Node A. The Reader Process reads a message at Node B using the Read queue API from queue space at Node B. The physical delivery of message is handled by the underlying file system protocol. The Read queue API passes the data to the Reader Process.
Means for Installation for TCSMQ

Unique Features of the Invention
While there are queuing means available in the market such as IBM MQ Series, Microsoft MSMQ, as well as components of products such as TIBCO and Webmethods, the unique features of this invention include:

o High performance and reliable delivery, benchmarked at 70,000 messages per second on a single queue running on an HP N-class machine comprising of 4 CPU
o High performance and reliable delivery benchmarked at 100*000 messages per second on a single queue running on an HP Keystone machine comprising of 4 CPUs and connected to an XP 1028 Storage Area Network
o Recovery time of less than 0.5 second to switch over from primary to failover channel demonstrated on an HP Keystone machine comprising of % CPUs and connected to an XP 1028 Storage Area Network
o Use of Storage Area Network to store the queue itself for high performance and reliability
o Usage of watermarks for flow control and coupling the flow control with high throughput and reliable delivery
o Usage of bulk writes and reads which is a unique feature in itself
To the best of the inventors' knowledge the queuing means available in the market from vendors mentioned above, provide high performance when used without reliable delivery option. When these means are used with reliable delivery option the throughputs are significantly less than that of this invention.
References
o A Performance Comparison Of IBM MQSeries 5.2 and Microsoft Message Queue (MSMQ) 2.0 on Windows 2000 Express and Persistent Delivery Modes - International Business Machines Corporation, 2001.
o VERITAS Storage Foundation Cluster File System, Installation and Administration Guide
o The IBM TotalStorage NAS Integration Guide

We Claim:
1. A message Queuing system for inter-process communication comprising, a means for accessing the Queuing system, a means for managing the Queuing system and a means for storing data of the Queuing system, the said means for accessing the Queuing system consisting of, a Queue Library Application Programming Interface (API) and Queue utilities, wherein the said Queue Library API providing interface, for connecting to the queuing system, for disconnecting from the queuing system, for opening a Queue, for closing a Queue, for writing a message to a Queue, for reading message from a Queue and the said utilities providing means for creating a Queue manager, means for creating a Queue, means for deleting a Queue, means for modifying configuration of a Queue and means for viewing the current state of a Queue; the said means for managing the Queuing system having a Queue manager consisting of a Queue space, a Queue lock library, a connection manager, a remote sender and a remote receiver; the said means for storing data of the Queuing system consisting of a connection repository, a Queue repository, a configuration file and a XMIT log/transmission log; a means for delivering a message to a process and a means for reliable delivery of a message to a process.
2. The message Queuing system for inter-process communication, as claimed in claim 1, wherein the said means for delivering a message to a process, includes delivering a message to a process on a local node, i.e. where the message is originated or a remote node, i.e. a node other than local node.

3. The message Queuing system for inter-process communication, as claimed in claim 2,wherein the said means for delivering a message to a remote node consists of a means for delivering the message to the remote node and a means for receiving the message at the remote node.
4. The message Queuing system for inter-process communication as claimed in Claim 1, wherein the said Queue Library API includes a means for writing messages in bulk to a Queue in the Queuing system.
5. The message Queuing system for inter-process communication, as claimed in claim 1 or 4,wherein the said Queue Library API includes a means for reading messages in bulk from a Queue in a Queuing system.
6. The message Queuing system for inter-process communication, as claimed in claim 1, wherein the said Queue Library API includes a means to peek at a message in a Queue, for returning a copy of the message in a Queue, in the Queuing system.
7. A message Queuing system for inter-process communication, as claimed in claim 1 or 6,wherein the said Queue Library API includes a means to peek at messages in bulk copies of the messages in a Queue in a Queuing system.
8. A message Queuing system for inter-process communication, as claimed in claim 1,wherein the said Queue utilities includes a means to create a Queue manager identified by a name, which includes creation of one instance of the connection manager, remote receiver, remote sender, connection repository and Queue repository.

9. The message Queuing system for inter-process communication, as claimed in claim 1 or 8, wherein the said Queue utilities includes a means for initializing the lock of the Queue in case of deadlock for a Queue, identified by a name under the Queue manager.
lO.The message Queuing system for inter-process commumcation, as claimed in claim 1, wherein the said means for viewing the current state of a Queue includes means for viewing current depth of a Queue, number of messages written to a Queue and number of messages deleted from a Queue.
11.The message Queuing system for inter-process commumcation, as claimed in claim 1, wherein the said Queue space consists of a control block for storing the details of the Queue, its parameters and implementation, and a data block, containing the message and the message related information.
12.The message Queuing system for inter-process communication, as claimed in claim 1, wherein the said remote sender provides means for reading messages for the Queue space on the local node and delivering the messages to Queue managers on the remote node.
13.The message Queuing system for inter-process communication, as claimed in claim 1 or 12, wherein the said remote sender communicates with the remote receiver based on various parameters like window size, high water mark, low water mark, remote sequence number, local sequence number.
14.The message Queuing system for inter-process communication, as claimed in claim 1,wherein the said remote receiver provides the means to receive a

message from the remote sender on local node and put the message in the Queue space of the Queue manager on the remote node and the remote receiver communicating with the remote sender based on the parameters of the window size.
15.The message Queuing system for inter-process communication substantially as herein described and illustrated in figs.2 to 6 of the drawings accompanying the complete specification.

Applicants' Patent Attorney
Dated this 10th day of September 2004.