JP2007526544A - Communication protocol between processors - Google Patents

Abstract

  The inter-processor communication (IPC) protocol network includes at least one IPC client (102) and an IPC server (108). The IPC protocol provides a means for the IPC client (102) to register with the IPC server (108) and freely communicate with each other without being restricted by what software architecture, operating system, hardware, etc. To do. The IPC protocol according to one embodiment of the present invention provides a dynamic IPC node configuration in a server-based IPC communication management framework.

Description

The present invention relates generally to the field of electronics, and more particularly to interprocessor communication (IPC) protocols / networks.

  Most electronic systems are composed of many network elements (components) such as hardware and software forming the system. Most systems have layers that correspond to communication between different network elements themselves, as well as between the different components that form the network elements. This layer is commonly referred to as interprocessor communication (IPC).

  In recent years, several protocols for performing communication between processors have been introduced. An example of an IPC is a PCIAGP controller (PAC), which integrates a host-to-PCI bridge, a DRAM controller, and a data path and an Accelerated Graphics Port (AGP) interface. Another example of an IPC is the OMAP® platform. In any of these platforms, when all support is above the hardware level, many design degrees of freedom cannot be obtained, and there is almost no degree of design freedom at low-level components and the channel level (physical layer).

  For example, the PAC platform is closed and embedded in the TAPI layer of the operating system, and the IPC code is not accessible to developers. Therefore, these platforms do not extend to component systems, so not only cannot dynamically allocate IPC sources, but also cannot dynamically allocate IPC sources, hardware support functions, and multi-node routing.

  One problem in applications such as real-time processing applications is the requirement for service discovery on different processors and rapid processing of IPC requests. In these situations, one aspect of ensuring good support is to make up for the work of different applications, such as mobile applications (MA) in wireless communication devices, and support collaborative processing prior to sending data to the target MA. That is. This co-processing support usually requires a smart hardware port that can transport IPC data to the coprocessor and re-route that data back to the target MA. Another aspect of ensuring good support is by carrying specific software services to software components on different MAs using dedicated links (ports). Today, these methods are neither dynamic nor run-time configurable. Thus, there is a need in the art for an IPC protocol that can provide a solution to some of these shortcomings in the prior art.

  The features of the invention are set forth with particularity in the appended claims. The invention may best be understood with reference to the following description, taken in conjunction with the accompanying drawings. In the several figures of the drawings, like reference numerals represent like elements.

While the specification concludes with the claims that characterize the invention, the invention will become better understood when the following description is considered in conjunction with the drawings.
IPC provides the support necessary for different processors operating in the system to communicate with each other. For example, in a dual processor (or multiprocessor) wireless architecture used in a wireless communication device that includes an application processor (AP) and a baseband processor (BP), the IPC is necessary for the processors to communicate efficiently with each other. Provide support. The IPC provides this support without imposing any restrictions on the AP or BP design.

  Any processor that employs IPC as its interprocessor communication stack can coexist and operate as if the two are actually running on the same processor core sharing a common operating system and memory. As the use of multiple processors in a communication device is becoming standard, IPC provides reliable communication between different processors.

  IPC hardware provides a physical connection that connects different processors to the IPC network. In one embodiment of the invention, data packets are preferably transported asynchronously between different hosts. Processors connected to the IPC network are assigned their physical and logical addresses statically or dynamically (eg, IPC addresses). Also, since data packets can flow in any direction within the IPC network in one embodiment of the present invention, the packets need to carry the destination address of the processor that they are trying to reach. Also preferably, the packet is checked for errors using conventional cyclic redundancy check (CRC) techniques. Although the network activity of the IPC network of the present invention may be somewhat similar to that present on an Internet network using an IP transport layer such as a Transmission Control Protocol / Internet Protocol (TCP / IP) network, the IPC of the present invention It is not divided into small networks by gateways like TCP / IP networks.

  Next, in FIG. 1, an IPC network 100 according to an embodiment of the present invention is shown. IPC network 100 includes a plurality of IPC clients 102-106 and, as some examples, different IPCs such as shared memory 110, universal asynchronous receiver / transmitter (UART) 112, and universal serial bus (USB) 114. An IPC server 108 connected to IPC clients 102-106 using a physical link is included. Note that with the IPC of the present invention, the IPC clients 102-106 can negotiate with the current IPC server 108 to switch roles. When IPC clients 102-106 negotiate to become IPC servers and become new IPC servers, all remaining IPC clients are instructed to change the server's IP address if there is a change in the IPC server Is done.

