KR100442688B1 - Interprocess communication method and apparatus - Google Patents

Abstract

A communication method for delivering a message from a source to a destination, the method comprising: providing an operating system integrated interface function independently accessible to an operating system (OS) of a communication device by an operating system independent access (OIA) layer; Providing a device integration interface function independently accessible to the physical device of the communication apparatus by the DIA layer, and destination information and a task provided by the source task by the UIPC layer. And transmitting a message from the source to the destination through at least one of the operating system independent access layer and the device independent access layer using a common task architecture having a basic common control flow.

Description

Interprocess Communication Method and Device {INTERPROCESS COMMUNICATION METHOD AND APPARATUS}

BACKGROUND OF THE INVENTION Field of the Invention The present invention relates to a communication system for performing interprocess communication (hereinafter referred to as "IPC"), in particular integrated process communication (Unified) which is not dependent on communication physical devices and operating sys. InterProcess Communication: hereinafter referred to as "UIPC" method and apparatus.

There are various methods of IPC for interprocess message communication, including pipes, semaphores, message queues, and shared memory, all of which are based on operating systems. Therefore, IPC methods are provided in various forms depending on the operating system on which they are based. The IPC method was dependent on the operating system. As a result, the application software had to change depending on the operating system used in the communication system in implementing the IPC and process. In addition, in the case of process communication between hardware devices, the device drivers are different depending on the physical devices provided. Therefore, the process requiring the device driver had to change the IPC function according to the device driver used. .

The IPC method in such a communication system was dependent on the operating system and the physical device. As a result, additional and repetitive overhead is caused by the change of the operating system and the physical device used in the communication system, which causes a considerable burden on the development time and cost of the communication system. It also made the software less usable and reusable.

Accordingly, an object of the present invention is to provide a flexible and integrated process communication method and apparatus that do not depend on the type of operating system and physical device adopted by the communication system.

Another object of the present invention is to provide an integrated process communication method and apparatus for performing process communication regardless of an operating system used in a communication system and having excellent software reuse and portability.

It is another object of the present invention to provide an integrated process communication method and apparatus for performing process communication regardless of physical devices used in a communication system.

It is still another object of the present invention to provide a communication device for delivering a message from a source to a destination regardless of which communication methods (for example, ATM, IP, SDH, etc.) are used by the communication device.

In accordance with the above object, the present invention provides a communication method for delivering a message from a source to a destination, the operating system integrated interface function that is independently accessible to the operating system (OS) of the communication device by the operating system independent access (OIA) layer Providing a device integrated interface function independently accessible to a physical device of the communication device by a device independent access (DIA) layer, and by the integrated interprocess communication (UIPC) layer. Sending a message from the source to the destination through at least one of the operating system independent access layer and the device independent access layer using a common task architecture having destination information provided by the task and a basic common control flow of the task. As a course Characterized in that made.

In addition, the present invention provides a communication apparatus for delivering a message from an origin to a destination, the operating system independent access (OIA) layer unit that provides an operating system integrated interface function that can be accessed independently of the operating system of the communication device, and the physical of the communication device From the source using a device independent access (DIA) layer unit that provides device independent interface functionality that is independently accessible to the device, and a common task architecture that has a basic common control flow of destination information and tasks provided by the source task. And an integrated inter-process communication (UIPC) layer that transmits the message to the destination through at least one of the operating system independent access layer and the device independent access layer.

In the embodiments of the present invention, the terms "process", "application", and "task" will be used interchangeably, and it should be understood that they mean tasks existing on the UIPC implemented in the present invention.

1 is a diagram illustrating a network configuration between each self for message exchange according to an embodiment of the present invention;

2 is an example of a specific configuration of a communication system to which the UIPC function is applied according to an embodiment of the present invention;

3 is a block diagram of a common software platform having a UIPC as a component according to an embodiment of the present invention;

4 is a view showing a UIPC configuration per card (per unit) according to an embodiment of the present invention;

5 is a basic common control flow diagram of a process using a structure of a common task architecture, that is, a task;

FIG. 6 is a diagram illustrating a UIPC API configuration and a common task architecture according to an embodiment of the present invention. FIG.

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 represented 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.

And the following foreign documents provide background and additional information for understanding the concept of the present invention:

Open Systems Interconnection, Basic Reference Model, ITU-T X. 200

Open Systems Interconnection, Data Link Service Definition, ITU-T X. 212;

Open Systems Interconnection, Network Service Definition, ITU-T X. 213;

Open Systems Interconnection, Transport Service Definition, ITU-T X. 214;

1 is a diagram illustrating a network configuration between each self for message exchange according to an exemplary embodiment of the present invention. The network topology of FIG. 1 includes an element management system (EMS) 8, a system controller self 10 having a plurality of cards including a card 12, and a smart device. an extended self 1 (20a) having a plurality of cards including a device (6) and a card (22a), an extended self 2 (20b) having a plurality of cards including a card (22b), and An expansion shelf 3 (20c) having a plurality of cards including a card (22c) is included.

