KR100606117B1 - Ipc processing apparatus and it's method in unix os system - Google Patents

Abstract

The present invention provides a method for processing interprocess communication in a Unix operating system system including an interprocess server that provides a variety of higher level applications and a compatible service with an exchange processor using a communication method different from the Unix operating system. Registering the message and a function called when the message arrives by the upper application with the corresponding message, and polling the interprocess communication server to determine whether a message registered by the upper application exists. When the registered message arrives, the registered function is called to the corresponding application.

UNIX OS, IPC Server

Description

IPC PROCESSING APPARATUS AND IT'S METHOD IN UNIX OS SYSTEM}             

1 is a configuration diagram for communication between a commercial UNIX OS-based system and the exchange processor,

2 is a configuration diagram for communication between a UnixOS based system and an exchange processor according to an embodiment of the present invention;

3 is a view for explaining a procedure for registering a callback (callback) to the IPM according to an embodiment of the present invention,

4 is a diagram illustrating a procedure of calling a registered callback method by reading a message from a file descriptor according to an embodiment of the present invention.

The present invention relates to an apparatus for communication between a Unix operating system-based system and an exchange processor, and more particularly, to a message delivery method and apparatus using an IPC server (Inter-Process Communication server).

Processes running on Unix Operating System (UNS) use Transmission Control Protocol / Internet Protocol (TCP / IP) to send messages to and from processes in the same processor or in different processors. However, processes running at exchanges run on exchange OSs that do not support these TCP / IP protocols. Therefore, in order to send a message from a Unix processor to a process in an exchange processor, an intermediate process is required to adapt the TCP / IP protocol to the exchange IP-C protocol.

A process for performing an intermediate process for delivering a message to the other side using these different protocols is provided in the exchange and the Unix OS system, and the process is called an IPC server (Inter-Process Communication server).

1 is a configuration diagram for communication between a commercial UNIX OS based system and an exchange processor, and an IPC server exists. The commercial Unix OS system 2 that communicates with the main exchange body 4 includes an IPC server 6 and various Unix processes 8a, 8b, 8c, i.e., various applications.

IPC communication methods in Unix include pipes, FIFOs, message queues, semaphores, shared memory, and sockets. The IPC communication method is selected as one of them according to the characteristics of the application, but an IPC communication method using a socket is mainly used.

Receives an IPC message from the exchange main body 4 and delivers the message to a higher-level application 8a, 8b, 8c in which the message is registered, and receives a message (signal) from the higher-level application 8a, 8b, 8c. For example, the IPC server 6 that transmits the IPC server 6 uses a UNIX INET socket.

In order to use the IPC mechanism provided by the IPC server 6, the upper application 8a, 8b, 8c, which is a user of the IPC server 6, first opens a socket before communication to the main body 4 of the exchange. It is necessary to obtain a file descriptor and to communicate with the exchange body 4 via the file descriptor. In addition, in the case of the initial signal (initial signal) in association with the file descriptor to register in advance to receive the signal to the IPC server (6). Here, the initial signal means a signal for sending a message using the message ID Signal_ID. Since each message ID (Signal_ID) is determined by a protocol according to a purpose, the message may be transmitted using the message ID (Signal_ID) even if the sender does not know the address of the receiver. The receiving side registers its desired message ID Signal_ID in a preset initial signal table to receive the message sent by the transmitting side.

After this series of procedures, each of the applications 8a, 8b, and 8c constantly polls the file descriptor to receive and process the IPC message. If the message exists, the message is read and processed according to the corresponding message ID. The message is then written to an already open file descriptor which causes the IPC server 6 to forward the message to the exchange body 4.

In this procedure, each upper application 8a, 8b, 8c must have a part in charge of IPC processing for each application in order to determine whether an IPC message exists. The part in charge of IPC processing has almost the same structure as other applications.

However, the above-described processing and structure has the following problems. First, persistent polling is necessary to determine the existence of an IPC message. Second, the polling structure is almost identical for each application, so having the same structure in multiple applications wastes system resources. Third, since the polling part and the pure application are closely related to each other to determine the existence of a message, the IPC polling part of the lower part should be modified when the application is extended and modified.

Accordingly, it is an object of the present invention to provide a method and apparatus for allowing each higher application to concentrate only on the processing of a pure application without considering the details of the underlying interface.

In accordance with the above object, the present invention integrates an IPC polling structure and allows each upper application to concentrate on the processing of pure applications without considering the details of the underlying interface, and provides a uniform interface for each IPC message user. To provide.

Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings. It should be noted that the same elements in the figures are denoted by the same numerals wherever possible. In addition, detailed descriptions of well-known functions and configurations that may unnecessarily obscure the subject matter of the present invention will be omitted.

2 is a block diagram for communication between a UnixOS-based system and an exchange processor that is based on a different method from the UnixOS according to an embodiment of the present invention. The main body of the exchanger 4, the IPC server 6, and various applications 18a, 18b and 18c) and an IPM (Inter Process Message) service package 20.

