WO2000062158A9

WO2000062158A9 - Method and apparatus for managing communications between multiple processes

Info

Publication number: WO2000062158A9
Application number: PCT/US2000/010183
Authority: WO
Inventors: Eric Bodner; Jonathan Liss; Genoveva Rizzo; Richard Sedlak; Diane Wilke
Original assignee: Tyco Submarine Systems Ltd
Priority date: 1999-04-14
Filing date: 2000-04-14
Publication date: 2002-02-14
Also published as: WO2000062158A3; WO2000062158A2

Abstract

An intermediary between multiple processes operates in a network environment. When one process requires servicing of a request by another process, according to the present invention, it need not know all of the details about the process it requires. Rather, the process can merely specify to the intermediary that it requires servicing of a given request. The intermediary then simply accesses a database of processes and determines which processes perform this function. Then, the intermediary determines which processes that perform the given function are available, and sends the information regarding the process that is available to perform the given function to the requesting process so that the requesting process can then access the available process directly.

Description

METHOD AND APPARATUS FOR MANAGING COMMUNICATIONS BETWEEN MULTIPLE PROCESSES

RELATED APPLICATIONS

The present application is related to U.S. Patent Application No. 08/ filed concurrently herewith by the same inventor, and entitled "Database Management Architecture," which has been assigned to the same assignee, and which is hereby incorporated by reference herein, including the drawings, as if repeated in its entirety in this application.

BACKGROUND OF THE INVENTION

The present invention relates generally to methods and apparatuses for controlling the communications between multiple processes, and more particularly, to a method and apparatus for controlling the communications between processes in a network environment, in which the processes are object oriented processes.

As undersea telecommunication networks become more sophisticated and complex, the need for networked maintenance-and-reporting support systems becomes crucial. This is especially true of synchronous digital hierarchy (SDH) undersea cable systems using optical-amplifier technology. Customers now require undersea cable-system operators to plan, provision, install, maintain, operate, and administer networks with increased reliance on networked, computer-aided maintenance tools that meet international standards.

The Network Management System (NMS) function of an undersea cable system can be part of a larger Telecommunications Management Network (TMN). The TMN includes Operation Support Systems (OSSs) and their connections to Submarine Lightwave (SL) Mediation Equipment (SME). Alternatively, the NMS function can operate in a centralized or decentralized arrangement for standalone applications. Both configurations support integrated, surveillance-and-control activities during system installation, normal operation, maintenance, fault location, and repair activities. With respect to network management, an undersea cable system can include one or more network elements (NEs), as shown in FIGs 7-8. Such key components as Line Monitoring Equipment, multiplexers, and Power Feed Equipment, which provide monitoring and control points, are considered NEs. Hierarchically, each of these elements is connected to the SME.

SME is a minicomputer-based system that supports graphical craft-interface terminals (CITs). These local and remote windows-based CITs are icon driven and feature point-and-click item selection. SME also supports relational database functions and upward communication capabilities. It does this through Q3 interfaces using the International Organization for Standardization stack that transports common management-information service element managed objects to a higher level OSS. SME supports three levels of users, and access is controlled through logins and passwords. The highest level user has access to all CIT functions, including the authorization of additional users. Midlevel users have access to all readable CIT data and can also configure equipment, such as multiplexers. The lowest level user can access only readable information, and cannot configure the multiplexer.

SME is logically associated with undersea cable terminations. It can be interconnected by means of undersea cable or alternate communication facilities. FIG 7 illustrates a three-terminal, branched, undersea cable network having a centralized TMN architecture. SME is linked to an external OSS for consolidated network management.

FIG 8 illustrates a three-terminal, branched undersea cable network with a decentralized architecture. SME is networked to provide distributed access to the individual NEs. Functionally, SME provides the following features:

• Performance management information presentation, which provides operators with the data necessary to perform preventative maintenance and to ensure quality.

• Fault-management capabilities, including alarm reporting at the CIT, notification of key circuit-pack trouble reports, and logging in at the database of alarms generated by digital line errors, PFE and terminals (multiplexers).

• NE monitoring of key subsystems, such as multiplexer data collected per G.821 or G.826 parameter sets, PFE status conditions, forward error correction performance (if so equipped) and the LMS system. • Historical logging, including the collection, time stamping, long term storage, and reporting of transmission equipment performance data, alarms, acknowledgments, and significant operator and system activities.