Referring to FIG. 1, in order for the extended self 3 20c to communicate with the system controller self 10, the communication between the extended self 3 20c and the system controller self 10 is physically extended to the extended shelf 2 20b. Even though it passes through, there is a virtual direct path between the extended self 3 (20c) and the system controller self (10) configured according to an embodiment of the present invention.

1 is a view illustrating a network structure to which the UIPC function of the present invention is applied. The UIPC according to an embodiment of the present invention will be described below in more detail with reference to FIG. 2, but it will be described in detail beforehand, between tasks in each card, between tasks on different cards in the same card, and in some self and It supports message exchange between tasks within attached smart devices 6 (eg, digital subscriber line modems and integrated access devices). It should be noted that if necessary, it is assumed that messages that need to be transferred between the two shelves are routed through the system controller shelf 10. This simplifies the protocol and reduces the overhead associated with protocols such as Internet Protocol (IP), which deal with more generalized network topologies. It should be recognized that the component management system 8 also communicates via the UIPC. Messages can be routed between the component management system 8 and any card in any shelf. One component management system 8 may look similar to any other self as far as the UIPC is concerned.

2 is an example of a specific configuration of a communication system to which the UIPC function is applied according to an embodiment of the present invention.

The extended self 20i shown in FIG. 2 is one of the plurality of extending shelves 20a, b, c shown in FIG. 1, and the system controller self 10 is the plurality of extended shelves 20a. , b, c) is self. Each of the shelves 10 and 20i includes a plurality of control cards 14, 16, 24, and 26, and one main control card for controlling the plurality of control cards 14, 16, 24, and 26. (main control card) 12,22 are provided. Each of the control cards 14, 16, 24, and 26 and the main control card 12, 22 have a UIPC 30 configured for inter-process message communication as part of a common software platform 32. It is provided as an element. The UIPC 30 is a means for providing a path for message communication between in-card, inter-card, inter-card, inter-self processes. Each UIPC 30 is connected to processes (application tasks) such as, for example, P1 and P2 shown in FIG.

As shown in Fig. 2, the UIPC 30 includes three types of "in-card process communication (internal process communication)", "in-card process communication (external process communication)", and "self-process communication (external process communication)". It is provided in the form. In the case of " self-card process communication " and " self-process process communication ", a separate device driver is required.

FIG. 3 is a block diagram of a common software platform 32 having a UIPC 30 as some component according to an embodiment of the present invention.

The common software platform 32 shown in FIG. 3 is software that provides common and common functions for common application in many different communication systems. The common software platform 32 resides in each of the cards 12, 14, 16, 22, 24, and 26 in the example shelf 10 and 20 shown in FIG. 2, and its components are divided into a number of functional units. It is.

The common software platform 32 is referred to as a component horizontally arranged (hereinafter referred to as "horizontal components") and vertically arranged components (hereinafter referred to as "vertical components"), as shown in FIG. ). Horizontal components such as common agent 40, common operation, administration and maintenance (OAM) 42, Unified InterProcess Communication (UIPC) 30, Device Independent Access layer (DIA) 46 ), Physical device drivers (48), RTOS (Real Time Operating System) 50, and hardware 52 are common functional blocks required by all communication systems, and specific technical functions are determined by vertical components. Are provided. Vertical components such as Asynchronous Transfer Mode (ATM) 56, synchronous digital hierarchy (SDH) + Plesiochronous Digital Hierarchy (PDH) 58, and Voice over Packet (VoP) 160 are the technical requirements of the communication system. As a functional block, technical functions are provided for horizontal components and are factors that change according to a communication system. For example, a common OAM 42, one of the horizontal components, collects and manages alarm and performance data for the maintenance of a communication system, while an ATM-related alarm, performance for an ATM-related communication system. The data is provided by vertical components called ATM 56. In Fig. 2, the hatched functional blocks 50, 162, 164, 166, 168 and 170 are functional blocks in which commercial software can be used or added.

In FIG. 3 the upper block from "common agent 40" to "common OAM 42" depends on the application of the software.

Various communication systems will include a common software platform 32 as shown in FIG. 3, and all applications intended to be implemented in the communication system are vertically configured with the horizontal components provided by the common software platform 32. It will be developed as a combination function of the components.

The function of the horizontal components of the common software platform 32 shown in FIG. 3 is described in more detail as follows.

1.Operating System Independent Access Layer (OIA layer) (54)

Portability of the application and the UIPC 30 by providing an OS integrated interface function so that the OS can be accessed independently without being dependent on an operating system (OS) such as the RTOS 50 in implementing the application and the UIPC 30. Improve). That is, even if the operating system of the communication system changes, the software application and the UIPC 30 can be reused without change.

2. Device Independent Access Layer (DIA Layer) (46)

By hiding specific parts of the physical device driver 48, a common model for various devices, that is, device-integrated interface function is provided for independent device access without device dependence. do. Accordingly, even if hardware chips such as hardware 52 of FIG. 3 are changed, the application and the UIPC 30 / OIA layer 54 can be reused without change by the DIA layer 46.

