KR100624679B1 - method and system for managing Inter Processor Communication channel in Embedded system - Google Patents

Abstract

In the present invention, the IPC manager for setting the IPC channel for each board at the time of booting the board in the embedded system to set the IPC channel using TCP or UDP socket between each board in the kernel layer, and the IPC manager for each board Provide API for service registration of upper application daemons to be run on the board of the server, and when the upper application daemon boots, the IPC administrator registers the service of the application daemon from the corresponding application daemon through the API and provides service information of the corresponding application daemon. And storing the control message receiving function provided by the application daemon as a callback function according to the service information, and when a message for any application daemon is received, the IPC manager calls the callback function bound by the service ID. Top Apps by Stable IPC channel management and control between LCRPCs by reducing the number of IPC channels that each application daemon must manage directly, including sending messages to the application daemons to perform IPC communication between application daemons, and having an IPC manager at the kernel layer. It can significantly reduce the amount of additional traffic for managing the IPC channel.

IPC, IPC Manager, Kernel, Application, Daemon, Relay, TCP, UDP

Description

Method and system for managing Inter Processor Communication channel in Embedded system             

1 is a conceptual diagram illustrating a conventional IPC channel management method performed between a switching control board and a subscriber board mounted in one system.

2 is a diagram illustrating the number of IPC channels according to IPC configuration.

3 is a conceptual diagram of an IPC channel management system according to the present invention;

4 is a diagram illustrating the number of IPC channels according to IPC configuration.

5 to 6 is a conceptual diagram illustrating the establishment of an IPC channel between different subscriber boards through a relay scheme.

7 is a conceptual diagram for explaining the IPC communication between the self using the relay function according to the present invention.

The present invention relates to an IPC (Inter Processor Communication) channel connection system and a method thereof, and more particularly, to communicate within or between subscriber boards in an embedded system using Linux as an operating system. The present invention relates to a system and method for setting and managing an IPC channel for performing the above.

Embedded systems are network systems (for example, router switches), rather than end-user devices such as personal computers (PCs), and typically use Linux as the operating system for system reliability.

In an environment using Linux as an operating system, independent software modules called daemons are run as many as necessary in the system to perform their respective tasks. These daemons communicate between different modules in the same subscriber board or between different types of modules in multiple subscriber boards.

Conventionally, these modules communicate with each other by directly opening a Transmission Control Protocol (TCP) or User Datagram Protocol (UDP) socket and connecting a full mesh method to a point-to-point through an IPC channel. have.

1 is a conceptual diagram illustrating a conventional IPC channel management method performed between a switching control board and a subscriber board mounted in a system.

Referring to FIG. 1, in general, there are three methods for communicating between application software (Application S / W) daemons in a system using Linux.

IPC Type A: MASTER / SLAVE (TCP, UDP)

IPC Type B: Full Mesh (TCP, UDP)

IPC Type C: Board Communication

In the IPC type A (3), the master daemon operates at the switch 2 and the slave daemons operate at the subscriber board 1 to communicate with each other, and the slave daemons do not need to communicate with each other. to be.

IPC Type B (4) is a case where each daemon independently needs to form IPC in full mesh form among other application daemons or other daemons.

IPC Type C (5) is a case where different daemons communicate on the same board. At this time, even in the same board as in the IPC type A form, the case in which the slaves are connected to a specific daemon as slaves may be mixed with other daemons in the same board. However, IPC type C forms generally use domain sockets.

If the application meshes should be full meshed between application daemons like the IPC B type Referring to FIG. 2, in order to open an IPC channel with one application daemon on each of 11 subscriber boards, it is necessary to use (11 x (11-1) / 2) ) = 55 IPC channels are required, and each daemon must manage 10 channels.

If the number of such application daemons is 10, the number of IPC channels in the system is increased by the number of daemons (11 x (11-1) / 2) x 10 = 550 IPC channels. In addition, the number of channels to be managed by TCP or UDP in the kernel of each subscriber board is also 10x10 = 100.

FIG. 2 shows the number of IPC channels according to IPC configuration in FIG. 1.

In the conventional method, the number of channels in each IPC method is as follows.

IPC Style A (dotted line)

