CN1326066C - Communication method and its device during process - Google Patents

Abstract

An inter-process communication method for delivering messages from a starting point to an end point, the method comprises the steps of: providing a unified interface function of an operating system at an operating system independent access (OIA) layer, and the unified interface function of the operating system is for the operating system of the communication device Can be independently accessed; at the device independent access (DIA) layer, a unified interface function of the device is provided, and the unified interface function of the device can be independently accessed for the physical device of the communication device; and at the unified inter-process communication (UIPC) layer , through at least one of the OS-independent access layer and the device-independent access layer, using information about the endpoint provided by the endpoint task, and using a common task structure based on the basic common control flow of the task, from the starting point Pass the message to the destination.

Description

Inter-process communication method and device thereof

technical field

The present invention relates to a communication system implementing inter-process communication (IPC). More specifically, the present invention relates to a method of Unified Inter-Process Communication (UIPC) and devices thereof, which are independent of communicating physical devices and operating systems.

Background technique

Inter-process communication uses various methods to implement inter-process message communication, such as pipes, semaphores, message queues, or shared memory. These methods are all OS-based. Therefore, it is possible to provide a variety of inter-process communication methods based on the operating system. In other words, the interprocess communication method depends on the operating system. Therefore, each time the inter-process communication and the process are to be realized, the application software needs to be changed accordingly according to the operating system used in the communication system. Likewise, assuming inter-process communication between hardware devices, different physical device drivers are used for different physical devices provided. Thus, for a process using a device driver, the inter-process communication function will be changed according to the kind of device driver used.

Such inter-process communication methods in communication systems depend on operating systems and physical devices. As a result, overhead occurs repeatedly when operating systems and physical devices in the communication system change. This not only deteriorates the reusability and portability of the software, but also increases the burden of time and cost on the development of new communication systems for related industries.

Contents of the invention

Therefore, an object of the present invention is to provide a flexible unified inter-procedural communication method and device thereof, which are independent of the operating system and physical devices of the communication system.

Another object of the present invention is to provide a unified inter-process communication method and apparatus thereof capable of performing inter-process communication with high repeatability and high portability regardless of the operating system used in the communication system.

Yet another object of the present invention is to provide a unified inter-process communication method and device thereof independent of physical devices of the communication system,

Still another object of the present invention is to provide a communication method regardless of the type of communication method (for example: Asynchronous Transfer Mode (ATM), Internet Protocol (IP), Synchronous Digital Hierarchy (SDH), etc.) used in the communication device. A communication device that transmits messages from a starting point to an end point.

For realizing above-mentioned object, provide a kind of communication method from starting point to terminal point, this method comprises the steps: provide a unified operating system interface function in operating system independent access (OIA) layer, this unified operating system interface function is to communication The operating system of the device is independently accessible; a device uniform interface function is provided at the device independent access (DIA) layer, and the device uniform interface function is independently accessible to the physical device of the communication device; at the unified inter-process communication layer, through At least one of the OS-independent access layer and the device-independent access layer transmits messages from the start point to the end point.

Another aspect of the present invention is to provide a communication device for transferring messages from a starting point to an end point, the device includes: an operating system independent access layer for providing a unified interface function of the operating system, and the unified interface function of the operating system has a significant impact on the communication device. The operating system is independently accessible; the device independent access layer that provides the unified interface function of the device, and the unified interface function of the device is independently accessible to the physical device of the communication device; the unified inter-process communication layer is used to access the layer independently through the operating system and at least one of the device-independent access layers to pass messages from the origin to the destination.

Another aspect of the present invention is to provide a method of interprocessor communication for passing messages from a start point to an end point, the method comprising the steps of: providing a common task structure with a basic common control flow of a task, as a unified An interface for interprocess communication; if an originating task uses the common task structure to provide a message and information about the destination, based on the information about the destination, it is determined whether the message is an interprocessor communication message within a card or between cards Inter-processor communication message between cards; if the message belongs to the inter-processor communication message between cards, then pass this message to a queue of the unified inter-process communication protocol stack for routing; if the message belongs to a process within a card Inter-device communication messages, then pass the message to a message queue of the corresponding task in the card through the application program interface library provided by the independent access layer of the operating system.

One thing to note in embodiments of the present invention is that terms like "process", "application", or "task" are used interchangeably to refer to tasks that exist on top of the unified interprocess communication layer .

Description of drawings

The above and other objects, features and advantages of the present invention will become more apparent through the following detailed description in conjunction with the accompanying drawings.

Fig. 1 is a schematic diagram of a network exchanging messages between each rack according to a preferred embodiment of the present invention;

2 is an exemplary diagram of a detailed configuration of a communication system to which unified inter-process communication is applied according to a preferred embodiment of the present invention;

3 is a block diagram of a common software platform including unified inter-process communication as a component according to a preferred embodiment of the present invention;

4 is a block diagram representing a unified inter-process communication configuration for each card (each unit) according to a preferred embodiment of the present invention;

Figure 5 is a flow diagram of a process using a common task structure, i.e., a basic control flow diagram of a task;

FIG. 6 is a block diagram illustrating a unified inter-process communication application program interface (API) configuration and common task structure according to a preferred embodiment of the present invention.

Detailed ways

Hereinafter, a preferred embodiment of the present invention will be described with reference to the accompanying drawings. In the following description, well-known functions or constructions are not described in detail since they would obscure the invention in unnecessary detail.

The following foreign language documents disclose the background and additional information of the present invention, which are helpful for understanding the principle of the present invention.

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

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

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

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