3. Unified Interprocess Communication (UIPC) 30

By concealing specific information about the sub-software and sub-hardware 52 such as the IPC mechanism and the RTOS 50 according to the operating system for the process communication, no additional work is required in the application implementation.

4. Common Operation, Administration Maintenance (Common OAM) (42)

-It provides a common method for operation and maintenance of various communication systems.

5. Common Agent Software (40)

-Provides interface with external network management system for network management of communication system.

As described above, it is possible to implement a software architecture that is reusable for various communication systems and that does not depend on an operating system and a hardware device by providing common functions without being tied to the implementation of a specific function in implementing various communication systems. The purpose of the existence of a common software platform 32. The UIPC 30 implements a process message communication method as part of the components of the common software platform 32.

The common software platform 32 has been described so far to better understand the present invention, and the configuration and function of the UIPC 30 will now be described in detail with the accompanying drawings.

The UIPC 30 is an element performed in every control unit, i.e., each of the control cards 12, 14, 16, 22, 24 and 26, as shown in FIG. It provides message communication function.

For message communication through the UIPC 30 according to an embodiment of the present invention, an application ID APP_ID and a network address N_ADDR are required. The application ID APP_ID is an ID for identifying a corresponding process to communicate with, and the network address N_ADDR is an address value indicating a physical location of the corresponding process. The network address N_ADDR has a size of four octets and consists of information of a rack-self-slot-port. Therefore, the network address N_ADDR can be used to find the physical location of the process. The network address N_ADDR uses only the self and the slot (location where the card is mounted) ID for the UIPC 30, and the rack and the port ID are used for other purposes. In FIG. 2, a case in which a message is transmitted from the process P1 in the main control card 12 of the system controller shelf 10 to the process P1 in the main control card 22 of the expansion shelf 20i will be described. First, it is assumed that the ID of the system controller shelf 10 is "1", the ID of the expansion shelf 20 is "2", and the slot IDs of the main control cards 12 and 22 are "2". First, the source and destination application ID APP_ID are each P1. The source network address N_ADDR is "0x00010200" (rack-self-slot-port) in hexadecimal and the destination network address N_ADDR is "0x00020200" (rack-self-slot-port) in hexadecimal. do. When the network address N_ADDR and the application ID APP_ID are compared in correspondence with the Internet protocol (IP), the network address N_ADDR is mapped to the IP address and the application ID APP_ID is similarly mapped to the port number of the Transmission Control Protocol (TCP). Can be.

Functions provided by the UIPC 30 according to an embodiment of the present invention are as follows.

UIPC 30 provides for interactive message transfer between tasks anywhere in the network component.

UIPC 30 allows the application to send messages asynchronously. The application program interface (API) gives an immediate response without blocking.

UIPC 30 allows tasks to send messages and respond synchronously with a timeout.

UIPC (30) extracts the underlying physical transport mechanism (underlying physical transport mechanism).

UIPC 30 provides a mechanism by which messages can be broadcast.

Low-level UIPC protocols can be changed without changing the upper layer protocols and vice versa.

UIPC 30 detects a transmission error on a link-to-link basis and retries the failed packets. This means that the data link layer of the protocol that handles each link must make the link reliable.

-The same UIPC API is used for internal process communication and external process communication.

The same UIPC 30 performs division and reassembly of large messages.

UIPC 30 provides a mechanism to enable debug output.

UIPC protocol parameters can also be set at run-time.

The UIPC 30 provides a mechanism for setting the maximum transmission unit for each link.

UIPC 30 accommodates links with variable maximum transmission units.

UIPC 30 supports message priority for real-time critical messages.

UIPC 30 is independent of the operating system (OS).

UIPC 30 allows a message from the controller to pass through transparently to the devices attached to the card.

The UIPC 30 has a role of delivering a message from a source to a destination, but does not provide a representation system for a specific system message because it is a role of an application for the content of the message. The presentation mechanism of the system message is a role of a presentation layer. In the UIPC 30 according to an embodiment of the present invention, the presentation layer does not include the presentation layer because it is directed to a real-time protocol.

4 is a diagram illustrating a UIPC configuration per card (per unit) according to an exemplary embodiment of the present invention. It should be understood that the task in FIG. 4 is regarded as the same concept as the process.

Referring to FIG. 4, the UIPC 30 according to the embodiment of the present invention, which is provided in each card (unit), is divided into a UIPC API (Application Program Interface) 60 and a UIPC protocol stack 70. It is divided into two parts. The reason for this is to efficiently distinguish between interprocessor communication that requires the UIPC protocol stack 70 and intraprocessor communication that does not require the UIPC protocol stack 70. External processor communication is when the network address N_ADDR is not its own, so a message must be transferred from its card to another card. Intraprocessor communication is because the network address N_ADDR is its own. This is the case when a message can be delivered directly to the task. The UIPC API (Application Program Interface) 60 is provided in the form of a library called from a task. The task calls the UIPC API 60 to send and receive messages and communicates with the UIPC protocol stack 70 for external process communication and processes the messages.