As shown in FIG 9, there are multiple vertically-integrated services. These services enable customers to manage and administer international, domestic networks and digital undersea cable systems. These services include cable administration, inventory of equipment, restoration and consultation, facility provisioning, digital cross- connecting, and trouble reporting.

Each service is realized as an individual module, and each module is supported on a database platform, such as Sybase for example. Other commercially available database platforms will suffice. Customers access the services through dialup, secure modems.

To perform this variety of service, each process performing the service must establish a communications link with another process requesting the service. Currently, when one process requires servicing of a particular request, say M, the requesting process must know all of the communications details regarding potentially available processes that service requests such as M. These details can often preclude rapid development of new independent processes because the processes must be developed serially rather than in parallel. Furthermore, these details can be easily misentered, or accidentally corrupted. Moreover, due to the dynamic nature of a network, the process that normally handles a given request may be busy, or off-line. Finally, new processes that are more efficient or have some other advantages may become on-line without the requesting process knowing of the existence of the new process.

One existing process for controlling communications between processes is known as Tooltalk™. Previously, many believed that Tooltalk™ could be a communications solution for the Undersea Network Management Equipment (UNME), which requires very high reliability and availability. Unfortunately, there are a variety of problems that may invalidate Tooltalk™ as a viable solution for controlling the communications in the UNME.

For example, when trying to test Tooltalk™ over Point-to-Point Protocol (PPP), Tooltalk™ needs to have a host table entry for each client that may request service from ttsessio . This creates a huge host management challenge because every UNME site will have to know all hosts at every other UNME site to facilitate remote access of any UNME site.

As ttsession does not operate on a well known socket or Internet Protocol (IP) address on the server, the session identification (session ID) must be stored so that Tooltalk™ users may retrieve this session ID allowing them access to the ttsession responsible for managing UNME system interactions. The current implementation for this procedure is to store the session ID returned by ttsession at startup in some sort of a table (e.g., a Sybase table). This implementation raises several issues. First, additional complexity must be allowed for with respect to the order in which processes must be started on the system (i.e., Sybase must be started before ttsession). Second, this in and of itself may be considered an additional point of failure. Third, all UNME applications utilizing the Tooltalk™ Application Program Interface must retrieve the ttsession ID from the server. This causes the executables to become more complex and larger (and thus slower) and inefficient, thereby adding further complexity to any development effort.

Furthermore, Tooltalk™ requires the use of a Tooltalk™ message database to determine valid messages for use with the software. Currently, there is no mechanism for viewing this database to reuse the currently defined messages. Additionally, there is a mechanism for adding new messages to the database, however, implementing a process to populate this database may create more problems than it solves. The reason is that defined message types must be stored in a definition file like a C programming language header file. To dynamically update the database would require a utility to be written that parses SafeMessages.h and makes calls to the Tooltalk™ facilities. Additionally, this utility (and definition file) would have to be delivered as part of the UNME installation. Another concern is that the message types are stored as strings which requires the use of functions such as strcmpQ which presents the developer with potential memory problems (leaks) and degrades the efficiency of the applications. In addition, it appears that a dynamic host table modification scheme would need to be implemented to support remote terminals over PPP. There are many potential problems this scenario presents, such as the possible destruction of the /etc/hosts file when changed via an automatic process.

Asynchronous notifications also appear to be a problem between XWindows and Tooltalk™. The problem in this area is that notifications received by X applications cannot be properly handled for two reasons. The first problem is that very often the data is irretrievable because the memory space somehow gets destroyed. The second problem is that the file descriptor that Tooltalk™ is using does not clear all the messages from the queue leaving remnants of messages past. Also, the Tooltalk™ library function provided for integration with XWindows {tttk_Xt_inpιtt_handler) does not work. The UNME User Interface (UI) depends heavily on notifications for network element status updates and alarm information so the ability to process notifications is paramount.

Moreover, Tooltalk™ is not thread safe because the its Application Program Interface (API) relies on static variables and attributes. Each of the Agent Managers must be multi-threaded because Telecommunications Management Network (TMN) 6000 produces multi-threaded code. There are possible scenarios which allow for software malfunctions because of Tooltalk™'s inability to make multiple file descriptors available.