Figure 1 is a schematic diagram of a network exchanging messages between each shelf, embodying the principles of the present invention. The network topology depicted in the figure includes an element management system (EMS) 8, a system controller shelf 10 equipped with a plurality of cards including card 12, a second rack equipped with smart devices 6 and a plurality of cards including card 22a. An expansion shelf 201, a second expansion shelf 20b equipped with a plurality of cards including the card 22b, and a third expansion shelf 30c equipped with a plurality of cards including the card 22c.

Referring to FIG. 1, since the third expansion shelf 20c can communicate with the system controller shelf 10, although the communication between the third expansion shelf 20c and the system controller shelf 10 can physically pass through the second expansion shelf 20b, according to According to the principle of the present invention, there is a virtual direct channel between the third expansion shelf 20c and the system controller shelf 10 .

FIG. 1 is mainly for explaining a network configuration to which the unified inter-process communication function of the present invention is applied. Although it will be described in detail later with reference to FIG. 2, a rough description of the unified interprocess communication of the present invention is that it supports message exchange between tasks on each card, message exchange between tasks on different cards on the same shelf, and some Message exchange between tasks of a particular rack and attached intelligent devices 6 (eg DSL modems and unified access devices). It should be noted that the functions described above are based on the assumption that the system controller shelf 10 decides, if necessary, the routing of messages to be delivered between two shelves. This simplifies the overall protocol and reduces the overhead associated with the protocol as the Internet Protocol handles a more general network topology. Likewise, messages can be sent on the path between the element management system 8 and a particular card on a rack. As far as unified interprocess communication is concerned, the element management system 8 works like another rack.

FIG. 2 illustrates a detailed configuration of a communication system to which the unified inter-process communication function of the present invention is applied.

The expansion shelf 20i in FIG. 2 is one of the plurality of expansion shelves described in FIG. 1, and the system controller shelf 10 is a shelf for controlling the plurality of expansion shelves 20a, 20b, and 20c. Each shelf 10 , 20i includes a plurality of control cards 14 , 16 , 24 and 26 , and a main control card 12 , 22 for controlling the plurality of control cards 14 , 16 , 24 and 26 . For each control card 14, 16, 24, 26 and master control card 12, 22 a unified interprocess communication 30 is provided as part of a common software platform 32 for interprocess message communication. Unified interprocess communication 30 is a means of providing a channel for interprocess message communication between processes on a card, between cards, on a shelf, and between shelves. Each unified interprocess communication 30 is connected to a process (application task) like P1, P2 shown in FIG. 2 .

As shown in FIG. 2, the unified interprocess communication 30 has three formats: "process communication within a card (interprocessor communication)", "process communication between cards within a rack (interprocessor communication)", " Process communication between racks (interprocessor communication)". In particular, "process communication between cards within one rack (interprocessor communication)" and "process communication between racks (interprocessor communication)" require a separate physical device driver.

FIG. 3 is a block diagram of a common software platform 32 that includes, in part, unified interprocess communication 30 as a component embodying the principles of the present invention.

The common software platform 32 depicted in Figure 3 is intended to provide generic and common functionality applicable to many different communication systems. A common software platform 32 exists in each of the cards 12, 14, 16, 22, 24 and 26 in the units 10, 20 illustrated in Figure 2, and its components are divided into functional units.

As shown in FIG. 3 , the common software platform 32 can be roughly divided into components arranged horizontally (hereinafter, referred to as horizontal components) and components arranged vertically (hereinafter, referred to as vertical components). More specifically, levels such as common agent 40, common operations management and maintenance (OAM) 42, unified interprocess communication 30, device independent access layer 46, physical device drivers 48, real-time operating system (RTOS) 50, and hardware 52 Components are common functional blocks required by various communication systems, and their specific technical functions are provided by vertical components. On the other hand, vertical components such as Asynchronous Transfer Mode (ATM) 56, Synchronous Digital Hierarchy (SDH) + Pseudo-Synchronous Digital Hierarchy (PDH) 58, Voice over Packet (VoP) 160 are required according to the type of communication system technical function blocks. Similar to before, the technical functions of the vertical components are provided by the horizontal components, and they differ according to the type of communication system. For example, common operation management and maintenance 42 among other horizontal components is providing alarms, collecting performance data, managing operation data especially for management and maintenance of the communication system. So, if Common Operations Management and Maintenance 42 does some ATM-related processing, such as providing an ATM-related alarm or collecting operational data for an ATM-related communication system, then a vertical device, precisely It is Asynchronous Transfer Mode 56 that provides these data. In the case of using or adding a commercial software, the function blocks 50, 162, 164, 166, 168 and 170 with oblique lines in Fig. 2 are used.

The upper modules, ie, from "common agent 40" to "common operation management and maintenance 42" shown in Fig. 3 are all dependent on the application of software.

Generally, various communication systems include a common software platform 32 as shown in FIG. Functional form to develop.

The specific functions of the horizontal components of the common software platform 32 shown in FIG. 3 are explained below:

1. Operating system independent access layer 54

It provides an operating system unified interface function for implementation of application and unified inter-process communication 30 so that an operating system (OS) can be independently accessed without depending on any operating system such as a real-time operating system 50 . As a result, portability of applications and UPC 30 is enhanced. In other words, software applications and UPC 30 can be reused by different operating systems in different communication systems.

2. Device Independent Access Layer 46