Total System IPC channel: (LCRPC # -1) * Appd #

IPC Style B (solid line)

Total System IPC channel: (LCRPC # x (LCRPC # -1) / 2) * Appd #

IPC Style C (within one LCRPC)

A form using domain socket: Slave Appd #

Form B with domain sockets: (Appd # x (Appd # -1) / 2)

       (SWRPC is also included as the number of LCRPC)

As described above, according to the conventional IPC channel management method, each application daemon must manage a large number of IPC channels and generate a lot of traffic for maintaining them. In addition, there is a problem that greatly increases according to the number of applications and the number of LCRPC.

SUMMARY OF THE INVENTION The present invention has been made to solve such a conventional problem, and an object of the present invention is to provide an IPC channel management method for reducing the number of IPC channels that application daemons must manage and for reducing traffic for managing the IPC channel. .

In order to achieve the above object, the present invention reduces the number of IPC channels that each application daemon must manage by providing an IPC manager in the kernel, and provides stable IPC channel management between LCRPCs (Line Card Routing Processing Controllers). And control, and can reduce the amount of additional traffic for managing the IPC channel.

In addition, scalability can be increased by supporting the IPC relay function for the IPC service which does not change with the increase of the application daemon, the LCRPC, or the increase of the system shelf.

Hereinafter, the present invention will be described in detail with reference to the accompanying drawings.

3 is a conceptual explanatory diagram of an IPC channel management system according to the present invention, and FIG. 4 is a diagram showing the number of IPC channels according to IPC configuration.

Referring to FIG. 3, an SWRPC 10 mounted on a switching board and an LCRPC 20, 30 mounted on each subscriber board are shown. In the figure, application daemons 12, 13, 22, 23, 32, and 33 are executed on each board.

SWRPC (10) and LCRPC (20, 30) has an IPC manager (11, 21, 31) to manage the IPC channel in the kernel (Kernel) when the LCRPC (20 or 30) performs booting, other boards and IPC Set up the channel. In this way, the IPC channel required for the IPC connection by the application does not connect to the full mesh under the management of each application.

The IPC manager 21 of the LCRPC 20 will be described as an example. The IPC manager 21 reads ipc0 interface configuration information of a specific kernel from the LCRPC 20 to which it belongs, and automatically recognizes its own IP, and reads hardware-specific registry information connected to the backplane through a driver to read the SWRPC 10 or the like. The mounting state of the GRPC 30 is determined.

The IPC manager 21 of the LCRPC 20 sends a hello signal to the SWRPC 10 and the LCRPC 30. When the SWRPC 10 and the LCRPC 30 receive the hello signal, the LCRPC 20 opens a TCP or UDP socket with the SWRPC 10 and the LCRPC 30 to perform IPC channel connection establishment.

The property configuration setting for this is saved as a configuration information file in a specific directory of the kernel so that the operator can change it when necessary. This configuration information file includes an application program interface (API) for performing IPC, an IPC connection type (full mesh or relay or a mixture of both, TCP or UDP, etc.).

That is, since the IPC manager 21 of the kernel sees the mounting states of the SWRPC 10 and the LCRPC 30 and directly establishes an IPC channel with the IPC managers 11 and 31 of the SWRPC 10 and the LCRPC 30, You can quickly set up an IPC channel regardless of whether the host application is active.

The IPC managers 11 and 31 of the SWRPC 10 and the LCRPC 30 and the IPC manager 21 who have set up the IPC connection in the kernel use the service registration API so that each application daemon on the board can use the service registration. to provide. The application daemons use the service registration API provided from the IPC manager 21 of the board to which they belong to the IPC manager 21 to inform the IPC manager 21 of its service ID and various parameters (for example, buffer size, IPC connection type, etc.). Relay, full mesh, mixed)) to register the IPC service.

The IPC manager 21 having received the IPC service registration from the arbitrary application daemons 22 and 23 registers the service in the internal DB, and binds the control message receiving function provided by the application daemons 22 and 23 as the callback function. . Then, if it is recognized as a control message received by the corresponding service, the IPC manager 21 delivers the message to the corresponding higher application daemons 22 and 23 by calling a callback function bound for each service or for each ID.

In addition, the IPC manager 21 provides APIs for transmitting IPC messages to the respective application daemons 22 and 23, so that the application daemons can send messages to any application daemons 22, 23, 32, and 33 of any LCRPCs 20 and 30. Can be sent.

The initial definition of API that can be provided by the IPC manager 21 is as follows.

 ipc_send (service id, service card, message, message size);

When the application daemons 22 and 23 call this function, the IPC manager 21 inserts a service ID and a message size into the header of the IPC message, and adds a message to the service card. Send to the IPC channel connected to the IPC manager (21, 31) of the LCRPC (20, 30) specified in.

The IPC managers 21 and 31 of the counterpart LCRPCs 20 and 30 that have received this recognize the service identifier, check the integrity of the message through the size, and then check the corresponding service identifier. Calls the callback function that was bound when registering, and delivers the message to the upper application daemon (22, 23, 32, 33).

On the other hand, when performing IPC C-type IPC connection establishment for communication in the same LCRPC / SWRPC (20, 30, 10), IPC manager (11, 21, 31) has a shared memory (Share Memeory) use. That is, since the application daemons 12, 13, 22, 23, 32, and 33 communicate with each other in the same LCRPC / SWRPC 20, 30, and 10, binding is performed when the corresponding service identifier is registered. Call the callback function that you did and pass the message to the upper application daemon. In other words, rather than sending a message to a TCP or UDP socket, you simply call the other service's callback function after saving the message in a specific area.

The IPCMgr Sublayer is a sub-layer of the IPC manager 21 and provides services for reliable communication at the upper end according to the characteristics of Layer1. If UDP is used, an example is to provide a function to guarantee retransmission for reliable UDP communication.

As such, each board mounted on the backplane by the IPC managers 11, 21, and 31 in the kernel of each board has already been configured for IPC connection. The daemon only needs to register IPC services with its IPC managers (11, 21, 31). Then, the IPC managers 11, 21, and 31 register and store the service ID of the application daemon that has performed IPC registration. If a desired service ID is desired in any message, the callback corresponding to the service ID is used. Call the function to pass the message to the application daemon.

Therefore, even when the application daemon is added, since it is not necessary to form an IPC channel full-mesh point-to-point under the management of the application daemon, referring to FIG. 4, the total number of IPC channels in the system is reduced as follows.

IPC Style A

Full system IPC channel: (# of LCRPC -1)

IPC Style B

Full system IPC channel: (# of LCRPC x (# of LCRPC -1) / 2)

IPC Style C (within one LCRPC)

       no socket connection

FIG. 5 and FIG. 6 are conceptual views illustrating setting of IPC channels between different subscriber boards through a relay scheme.

Referring to FIG. 5, for example, the slave application daemons 22, 23, 32, and 33 of the LCRPCs 20 and 30 do not directly exchange messages, but the master application daemons 12 and 13 of the SWRPC 10. ) And the slave application daemons 22, 23, 32, and 33 of each LCRPC 20 and 30 connect and exchange messages with each other, the LCRPC 20 passes through the SWRPC 10 through the relay function to the LCRPC 30. You can communicate with

When the IPC channel of the entire embedded system is set to relay without full mesh, all IPC channels are connected to the SWRPC 10 only, and IPC messages between the LCRPC 20 and 30 are relayed to the SWRPC 10 through the relay function. ) Relays in the IPC manager (11).

This relay function can be used to connect the self to each other when the self is extended.

FIG. 7 is a conceptual diagram for explaining IPC communication between self using a relay function. FIG.

Referring to FIG. 7, Self A and Self B establish IPC channels through respective IPC managers between SWRPC and LCRPCs in the self, thereby enabling IPC communication between daemons running in each SWRPC and LCRP.

In addition, Self-A's SWRPC and Self-B's SWRPC enable IPC communication by setting IPC channels among IPC managers.

In this state, since each LCRPC (1-11) of Self A and Self B has their own SWRPC and IPC channels, the SWRPC in the Self Self and the SWRPC in the Other Self are randomly selected. IPC channel can be set through LCRPC and relay function.

This feature is useful when SWRPCs establish IPC channels between themselves, and communicate with each other's applications on LCRPCs of different self, and can increase the overall IPC scalability of the system.

According to the present invention, by reducing the number of IPC channels that each application daemon must manage directly, by having an IPC manager in the kernel layer, stable IPC channel management and control between LCRPC, and additional traffic for managing the IPC channel The amount of can be significantly reduced.

In addition, the scalability of the system can be increased by supporting the IPC relay function for the IPC service which does not change with the increase of the application daemon, the LCRPC, or the increase of the system itself.

Claims (9)

In an embedded system including a plurality of boards, When booting each board, the IPC channel is configured in the kernel layer by using an IPC manager of a kernel layer for each board, using a Transmission Control Protocol (TCP) or UDP (user datagram protocol) socket between the boards. To do that, Providing, by the IPC manager, an API (Application Program Interface) for registering services of upper application daemons running on the board; Upon booting a higher application daemon, the IPC manager registers a service from the application daemon through the API, stores service information of the application daemon, and the application daemon calls back a function according to the service information. Binding a control message receiving function provided by When each IPC manager receives a message, calling the callback function bound by the corresponding service ID to deliver a message to a higher application daemon, IPC channel management method of the embedded system comprising the step of performing IPC communication between application daemons . The method of claim 1, wherein the setting of the IPC channel comprises: The IPC administrator reads the configuration information and recognizes the board IP. Reading hardware-specific registry information attached to the backplane to determine the mounting status of other boards; Transmitting a hello packet to a board mounted according to a mounting state of the other board; An IPC channel management method of an embedded system that performs the steps of configuring an IPC channel at a corresponding board and kernel layer receiving a hello packet. The method of claim 1, wherein performing the IPC communication between the application daemons comprises: Providing, by each board, an API for transmitting a message from a higher application daemon by the IPC manager; A higher application daemon using the API to transmit a message to the IPC manager to be sent to an application daemon belonging to any board; The IPC manager interprets the API and transmits the API to an application daemon of a corresponding board. The method of claim 3, wherein the API for sending a message of the application daemon, A method of managing an IPC channel of an embedded system that includes information about a service identifier of an application daemon, a board on which the application daemon is running, a message, and a message size. The method of claim 3, wherein the transmitting to the application daemon of the corresponding board comprises: If the application daemon to transmit the message is on different boards, the message is transmitted to the IPC manager of the board through the IPC channel established using the other board and the TCP or UDP socket, and the IPC manager of the other board IPC channel management method of the embedded system to send the message to the application daemon. The method of claim 3, wherein the transmitting to the application daemon of the corresponding board comprises: If the application daemon to transmit the message is located on the same board, the IPC channel of the embedded system to store the message in a specific area of the shared memory, and to call the application daemon callback function to send the message to the application daemon How to manage. In an embedded system including a switching control board and a plurality of subscriber boards, The switching control board drives an IPC manager for IPC channel configuration at boot time of the board to set an IPC channel at the kernel layer of each subscriber board using TCP or UDP sockets at the kernel layer, and transmits a message from an arbitrary subscriber board. Upon request, relay the message to the other subscriber's board, Each of the subscriber boards drives an IPC manager for setting an IPC channel for each board upon booting of the board, sets up the switching control board and the IPC channel at the kernel layer, and sends a message to the switching control board through the IPC channel set at the kernel layer. IPC channel management system for transmitting to the IPC communication with the other subscriber board by the function of the relay of the switching control board. In a self-contained embedded system comprising a switching control board and a plurality of subscriber boards, The switching control board, when booting the board, drives the IPC manager to establish the IPC channel and the switching control board of the counterpart self using TCP or UDP sockets at the kernel layer, and from any subscriber board to the board of the counterpart self. When a message transmission request is made, relaying the message to the kernel layer to the switching control board of the counterpart self, Each of the subscriber boards drives an IPC manager for each board when the board is booted, establishes an IPC channel with the switching control board using TCP or UDP sockets at the kernel layer, and sends a message to the subscriber board of the other party. If present, the IPC transmits the message through the IPC channel set between switching control boards in the same shelf and performs IPC communication with the counterpart subscriber board by a function of a relay between the switching switchboard and the counterpart switching control board in the same shelf. Channel management system. delete

Images