Furthermore, it is unknown if Tooltalk™ can handle a scenario where redundant processes may be used to facilitate a large volume of requests as in the case of a process like DBServer, which is a UNME-specific process. DBServer must handle requests for potentially large data sets resulting from queries of the process. The reason for this issue is that it is desirable to operate more than one instantiation of a process to potentially increase the efficiency of the system. Under Tooltalk™ many processes may observe a message, only however, one may handle that message.

Finally, scenarios where ttsession would being handling requests on the secondary UNME unit are not possible, yet this functionality is desirable if not critical in the operation of the UNME system to achieve the desired levels of reliability and availability for this system. The present invention is therefore directed to the problem of developing a method and apparatus for controlling communications between two processes that solves the above mentioned problems, but does not require that a process know the exact communication details when requesting service for a particular request, yet provides the desired levels of reliability and availability required for applications such as UNME.

SUMMARY OF THE INVENTION

The present invention solves this problem by providing an intelligent agent process that acts as a intermediary between a requesting process and all other processes, which agent provides all necessary communication information, such as port location and other details, for the two processes to communicate with each other. This enables the requesting process to receive service on its request in as fast a time as possible without requiring the requesting process to be aware of the state of the other processes and their communication details. According to the present invention, a method for communicating between multiple processes, includes the steps of establishing communications between all processes through an intelligent agent process such that intended senders and receivers are hidden from each other, and storing details of each process available to service requests in a storage accessible by the intelligent agent process. In addition, the above method, can also optionally include the steps of accessing the storage for details on a particular process when another process desires to communicate with the particular process, sending registration information about a particular process to the intelligent agent process when the particular process becomes on-line, dynamically updating the information stored in the storage accessible by the intelligent agent process upon receipt of the registration information, or sending a notification from a process to the intelligent agent process that the process is available to service another request.

Another method according to the present invention for communicating between at least one client and at least one server in a network environment, includes the steps of: a) sending a particular request for service from a client to an intermediate process, which maintains a handler list including information about which servers handle the particular request; b) accessing the handler list to identify a particular server that services the particular request; c) sending communication information regarding the particular server to the client; d) sending a message to the particular server indicating that the particular server will be receiving a request; and e) sending the request from the client to the particular server. In this case, the method of the present invention can optionally include the steps of sending a message to the intermediate process from the particular server upon completion of servicing of the particular request by the particular server that indicates the particular server is completed with the particular request, or sending from the intermediate process communication information to the particular server identifying the client that will be sending the request.

According to the present invention, an apparatus for controlling communications in a network environment so that the processes being executed on the network need not know any communication details of other processes on the network, includes a master server executing an intermediary process, which performs the following steps: a) receiving a message from a client on the network that requires service that indicates a type of request for which the client requires servicing; b) determining which registered servers service the type of request received in step a); c) determining the availability of those registered servers determined in step b); d) selecting one of the registered servers determined to be available in step c); and e) sending the communication details regarding the one server selected in step d) to the client so that the client can then access the selected server directly.