In FIG. 2, an IPC stack 200 of an IPC server 108 (or IPC client 102-108) according to an embodiment of the present invention is shown. The IPC stack 200 is designed to be integrated under an operating system (OS) and to provide support for the interprocessor communication needs of component traffic. The IPC stack consists of three main layers: That is,
(1) IPC Presentation Manager (202): This layer is used to convert different data types between different system components (eg, software threads).

  (2) IPC Session Manager (204): This layer is a central repository for all incoming / outgoing IPC traffic between the IPC stack and all system components. The IPC session manager 204 has several functions. That is, assigning component IDs to join IPC components; determining whether IPC data needs to be hidden; routing IPC data, terminating IPC traffic; placeholders for IPC processors; providing IPC addresses, IPC Includes client assignment and authentication.

  IPC Transport Layer (208): Located in the IPC Session Manager (Layer) 204. The IPC transport layer 208 performs very basic cyclic redundancy checks for the purpose of transporting IPC data between different processors. In addition, the IPC transport layer 208 is responsible for routing IPC messages to their final destination on the IPC network 100. The transport layer routing function is only available on the IPC server.

  IPC router block (210): Transports IPC data to a destination component (not shown). The incoming IPC message carries, among other things, the origin component ID, such as voice and modem, and the IPC message OP code. Note that according to embodiments of the present invention, a unique OP code is assigned to each component / software thread such as voice and modem connected to the IPC network (see, eg, 502 in FIG. 5). The IPC session manager 204 relies on the router block 210 to send the IPC data to the correct component (s).

  (3) Device interface layer (206): Plays a role in managing the IPC physical-to-logical IPC channel. Its main function is to extract the IPC hardware completely so that the stack IPC is not dependent on the hardware. The device interface layer 206 manages the physical bandwidth of the immediate IPC link and supports all IPC logical channels. In the incoming path, the device interface layer 206 intercepts data from different physical channels 110-114 and passes them to the rest of the IPC stack. On the outgoing path, the device interface layer 206 manages the data loading of the IPC logical channels by sending them on the appropriate physical channel. The device interface layer 206 also concatenates IPC packets belonging to the same IPC channel and then sends them to the IPC hardware. Channel requirements are negotiated in advance between the IPC session manager 204 and the IPC device interface layer 206. The device interface layer 206 includes a hardware port, which provides a device interface with the IPC clients 102-106.

FIG. 3 shows an IPC component ID assignment routine. Any new component that wishes to participate in IPC communication must do so by first requesting an IPC identification number (ID) from its IPC session manager (eg, session manager 204) in step 302. Don't be. The local session manager (eg, the session manager located at the client to which the component is connected) then calls the IPC server session manager for the new IPC component and performs component ID assignment at step 304. According to an embodiment of the invention, the component ID is dynamic and is assigned by the session manager. The main IPC server location is most likely on the main AP. Each IPC node preferably has a unique IPC node ID, and the session manager maintains the following information for each participating IPC node in its database. That is,
IPC node type: For example, specific BP or AP, wireless local area network (WLAN) AP, etc.

IPC address: IPC node IPC address Data type: IPC node data type
OP Code List: This is a list of all IPC message OP codes that the component has applied for.