By hiding the more specific parts of the physical device driver 48, a common model is provided for various devices, that is, the device uniform interface function, which enables independent access to different devices without depending on the device. This is the benefit of the device independent access layer 46, now the application and UIPC 30/operating system independent access layer 54 can be reused even if the hardware chip like the hardware 52 shown in FIG. 3 is changed.

3. Unified Interprocess Communication 30

Depending on the operating system used for inter-process communication, the underlying software such as the real-time operating system 50, and the underlying hardware 52, by hiding detailed information about the inter-process communication mechanism, when changing the operating system to implement an application, it is not particularly necessary separate tasks.

4. Public operation management and maintenance 42

Provides a common method for the operation, management and maintenance of various types of communication systems.

5. Public proxy software 40

For more efficient network operation in the communication system, an interface is provided to the external network operating system.

In short, the common software platform 32 exists primarily to enable a software structure that is reusable for different kinds of communication systems and is independent of the operating systems and hardware devices. Also, the unified inter-process communication 30 is a component of the common software platform 32 for implementing the inter-process message communication method.

So far, the public software platform 32 has been described for better understanding of the present invention. From now on, the configuration of the unified inter-process communication 30 and its functions will be explained in detail.

Similar to FIG. 2 , UPC 30 operates within each of the control units, ie control cards 12 , 14 , 16 , 22 , 24 and 26 . It mainly provides a message communication function between processes in a card, on a rack, or in different racks.

Message communication through the unified inter-process communication 30 of the present invention requires an application identifier (ID) APP_ID and a network address N_ADDR. The application identifier APP_ID is an identifier for distinguishing the relevant process for communication, and the network address N_ADDR is an address value indicating the physical address of the relevant process. The network address N_ADDR has a size of 4 bytes and includes rack-shelf-slot-port (rack-shelf-slot-port) information. Therefore, the physical address of the corresponding process can be easily obtained by using the network address N_ADDR. The network address N_ADDR only uses a rack and slot (where the card is fixed) identifier for the unified interprocess communication 30, the cabinet and port identifiers are used for other purposes. Referring to FIG. 2 again, as an example, a message is transferred from the process 1 (P1) of the main control card 12 of the system main control shelf 10 to the process 1 (P1) of the main control card 22 of the expansion shelf 20i. Assume that the identifier of the system controller shelf 10 is "1", the identifier of the expansion shelf 20 is "2", and the slot identifiers of the main control cards 12 and 22 are "22". First, the start point and end point application identifiers APP_ID are P1 respectively. Then, the start network address N_ADDR is the hexadecimal number "0x00010200" (cabinet-rack-slot-port), and the end network address N_ADDR is also the hexadecimal number "0x00020200" (cabinet-rack-slot-port). When comparing the network address N_ADDR and the application identifier APP_ID with the network protocol, it is found that the network address N_ADDR approximately corresponds to an Internet Protocol address, and the application identifier APP_ID corresponds to a Transmission Control Protocol (TCP) port number.

The following are the functions of the unified inter-process communication 30 embodying the principles of the present invention.

UPC 30 delivers a bidirectional message to tasks anywhere in the network components.

Unified Inter-Process Communication 30 allows applications to pass messages asynchronously. The API gives an immediate response without blocking.

Unified Interprocess Communication 30 allows tasks to pass messages and respond synchronously when they are temporarily out of work.

UPC 30 abstracts an underlying physical transport mechanism.

Unified Inter-Process Communication 30 provides a mechanism for broadcasting messages.

UPC 30 enables the lower-level UPC protocol to be changed without changing the higher-level protocol, and vice versa.

UPC 30 detects link-to-link based transmission errors and reselects erroneous packets. This means that the data link layer of the protocol used to control each connection should be able to make reliable connections.

The Common Unified Interprocedural Communication API is used for inter-processor communication and external process communication.

Common Unified Interprocedural Communication 30 splits and reassembles large volumes of messages.

UPC 30 provides a mechanism for outputting error correction.

UIP parameters are also configurable during runtime.

UC 30 provides a mechanism to assign a maximum transmission unit to each link.

UC 30 supports links with variable maximum transmission units.

Unified Inter-Process Communication 30 supports message prioritization for real-time sensitive messages.

UC 30 is operating system independent.

UIPC 30 enables messages to pass transparently from the controller and ultimately to the device affixed to the card.

Although UPC 30 transfers messages from origin to destination, it acts as an application as far as the contents of the messages are concerned. Thus, no presentation mechanism is provided for specific system messages. The presentation mechanism of the system message is similar to a presentation layer, but the UPC 30 according to the present invention does not include a presentation layer because the UPC 30 is for a real-time protocol.

FIG. 4 is a diagram showing the configuration of the unified inter-process communication 30 per card (each unit), embodying the principle of the present invention. It should be understood that in the figures, "task" and "process" are used interchangeably.

Referring to FIG. 4 , the UPC 30 included in each card (unit) can be roughly divided into a UPC API 60 and a UPC protocol stack 70 . In this way, it is possible to more effectively distinguish between inter-processor communication requiring the UIP stack 70 and inter-processor communication not requiring the UIP stack 70 . Specifically, inter-processor communication is a case where its network address N_ADDR is not itself, so that a message should pass from its card to another card, and inter-processor communication is another case, Wherein, its network address N_ADDR is itself, so that the message is directly delivered to a corresponding task inside the card. Meanwhile, the UPC API 60 is provided in the form of a library to be called from a task. In general, tasks call the UPC API 60 to send and receive messages, and communicate with the UPC protocol stack 70 to control interprocessor communication messages.