First, the UIPC API 60 according to an embodiment of the present invention will be described in more detail with reference to FIG. 4.

UIPC API (60)

The UIPC API 60 is a shared library that can be used in any task (process) and provides an interface to all external functions provided by the UIPC 30. In short, UIPC API 60 provides an interface for any application task to use UIPC functionality. In addition, external and internal process communication paths are determined based on the network address N_ADDR and the application ID APP_ID. The UIPC API 60 does not use the UIPC protocol stack 70 for intraprocessor communication. The UIPC API 60 examines the network address N_ADDR indicating the physical location of the corresponding application task (process), and, if it is intraprocessor communication, provides the OIA API library provided by the OIA layer 54 of FIG. The message is delivered directly to the message queue of the task (process). If it is an interprocessor communication, the UIPC API 60 delivers the message to the message queue of the UIPC protocol stack 70 for routing to find the destination.

The most important of the external functions provided by the UIPC API 60 to the task (application) is to provide a common task architecture of the common software platform 32 to enable the task to use the UIPC. Representative functions of a common task architecture according to an embodiment of the present invention are as follows.

Developers don't have to redesign task structures.

2. Asynchronous callback is performed on the caller's task.

3. There is no need for developers to integrate applications with common components (eg common OAM, etc.).

4. Communicate between tasks using Message Queuing. This is because it is a common IPC mechanism provided by all operating systems.

Of all the components (horizontal component + vertical component) of the common software platform 32, the software application of the upper block of the UIPC layer 30, for example, the common agent task 40, the common OAM task 42, etc. The common task architecture according to the embodiment of the present invention provided by the API 60 is used and implemented. The basic common control flow of a task (process) using the structure of the common task architecture of the four functions is shown in FIG.

Referring to FIG. 5, the task waits for message reception using a queue. When the task receives the message asynchronously (step 100), the task decodes the received message and analyzes it (step 102), and then performs message processing (step 104). If the task requires processing separately, after performing other application specific processing (step 106), the process returns to step 100 and waits for a message reception.

The conventional task architecture of a conventional legacy task architecture and a task having a basic common control flow as shown in FIG. 5 according to an embodiment of the present invention were compared in the tables of Tables 1 and 2 below. Conventional legacy tasks, such as the example shown in the table of Table 1, do not have a common structure and are individually designed in different forms depending on the developer and task function. This was a significant overhead in development time and had to be redesigned even for tasks with similar functionality. Meanwhile, the common task architecture according to the embodiment of the present invention as described in the table of Table 2 is implemented to have a basic common control flow of the task as shown in FIG. 5 to eliminate the conventional overhead. So it has a significant effect on shortening development time.

The common task architecture shown in Table 2 will be described in detail with reference to FIG. 6.

FIG. 6 illustrates a UIPC API configuration and a common task architecture according to an embodiment of the present invention. Referring to FIG. 6, the main task of each card generates a global information table as shown in Table 3 below in the UIPC, and generates subtasks task1 and task2 that perform unique functions (eg, alarm task, performance task, etc.). .

Task ID Application ID Pointer to the dynamic message handler table for the task Pointer to the static message handler table for the task Pointer to the dynamic message class table of the task Pointer to the task's idle message handler. Wait time used in Uipc_RcvLoop ()

<< UIPC Global Information Table >>

Hereinafter, the UIPC global information table inside the UIPC will be described in detail. The global information table contains information about all the tasks in a particular card. Each entry in the global information table is a task control block (TCB). Each task control block will hold the information to which the task is constantly assigned.

The first field of the task control block is 'task ID'. The second field of the task control block is an 'application ID'. This will be the 'application ID' of the task's 'Main Queue'.

Each task will have a dynamic message handler table, a static message handler table, and a dynamic message class table. Each time a task raises Uipc_RegisterOneTimeApi (), an entry is made in the task's dynamic message handler table. Entries in this dynamic message handler table are not permanent. The entry is deleted as soon as the response of one API arrives. The dynamic message handler table may be implemented using balanced binary trees. Each time a task raises Uipc_RegisterMsgHandler (), an entry will be made in the static message handler table. The static message handler table is dedicated to the watcher's API. Unlike the dynamic message handler table, entries in the static message handler table will be permanent. The static message handler table will be implemented using arrays.

Each time the task triggers Uipc_GenerateTempMsgClass (), the message class will revert back to the task, and the necessary updating is done in the dynamic message class table so that the particular message class is busy. Each time the task raises Uipc_FreeTempMsgClass (), the UIPC will make the necessary changes in the dynamic message class table so that a particular message class can be used in the future. The dynamic message class table will also be implemented as an array.