Component ID: List of all component IDs Next, FIG. 4 shows the IPC stack together with all the main IPC tables. The dynamic routing table 402 includes a node type, IPC address / port # information, a data type, and an application list. The component routing table 404 includes information for linking the OP code information and all the components applied for each specific OP code. Finally, the channel resource table 406 includes a link for each channel ID with a list of physical channel IDs.

  FIG. 5 shows a block diagram of how an IPC stack according to an embodiment of the present invention provides an IPC channel to components such as software threads (eg, voice, etc.). Component 502 first requests an IPC channel in step 504. The session manager shown in FIG. 5 negotiates a component request with the device layer in step 506 using the defined API. The device layer (device interface) then requests hardware resources such as the data channel 508. In response to the request, the session manager shown in FIG. 5 provides an IPC channel to the requester in step 510. Component 502 then sends the data on the assigned channel 508. Then, the device layer transfers data to the IPC network. The mapping from logical to physical channel ID is a function of the IPC device interface.

  Next, in FIG. 6, the first step in IPC client initialization is to send a registration request (step 606) between the IPC client 602 and the IPC server 604. In step 608, the IPC server 604 authenticates the request made by the IPC client 602. Thereafter, the IPC address is transmitted to the IPC client, and registration is completed in step 610. The IPC client session manager sends a copy of its dynamic routing table to the IPC server in step 612.

  The detailed steps performed during the IPC client initialization process are shown in FIG. In step 702, the client session manager (shown in the table as a session (client)) sends a setting request to the session manager of the IPC server (shown in the table as a session (server)). In step 704, authentication is requested by the session manager of the IPC server. Authentication between the IPC client and the IPC server is then performed at step 706.

  The parameter of the setting request includes a node type and a data type. In step 702, in response to the configuration request, the session server assigns an IPC address to the requester. If not, set up a dynamic routing table for the requester. In step 708, a setting instruction is sent to the requesting side. The setting instruction parameter includes the IPC address of the server and the newly assigned IPC address of the client.

  In response to receiving the setup indication, a component attached to the session client may request control / data from the client's session manager. In step 710, the session client sends a setting instruction confirmation message to the session server. The “setting instruction confirmation” message does not have a parameter when the setting instruction confirmation message is received in step 710, and the session server can start an IPC stream to the newly set session client. The session server then sends a setting update message to the session client in steps 712 and 714. This causes both session clients shown in FIG. 7 to update their respective dynamic routing tables (not shown) and in steps 716 and 718 send a configuration update confirmation message to the session server. When the setting update confirmation message is received, the session server confirms that all participating IPCs have been updated.

  When a packet is received by the IPC session manager, it comes in the form of data that includes the source component ID, destination ID, channel ID, and BP or AP type. The IPC session manager adds the destination component ID when the destination ID is not inserted. The IPC session manager also inserts an IPC address. It is the IPC session manager that finds the destination ID based on the received message OP code. The destination ID is based on a lookup table. This lookup table is dynamically updated each time a component subscribes to a new IPC message OP code (eg, a voice component subscribes to a voice message by sending a request to the IPC session manager).

  FIG. 8 shows a series of events during a typical destination ID discovery sequence between a component and its IPC session manager according to an embodiment of the present invention. In step 802, the component sends its source ID (no destination ID), destination BP or AP type, and IPC data including header and data. In step 804, the IPC session manager looks up the corresponding dynamic routing table and looks at the IPC data header OP code and the type of destination BP or AP to find the correct destination address. In step 806, the IPC session manager inserts the component's IPC address and sends it to the device layer.

  FIG. 9 shows typical steps performed when the IPC component is initialized. Once the BP is set by the IPC server shown in FIG. 9, components such as component 902 can subscribe to different services. In step 904, the components subscribe themselves to functions such as audio and video. The component application information is then sent to the IPC session manager to generate a component ID (if an ID has not yet been assigned) and to generate or update a dynamic routing table for a specific IP address. Performed (step 906). In step 908, the session manager updates the IPC server with the information from step 906. Upon receipt of the updated dynamic routing table at step 908, an update confirmation is sent by the IPC server to the IPC client at step 912. Once the server is called, the new dynamic routing table update is broadcast to all relevant processor steps 910.

  In FIG. 10, the same component initialization process consists of a component (client) 1002, a session (client), also known as client session manager 1004, and a session (also known as server session manager 1006) ( Server). The component setting request in step 1008 is transmitted by the component (client) 1002. In response to the request, the client session manager 1004 negotiates a device layer (not shown) and a logical channel. The client session manager 1004 also assigns a component ID and adds a new OP code list to its dynamic routing table (not shown). In step 1010, the client session manager 1004 sends a setup response including the component ID and channel ID as parameters. In response to the setting response, the component (client) 1002 receives the ID and channel ID from the session manager 1004 of the client.

  Once the client session manager 1004 responds to the setting request in step 1008 in step 1010, the client session manager 1004 sends a setting update request to the session server (server session manager) 1006 in step 1012. Send. The parameter of the setting update request is any new change made in the dynamic routing table (not shown). The server's session manager 1006 updates the dynamic routing table for that IPC address. In step 1016, the session manager 1006 of the server sends the setting update contents to all IPC clients (not shown). Meanwhile, in step 1014, a setting update instruction is sent to the session manager 1004 of the client. The server's session manager 1006 confirms that the server has updated its routing table with the changes sent.

  In the setting update message of step 1016 that includes the dynamic routing table as parameter (s), the session server 1006 updates the dynamic routing table and sends a setting update confirmation message in step 1018. The server then confirms that all participating IPCs have been updated.

  The IPC session manager determines the routing path for incoming and outgoing IPC packets. The route of the outgoing packet is determined by the IPC address of the component. If the destination address is found to be that of the local processor, the mapping of the IPC to the operating system (OS) is performed within the session manager. If the destination address is found to be for a local IPC client, the packet is sent to the IPC stack for further processing (eg, concealment). If the destination component is located on the same processor as the component sending the IPC packet, concealment is not required and the packet is passed through a normal OS message call (e.g., Microsoft message queue). Please note. In this way, components do not have to worry about modifying their message input method. All that is required is to change the way they write messages rather from OS-specific design to IPC calls.

  For incoming packets, if the destination address of the message is not equal to that of the IPC server, the incoming packet is routed to a valid IPC client. Incoming packet routing is handled by the session manager of the IPC server. Otherwise, the message is forwarded to the correct component or components depending on whether the component destination ID is set to a valid component ID or 0XFF.

  The IPC router block (eg, see IPC router block 210 in FIG. 2) transports IPC data to the destination component. The incoming IPC message carries, among other things, the origin component ID and the IPC message OP code for voice or modem. The IPC session manager relies on its component routing table to send the IPC data to the correct component (s). Both the dynamic routing table and the component routing table are updated by the IPC server / client.

  At startup, each component must register itself with its session manager to obtain an IPC component ID. In addition, incoming IPC messages such as voice and modem must be applied. This information is stored in the component routing table and used by the IPC session manager.

  As shown in FIG. 11, if a component (eg, software thread) 1102 sends its data request to the IPC session manager at step 1104, a check is made for the destination IPC node (eg, BP). If the IPC node does not support the IPC message OP code, an error response is returned to the component 1102. In addition to the error response, the IPC session manager returns updates for all IPC nodes that can receive that particular OP code. It is up to the component to determine to which of the IPC node (s) the message will be forwarded. The IPC session manager 1106 continues to conceal the data with the IPC header information, after which the data is determined by the session manager if the destination component is located in the IPC network, not the local processor, Sent over an IPC network.

  FIG. 12 shows an IPC data header 1202 according to an embodiment of the present invention. This header includes the source and destination IPC addresses, the source port, the destination port provided by the IPC router, the length and checksum information provided by the IPC transport, and the source IPC provided by the session manager. Components and destination IPC components are included. The message OP code, message length, and IPC data are provided by component 1204.

  A representative IPC data request according to an embodiment of the present invention is shown in FIG. In step 1302, the component sends an update request. Preferably, the component update parameters include a node type and an OP code. The component searches for a node type that supports the destination OP code. If the node type is equal to 0xFF, the session manager (shown as “session” in FIG. 13) continues to send component information to all node tables for all participating IPCs. If the OP code field is equal to 0xFF, the session manager shown in FIG. 13 continues to send the OP code list belonging to the specified node type to the component. On the other hand, if the OP code has a specific value, the session manager continues to send a true or false value to the component corresponding to whether the node type supports or does not support that specific OP code.

  In step 1304, the component update instruction is sent to the component. If the node type is equal to 0xFF, the node table is returned to the component. If the OP code field is equal to 0xFF, a list of OP codes is returned to the component. However, if the OP code is a specific value, a true or false message is returned. In step 1306, a component data request is made. The parameter for requesting component data includes a node type, an IPC message OP code, IPC message data, a channel ID, and a component ID. In the component data request, the session manager checks the node type and determines if the OP code is supported. If the node type does not support OP code, a component update instruction is sent in step 1308. However, if the node type supports OP codes, a data request is sent to the device layer in step 1310. The data request parameters include an IPC message, a channel ID, and an IPC header.

  The device layer schedules to send a data request message based on the channel ID. The device layer selects IPC hardware based on the port # header information. Once the data is populated, a data confirmation message is sent at 1312 to the session manager. In step 1314, the session manager continues to send a component data confirmation message to the component. The component may wait for confirmation and then send further IPC messages. Once the data confirmation is received, the component can continue to send the next IPC message.

  In step 1316, the device layer sends a data indication message including IPC message data and an IPC header. The session manager checks the destination IPC header of the message and if it is different from the local IPC address, the session manager sends (routes) the message to the correct IPC node. In step 1310, the session manager sends a data request to the device layer with a reserved channel ID. The session manager checks the destination component ID, and if it is equal to 0xFF, routes the message to all components that have applied for that OP code. In step 1318, the session manager sends a component data indication message and the component receives the IPC data.

  The IPC stack uses a reservation control channel for communication between all relevant IPC nodes. At startup, the session manager of the IPC server uses this link to broadcast a message to the IPC client and vice versa. During normal operation, this control channel is used to carry control information between all APs and BPs.

  In FIG. 14, control channels 1402-1406 arranged between the IPC stack (shown as IPC stack and IPC stack server) and the IPC hardware are shown. Also, the control channel information 1408 is transmitted together with the data packet 1410 when data is transmitted between different IPC hardware. Initially, the IPC client broadcasts its setting request on the IPC control channel. The IPC stack server receives the broadcast and responds with the IPC address for that client. This IPC address is associated with the dynamic routing table for that particular processor (AP or BP).