First, the unified inter-process communication API 60 according to the preferred embodiment of the present invention will be explained in further detail with reference to FIG. 4 .

Unified Interprocess Communication API 60

The UPC API 60 is a common library that can be shared by any kind of tasks (processes), and provides an interface related to each internal operation provided by the UPC 30 . In other words, the UPC API 60 provides an interface that enables any type of application task to use the UPC function. In addition, the unified inter-process communication API 60 determines the inter-process and intra-process communication paths based on the network address N_ADDR and the application software identifier APP_ID. In the meantime, the UPC API 60 does not use the UPC protocol stack 70 for inter-processor communication. Furthermore, the UPC API 60 searches out the network address N_ADDR, tries to find the physical address of the corresponding application task (process), and, if inter-processor communication is involved, sends the message through the The operating system independent access application program interface provided by the independent access layer 54 is directly delivered to the message queue of a corresponding task (process). On the other hand, if interprocessor communication is involved, the UPC API 60 passes the message to a message queue of the UPC protocol stack 70 to route the message to the destination.

One of the most important functions that UPC API 60 provides to tasks (applications) is a common task structure of common software platform 32, which enables tasks to use UPC. The main functions of the public task structure according to the present invention are listed below:

1. The developer does not need to redesign the task structure.

2. Execute an asynchronous callback function on a caller's task.

3. Developers do not have to work on the integration of common components (eg, common operation management and maintenance) and applications.

4. Inter-task communication based on the message queue method is now possible because this is a common inter-process communication mechanism provided by all operating systems.

Among the components of the common software platform 32 (horizontal components + vertical components), especially the software applications of the upper block of the unified inter-process communication layer 30, for example, the common agent task 40, the common operation management and maintenance task 42, etc., by using This was achieved successfully through a common task structure embodying the principles of the present invention. FIG. 5 is a basic common control flow of a task (process) using the common task structure having the above-mentioned four functions.

Referring to Figure 5, a task waits for a message using a queue. A task receives a message asynchronously (S100), decodes and analyzes the received message (S102), and performs message processing (S104). If separate processing is required, the task processes other specific applications (S106), and then waits for a message back to step 100.

Table 1 and Table 2 show the results of comparison between the traditional inherited task structure and the common task structure of tasks with a basic common control flow as shown in FIG. 5 according to the present invention. As illustrated in Table 1, since the traditional inherited task is not a public structure, it will be individually designed into different formats according to developer and task operations. So, even though the task is worth considering overhead during development, it has to be redesigned. In contrast, as shown in Table 2 below, the common task structure according to the present invention implements a basic common control flow with tasks as shown in FIG. 5, where system overhead is avoided. In this way, the development time can be shortened considerably.

[Table 1]

<Inheritance Task Structure>

performanceTaskMain(){/*Task initialization and component library initialization*/performanceTaskInit();/*Receive messages on the main queue forever*/

FOREVERrcvMsg(myQ，&pMsg) switch(msgType) case PERFORMANCE_TYPE_MSG calls the execution component library to process the message case MY_MSGS processes the message end switch/*Other processing before receiving the next message*/}/*taskMain ends*/

[Table 2]

<common task structure>

taskMain(){/*Task initialization and component library initialization*/Uipc_InitTaskContext();/*Create a message queue that can be used by a task for UIPC*/Uipc_CreateQueue(MY_APP_ID, &hMyQueue);/*Uipc_RcvLoop() of a task in Waiting to receive messages on this queue*/Uipc_SetmainQueue(hMyQueue);/*Registers that will receive messages of a specific class*/Uipc_RegisterMsgHandler(MY_MSG_CLASS,&MyMessageHandler);/*Uipc_RcvLoop() will process the message, when there is no message in the queue , call the registered idle handler (handler)*/Uipc_RegisterIdleHandler(&MyIdleHandler)/*receive messages on the main queue forever*/Uipc_RcvLoop();}

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

FIG. 6 is an exemplary diagram of the configuration and common task structure of the UPC API according to the present invention. Referring to Figure 6, the main task of each card generates a global information table similar to that shown in Table 3 within the unified interprocess communication, and generates service tasks, task 1 and task 2, which perform their own specific functions (Example: alarm task, operation task, etc.).

[table 3]

task identifier application identifier A pointer to the dynamic message handler table for the task A pointer to the static message handler table for the task A pointer to the dynamic message class table for the task Free message handler pointer for the task The waiting time used in Uipc_RcvLoop()

To explain more about the UIPC global information table within UPC, the global information table contains information about all tasks on a particular card. Each entry in the global information table is a task control block (TSB). It is assumed that each task control block has uniformly specified information.

The first field of the task control block is the 'task identifier'. The second field of the task control block is the 'Application Identifier', which is the 'Application Identifier' of the task's 'Main Queue'.

Each task has a dynamic message handler table, a static message handler table, and a dynamic message class table. Whenever a task calls Uipc_RegisterOneTimeApi(), an entry is created in the dynamic message handler table. Such tasks in the list of dynamic message handlers are not fixed. In fact, the entry is deleted whenever a response is received from the API. This dynamic message handler table can be implemented by using a balanced binary tree. Whenever a task creates Uipc_RegisterMsgHandler(), an entry is created in the static message handler table. Here, the static message handler table is dedicated to an application program interface of a supervisor (supervisor). Unlike the entries in the dynamic message handler table, the entries in the static message handler table are fixed. Thus, the static message handler table can be implemented using an array.

