Real-time publish-subscribe system

• US 8,150,988 B2
• Filed: 12/10/2010
• Issued: 04/03/2012
• Est. Priority Date: 04/05/2001
• Status: Expired due to Term

• Current Assignee: Real-Time Innovations, Inc.
• Original Assignee: Real-Time Innovations, Inc.
• Inventors: Pardo-Castellote, Gerardo, Hamilton, Mark, Thiebaut, Stefaan Sonck
• Primary Examiner(s): Shaw, Peling
• Application Number:
  US12/965,589
• Publication Number:
  US 20110185074A1
• Time in Patent Office: 480 Days
• Field of Search: 709223-224, 709/230, 715/736
• US Class Current: 709/230
• CPC Class Codes: G05B 2219/33149 Publisher subscriber, publisher, master broadcasts data to slaves, subscriber
• CPC Class Codes: H04L 67/12 specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
• CPC Class Codes: H04L 69/329 in the application layer [OSI layer 7]
• CPC Class Codes: H04L 9/40 Network security protocols

Abstract

A real-time protocol for real-time network programming applications is disclosed. The protocol is executable on a computer network having a plurality of nodes that include applications, a network stack, an operating system, and middleware capable of executing real-time operations. The protocol can use group objects to model physical and logical devices connected to the network wherein each group object comprises at least one variable. Changes in these variables are encapsulated in variable change messages which are propagated in the network using communication objects. Also described is a real-time messaging format useful for implementing the protocol.

Claims

1. A real-time protocol executable on a computer network having a plurality of nodes, wherein the nodes include real-time middleware capable of executing real-time operations, the middleware of each node further including:

a write object associated with a variable;

a read object associated with a variable;

a message interpreter that receives and interprets the variable change messages so that they can be read by a read object;

a variable reference table which a write object uses to track variable information;

a remote reader reference table for each reader that has registered to receive information from the writer so that the writer can determine a message status for each reader registered to receive information from the writer, wherein

a variable is a data object that includes a plurality of parameters and a plurality of associated parameter values,

a variable includes parameters for a globally unique identifier and, implicitly or explicitly, a type and a topic; and

the write object is capable of writing variable change messages having a topic to associated read objects that are registered to receive variable change messages having the topic, without the read communication objects otherwise requesting the change information.

2. The protocol of claim 1 wherein variable change messages are sent from write objects to read objects, wherein the variable change messages include header information that is cached by the message interpreter so the header information need not be included in every message.

3. The protocol of claim 1 wherein variable change messages are sent from write objects to read objects, wherein the variable change messages include information about the properties of a variable that are cached by the middleware at the receiving end so that the properties of the variable need not be sent with every change message.

4. The protocol of claim 1 wherein variable change messages are sent from write objects to read objects, wherein the variable change messages include information about the properties of a write object that are cached by the middleware at the receiving end so that the properties of the write object need not be sent with every change message.

5. The protocol of claim 1 wherein messages are sent that include submessages that change the context of the message interpreter at a receiver end and thus affect the interpretation of subsequent submessages so that the context information need only be included once in the message and not with every submessage.

6. The protocol of claim 1 wherein variable change messages are sent from write objects to read objects, wherein the variable change messages include submessages and submessage header information that is cached by the message interpreter so the submessage header information need not be included in every submessage.

7. A real-time publish-subscribe (RTPS) message format for use on a real-time computer network where the RTPS messages are sent between communication objects, wherein the communication objects include write communication objects and read communication objects the communication objects are associated with variables, a variable is a data object that includes a plurality of parameters and a plurality of associated parameter values, and a variable includes parameters for a globally unique identifier and, implicitly or explicitly, a type and a topic;

wherein the read communication objects are configured to register with the write communication objects to receive information concerning topics for which those write communication objects have variable information; and

each write communication object is configured, in response to change information regarding the variable information for a topic, to cause the change information regarding the variable information for that topic to be provided to those read communication objects registered to receive information for that topic without the read communication objects otherwise requesting the change information,

each RTPS message comprising;

a modular message format having a RTPS message header of a uniform length;

a variable number of RTPS submessages where each RTPS submessage includes

a RTPS submessage header of uniform length; and

a RTPS submessage payload comprised of a variable number of RTPS submessage elements.

8. A real-time publish-subscribe (RTPS) message format as in claim 7, wherein the RTPS message header includes:

a RTPS header that identifies the message as a RTPS message;

a version identifier that identifies a RTPS protocol version being used by a message sender;

a vendor identifier that identifies a vendor for the RTPS protocol version being used by the message sender;

a host identifier that identifies the node sending the RTPS message; and

an application identifier that identifies the application sending the RTPS message.

9. A real-time publish-subscribe (RTPS) message format as in claim 7, wherein the RTPS submessage header includes:

a submessage identifier that enables a Message Interpreter to determine the contents of the RTPS submessage;

at least one flag, including an endianess identifier that enables the Message Interpreter to determine the endianess of the RTPS submessage; and

a submessage-length field identifying the number of octets to the next RTPS submessage header in a data stream, thereby permitting the Message Interpreter to skip over RTPS submessages it does not understand.

10. A real-time publish-subscribe (RTPS) message format as in claim 7, wherein the RTPS submessage element can include an Object Identifier that identifies the object instance and the kind of object that is sending the submessage.

11. A real-time publish-subscribe (RTPS) message format as in claim 7, wherein the RTPS submessage element includes:

a reader identifier that identifies the reader of the message using a Global Unique Object Identifier (GUID);

a writer identifier that identifies the writer of the message using a Global Unique Object Identifier (GUID);

a sequence identifier that identifies the beginning sequence number for which the submessage element applies; and

a bitmap that is used to identify the individual sequence numbers for which the submessage element applies.

12. A real-time publish-subscribe (RTPS) message format as in claim 7, wherein the RTPS submessage element is used to encapsulate the properties of a RTPS communication object and includes:

a parameter identifier that identifies a communication object parameter;

a size identifier that defines the number of octets in a value for the communication object parameter;

a value for the communication object parameter; and

a sentinel that terminates the submessage element.

13. The real-time publish-subscribe (RTPS) message format of claim 12, wherein the RTPS submessage element is used to encapsulate the properties of a RTPS communication object enables a Message Interpreter to skip parameters that it does not recognize and process a remaining portion of the submessage.

14. The real-time publish-subscribe (RTPS) message in claim 13, wherein the RTPS submessage element is used to encapsulate the properties of a RTPS communication object enables new parameters to be added in future versions of the protocol and still remain interoperable with versions of the protocol that do not recognize the newer parameters.

15. A real-time publish-subscribe (RTPS) message format as in claim 7, wherein the RTPS submessage element can include an Object Identifier that identifies an object instance and the kind of object that is meant to receive the submessage.