U.S. patent application number 13/698826 was filed with the patent office on 2013-03-14 for method and system for efficient inter- process communication in a high availability system.
This patent application is currently assigned to HUGHES SYSTIQUE INDIA PRIVATE LIMITED. The applicant listed for this patent is Shilpa Mahna Bhatnagar, Anil Kumar. Invention is credited to Shilpa Mahna Bhatnagar, Anil Kumar.
Application Number | 20130067488 13/698826 |
Document ID | / |
Family ID | 44511141 |
Filed Date | 2013-03-14 |
United States Patent
Application |
20130067488 |
Kind Code |
A1 |
Kumar; Anil ; et
al. |
March 14, 2013 |
METHOD AND SYSTEM FOR EFFICIENT INTER- PROCESS COMMUNICATION IN A
HIGH AVAILABILITY SYSTEM
Abstract
A system, method and associated data structures for providing
inter process communication where IPC endpoints may get relocated
during the operation of the system. A device in accordance with the
principles of the present invention comprises IPC filter rule
management process, IPC filter rule lookup process, IPC filter rule
table and plurality of IPC endpoints and a network interface for
connectivity, wherein IPC filter rule management process creates,
deletes and updates the entries in IPC filter rule table, and
wherein IPC filter rule lookup process finds the matched rule and
takes the forwarding actions. A system in accordance with the
principles of present invention for providing inter process
communication where IPC endpoints may get relocated during the
operation of the system comprises a plurality of preferred devices
which in an embodiment may be connected with plurality of
functional peers through plurality of network interfaces.
Inventors: |
Kumar; Anil; (New Delhi,
IN) ; Bhatnagar; Shilpa Mahna; (New Delhi,
IN) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Kumar; Anil
Bhatnagar; Shilpa Mahna |
New Delhi
New Delhi |
|
IN
IN |
|
|
Assignee: |
HUGHES SYSTIQUE INDIA PRIVATE
LIMITED
New Delhi
IN
|
Family ID: |
44511141 |
Appl. No.: |
13/698826 |
Filed: |
May 19, 2011 |
PCT Filed: |
May 19, 2011 |
PCT NO: |
PCT/IN11/00352 |
371 Date: |
November 19, 2012 |
Current U.S.
Class: |
719/313 |
Current CPC
Class: |
G06F 9/546 20130101 |
Class at
Publication: |
719/313 |
International
Class: |
G06F 9/54 20060101
G06F009/54 |
Foreign Application Data
Date |
Code |
Application Number |
May 19, 2010 |
IN |
1166/DEL/2010 |
Claims
1. A device for providing inter process communication where IPC end
points may get relocated during the operation of the device
comprising: a. one or more network interfaces; b. an IPC filter
rule management entity to create, update and delete IPC filter
rules as IPC message flows are created, relocated or deleted; c. an
IPC filter rule table to store IPC filter rules; d. an IPC filter
rule lookup entity to associate an IPC filter rule in the IPC
filter rule table, forwarding an IPC message in accordance with the
forwarding actions of the IPC filter rule; and e. one or more IPC
end points.
2-37. (canceled)
38. The device as claimed in claim 1, wherein the filter rule
comprises a filer mask, a filter value and a forwarding action
comprising a forwarding address and an interface.
39. The device as claimed in claim 38, wherein the filter mask
comprises any combination of standardized or non-standardized
fields of the IPC message that uniquely identify an IPC message
flow.
40. The device as claimed in claim 38, wherein the filter value
comprises values of the fields selected by the filter mask to
identify all IPC messages of an IPC message flow.
41. The device as claimed in claim 40, wherein the field value
comprises of a scalar value, a range or a wild card.
42. The device as claimed in claim 1, wherein the IPC filter rule
table is implemented as a hash table, a ordered table or an
unordered table.
43. The device as claimed in claim 38, wherein the forwarding
address can be an Internet Protocol address or any other form of
address assigned to identify a IPC endpoint.
44. The device as claimed in claim 1, wherein the IPC message is
forwarded to the address through the interface provided in the
forwarding action of the associated filter rule.
45. The device as claimed in claim 1, wherein the IPC message is
dropped when the forwarding address is not specified in the
associated rule.
46. The device as claimed in claim 1, wherein the IPC message is
forwarded to the IPC endpoint using an implementation specific
manner to the forwarding action address in the associated filter
rule when the forwarding action interface is configured as
"lo".
47. A system for providing inter process communication where the
IPC end points may get relocated during the operation of the
system, comprising one or more interconnected devices that each
comprise: a. one or more network interfaces, b. an IPC filter rule
management entity to create, update and delete IPC filter rules as
IPC message flows are created, relocated or deleted, c. an IPC
filter rule table to store IPC filter rules, d. an IPC filter rule
lookup entity to associate an IPC filter rule in the IPC filter
rule table, forwarding an IPC message in accordance with the
forwarding actions of the IPC filter rule, and e. one or more IPC
end points
48. The system as claimed in claim 47, comprising one or more
interfacing units for communicating with peer nodes.
49. The system as claimed in claim 47, wherein the IPC endpoints of
an IPC message flow are located within the system.
50. The system as claimed in claim 47, wherein at least one of the
IPC endpoints of an IPC message flow is located outside the
system.
51. The system as claimed in claim 47, wherein one or more system
events comprising addition, deletion, failure and mobility of an
IPC endpoint and system scalability are used by the IPC filter rule
management entity to update the IPC filter rule table.
52. A method for inter-process communication between a source and
destination IPC endpoints, comprising: a. adding, deleting, and
updating one or more IPC filter rules; b. waiting for and receiving
one or more incoming or outgoing IPC message; c. determining the
rule associated with the IPC message; and d. forwarding the IPC
message according to the forwarding action of the IPC filter
rule.
53. The method as claimed in claim 52, wherein the outgoing IPC
messages are received on the device comprising the source IPC
endpoint of the IPC message.
54. The method as claimed in claim 52, wherein the incoming IPC
messages are received on the device comprising the destination IPC
endpoint of the IPC message.
55. The method as claimed in claim 52, wherein determining the rule
associated with IPC message comprises: a. comparing the value of
the IPC message fields selected by the filter mask of the IPC
filter rule with the filter value of the rule; and b. determining
the applicability of the IPC filter rule based on the
comparison.
56. The method as claimed in claim 52, comprising analyzing all the
IPC filter rules in the table from beginning to end till an
applicable IPC filter rule is found.
57. The method as claimed in claim 52, wherein the IPC message is
silently dropped when no applicable IPC filter rule can be
found.
58. The method as claimed in claim 52, wherein an exception is
generated and the IPC message is silently dropped when no
applicable IPC filter rule can be found.
59. The method as claimed in claim 52, wherein the IPC message is
forwarded using a default forwarding action when no applicable IPC
filter rule can be found.
60. The method as claimed in claim 52, wherein the IPC message is
silently dropped when an invalid forwarding action is found in the
IPC filter.
61. The method as claimed in claim 52, wherein an exception is
generated and IPC message is silently dropped when an invalid
forwarding action is found in the IPC filter.
62. The method as claimed in claim 52, wherein the IPC message is
forwarded using a default forwarding action when an invalid
forwarding action is found in the IPC filter.
63. The method as claimed in claim 60, wherein the forwarding
action is considered invalid if the forwarding address is not
reachable through the interface, the forwarding address is not
configured or the interface is not valid.
64. The method as claimed in claim 52, wherein the IPC message is
forwarded to the IPC endpoint using an implementation specific
manner to the forwarding action address in the associated filter
rule when the forwarding action interface is configured as
"lo".
65. The method as claimed in claim 55, wherein the scalar value of
a field in the IPC filter rule is considered to be equal to the
corresponding filed value in IPC message when the two values are
equal.
66. The method as claimed in claim 55, wherein the range value of a
field in the IPC filter rule is considered to be equal to the
corresponding field value in IPC message when the range comprises
the field value.
67. The method as claimed in claim 55, wherein a wild card value in
a field in the IPC filter rule is always considered to be equal to
the corresponding field value in the IPC message.
68. The method as claimed in 55, wherein the IPC filter rule is
applicable when the values of all the fields of the IPC message
match with the corresponding IPC filter values of the IPC filter
rule.
69. The method as claimed in claim 52, wherein adding a new IPC
filter rule comprises: a. constructing a new IPC filter rule by
assigning a filter mask, filter value and forwarding action
corresponding to an IPC message flow; b. resolving conflicts of the
new IPC filter rule with the existing IPC filter rules that have
identical filter mask and filter values but different forwarding
action; c. inserting the new IPC filter rule in the table; and d.
merging two or more rules in the table that have identical
forwarding action and filter mask.
70. The method as claimed in claim 52, where deleting an IPC filter
rule comprises: a. removing the rule from the table; and b. merging
two or more remaining rules in the table that have identical
forwarding action and filter mask.
71. The method as claimed in claim 52, wherein updating an IPC
filter rule comprises: a. removing the IPC filter rule from the
table; and b. adding an updated rule comprising: constructing a new
IPC filter rule by assigning a filter mask, filter value and
forwarding action corresponding to an IPC message flow; resolving
conflicts of the new IPC filter rule with the existing IPC filter
rules that have identical filter mask and filter values but
different forwarding action; inserting the new IPC filter rule in
the table; and merging two or more rules in the table that have
identical forwarding action and filter mask.
72. The method as claimed in claim 69, wherein merging two or more
IPC filter rules comprises: a. constructing a new rule comprising
fields which have identical values; b. removing the IPC filter
rules to be merged from the table; and c. adding a new rule to the
table.
73. The method as claimed in claim 69, wherein resolving conflict
between two IPC filter rules comprise adding one more IPC message
fields that have different values in the IPC message flows
corresponding to conflicting rules to filter mask of the
conflicting rules.
Description
FIELD OF THE DISCLOSURE
[0001] The present disclosure relates to inter process
communication methods in software. More specifically, the present
disclosure pertains to a method and associated system and data
structure for efficient inter process communication in an
environment where the IPC address associated with the destination
entity may change at any time.
BACKGROUND OF THE DISCLOSURE
[0002] In conventional communication systems shown in FIG. 1, a
node 10 is required to interface with many neighbors. These are
collectively shown in FIG. 1 as "Functional Peer Left" and
"Functional Peer Right". There are strict availability and
scalability requirements for the said node on all interfaces. In
order to meet availability requirements, the system is implemented
using redundant software components, redundant hardware elements
and one or more of several possible high availability schemes.
Scalability requirements are met through modular design. Software
components are mapped to hardware elements which provide an
execution environment for these software components. High
availability schemes are realized using appropriate check pointing,
data replication and failure detection schemes. On failure of a
working hardware element or software component, a standby (hot)
software component starts functioning in place of the failed
software component. It also includes switching of hardware
elements.
[0003] FIG. 2 shows a communication system 10 comprising plurality
of hardware elements 20 through 2x. Software functional components
associated with the processing of the interworking with functional
peer left comprising plurality of modules 20_500 through 20_5xx and
with functional peer right comprising plurality of modules 21_600
through 21_6xx. Functionality of these components is defined by the
relevant specification in terms of protocol data units (PDU) or
messages received from the functional peer and actions to be taken
by the node 10. Such an action is performed by the plurality of
software functional components 20_500 through 20_5xx and 21_600
through 21_6xxx and may or may not produce PDU on the same
interface or on other interface. To realize this processing, the
software functional components 20_500 through 20_5xx and 21_600
through 21_6xx are required to communicate among each other. This
type of communication is referred to as inter process communication
(IPC). Software function components that communicate with each
other using IPC are called IPC end points. This is realized using a
network 50 internal to the node. Every hardware element is
connected to network 50 through network interface 20_400 through
2x_400 and assigned layer 3 addresses 10.0.0.1 through 10.0.0.x+1.
The IPC endpoints may be located on the same hardware element or on
different hardware elements. IPC endpoints 20_300 through 2x_300
are responsible for delivering the IPC messages to the destination
IPC endpoints. There are also several different timing or design
specific considerations for inter process communication.
[0004] There are many standard platforms such as cPCI, ATCA,
microTCA etc. available off the shelf which can be used to realize
node 10. These standard platforms can accommodate one or more
hardware elements (such as hardware boards) to realize plurality of
hardware element 20 through 2x. These hardware elements have a CPU,
memory, the required communication interface, other hardware
accelerators and a host operating system such as Linux. A
communication interface on the hardware element is assigned one or
more IP addresses and used for local-to-remote communication. A
loopback interface is also provided for local communication.
[0005] IPC routing module maps the destination IPC endpoint to IP
address and IPC message is sent through TCP/IP and routed using a
kernel IP routing table to the destination IPC endpoint. To
communicate with a desired IPC endpoint, the source IPC endpoint is
required to select the correct IP address associated with the
hardware element where the desired destination IPC endpoint is
located. In other words, an IP address is associated with an IPC
endpoint. FIG. 3 shows IPC message exchange 1000 from 20_500 to
20_501 located on same hardware element 20. IPC endpoint 20_300
maps 20_501 to the IP address 20_400 and message is routed using IP
routing table. IPC endpoint 20_300 receives the message and sends
it to 20_501. FIG. 3 also show IPC message exchange 2000 from
20_500 to 21_600 located on hardware elements 20 and 21
respectively. IPC endpoint 20_300 maps 21_600 to the IP address
21_400 and message is routed using IP routing table. IPC endpoint
21_300 receives the message and sends it to 21_600. Hardware
element 22 is hot standby to hardware element 21.
[0006] The association of an IP address with an IPC endpoint is not
fixed and may change because of failure. FIG. 4 shows that on
failure of hardware element 21, hardware element 22 becomes active
and 21_600 is now associated with different IP address (22_400).
This means IPC endpoint 20_300 should send messages for IPC
exchange to IP address 22_400.
[0007] PDUs from left functional peer and right functional peer are
processed in a user data context which may be established through
control PDUs exchange or statically configured. There will be many
user data contexts exist in the system, one each for every PDUs
flow. A scalable system would implement plurality of software
functional elements and plurality of hardware elements for handling
many user data contexts. Due to this user data context associated
with a flow will have many instances. Software functional
components are required to communicate with each others to process
PDUs associated with user data context. This means a software
functional component together with user data context participates
in inter process communication and are being referred to as IPC
endpoints.
[0008] The IPC endpoints may get relocated because of exceeded
capacity, failure or change in the Functional peer and will require
change in the selected layer 3 address and destination IPC end
point by source IPC endpoint for IPC messaging. IPC message
exchange between two IPC endpoints is called as IPC message
flow.
[0009] It can be seen that there is a need for a method and data
structures for providing efficient inter process communication
where IPC endpoints may be relocated during operation of the
system.
SUMMARY OF THE INVENTION
[0010] To overcome the limitations described above, and to overcome
other limitations that will become apparent upon reading the
understanding of the state of art, the present invention discloses
a system, method and associated data structures for providing inter
process communication where IPC endpoints may get relocated during
the operation of the system.
[0011] An embodiment of the present invention solves the above
described problems by assigning a filter rule to IPC message flow,
storing said rule in IPC filter rule table, identifying a match
rule when an IPC message is send and forwarding IPC message
according forwarding action of the matched rule. It further
comprises updating the affected filter rules when IPC destination
is relocated.
[0012] A device in accordance with the principles of the present
invention includes IPC filter rule management process, IPC filter
rule lookup process and IPC filter rule table, wherein IPC filter
rule management process creates and updates the entries in IPC
filter rule table, and wherein IPC filter rule lookup process finds
the matched rule and takes the forwarding actions.
[0013] A system in accordance with the principles of present
invention for providing inter process communication where IPC
endpoints may get relocated during the operation of the system
comprises a plurality of preferred devices which in an embodiment
may be connected with plurality of functional peers through
plurality of network interfaces.
[0014] An implementation according to a preferred embodiment of the
present invention can use system events such as addition, deletion,
failure and mobility of IPC endpoint; system scalability and/or
combination thereof for IPC filter rule management process to
update the IPC filter rule table.
[0015] The details of one or more implementations are set forth in
the accompanying drawings and the description below. Other features
will be apparent from the description and drawings, and from the
claims.
DESCRIPTION OF DRAWINGS
[0016] FIG. 1 shows a typical data communication system
[0017] FIGS. 2 through 4 show the conventional method of IPC
message forwarding
[0018] FIG. 5 shows a device and associated data structure
according to a preferred embodiment
[0019] FIG. 6 is a flow chart describing an exemplary IPC filter
lookup according to a preferred embodiment
[0020] FIG. 7 is an exemplary system demonstrating IPC message flow
forwarding according to a preferred embodiment
[0021] FIG. 8 is an exemplary system demonstrating relocation of
IPC endpoints
DESCRIPTION OF THE DISCLOSURE
[0022] In the following description of the embodiments, reference
is made to the accompanying drawings that form a part hereof, and
which is shown by way of illustration of the specific embodiments
in which the invention may be practiced. It is to be understood
that other embodiments may be utilized without departing from the
scope of the present invention.
[0023] The present invention provide method, system and associated
data structures for providing inter process communication (IPC)
where IPC endpoints may get relocated during the operation of the
system.
[0024] As used herein, the term "filter rule" collectively refers
to filter mask, filter value and forwarding action. As used herein,
term "filter mask" collectively refers to fields of IPC message
such as source and destination IPC endpoint identifiers, IPC
message flow identifier and any other fields in IPC message. As
used herein, the term "filter value" refers to the values of the
fields selected by filter mask for the said rule. As used herein,
filter mask and filter value of a filter rule uniquely associates a
filter rule with an IPC message flow through and vice a versa. As
used herein "forwarding action" refers to the address and outgoing
interface to be used for forwarding IPC message. As used herein,
the term "matched rule" or "selected rule" refers to a rule which
is when a filter mask of the said rule is applied on an IPC
message, resultant fields' values are equal or identical to the
filter value of the said rule.
[0025] An embodiment of the present invention solves the above
described problems by assigning a filter rule to IPC message flows,
storing said rules in IPC filter rule table, identifying a match
rule when an IPC message is send and forwarding IPC message
according to forwarding action of the matched rule. It further
comprises updating the affected filter rules when IPC endpoint is
relocated.
[0026] A device in accordance with the principles of the present
invention as shown in FIG. 5 includes IPC filter rule management
process (20_700), IPC filter rule lookup process (20_800), IPC
filter rule table (20_900) and plurality of IPC endpoints 20_500
through 20_5xx and a network interface (20_400) for connectivity,
wherein IPC filter rule management process creates, deletes and
updates the entries in IPC filter rule table, and wherein IPC
filter rule lookup process finds the matched rule and takes the
forwarding actions.
[0027] We use an IPC Filter Rule Table 20_900 to store the Filter
rules for efficient lookup. In the following discussion `IPC Filter
Rule Table` and `Table` are used interchangeably. This table
comprises: [0028] 1. Filter Mask: defines the fields of IPC message
to be used from the IPC message for matching the entry in the
table. An implementation according to a preferred embodiment may
use source and destination IPC endpoint identifiers, IPC message
flow identifier and any other fields in IPC message Source
Identifier. Source and destination IPC endpoint identifiers may be
mapped to the network address in the packet or any identifiers
assigned to the IPC end points. IPC message flow identifier is an
identifier assigned to uniquely identify an IPC message exchange
between two IPC endpoints. IPC flow identifier may also be a
protocol field defined by communication protocol. [0029] 2. Filter
Value: defines the value(s) for the corresponding fields of an IPC
message selected by Filter Mask. A value can be wild card, which is
a match for all possible values of the corresponding field. [0030]
3. Forwarding Action--Address: provides the IP address or IPC
endpoint identifier to be used for forwarding the IPC message.
[0031] 4. Forwarding Action--Interface: Network interface to be
used for forwarding the IPC message. "lo" is a special interface.
If IPC message is forwarded through this interface then it is
delivered to a IPC endpoint exists locally on the same hardware
element. This forwarding mechanism is operating system dependent
and can be for example, socket, POSIX queue, shared memory.
[0032] An implementation according to preferred embodiment of the
present invention can use system events such as addition, deletion,
failure and mobility of IPC endpoint; system scalability and/or
combination thereof for IPC filter rule management process to
update the IPC filter rule table. IPC filter rule management
process may be required to split an existing filter rule into two
or more filter rules or merge many existing filter rules into one
filter rule at the time of adding, updating or deleting a filter
rule. Existing filter rule in the table is required to be splitted
when there would be two or more filter rules with identical filter
mask and filter value but different forwarding actions. A filter
rule is splitted into multiple filter rules by adding one more
fields to the filter mask. Two or more existing filter rules in the
table are required to be merged into one entry when their
forwarding actions are identical. Filter rules are merged by
removing the one or more fields from the filter masks for which
filter values are not identical.
[0033] FIG. 6 is a flow chart 800 of filter rules lookup performed
by IPC Filter Rule Lookup process (20_800). Process begins by
receiving an IPC message on either incoming or outgoing interface
(100) on any of the interface of the system. All filter rules from
beginning to end are checked (200, 410) if "values of the fields in
the IPC message selected by filter rule's filter mask" are
identical to "filter values" (320). If such a filter rule is found
(420) then IPC message is forwarded to the filter rule's forwarding
address (420). If end of the table is reached then message is
dropped (310).
[0034] FIG. 7 shows an exemplary system 10 according to a preferred
embodiment of the present invention comprising plurality of
preferred devices 20 through 2y and which in an embodiment may be
connected with plurality of external functional peers 50 and 55
through plurality of network interfaces 500 through 50m. IPC
endpoints of IPC message flow 1000 are located on the same device
20. IPC endpoints of IPC message flow 2000 are located on different
devices 20 and 21. A function peer 50 communicates with system 10,
IPC endpoint 20_500. A protocol field (e.g. GRE Key 123450) in the
message exchange is used as IPC message flow identifier. System 10
is connected with function peer 55 through network interface 500.
IPC endpoint 21_501 of System 10 communicating with function peer
55 is also shown. A protocol field (e.g. GRE Key 56789) in the
message exchange is used as IPC message flow identifier. System 10
is connected with function peer 55 through network interface 50m.
Corresponding IPC Filter rule table is also shown in FIG. 7. IPC
Filter rule table 20_901 is used by IPC Filter rule lookup process
20_800 and IPC Filter rule table 21_901 is used by IPC Filter rule
lookup process 21_800.
[0035] FIG. 8 demonstrates the relocation of IPC end point
according to the preferred embodiment of the present invention. IPC
message flow 2000 is relocated from 21 to 22. IPC filter rule
tables after the relocation are also show in the FIG. 8. Subsequent
IPC messages of 2000 will be forwarded to 22 by IPC Filter Rule
Lookup process 20_800. IPC Filter Rule Lookup process 22_800 will
forward these IPC messages to 22_500.
[0036] The foregoing description of the exemplary embodiment of the
invention has been presented for the purpose of illustration and
description. It is not intended to be exhaustive or to limit the
invention to the precise form disclosed. Many modifications and
variations are possible in light of the above teaching. It is
intended that the scope of the invention be limited not with this
detailed description, but rather by the claims appended hereto.
* * * * *