Whenever a task calls Uipc_GenerateTempMsgClass(), the message class returns to the above task and any necessary updates are made in the dynamic message class table to make a particular message class busy. Also, whenever the task calls Uipc_FreeTempMsgClass(), UPC makes the necessary updates to the dynamic message class table to make a particular message class available for a subsequent use. The dynamic message class table is implemented as another array.

The global information table includes a pointer for each of the above tables. Furthermore, the global information table includes pointers to the 'idle message handler' functions of the tasks. The global information table also includes the latency, which is assumed to be used only in Uipc_RcvLoop() of each task. Within the Uipc_RcvLoop API, latency is checked against the global info table. Since every task has access to the global information table, a designated semaphore signal protects the global information table. This semaphore is generated during Uipc_InitCardContext().

Referring again to FIG. 6, in the UIP, Uipc_InitCardContext() is assumed to initialize UIP 30 according to the present invention. Uipc_InitCardContext( ) run by the main task specifies a block of memory to use UIP 30 and creates a data internal structure. Here, Uipc_InitCardContext() should be called only once for each card (unit).

A further explanation will be given regarding the common task structure of the slave tasks task1 and task2, which are spawned by the master task.

Within the common task structure, Uipc_InitTaskContext() specifies a global information table and registers the assignment to the global table The entry's global information table. Also, Uipc_InitTaskContext() should only be called once for each task.

Uipc_CreateQueue(TASK1_APP_ID, &Task1Queue) creates a queue to help each task to receive messages using unified interprocess communication. Uipc_CreateQueue(TASK1_APP_ID, &Task1Queue) registers a created queue ID into the queue table for the task's application ID.

Uipc_SetmainQueue(hTask1Queue) sets a corresponding queue as a main queue for receiving messages. Once registered as the main queue, it will be used as a message waiting queue inside Uipc_RcvLoop().

Uipc_RegisterMsgHandler(TASK1_MSG_CLASS, &Task1MessageHandler) registers the message (message class) used to process the message received from a task and the handler function (handler function) used for message processing into a global information table. They are used to process messages received inside Uipc_RcvLoop().

When a task wants to perform functions other than message processing, Uipc_RegisterIdleHandler(&Task1IdleHander) registers the handler function into a global information table, and when no message is received from Uipc_RcvLoop(), it executes a given other work.

The process of a task receiving messages from the main queue and processing these received messages is carried out in Uipc_RcvLoop(). It never responds, but internally executes an infinite loop. Also, it does things like message reception/message decoding/message processing/additional work.

The UIPC protocol stack 70 of the UIPC 30 will now be described in detail with reference to FIG. 4 .

Unified Interprocess Communication Protocol Stack 70

The UPCP stack 70 is used for inter-processor communication. Interprocessor communication occurs when the UPC API 60 passes messages using a queue from the UPC protocol stack 70 . The UIP stack 70 requires a routing library for determining the routing of messages based on the application identifier APP_ID and the network address N_ADDR. For routing, the UPC API 60 uses the application identifier APP_ID and the network address N_ADDR to call the API provided by the routing library and decide which type the received message belongs to, i.e., an interprocessor message or Processor internal messages. If it is an interprocessor message, the UPC API 60 sends the message to a queue in the UPC protocol stack 70 . Typically, this protocol stack conforms to the Open Systems Interconnection (OSI) model, but in the present invention, it does not support all 7 layers, but only 3 of them. More specifically, the unified interprocess communication protocol stack 70 embodying the principles of the present invention supports a data link layer 72 , a network layer 74 , and a transport layer 76 . The data link layer 72 has a data link queue, while the network layer 74 has a network queue, and the transport layer 76 has a transmit queue.

The operation of those three layers will be explained in detail later. However, before describing each layer in further detail, it is necessary to introduce some general requirements that apply to each layer. The purpose of doing this is to realize the above-mentioned layers.

First, the header of each layer should include a protocol discriminator. The discriminator indicates whether a particular protocol or a combination of protocols is accompanying the message. Typically, the protocol discriminator includes 2 or 3 bits in the header. This implementation can be done without changing other protocols. For example, a received message processed by the network layer 74 has a protocol discriminator in its network layer header that indicates which protocol module is to process the message next. If UPC intends to support a transport layer protocol like Transmission Control Protocol or User Datagram Protocol (UDP), the Protocol Discriminator informs Network Layer 74 whether the message is to be delivered to the Transmission Control Protocol or User Datagram Protocol module . In this case, the User Datagram Protocol refers to the Internet standard network layer, transport layer, and session layer protocols that provide datagram services. Similar to Transmission Control Protocol, User Datagram Protocol is also a connectionless protocol on top of the Internet Protocol.

Some protocol layers depend on other layers, or they cannot be used independently. For example, D-channel Link Access Procedure (LAPD), a data link layer protocol, relies on the physical high-level data link control (HDLC) layer. Here, "D channel link access procedure" means a link access procedure on D channel.

Each layer has a message priority. Therefore, messages or segments (segments: if a message is long enough, it is segmented) with high priority are delivered before other messages and segments. Preferably, two priorities, ie, "normal" and "superior" priorities are introduced in the present invention, because further divisions would only confuse things more. However, another allocation of priorities can be made at any time if necessary.

In addition, each layer can define specific control messages, which are exchanged between the same layer at an endpoint. These control messages negotiate protocol parameters with a layer or allow a layer to enforce a flow control.

The characteristics and responsibilities of each protocol layer are described below. Each part has a list of primitives provided by each layer. These primitives are assumed to expose an external interface to additional software (ie, the next protocol layer). They do not have to interpret the actual messages communicated between the two endpoints. Also, the definition of these messages and their state machinery needs no explanation, as they will be defined when a more concrete design is built.