The global information table contains pointers to all of the above tables. In addition, the global information table also includes a pointer to the 'Idle Message Handler' function of the task. The global information table will contain the latency that must be used in Uipc_RcvLoop () for each task. Each time within the Uipc_RcvLoop API the global information table will be queried for latency. Since the global information table will be accessed by all tasks, some semaphore signal will protect the global information table. This semaphore signal will be generated during Uipc_InitCardCentext ().

Referring back to FIG. 6, in the UIPC API, Uipc_InitCardContext () is requested to initialize the UIPC 30 according to an embodiment of the present invention. Uipc_InitCardContext () performed by the main task creates a memory allocation and internal data structure for use by the UIPC to use the UIPC 30. Uipc_InitCardContext () should only be called once per card (unit).

Hereinafter, the common task architecture of the subordinate tasks task1 and task2 generated by the main task will be described in detail.

In the common task architecture, Uipc_InitTaskContext () allocates a global information table for each task creation and registers it in a global table entry so that various tasks can communicate using the UIPC 30. Uipc_InitTaskContext () should be called only once per task.

Uipc_CreateQueue (TASK1_APP_ID, hTask1Queue) creates a queue to receive messages using UIPC in each task. Uipc_CreateQueue (TASK1_APP_ID, hTask1Queue) registers the created queue ID in the queue table for the application ID of the task.

Uipc_SetmainQueue (hTask1Queue) registers this queue as the main queue for receiving messages in tasks. Once registered as the main queue, it is used as a queue for message wait inside Uipc_RcvLoop ().

Uipc_RegisterMsgHandler (TASK1_MSG_CLASS, Task1MessageHandler) is used to process the message received in Uipc_RcvLoop () by registering the message type (message class) to be processed in the task and the handler function to process the message in the global information table.

Uipc_RegisterIdleHandler (Task1IdleHandler) registers a handler function in the global information table when a task wants to perform additional functions in addition to the received message handling function, and performs additional work when there are no messages received inside Uipc_RcvLoop ().

Uipc_RcvLoop () is the part where the task performs the reception of messages from the main queue and the processing of received messages, and internally loops indefinitely without returning. This is where you receive the message, decode the message, process the message, and perform additional tasks.

Next, the UIPC protocol stack 70 of the UIPC 30 will be described in detail with reference to FIG. 4 again.

UIPC Protocol Stack (70)

The UIPC protocol stack 70 is for interprocessor communication. External process communication is performed by sending a message from the UIPC API 60 to the queue of the UIPC protocol stack 70. The UIPC protocol stack 70 needs a routing library to determine the message route, based on the application ID APP_ID and the network address N_ADDR. For routing, the UIPC API 60 calls the API provided by the routing library with the application ID APP_ID and the network address N_ADDR to determine whether it is an intraprocessor message or an interprocessor message. To judge. If it is an interprocessor message, the UIPC API 60 sends the message to the queue of the UIPC protocol stack 70. A typical protocol stack is based on the Open System Interconnection (OSI) model, but the UIPC protocol stack 70 according to an embodiment of the present invention does not support all seven layers but only three layers as follows. In short, the UIPC protocol stack 70 according to an embodiment of the present invention supports a data link layer 72, a network layer 74, and a transport layer 76. . A data link queue exists in the data link layer 72, a network queue exists in the network layer 74, and a delivery queue exists in the delivery layer 76.

The function of the three layers according to the invention will be described in detail below. However, before referring to the details of each layer, the following general requirements apply to each layer. These are intended as guidelines for implementers of the layers.

The header for each layer must contain a protocol identifier. The identifier indicates which protocol or combination thereof is involved in the message. This usually consists of two or three bits inside the header. This will allow different protocols to be implemented in the future without changing to other protocols. For example, an incoming message being processed by network layer 74 will have a protocol identifier in the network layer header that indicates which protocol module should be next to process the message. If the UIPC wishes to support transport layer protocols such as Transmission Control Protocol (TCP) or User Datagram Protocol (UDP), the protocol identifier may or may not forward the message to the TCP or UDP module. ). The UDP refers to session layer protocols that provide Internet standard network layer, transport layer, and datagram services. UDP, like TCP, is a connectionless protocol at the top layer of IP.

Some protocol layers may depend on other layers and may not be used independently. For example, consider a LAPD, which is a data link layer protocol depending on a physical high level data link control (HDLC) layer. The acronym "LAPD" indicates a link access procedure on the D channel.

Each layer will retain the priority of the message. High priority messages or segments (in case of long messages that need to be fragmented) will always be sent before other messages or segments. It is recommended that only two priorities, namely 'normal' and 'high', are supported in the present invention. Further divisions can only lead to confusion. However, further priority division may also be supported by the present invention.

Each layer may define specific control messages that are exchanged between the same layers at the endpoint. These control messages allow either side to negotiate protocol parameters or to perform flow control.

The following section will describe the characteristics and responsibilities of each protocol layer. Each part also contains a list of primitives that the layer must provide. These primitives are intended to show an external interface (i.e., the next protocol layer) provided to other software. They do not describe the actual messages passed between the two endpoints. The definition of those messages and their associated state machines will not be described here. Such will be defined when the specific design is performed.