IPC application program interface (API)
Some of the APIs for the IPC protocol of the present invention are listed below.
1) From IPC session manager to component interface
CreateComponentInst ()
Create a component database in the IPC session manager. Information such as component data type (big endian vs. little endian) and message OP code subscription are used in the dynamic data routing table belonging to the IPC address.

OpenChannelKeep ()
Open the IPC channel. If it is available, ChannelGrant () is issued. The channel is reserved until CloseChannel () is issued. The component sends a QoS request to the IPC session manager. If the component ID has not yet been assigned, the IPC channel assigns it (eg, ChannelGrant ()).

OpenChannel ()
Open the IPC channel. If it is available, ChannelGrant () is issued. The parameters are the same as those used for the OpenChannelKeep () basic element.

OpenChannelWThru ()
Open the IPC channel. If it is available, ChannelGrant () is issued. This is a write request via the channel which means that the concealment is stopped on this channel (eg non-UDP_AT command).

CloseChanneI ()
Request to close the IPC channel. The component no longer needs the channel. The resource is then released.

ChannelGrant ()
A channel is given to the requester. The channel ID is assigned by the IPC session manager if it is not already assigned.

ChannelError ()
A channel error has occurred. The channel is closed and the requester is notified.
ChannelDataIndication ()
The requester is warned that data about the channel should be sent. This message is sent to the target component by the IPC presentation manager. This includes control channel data.