These primitives will be named according to the terminology of the International Telecommunication Union (ITU) and will be divided into "request", "response", "indication" and "confirmation" as shown below.

Request: It means a function that a layer should support, usually the next layer of the layer calls it to request a certain operation.

Response: It is invoked by a remote or remote terminal when a command requesting a response is received. Thus, the requester of the above 'request' will receive the acknowledgment.

Indication: It is a notification that something has happened. Usually, it indicates the next level up, or indicates that such commands are received by code generated later. Most 'indications' are the result of a remote (remote) terminal initiating an operation via a 'request'.

Acknowledgment: It is a confirmation of the response to the 'request'.

Every primitive has data that has a specific primitive associated with it. The mechanism for passing primitives between layers will not be described in detail here since it is part of the detailed design of the layers.

On the other hand, it is very important to be aware of the need to define a Maximum Transmission Unit (MTU). The maximum transmission unit defines a maximum message size. Any message smaller than the maximum size can be delivered as a single message.

In fact, determining the maximum transmission unit is part of an application design. So, it's not defined as part of Unified Interprocedural Communication. However, to specify the maximum transfer unit, UPC defines an internal API that is only visible to UPC components. The determination of the maximum transmission unit is based on the request to execute an application, the number of hops the message is supposed to take (hop: the segment between one router and another router), and the communication link speed currently in use.

There can be many complexities in the network used to direct the path of messages from one node to the next. For example, if the maximum transmission unit of each hop is not the same, some measures must be taken to resolve this imbalance. The problem is that problems often arise when a node delivers a message with a large MTU, and the message is broadcast by another node one hop later with a small MTU. Of course, for a specific node, it is very difficult to know the maximum transmission unit of each link that the message passes through. In fact, an originating node might not even know which link the message will be delivered to. All the starting node knows is how to send the message to the next node. Therefore, each node's protocol stack should be able to overcome the difference in the maximum transmission unit size of the link connected to a corresponding node. The network layer 74 has a segmentation function, which will be described later in the "Network layer 74" section. It will be used to fragment a large MTU into smaller MTUs. If the network layer does not perform segmentation, an end-to-end connection can be attempted as an option, where all nodes participate in the discussion of determining the maximum transmission unit. Unfortunately, this approach incurs overhead and is ineffective for connectionless messages.

Data Link Layer 72

Among the three layers supported by the UIP stack 70, the data link layer 72 is explained first. The data link layer 72 connects a data link between endpoints, and is responsible for error-free data transmission between links, and provides the following operations.

1. Queuing by providing data priority.

2. Support the smooth sending and receiving of data by providing a process control.

3. Support error-free data transmission.

4. Provide a connectionless mode and a connection-oriented mode, and perform data link connection/release in the connection-oriented mode.

5. When there is an error, the corresponding data can be resent.

Table 4 is a content and their description of the primitives of the connection-oriented mode on the data link layer 72, which requires at least connection-oriented data links. Shown in Table 5 is a content and their description of the primitives of the connectionless mode on the data link layer 72, which requires at least a connectionless data link.

[Table 4]

<Primitives of Connection-Oriented Mode on Data Link Layer 72 and Their Descriptions>

Serve Primitives describe link building DL-CONNECT request It initiates a connection to a remote endpoint or to a physical channel. DL-CONNECT instruction It is received when a remote endpoint initiates a connection to this DL-CONNECT response It is called by the DL-CONNECT indication receiver to accept the connection DL-CONNECT confirmation Notifies the originator of the connection that a remote endpoint has accepted the connection. normal data transmission DL-DATA request Used by the transmitter to transmit data. DL-DATA instruction is sent to the receiver for data reception link release DL-DISCONNECT request Either sender or receiver can initiate connection release. No response required. DL-DISCONNECT instruction When the remote endpoint releases the connection, it is accepted.

[table 5]

<Primitives of connectionless mode on data link layer 72 and their description>

Serve Primitives describe link building DL-DATA request The sender uses it for data transfer. DL-DATA instruction The receiver uses it for data reception.

The network layer 74 of the three layers supported by the unified interprocess communication protocol stack 70 is explained below. Network layer 74 is responsible for the routing of messages between processors for inter-processor communication. The function of the network layer 72 is described below.

1. It provides a message routing function.

It determines message routing based on network address N_ADDR. More specifically, the network layer decides whether a message should be sent to a transport layer as a process message, or should be passed through another interface to reach its final destination.

2. It supports message segmentation and reassembly.

When a message is routed, it is fragmented and reassembled if the message is sent to an interface with a different maximum transmission unit than the data link layer.

3. It performs a stateless operation.

Since the network layer 74 does not support message retransmission functionality, it performs a stateless operation with no state mechanism. When a message is sent, no matter whether the receiver receives the message or not, the sent message is not saved and will eventually disappear. It needs to be placed in the transport layer 76 if it is required to send/receive messages more reliably between endpoints.

UPC 30 defines additional address-related primitives to have an interface that can perform the operations of network layer 74 described above. Table 6 below is the content of the primitives of the network layer 74 and their descriptions.

[Table 6]

<primitives and their descriptions on the network layer 74>

Serve Primitives describe Ordinary data transfer N-DATA request The transmitter uses it for data transmission N-DATA indication The receiver uses it for data reception