Another embodiment of the above apparatus of the present invention includes a database coupled to the master server storing a handler list, a notification list and a registration list, wherein the master server updates the handler list, the notification list and the registration list in a dynamic manner, by continually updating the contents as new clients and servers come on-line, undertake new requests and complete processing of assigned tasks. In this embodiment, the handler list includes a list of requests handled by all of the clients and servers operating on the network, a cross reference to those clients or servers that handle each of these requests, and an availability indicator for each client or server, which indicates whether the client or server is currently available to service a new request, the notification list includes a list of a plurality of messages sent on the network, and a cross reference to those clients or servers that have registered for notification of each message when the message is output by some client or server on the network, and the registration list includes a list of all registered clients and servers operating on the network and all communication details necessary for a client or server to communicate with a registered client or server. Furthermore, in the above embodiment, when the master server assigns a client or server to service a particular request, the master server raises a flag in the handler list that indicates the client or server is unavailable to service other requests, if requested by the client or server (configurable) and when the client or server completes the particular request and sends a notification to the master server, the master server lowers the flag in the handler list indicating the client or server is available to service additional requests. According to the present invention, the master server executes several predefined processes. These include: a registration process during which the master server stores a registration structure received from a client or server operating on the network, and sends the registration structure as a reply to the client or server with the port number for the client or server to use as a connection port; a deregistration process during which the master server, in response to a registration structure received from a client or server registered with the master server, removes all occurrences of the client or server from the registration, handler and notification lists in the database; a handler process during which the master server, in response to a registration structure received from a client or server registered with the master server followed by a message number to handle, adds handler information about the client or server to the handler list for later requests; a withdraw handler process during which the master server, in response to a registration structure received from a client or server registered with the master server followed by a message number, removes the handler information about the client or server from the handler list; a notification process during which the master server, in response to a registration structure followed by a message number from a client or server registered with the master server, adds notification information about the client or server to the notification list; a denotification process during which the master server, in response to a registration structure followed by a message number from a client or server registered with the master server, the master server removes the notification information about the client or server from the notification list; a lookup handler process during which the master server, in response to a request from a client or server registered with the master server requesting a registration structure of any client or server handling a message the client or server wants to request followed by a message number request, the master server locates the registration structure of a client or server to handler the request based on the message number and sends the registration structure of the client or server to handle the request to the client or server requesting the registration structure as a reply (in this embodiment, if the master server is unable to find a client or server to handle the request, a port number attribute of the registration structure in the reply is set to an invalid port number); and master server notify process during which the master server, in response to a particular message and data received from a client or server registered with the master server, consults the notification list and forwards the particular message and data to all registered recipients of the particular message. BRIEF DESCRIPTION OF THE DRAWINGS

FIG 1 depicts a prior art technique for four processes to communicate with each other.

FIG 2 depicts one embodiment of the apparatus of the present invention acting as an intermediary between a client process and a server process.

FIG 3 depicts another embodiment of the apparatus of the present invention in which multiple clients are depicted.

FIG 4 depicts an example of a registration list used in the method of the present invention. FIG 5 depicts an example of a handler list used in the method of the present invention.

FIG 6 depicts an example of a notification list used in the method of the present invention.

FIG 7 illustrates a three-terminal, branched, undersea cable network having a centralized telecommunications management network architecture, in which the present invention is applicable.

FIG 8 illustrates a three-terminal, branched undersea cable network with a decentralized architecture, in which the present invention is applicable

FIG 9 illustrates a portfolio of services available to a user to administer and manage an undersea cable network, in which the present invention is applicable.

DETAILED DESCRIPTION

The present invention provides an intermediary between multiple processes operating in a network environment. Rather than each process being required to know all of the processes on-line, what requests they service, and where they are located on the network, the intermediary acts as a repository for this information.

So, when one process requires servicing of a given request, according to the present invention, it need not know all of the details about which processes can service that type of request. Rather, the requesting process merely specifies to the intermediary the type of request of which it requires servicing. The intermediary then accesses a database of processes and determines the processes that service this type of request. The intermediary then determines which of these processes are available, i.e., on-line and not being utilized, and sends the information regarding one available process to the requesting process so that the requesting process can then access the available process directly. The intermediary also sends a notification to the available process so that the available process is ready to service the request when it arrives.

Shown in FIG 1 is the prior art in which each process must open a unique port and know the exact location of the port for each process it must communicate with. In this simple example, four processes 1 1-14 must create twelve (12) socket connections. Turning to FIG 2, shown is a simple embodiment of the present invention to illustrate the concept. The intermediary discussed above is indicated in FIG 2 as the Intelligent Process Communication (IPC) Manager 21. In this case, the process initiating the request is the Client 22, and the available process for servicing the request is the Server 23. Here, the Client 22 initiates request M and sends it to the IPC Manager 21.

According to the method of the present invention, rather than simply requiring the Client 22 to know the existence of the Server 23 as a process that will service the request M, and which is currently on-line and available, the Client 22 simply sends the request M to the IPC Manager 21. The IPC Manager 21 then searches its database 24 for information about which processes service the requests M, which of the processes that service request M are on-line and which are not being utilized, and discovers that the Server 23 processes the request M, is on-line and is available to service this request.

The IPC Manager 21 also retrieves the information needed by the Client 22 to send the request M to the Server 23, which information is stored in the IPC Manager's database 24. The IPC Manager 21 then sends this information to the Client 22. The IPC Manager 21 also sends a notification (or wake up call) to the Server 23 to let the Server 23 know that it will be receiving a request soon.