The primitives described above will be named using the terminology of the International Telecommunication Union (ITU), and will be categorized into "Request", "Response", "Indication", and "Confirm".

Request: This means one function that the layer must support and is intended to be invoked by the next layer above it in order to request an action.

Response: This is triggered by the far end terminal when an indication is received that requires one response. As a result, the requestor of the above-mentioned 'Request' will receive the confirmation.

Indication: This is a notification that an event has occurred. It is intended that the next layer up or later generated code receives these instructions. Most of the 'Indications' are the result of the remote terminal initiating an operation through one 'Request'.

Confirm: This is a confirmation that the above 'Request' is answered.

Each primitive has data associated with that primitive. The mechanism for passing primitives between layers is not described in detail here because it is part of the detailed design of the layers.

It is very important to note that the Maximum Transmission Unit (MTU) must be defined. The maximum transmission unit (MTU) defines the maximum message size. Any messages below this size are sent as a single message.

Determining the maximum transmission unit is part of the application design. It is therefore not defined as part of the UIPC. However, UIPC defines an internal API that is visible only to components of UIPC to set the maximum transmission unit. The maximum transmission unit is determined by the application task requirements, the number of hops (called nodes between routers) that one message is expected to take, and the speed of the communication link being used.

There is a complex problem that arises from networks that route messages from one node to the next. If the maximum transmission unit (MTU) for each hop is not the same, something must be done to resolve this imbalance. The problem here arises when one node transmits a message with a large MTU and when the message is relayed through one node over a hop with a small MTU. It will be very difficult for any node to know. In fact, the originating node may not even know which links to go to. All it knows is how to send a message to the next node. Thus, the protocol stack of each node must resolve the difference in MTU size on the links connected to that node. As described in the section " network layer 74 " described later herein, the network layer 74 has a message segmentation function. This should be used to divide the larger MTU into smaller MTUs. If the network layer does not want to do this at each node, an alternative is to implement an end-to-end connection and negotiate to determine what the maximum MTU should be across all nodes. However, this method incurs overhead and will not work for connectionless messages.

Data Link Layer (72)

First, the data link layer 72 among the three layers supported by the UIPC protocol stack 70 will be described below. The data link layer 72 connects data links between endpoints, is responsible for error-free data transmission between links, and provides the following functions.

1. Queuing by providing data priority.

2. Provides flow control to support smooth transmission and reception of data.

3. Support error-free data transmission.

4. Provides connection-less mode and connection-oriented mode, and connects and disconnects data links when connection-oriented.

5. In case of error, retransmission of the data is possible.

Table 4 below summarizes the connected mode primitives in the datalink layer 72 that are required at least for the connected data links and their descriptions, and Table 5 shows at least the required data link layer 72 for the disconnected data links. A summary of the connectionless mode primitives and their descriptions.

service Primitive Explanation Link setting DL-CONNECT request Initiate a connection with a remote end or a physical channel. DL-CONNECT indication Receive when the remote end starts connecting to you. DL-CONNECT response Triggered by the receiving side of the DL-CONNECT indication to accept the connection. DL-CONNECT confirm Notify the party that initiated the connection that the remote end accepted the connection. Normal data transfer DL-DATA request Used by the sender to send data. DL-DATA indication The receiving side takes this when receiving data. Unlink DL-DISCONNECT request Either side can initiate disconnection. There is no response. DL-DISCONNECT indication Received when the remote end disconnects.

<< Connected Mode Primitives at Datalink Layer 72 and Their Descriptions >>

service Primitive Explanation Link setting DL-DATA request Used by the sender to send data. DL-DATA indication The receiving side takes this when receiving data.

<< connectionless mode primitive at datalink layer 72 and its description >>

Next, the network layer 74 among the three layers supported by the UIPC protocol stack 70 will be described. Network layer 74 is responsible for routing messages between processes in interprocessor communication. Network layer 74 provides the following functions.

1. Provide message routing.

The message path is determined based on the network address N_ADDR. The network layer determines whether the message should be sent to the transport layer as a message of the received process or needs to be delivered through another interface to reach its final destination.

2. Supports segmentation and reassembly of messages.

When routing a message, when the maximum transport unit (MTU) of the data link layer delivers the message to different interfaces, the message is divided and reassembled.

3. Perform a stateless operation.

Since the network layer 74 does not support the message retransmission function, the network layer 74 performs a stateless operation without a state machine. Once the message is sent, the sent message is lost without being stored, regardless of whether it is received. If reliable transmission and reception between endpoints is required, this should be done at transport layer 76.

The UIPC 30 defines additional address-related primitives to have an interface that performs the functions of the network layer 74 described above. Table 6 below summarizes the primitives of network layer 74 and their descriptions.

service Primitive Explanation Normal data transfer N-DATA request Used by the sender to send data. N-DATA indication The receiving side takes this when receiving data.