Finally, the transport layer 76 of the three layers supported by the UIP stack 70 is explained. In general, the transport layer 76 is responsible for end-to-end communication between tasks. The function of the transport layer 76 will be explained more below.

1. It provides message routing function.

It sends received messages to the destination application. Finally, the transport layer 76 is responsible for building a routing table based on the application identifier APP_ID. The routing table may be formed through an internal API used by the UPC API 60 .

2. It provides connectionless mode and connection-oriented mode. The connectionless mode is used under the condition that the lower layer (for example, the data link layer) guarantees end-to-end reliability to reduce the system overhead in the communication process. Therefore, in connectionless mode, as in the data link layer 72, there is no check at all whether the target application has received the message. On the other hand, in the connection-oriented mode, the end-to-end application connection should be established so that messages can be sent/received. In terms of function, it is similar to a socket of Transmission Control Protocol. In addition, because the connection-oriented mode has additional system overhead and is very complicated when establishing/releasing connections, it is best not to use this mode too often, especially when a lower layer has relatively low reliability and when the When there are not many requests for real-time communication requests.

3. It provides message multiplexing function.

When receiving a large number of messages from many applications, the transport layer 76 combines the messages based on the network address N_ADDR of the origin and delivers the combined messages to a corresponding application.

Table 7 is the content and description of the primitives of the connection-oriented mode at the transport layer 76, which are required by an external interface function. Table 8 is the content and description of the primitives of the connectionless mode in the transport layer 76, which are required by an external interface function.

[Table 7]

<Primitives of connection-oriented mode in transport layer 76 and their description>

Serve Primitives describe link building T-CONNECT request It initiates a connection to an application. Its responses are associated with queue handlers. T-CONNECT instruction It is received when a remote endpoint initiates a connection to an application. T-CONNECT response It is called by the T-CONNECT indication receiver to accept the connection. T-CONNECT confirmation It notifies the originator of the connection that a remote endpoint has accepted the connection. Normal data transfer T-DATA request It is used by the transmitter for data transmission. T-DATA indication It is used by the receiver for data reception. link release T-DISCONNECT request Either sender or receiver can initiate connection release. no response required T-DISCONNECT instruction It is accepted when the remote endpoint releases the connection.

[Table 8]

<primitives and descriptions of connectionless mode in transport layer 76>

Serve Primitives describe normal data transmission T-DATA request The transmitter uses it for data transmission. T-DATA indication The receiver uses it for data reception.

A general procedure for transferring message data from an initiating task to a terminating task embodying the principles of the present invention will now be described with reference to FIGS. 1 to 6 .

To deliver a message to a destination task, the initial task calls the function Uipc_SendMsg(data, destination address), which can provide the network address N_ADDR, application identifier APP_ID and message data of the destination task from the UPC API. Thereafter, the task loads the network address N_ADDR, the application software identifier APP_ID, and the message data of the target task into the function Uipc_SendMsg (data, destination address), and the UIP 60 determines the destination address, that is, the network Whether the address N_ADDR is the same as the network address on its own card. If it is the same, that is, if the destination address, or network address, is the network address on its own card, then inter-processor communication unifies inter-process communication to deliver the message to the destination. However, if the destination address is not the same as the network address on its own card, then the inter-processor communication unifies the inter-process communication to deliver the message to the destination. If the network address N_ADDR loaded into the function Uipc_SendMsg(data,destination address) is the network address on its own card, i.e., the unified interprocess communication for processor internal communication, then the unified interprocess communication API 60 is passed through the operating system The independent access application programming interface library directly transfers messages to a message queue of the purpose task in the card, and the operating system independent access application programming interface library is provided by the operating system independent access layer 54 in FIG. 3 . In cases involving inter-processor communication and inter-process communication, the protocol stack 70 is not used at all. Meanwhile, since the message has been received, by using the Uipc_RcvLoop() function, based on the basic common control flow of the common task structure shown in Fig. 5 and Fig. 6, the destination task controls such as message reception, message decoding, message processing and following Related operations such as other processing performed by tasks alone.

On the other hand, if the destination address, or network address N_ADDR, is not the same as the network address on its own card, that is, if the communication between processors is uniform interprocess communication, then the UIP 60 The message is passed to a message queue of the UPCP stack 70 for routing search to an external destination. More specifically, the UPC API 60 passes the message to a delivery queue of the UPC protocol stack 70 . The transport layer 76 then directs the transport layer specific operations for the messages sent to the delivery queues, processes these messages, and sends the processed messages to a network queue of the network layer 74. Network layer 74 directs network layer specific operations for sending to network queues and passes these messages to a data link queue of data link layer 72 . Similarly, the data link layer 72 guides the specific operation of the data link layer for messages sent to the data link queue, and passes these messages to the device independent access layer (please refer to 46 in FIG. 3 ), through the device independent The access layer (please refer to 46 in FIG. 3 ) is sent to the device driver 48 on the destination card, and sent to the device driver 48 .

Afterwards, the message sent to the device independent access layer (please refer to 46 of FIG. 3 ), device driver 48 of the destination card is sent to the destination task through the data link layer 72 of the protocol layer 70, the network layer 74 and the transport layer 76. Likewise, the network address N_ADDR and the application identifier APP_ID can be used to identify the destination card and the destination task. Correspondingly, by using the Uipc_RcvLoop() function provided by the unified interprocess communication API library, based on the basic control flow of the common task structure shown in Figure 5 and Figure 6, the purpose task controls such as message reception, message decoding, message Related operations such as processing and other processing performed individually by tasks as requested.