Upon receipt of the information about the Server 23, the Client 22 sends its request M to the Server 23 in a known manner. The Server 23 then processes the request M in a normal manner. According to the present invention, the IPC Manager 21 acts as the intermediary between all requesting processes and all servicing processes.

The communications between each of the processes (i.e., the Client 22 and the Server

23) need only be made while the communication is taking place. Once completed they need not remain open. To create the database of information regarding processes, the present invention provides for a registration step during which information regarding a process is passed to the IPC Manager.

There are three types of registration messages sent to the IPC Manager. The first type is a process registration message, which transmits initialization type information to the IPC Manager. This information consists of the socket number in which the process is located, the host name in which the process is located, and a pattern used in indirect addressing of the process.

A second type of registration message is a service registration. This message registers the process with the IPC Manager as a process that services a given request. A third type of registration message is a notification registration. This message tells the IPC Manager that when the IPC Manager receives a particular notification to send it to the process.

The registration process continues in a dynamic manner. When a process first comes on-line, it registers with the IPC Manager. Then, when the IPC Manager assigns a process to a particular request, the IPC Manager knows this process is not available to any other requests. Finally, when a process completes processing of a particular request, the process sends a notification to the IPC Manager that the process is available for servicing requests again. Thus, at all times, the IPC Manager knows which processes are on-line, which are not being utilized and which service which type of requests.

The present invention changes the UNME R2 inter-process (IPC) paradigm from being Tooltalk™ based to that being socket based. The present invention is also useful for solving X- Window/IP C/notification problems. The IPCManager is an IPC mechanism developed to isolate the GUI notification problems experienced with Tooltalk™. This implementation can be extended to the UNME R2 IPC architecture.

The present invention new inter-process communication scheme handles requests and notifications without the process requiring knowledge of which process is sending or receiving the information at compile or runtime.

The present invention utilizes a master server process which listens to a well- known socket port on the UNME server hardware. Each of the applications requiring inter-process communication services would register with this server and inform the server of the messages it will handle and want notification of. The server will then direct all clients desiring replies to requests to the appropriate application to service that request. The server will also be responsible for ensuring that all notifications are delivered to all interested applications. Conversely, each registered application will unregister from the server when it normally terminates operation or does not need a particular notification or chooses to no longer handle ceπain requests. Each of the defined interactions with this IPCManager server is defined following this paragraph.

1. IPCM_REGISTER

Registers a process with the IPCManager (IPCM). The process sends a "registration" structure to the IPCM and then receives it as a reply with the port number to use as it's connection port. Listed below is an example of a registration message sent to the IPC Manager from a process during registration.

2. IPCM_DEREGISTER

De-registers a process from IPCM. The process sends its "registration" structure to the IPCM which will in turn remove all occurrences from the process, handler, and notification lists. See FIGs 4-6 for examples of these lists, respectively. Listed below is an example of a deregistration message sent to the IPC Manager from a process during deregistration. 3. IPCM_OFFER_HANDLER

Registers a process as a request handler for a particular message. The process sends its "registration" structure followed by the message number to handle. The IPCM in turn adds the handler information to the request handler list (see FIG 5) for later requests. Listed below is an example of an offer handler message sent to the IPC Manager from a process.

4. IPCM_WITHDRAW_HANDLER

Deregisters a process as a request handler for a particular message. The process sends its "registration" structure followed by the message number. The IPCM in turn removes the handler information from the request handler list (see FIG 5). Listed below is an example of a withdraw handler message sent to the IPC Manager from a process.

5. IPCM_REGISTER_NOTIFICATION

Informs IPCM that the process is requesting notification of a particular message. The process sends its "registration" structure followed by -the message number. The IPCM adds the notification information to the notification list (see FIG 6). Listed below is an example of a registration notification message sent to the IPC Manager from a process during registration notification.

6. IPCM_DEREGISTER_NOTIFICATION

Informs IPCM that the process no longer wants notification of a particular message. The process sends its "registration" structure followed by the message number. The IPCM removes the notification information from the notification list (see FIG 6). Listed below is an example of a deregistration notification message sent to the IPC Manager from a process during deregistration notification.

7. IPCM_LOOKUP_HANDLER

Requests the "registration" structure of any process handling the message the process wants to request. The process sends its "registration" structure and message number request. The IPCM then finds the "registration" structure of a handler based on the message number and sends it to the process as the "reply." If the IPCM is unable to find a handler, the port number attribute of the "registration" structure is set to -1 which is an invalid port number. Listed below is an example of a lookup handler message sent to the IPC Manager from a process.