Looking at the structure according to the embodiment of the present invention shown in Figure 2, it can be seen that the IPM service package 20 is additionally configured independently of the various applications (18a, 18b, 18c). The IPM service package 20 is located between various applications 18a, 18b, and 18c and the IPC server 6, and is responsible for polling and distribution functions for registered messages. That is, polling is performed on the messages registered by the upper applications 18a, 18b, and 18c, and the upper applications 18a, 18b, and 18c call together with the functions registered when the upper applications 18a, 18b, and 18c register messages. 18c) let this be done.

In more detail, the upper applications 18a, 18b, and 18c register the message and the function called when the message arrives together in the IPM service package 20. Then, the IPM service package 20 polls to determine whether there is a message registered by the upper application 18a, 18b, or 18c, and when the registered message arrives, the IPM service package 20 registers the registered function with the corresponding application (18a, 18b, 18c). Call

The IPM service package 20 uses a callback pattern to distribute the received message to registered IPM clients, i.e., applications 18a, 18b, and 18c. Here, the IPM client uses the message ID for registration, and the IPM service package 20 calls the registered callback when there is a registered message ID among the received messages.

3 is a diagram illustrating a procedure of registering a callback to the IPM service package 20 according to an embodiment of the present invention. In FIG. 3, callback, interface, newEntry, calback_, registry, connection_, and ipcServer Library are internal objects of the IPM service package 20.

Referring to Figure 3 describes the procedure for registering a callback,

(1) The IPM Client, that is, the applications 18a, 18b, and 18c, registers a callback method using the message ID in the callback (registerCallback).

(2) The callback creates a callback instance and sends that instance to the interface (registerCallback). This is to open the interface.

(3) The interface adds a command (callback function and message ID) to the storage object registry_.

(4) registry_ creates an entry (newEntry) and adds the requested action to the static add method in the entry type.

(5) newEntry creates its own instance (new).

(6) The new entry instance itself links.

(7) newEntry links the link request to callback_, the callback object.

(8) The callback object callback_ determines whether the link request message is an initial signal (is Initial).

(9) If it is an initial signal, the callback object callback_ calls the link on the interface. This is a function of success.

(10) The interface links the request to the connection.

(11) The connection queries to set the file descriptor to the blocking mode (setBlocking). This is a query to keep the file descriptor staying until the desired message comes.

(12) connection calls ipclink, ipcServer Library. This is a function to match the message ID and the file descriptor.

(13) The connection requires the interface to recover the blocking mode of the file descriptor. This allows the file descriptor to stay on until the desired message is reached.

Referring to FIG. 4, a procedure of reading a message from a file descriptor and calling a callback method registered in the IPM service package 20 to the corresponding applications 18a, 18b, and 18c will be described. 4 is a diagram illustrating a procedure of calling a registered callback method by reading a message from a file descriptor according to an embodiment of the present invention.

(1) When an event is detected, the global reactor calls handle_input on svcHandler, a registered service handler.

(2) The svcHandler sends a call to the interface (readEvent).

(3) The interface invokes read messages (readMsg) to combine and send messages.

(4) The interface dispatches its own dispatch.

(5) The interface requests to copy the callback method to resgistry_ if there is a callback method by message ID (clonedCallback).

(6) The interface invokes dispatch on the copied callback method (IPMDispathc (clonedCallback)).

(7) The interface calls the dispatcher.

(8) The dispatcher requests a dispatch to clonedCallback.

(9) The callback requests a function from the IPM client registered by the message ID, that is, the application 18a, 18b, 18c.

Accordingly, the upper application 18a, 18b, 18c processes the function request and transmits the response to the IPC server 6 using the IPM service package 20.

As described above, in the present invention, when a commercial Unix-based system performs IPC communication with an existing exchange, a system for polling messages is integrated to prevent waste of system resources and to relay IPCs of upper applications and lower layers. By promoting mutual independence between IPM service packages, the upper application can modify the application regardless of the processing of the underlying IPM service package.

In the above description of the present invention, specific embodiments have been described, but various modifications may be made without departing from the scope of the present invention. Therefore, the scope of the present invention should not be defined by the described embodiments, but should be determined by the equivalent of claims and claims.

Claims (6)

An apparatus for interprocess communication processing in a Unix operating system system, Various top applications, A server that provides a compatible service with an exchange that uses a communication method different from that of the upper level applications of the UNIX operating system, A message between the upper applications and a server, the message of the upper applications and a calling function of the message are registered, and when the message arrives from the server after polling the registered message, the arrived message is sent to the applications. And a service package for distributing. In the inter-process communication processing method in the Unix operating system system having a server providing a compatible service with a variety of higher-level applications and a switch using a communication method different from the UNIX operating system of the upper applications, Registering a message of the upper applications and a calling function when the message arrives in a service package provided between the upper applications and the server; And polling the registered message to determine whether the registered message exists and calling the application corresponding to the registered calling function when the registered message arrives from the server. The interprocess communication processing method characterized by the above-mentioned. The method of claim 1, And wherein the service package distributes the arrived message to the applications using a callback pattern when the message arrives. The method of claim 1, And the service package invokes an application corresponding to the registered calling function when the message arrives. The method of claim 2, The registering of the service package may include registering using a message identifier. The method of claim 2, And invoking the application corresponding to the registered call function by using a callback pattern.

Images