<< Primary Primitives at Network Layer 74 and Their Description >>

Finally, the transport layer 76 among the three layers supported by the UIPC protocol stack 70 will be described below. The transport layer 76 is responsible for end-to-end communication between tasks. The transport layer 76 has the following functions.

1. Provide message routing.

Deliver the received message to the destination application. To this end, the transport layer 76 is responsible for establishing a routing table based on the application ID APP_ID. Access to the routing table is provided through an internal API for use in the UIPC API 60.

2. It provides a connection-less mode and a connection-oriented mode. The connectionless mode is used under the assumption that lower layers (eg, data link layers) guarantee end-to-end reliability in order to reduce overhead in communication. Do not check whether the destination application receives the message. In connected mode, a connection must be established between end-to-end applications in order to send and receive messages, which is similar in functionality to the sockets of Transmission Control Protocol (TCP). Because connection-oriented mode has additional overhead and complexity in establishing and tearing down the connection, it is desirable to use this mode when the reliability of the lower layer is not expected or when the demand for real-time communication is relatively high. .

3. Provides message multiplexing.

When a plurality of messages are received from various applications, the transport layer 76 combines the messages based on the source network address N_ADDR and delivers them to the corresponding application.

Table 7 below summarizes the connected mode primitives and their descriptions at the transport layer 76 required for external interface functionality, and Table 8 below describes the connected mode primitives at the transport layer 76 required for external interface functionality. And a summary of the description.

service Primitive Explanation Link setting T-CONNECT request Start a connection with the application The response is related to the queue handler. T-CONNECT indication Received when the remote end initiates a connection to an application. T-CONNECT response Triggered by the receiving side of the T-CONNECT indication to accept the connection. T-CONNECT confirm Notify the party that initiated the connection that the connection is now made. Normal data transfer T-DATA request The sender uses this to send data. T-DATA indication The receiving side takes this when receiving data. Unlink T-DISCONNECT request Either side can initiate disconnection. There is no response. T-DISCONNECT indication Received when the remote end disconnects.

<< Connected Mode Primitives in the Transport Layer 76 and Their Description >>

service Primitive Explanation Normal data transfer T-DATA request The sender uses this to send data. T-DATA indication The receiving side takes this when receiving data.

<< Unconnected Mode Primitives in the Transport Layer 76 and Their Description >>

Hereinafter, a schematic process of transferring message data from a source task to a destination task according to an embodiment of the present invention will be described with reference to FIGS. 1 to 6.

The source task calls the Uipc_SendMsg (data, destinationAddress) function from the UIPC API library that can contain the message data along with the network address N_ADDR and the application ID APP_ID of the destination task to deliver the message to the destination task. Accordingly, the task loads the destination task's network address N_ADDR and application ID APP_ID and a message into the Uipc_SendMsg (data, destinationAddress) function, and the UIPC API 60 determines whether the destination address, that is, the network address N_ADDR is the network address of its card. do. If the network address, which is the destination address, is the network address of the magnetic card, the message delivery to the destination will be performed by the intraprocessor communication UIPC. If the network address of the magnetic card is not the network address, the message delivery to the destination will be performed by the interprocessor communication. communication) will be performed by UIPC. The UIPC API 60 uses the OIA API library provided by the OIA layer 54 of FIG. 3 if the network address N_ADDR included in the Uipc_SendMsg (data, destinationAddress) function is the network address of its card, that is, the internal process communication UIPC. Deliver the message directly to the message queue of the destination task in the card. In the case of the internal process communication UIPC, the protocol stack 70 is not used. The destination task that receives the message uses the Uipc_RcvLoop () function based on the basic common control flow of the common task architecture shown in FIGS. 5 and 6 to receive the message, decode the message, process the message, and process the task separately. Perform control to perform functions.

If the network address N_ADDR, which is the destination address, is not the network address of the magnetic card, that is, the external process communication UIPC, the UIPC API 60 delivers a message to the message queue of the UIPC protocol stack 70 for routing to find an external destination. More specifically, the message is delivered to the delivery queue of the UIPC protocol stack 70. The forwarding layer 76 performs a transport layer-specific operation as described above with respect to the message received in the forwarding queue, processes the message, and delivers the message to the network queue of the network layer 74. The network layer 74 transmits the message received in the network queue to the data link queue of the data link layer 72 after performing the network layer-specific operation as described above. The data link layer 72 also performs a data link layer-specific operation as described above on the message received in the data link queue, and then the DIA layer of the destination card through the DIA layer (46 in FIG. 3) and the device driver 48. (46 in Fig. 3), the transfer is made to the device driver 48.

The message received by the DIA layer of the destination card (46 in FIG. 3) and the device driver 48 is transferred to the destination task through the data link layer 72, the network layer 74, and the transport layer 76 of the protocol layer 70. Is passed to. The destination card and the destination task can be known using the network address N_ADDR and the application ID APP_ID. Accordingly, the destination task uses the Uipc_RcvLoop () function provided by the UIPC API library to receive a message, decode a message, process a message, and separate a task based on the basic common control flow of the common task architecture shown in FIGS. 5 and 6. If processing is required, perform the control to perform the corresponding function.