8. IPCM_NOTIFY

Sends the message to all clients registering for the notification. The process sends the message number of the notification and the corresponding data. The IPCM then consults the notification list (see FIG 6) and forwards the message and data to the registered recipients of the message. Listed below is an example of a notify message sent to all clients registered with the IPC Manager to receive a particular notification.

Multiple Client/Server Example The present invention currently supports communication requests and notifications between multiple servers and clients including X Window applications. Turning to FIG 3, shown therein are multiple clients 31-33 (A-N) and multiple servers 35-37 (A-M) coupled to the IPC Manager 34. The dashed line shows a temporary communication link between client N 33 and server M 37. First, clients A-N 31-33 register with the IPC Manager, as mentioned above, during which they provide the communication details about themselves to the IPC Manager 34, which maintains a registration list (see FIG 4) of these clients and their associated communications details, such as socket location, host name, and indirect addressing pattern. Servers A-M 35-37 also register with the IPC Manager 34 in a similar manner, and are placed on the registration list (see FIG 4).

Next, at some point in time, servers A-M 35-37 register with the IPC Manager those requests they will handle. The IPC Manager maintains the handler list (see FIG 5) with this information.

Upon receipt of a handler request from the client N 33, the IPC Manager consults the handler list (see FIG 5) and determines that all of the servers A-M 35-37 handle this request, however, the IPC Manager also determines that Server B is busy processing a previous request, and has not sent a message to the IPC Manager that it has completed processing of the earlier request.

At this point, the IPC Manager can choose any of the remaining servers 35, or 37. There are many ways to determine which server to choose, such as to cycle among them, the first on the list, the last on the list, random order, maintain a list of which servers were chosen the least and use the least chosen server, etc. In any case, we shall assume that server M 37 was chosen on one of these bases by the IPC Manager. The IPC Manager then sends the communications details for server M 37 to the client N 33, and sends a message to the server M 37 that it will be receiving a request soon (a wake up call). The client N 33 then contacts the server M 37 directly, establishes a temporary communication link, and passes the request in the normal manner to the server M 37. Once completed the server M transmits the results to the client N 33. Once the client N 33 has received the results, it severs the temporary communication link, as this link is no longer required, thus keeping the network simple.

Problems Addressed by the IPC Manager Architecture

Since IPCM is based on sockets, the client processes only need to know the host name or the IP address of the UNME server where the IPCM is running for connection. When the client connects to IPCM, the client will send its IP address (not its host name) to IPCM so that requesters of a client's "registration" information structure will not need to consult the /etc/hosts file.

Because IPCM listens to a "well known" socket port, Sybase, or another mechanism, will not be needed to store the session identification of IPCM. The client process will only need to know the UNME it wishes to connect. The IP address information for connections to the UNMEs is available via a UNME generic library class called GNstation. In addition, no one but the Database Development needs to link with Sybase or the UNME database libraries. This reduces complexity in the build environment and increases the efficiency of the installed executables. Also, OpenClient™ does not need to be installed at the client (UI) workstation. This reduces the number of failure points in the installation process and requires fewer licenses of OpenClient™.

Since Tooltalk™ is no longer used, the database is not required. SafeMessages.h is converted to an enumeration scheme with respect to the message types. The enumeration scheme eliminates the aforementioned potential memory problems and increases the efficiency of comparisons. Since integers (numbers) are used in the present invention, comparisons are done by comparison of message numbers rather than message strings as in the prior art. As numbers are more easily compared in most computer languages, this increases the efficiency. A dynamic host table modification scheme is no longer necessary to support remote terminals over PPP. Since just about every communications protocol is based on sockets this becomes a non-issue. The present invention works much the same as telnet or sendmail does over PPP.

The new architecture has been extensively tested in the UNME product and no anomalies have been found thus far. All messages are received and processed without transmission protocol errors. The behavior which has been observed in the XWindows Tooltalk™ integration has not been observed in the new architecture.

Since the present invention does not use any static variables and new socket connections are created during the request process, this implementation is thread safe. The present invention supports multiple connections to IPCM from the same process using different file descriptors which is a capability not possible Tooltalk™.