DataChannetRequest ()
The requester wants to send data about the opened channel. This includes control channel data.

ChannelClose ()
Request to close the IPC channel. The channel inactivity timer expires and the channel associated with the timeout is closed. This may be due to a channel error.

2) Between IPC session manager and IPC device interface
OpenChannel ()
Opens a logical IPC channel. If it is available, ChannelGrant () is issued. The IPC session manager sends a channel priority request to the IPC device interface manager.

CloseChannel ()
Request to close the IPC logical channel. The component determines that the channel is no longer needed.

ChannelGrant ()
A logical channel is provided to the requester.
ChannelError ()
A channel error has occurred. (For example, CRC failure or physical channel failure for incoming data)
ChannelDataIndication ()
The requester is warned that data about the channel should be sent.

DataChannelRequest ()
The requester wants to send data about the logical channel.
ChannelClose ()
Request to close the IPC channel. The channel inactivity timer expires and the channel associated with the timeout is closed. This may be due to a channel error.

3) From IPC session manager to IPC presentation manager
ChannetDataIndication ()
The requester is warned that data about the channel should be sent. Information is transferred to the target component in the correct data format.

4) IPC hardware / IPC stack interface
OpenChannel ()
Open physical IPC channel. If it is available, aChannelGrant () is issued. The IPC session manager sends a channel priority request to the IPC hardware.

CloseChannel ()
Request to close the IPC physical channel. The component no longer needs a channel.

ChannelGrant ()
A physical channel is provided to the requester.
ChannelError ()
A channel error occurred (eg, CRC failure or physical channel failure for incoming data).