Table 9 below is an example of a program for the Uipc_SendMsg (data, destinationAddress) function that is called and executed in a task from the UIPC API 60.

Table 10 below is an example of a program for the Uipc_RcvLoop () function that is called and executed in a task from the UIPC API 60.

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.

As described above, the present invention improves the ease of development and shortens the development period since all applications (processes) have a common structure through the structure that the UIPC is a common task architecture. In addition, through the combination of horizontal components and vertical components called common software platform, UIPC has the advantage of eliminating the task of changing the operating system and device in process communication.

Claims (17)

In a communication method for transferring a message from a source to a destination, Providing an operating system integrated interface function independently accessible to an operating system (OS) of a communication device by an operating system independent access (OIA) layer, Providing, by a device independent access (DIA) layer, a device integration interface function independently accessible to a physical device of the communication apparatus; Integrate interprocess communication (UIPC) layer to send messages from the source to the operating system independent access layer and the device independent using a common task architecture that has a common common control flow of destination information and tasks provided by the source task. And transmitting to the destination via at least one of the access layers. The method of claim 1, wherein the integrated inter-process communication layer, A UIPC application program interface (API) for providing an interface for the task to use a UIPC function, and determining external and internal process communication paths based on the destination information based on the destination information; And a UIPC protocol stack configured to perform inter-unit routing for external process communication among messages routed by the UIPC API. The method of claim 1, wherein the UIPC protocol stack, A data link layer that connects data links between endpoints and is responsible for transferring error-free data between links; A network layer that is responsible for routing messages between tasks in external process communication; An interprocess communication method comprising a transport layer that is responsible for end-to-end communication between tasks. The communication method as claimed in claim 1, wherein the destination information comprises an application identifier for identifying the task to be communicated with and a network address indicating a physical location of the task. The method of claim 4, wherein the network address comprises information of a rack-self-slot-port. 5. The method of claim 4, wherein the UIPC API is a shared library that can be used in any task. The inter-process communication method of claim 1, wherein the basic common control flow of the common task architecture is a task of performing a message reception, a message decode, a message processing, or another specific corresponding function when a task is processed separately. A communication device for transferring a message from a source to a destination, An operating system independent access (OIA) layer unit providing an operating system integrated interface function independently accessible to an operating system of a communication device; A device independent access (DIA) layer unit for providing a device integration interface function independently accessible to a physical device of the communication apparatus; Send a message from the source to the destination through at least one of the operating system independent access layer and the device independent access layer using a common task architecture having destination information provided by the source task and a basic common control flow of tasks. An inter-process communication device comprising: an integrated inter-process communication (UIPC) layer unit. The method of claim 8, wherein the integrated inter-process communication layer, A UIPC application program interface (API) for providing an interface for the task to use a UIPC function, and determining external and internal process communication paths based on the destination information based on the destination information; And a UIPC protocol stack configured to perform inter-unit routing for external process communication among messages routed by the UIPC API. The method of claim 8, wherein the UIPC protocol stack, A data link layer that connects data links between endpoints and is responsible for transferring error-free data between links; A network layer that is responsible for routing messages between tasks in external process communication; An inter-process communication device comprising a transport layer that is responsible for end-to-end communication between tasks. 9. The communication apparatus of claim 8, wherein the destination information comprises an application identifier for identifying the task to be communicated with, and a network address indicating a physical location of the task. 12. The communication device of claim 11, wherein the network address comprises information of a rack-self-slot-port. 10. The interprocess communication device of claim 9, wherein the UIPC API is a shared library that can be used in any task. The inter-process communication apparatus of claim 8, wherein the basic common control flow of the common task architecture is a task of performing a message reception, a message decode, a message processing, or another specific corresponding function when a task is processed separately. In a communication method for transferring a message from a source to a destination, Providing a common task architecture with a basic common control flow of tasks as an interface for integrated interprocess communication (UIPC), If the source task provides the message and the destination information using the common task architecture, determining whether the internal process communication message in the card or the external process communication message between the cards is based on the destination information; Transmitting a message to a queue of a UIPC protocol stack for routing if the message is an external process communication message between the cards; And wherein the internal process communication is a process of delivering a message to a message queue of a corresponding task in a card through an application program interface (API) library provided by an operating system independent access (OIA) layer. The method of claim 15, wherein the UIPC protocol stack, A data link layer that connects data links between endpoints and is responsible for transferring error-free data between links; A network layer that is responsible for routing messages between tasks in external process communication; An interprocess communication method comprising a transport layer that is responsible for end-to-end communication between tasks. A communication device for transferring a message from a source to a destination, An operating system portion that processes internal communications within the device independently of the operating system of the device, And a hardware portion for handling communications external to or from the apparatus, independent of hardware devices in the apparatus.