Load Balancing is an additional feature of IPCM. The process accomplishes simple load balancing amongst multiple processes offering the handlers for identical messages. Failing Over to the Secondary UNME Unit is now possible. The IPCM code is written to maintain a disk file of the registration lists (see FIG 4) that IPCM uses to manage the requests and notifications. This allows the secondary IPCM once invoked to start with a basic picture of what was being managed at the time IPCM or the hardware failed. The client's code must provide for the occasion when the IPCM they are registered with is no longer available. The client must then try to register with the secondary IPCM (if available).

FIG 4 depicts an exemplary registration list. In this case, PI refers to process 1, P2 to process 2, UI to user interface, DB to database, the third column is the process identification (PID), the fourth column is the port number, and the fifth column is the state of the process.

FIG 5 depicts an exemplary handler list. The first column is the message number. The second column links the messages to the indices in the registration list.

FIG 6 depicts an exemplary notification list. The first column is the message number and the second column links the message number to the indices in the registration list.

Claims

WHAT IS CLAIMED IS:

L A method for communicating between multiple processes, comprising the steps of: a) establishing communications between all processes through an intelligent agent process such that intended senders and receivers are hidden from each other; and b) storing details of each process available to service requests in a storage accessible by the intelligent agent process.

2. The method according to claim 1 , further comprising the step of accessing the storage for details on a particular process when another process desires to communicate with the particular process,

3. The method according to claim 1, further comprising the step of sending registration information about a particular process to the intelligent agent process when the particular process becomes on-line.

4. The method according to claim 3, further comprising the step of dynamically updating the information stored in the storage accessible by the intelligent agent process upon receipt of the registration information.

5. The method according to claim 3, wherein the registration information includes a service registration.

6. The method according to claim 5, wherein the service registration includes a statement to the intelligent agent process that the particular process is a server for a particular request.

7. The method according to claim 3, wherein the registration information includes a notification registration.

8. The method according to claim 7, wherein the notification registration includes a statement to the intelligent agent process that upon receipt of a particular message the intelligent agent process should send the particular message to the particular process.

9. The method according to claim 3, wherein the registration information includes a process registration that indicates a particular process exists.

10. The method according to claim 9, wherein the process registration includes information regarding a socket number of the particular process.

11. The method according to claim 9, wherein the process registration includes information regarding a host name of the particular process.

12. The method according to claim 9, wherein the process registration includes information regarding a pattern used for indirect addressing of the particular process.

13. The method according to claim 1, wherein the storage accessible by the intelligent agent process includes active memory.

14. The method according to claim 1, wherein the storage accessible by the intelligent agent process includes a persistent disk file.

15. The method according to claim 1, wherein the storage accessible by the intelligent agent process includes both active memory and a persistent disk file.

16. The method according to claim 1, further comprising the step of sending a notification from a process to the intelligent agent process that the process is available to service another request.

17. A method for communicating between at least one client and at least one server in a network environment, comprising the steps of: a) sending a particular request for service from a client to an intermediate process, which maintains a handler list including information about which servers handle the particular request; b) accessing the handler list to identify a particular server that services the particular request; c) sending communication information regarding the particular server to the client; d) sending a message to the particular server indicating that the particular server will be receiving a request; and e) sending the request from the client to the particular server.

18. The method according to claim 17, further comprising the step of sending a message to the intermediate process from the particular server upon completion of servicing of the particular request by the particular server that indicates the particular server is completed with the particular request.

19. The method according to claim 17, wherein the intermediate process also sends communication information to the particular server identifying the client that will be sending the request.

20. The method according to claim 17, wherein the communication information includes at least one selected from the group consisting of a socket location, a host name and a pattern for indirect addressing.

21. An apparatus for controlling communications in a network environment so that the processes being executed on the network need not know any communication details of other processes on the network, comprising a master server executing an intermediary process, which performs the following steps: a) receiving a message from a client on the network that requires service that indicates a type of request for which the client requires servicing; b) determining which registered servers service the type of request received in step a); c) determining the availability of those registered servers determined in step b); d) selecting one of the registered servers determined to be available in step c); and e) sending the communication details regarding the one server selected in step d) to the client so that the client can then access the selected server directly.

22. The apparatus according to claim 21 , wherein the master server sends a wake up call to the one server so that the one server is ready to service the request when the request arrives from the client.