ChannelDataIndication ()
The requester is warned that data about the channel should be sent.
DataChannetRequest ()
The requester wants to send data about the physical channel.

ChannelClose ()
Request to close the IPC channel. The channel inactivity timer expires and the channel associated with the timeout is closed. This may be due to a channel error.

FIG. 15 shows a block diagram of an electronic device such as a wireless communication device 1500 (eg, a mobile phone) having a baseband processor (BP) 1502 and an application processor (AP) 1504 that communicate with each other using an IPC network. The IPC protocol of the present invention provides communication between a plurality of processors in a system such as the communication device 1500. IPC allows registration of mobile application (MA) clients (eg, iDEN ^TM _WLAN) to MA servers such as dedicated communication system (PCS) applications, and two MAs within their own MA, It provides a means to communicate freely without any restrictions on what software architecture, operating system, or hardware it depends on.

  The IPC protocol dynamically adds an arbitrary IPC-compliant MA to the IPC link for communication. Thus, the IPC network is formed without any dependency on compile time, i.e. without any other software. The IPC of the present invention presents a standard way for software components to communicate with the IPC stack (not shown in FIG. 15), and the hardware under the stack is different for the components to communicate. Extracted so that a link can be selected.

  While the preferred embodiments of the invention have been illustrated and described, it will be clear that the invention is not so limited. Numerous modifications, changes, variations, substitutions and equivalents may occur to those skilled in the art without departing from the spirit and scope of the invention as defined by the appended claims.

The figure which shows the IPC network based on embodiment of this invention. FIG. 3 shows an IPC stack according to an embodiment of the present invention. FIG. 4 illustrates IPC component IPC assignment according to an embodiment of the present invention. The figure which shows the main IPC table based on embodiment of this invention. FIG. 4 shows channel allocation according to an embodiment of the present invention. FIG. 6 is a diagram showing highlighted steps involved in an IPC client initialization routine according to an embodiment of the present invention. FIG. 6 is another diagram highlighting and illustrating the steps involved during IPC client initialization according to an embodiment of the present invention. FIG. 3 is a diagram showing highlighted first level IPC concealment according to an embodiment of the present invention. The figure which highlights and shows the step performed at the time of IPC component initialization based on embodiment of this invention. The figure which highlights and shows the step performed at the time of the component initialization based on embodiment of this invention. The figure which shows the IPC data transfer between the IPC client and IPC server based on embodiment of this invention. The figure which shows the IPC data header based on embodiment of this invention. The figure which shows the step performed at the time of the IPC data request based on embodiment of this invention. The figure which shows the IPC network based on embodiment of this invention. The figure which shows electronic devices, such as a radio | wireless communication apparatus based on embodiment of this invention.

Claims (10)

An IPC server;
An IPC client connected to the IPC server,
The IPC client
A presentation manager;
A session manager connected to the presentation manager;
An IPC stack having a device interface connected to the session manager;
An interprocessor communication (IPC) network in which an IPC client uses an IPC stack to communicate with an IPC server. The IPC network of claim 1, wherein at least one component is connected to an IPC client. The IPC network of claim 2, wherein the presentation manager is used to paraphrase different data types between at least one component. The IPC network of claim 2, wherein the session manager assigns a part ID for at least one component. 5. The IPC network according to claim 4, wherein the part ID assigned to at least one component is dynamic and can be reassigned. The session manager further comprises an IPC router block having a component routing table for the session manager to send IPC data to one or more components linked with a particular opcode. The IPC network according to claim 2, wherein the IPC network is used. The IPC network of claim 1, wherein at least one IPC hardware is connected to the device interface, the device interface extracting at least one IPC hardware, whereby the IPC stack is independent of the hardware. A first processor acting as an IPC server and a second processor acting as an IPC client;
A method of performing IPC between a first processor and a second processor, comprising: communicating between the IPC server and the IPC client via an IPC network having an IPC stack in each of the IPC server and the IPC client. . The IPC stack in each of the IPC server and the IPC client is
A presentation manager;
A session manager connected to the presentation manager;
A device interface connected to the session manager;
The method of claim 8 comprising: A session manager in each of the IPC server and the IPC client has a dynamic routing table;
The method according to claim 9, further comprising: routing data sent from the IPC client to the IPC server appropriately using a dynamic routing table in each of the IPC server and the IPC client.

Images