Table 9 below illustrates a program for the Uipc_SendMsg(data, destination address) function, which is executed in a task, and which has been called by the UPC API 60.

[Table 9]

Uipc_S endMsg(data, destinationAddress){if(destinationAddress==myAddress)/*communication between the unified process of the task in the card (unit) {1. Get the destination queue identifier->DestQueue2. Use the DestQueue to transfer the data through the independent access of the operating system Send to another task->Oia_WriteQByld(DestQueue, AppDAta); }else /*UPC for tasks between cards (units){

Send the data to the "unified inter-process communication stack transfer task queue" ->us_AL_Transmit_TL(AppData){Oia_WriteQByld(TransportQueue, AppData);

Similarly, Table 10 below illustrates a section of the Uipc_RcvLoop() function, which is executed in a task and has been called by the UPC API 60 .

Table 10

Uipc_RcvLoop(){Uipc_Rcv(){Oia_ReadQByld(AppQueue，AppData)->Receive a message}Uipc_ProcessMsg(AppData){Decode and process the message}}

Finally, the unified inter-process communication of the present invention enables all applications (processes) to have a common structure through a structure called a common task structure, and finally reduces the burden and shortens the development time of a new communication system. In addition, the benefit of a common software platform, the combination of horizontal components and vertical components, is that additional work will not be done due to changes in operating systems and devices in the future.

While the invention has been shown and described with reference to preferred embodiments thereof, it will be understood by those skilled in the art that modifications may be made without departing from the spirit and scope of the invention as defined in the appended claims. Various changes in form and detail.

Claims (12)

1. A method of interprocess communication for transferring messages from a starting point to an end point, the method comprising the steps of: In the operating system independent access layer, a unified interface function of the operating system is provided, and the unified interface function of the operating system can be independently accessed for the operating system of the communication device; In the device independent access layer, a unified interface function of the device is provided, and the unified interface function of the device can be independently accessed for the physical device of the communication device; At the UPC layer, the UPC API provides an interface that enables tasks to use the UPC functions and determine the paths for intra-processor and inter-processor communications based on information about endpoints, and UPC The communication protocol stack passes through the data link layer for connecting a data link between the endpoints and transferring error-free data between the links, the network layer for routing messages between tasks during communication within the processor, and the user interface. A transport layer for end-to-end communication between tasks to route unit-to-unit communications within a processor using messages whose routing is determined by the UPC API, thereby accessing through OS-independent access layers and device-independently At least one of the layers, passing messages from a starting point to an ending point. 2. The method of claim 1, wherein the information about the endpoint includes an application identifier for identifying a corresponding task to communicate with and a network address for locating the corresponding task A physical address of . 3. The method of claim 2, wherein the network address includes cabinet-rack-slot-port information. 4. The method of claim 2, wherein the UPC API is a common library applicable to all tasks. 5. The method of claim 1, wherein the basic common control flow of the common task structure includes message reception, message decoding, message processing, and a task to perform related functions upon request. 6. An apparatus for interprocessor communication passing messages from an origin to an end, the apparatus comprising: The operating system independent access layer is used to provide a unified interface function of the operating system, and the unified interface function of the operating system can be independently accessed by the operating system of the communication device; The device independent access layer is used to provide a device unified interface function, and the device unified interface function can be independently accessed by the physical device of the communication device; and a unified inter-process communication layer for passing messages from an origin to an end point through at least one of an OS-independent access layer and a device-independent access layer; The unified interprocess communication layer includes: Used to provide an interface so that tasks can use the unified process communication function and also use A unified inter-process communication application program interface based on determining the path of intra-processor communication and inter-processor communication based on information about the endpoints; and A unified interprocedural communication protocol stack for routing between units for inter-processor communication using messages whose path is determined by a unified interprocess communication API, the unified interprocess communication protocol stack comprising: The data link layer connects a data link between the links and is used to transmit error-free data between the links, the network layer is used for the routing of messages between tasks during the internal communication of the processor, and the end-to-end communication between tasks. The transport layer for communication. 7. The apparatus of claim 6, wherein the information about the endpoint includes an application identifier for identifying a corresponding task communicating with it and a network address for locating the corresponding task A physical address of . 8. The apparatus of claim 7, wherein the network address includes cabinet-rack-slot-port information. 9. The apparatus of claim 6, wherein the UPC API is a common library applicable to all tasks. 10. The apparatus of claim 6, wherein the basic common control flow of the common task structure includes message reception, message decoding, message processing, and related functions that a task is to perform upon request. 11. A method of interprocessor communication for passing messages from a starting point to a destination, the method comprising the steps of: Provide a common task structure with a basic common control flow of a task, as an interface for unified inter-process communication; If an initiating task uses the common task structure to provide a message and information about the destination, based on the information about the destination, determine whether the message is an interprocessor communication message within a card or an interprocessor communication message between cards ; If the message is an inter-processor communication message between cards, then through the Unified Interprocedural Communication Protocol stack included for connecting a data link between the endpoints and for transferring error-free data between the links layer, a network layer for routing messages between tasks during inter-processor communication, and a transport layer for end-to-end communication between tasks to pass the message to a queue in the UPC stack for processing. routing; If the message belongs to an inter-processor communication message in a card, then the message is delivered to a message queue of a corresponding task in the card through the API library provided by the independent access layer of the operating system. 12. An apparatus for interprocessor communication passing messages from an origin to an end, the apparatus comprising: an operating system block for independently handling internal communications within the device; and A hardware block for independently handling external communications from the outside to the device or from the device to the outside.

Images