23. The apparatus according to claim 21 , wherein the master server maintains a list with information regarding registered clients and servers operating on the network.

24. The apparatus according to claim 23, wherein the master server receives details regarding the clients and servers operating on the network during a registration process which is initiated when a client or server becomes on-line on the network and transmits information regarding itself to the master server, which updates the list with information regarding registered clients and servers.

25. The apparatus according to claim 24, wherein the information the master server includes in the list with information regarding registered clients and servers, which information is received from the client or server during the registration process, includes a socket number in which the client or server is located, a host name in which the client or server is located, and a pattern, if any, used in indirect addressing of the client or server.

26. The apparatus according to claim 21, wherein the master server maintains a handler list with information regarding registered clients and servers received from clients and servers during a service registration process, and said information includes which types of request the clients and servers handle.

27. The apparatus according to claim 21, wherein the master server maintains a notification list with information regarding registered clients and servers received from clients and servers during a notification process, and said information includes which types of notifications to send to which clients and servers.

28. The apparatus according to claim 23, further comprising a database coupled to the master server storing a handler list, a notification list and a registration list, wherein the master server updates the handler list, the notification list and the registration list in a dynamic manner, by continually updating the contents as new clients and servers come on-line, undertake new requests and complete processing of assigned tasks.

29. The apparatus according to claim 28, wherein the handler list includes a list of requests handled by all of the clients and servers operating on the network, a cross reference to those clients or servers that handle each of these requests, and an availability indicator for each client or server, which indicates whether the client or server is currently available to service a new request.

30. The apparatus according to claim 28, wherein the notification list includes a list of a plurality of messages sent on the network, and a cross reference to those clients or servers that have registered for notification of each message when the message is output by some client or server on the network.

31. The apparatus according to claim 28, wherein the registration list includes a list of all registered clients and servers operating on the network and all communication details necessary for a client or server to communicate with a registered client or server.

32. The apparatus according to claim 28, wherein when the master server assigns a client or server to service a particular request, the master server raises a flag in the handler list that indicates the client or server is unavailable to service other requests, and when the client or server completes the particular request and sends a notification to the master server, the master server lowers the flag in the handler list indicating the client or server is available to service additional requests.

33. The apparatus according to claim 21 , wherein the master server executes a process that listens to a well-known socket port on network.

34. The apparatus according to claim 21 , wherein the master server executes a registration process during which the master server stores a registration structure received from a client or server operating on the network, and sends the registration structure as a reply to the client or server with the port number for the client or server to use as a connection port.

35. The apparatus according to claim 28, wherein the master server executes a deregistration process during which the master server, in response to a registration structure received from a client or server registered with the master server, removes all occurrences of the client or server from the registration, handler and notification lists in the database.

36. The apparatus according to claim 28, wherein the master server executes a handler process during which the master server, in response to a registration structure received from a client or server registered with the master server followed by a message number to handle, adds handler information about the client or server to the handler list for later requests.

37. The apparatus according to claim 36, wherein the master server executes a withdraw handler process during which the master server, in response to a registration structure received from a client or server registered with the master server followed by a message number, removes the handler information about the client or server from the handler list.

38. The apparatus according to claim 28, wherein the master server executes a notification process during which the master server, in response to a registration structure followed by a message number from a client or server registered with the master server, adds notification information about the client or server to the notification list.

39. The apparatus according to claim 38, wherein the master server executes a denotification process during which the master server, in response to a registration structure followed by a message number from a client or server registered with the master server, the master server removes the notification information about the client or server from the notification list.

40. The apparatus according to claim 21 , wherein the master server executes a lookup handler process during which the master server, in response to a request from a client or server registered with the master server requesting a registration structure of any client or server handling a message the client or server wants to request followed by a message number request, the master server locates the registration structure of a client or server to handler the request based on the message number and sends the registration structure of the client or server to handle the request to the client or server requesting the registration structure as a reply.

41. The apparatus according to claim 40, wherein if the master server is unable to find a client or server to handle the request, a port number attribute of the registration structure in the reply is set to an invalid port number.

42. The apparatus according to claim 28, wherein the master server executes a master server notify process during which the master server, in response to a particular message and data received from a client or server registered with the master server, consults the notification list and forwards the particular message and data to all registered recipients of the particular message.