DDS — Additional_communication_paradigms

Issue# 2010 Additional_communication_paradigms Issue [Boeing SOSCOE] ? In addition to the Data-Distribution model, our applications also need two basic communication models; Point2Point and GroupCommunications. ? The API’s and PIM defined in DDS would fit well with those communication models as well. That is, the concept of typed DataReaders and DataWriters that are configured by means of QoS and interact with the user-level application by means of listeners and conditions are all applicable to Point2Point and GroupCommunications. ? It would therefore be useful to introduce extensions such that the application can use these additional communication models in a way that fits naturally with the data-distribution PIM. ? In Boeing SOSCOE’s applications Point2Point communications: • Represent 1-to-1 bi-directional communication channels similar to UNIX “pipes” that can be configured by means of QoS • Are “connection-oriented” in the sense that each endpoint must explicitly establish the “connection” and is made aware if the “connection” is broken • Allow the application to read-write typed data to the other end-point. Each “writer” in one side of the connection communicates with the corresponding “reader” at the other end. In general each writer must be matched by a reader at the opposite end. Otherwise it is a configuration error. • Allow prioritization among the data written by different writers by means of QoS • Allow both synchronous and asynchronous writes. • Support the concept of application-level acknowledgements or “transactional” messaging by which the writing application can receive notification that the reading application has received the message and has positively acted on it. • Support the classic “client-connect versus server-listen/accept” pattern such that the “server” side can establish multiple dedicated point-to-point connections to each “client” that requests a connection. • Filters are not generally expected to be required for Point2Point communications. However, in order to keep the same API they should be allowed. The middleware should automatically give positive acknowledgement of reliable or transactional data that has been filtered out. • It is an error for a data-writer to write a Topic that does not have a corresponding data-reader. The writer() call should return a special error code indication there is no matching DataReader. In Boeing SOSCOE’s applications GroupCommunications : • Provide the capability for a group of peer applications to organize themselves into a “group”, such that each member of the group is aware of the presence of all other members and can send messages directed to either one specific peer, all the peers in the group, or a subset of the members of the group. • Provide some means to control group membership. • Each member of the group is identified by some “ID” such that other members can refer to it and direct messages to it. • Provide a serialized view of membership and delivery of messages such that: • The writer knows the membership when it sends each message and anybody that does not belong to that membership will not get the message. • All members of the group have the same view of the membership for each message delivered to them. • Do not need to provide total order or even agreed order. • Act as a “live” group in that messages are only delivered to the members that are present when the message is sent. In other words, it does not store messages on behalf of future members of the group • It is OK to write a DataWriter that does not have a corresponding DataReader on some of the other Group members. The data is considered acknowledged for RELIABLE but not for the purpose of TRANSACTIONAL (ref issue# 2060). Proposal [Boeing SOSCOE] ? Consider introducing a more primitive concept for a group of endpoints, from which the following classes derive: Publisher, Subscriber, EndpointConnector, and GroupConnector. ? This base class could be called “Connector” but does not really mean a “connection” in the “TCP” sense, rather the “connectivity” into the middleware services. ? All these “Connectors” act as factories for DataReader and DataWriter entities (which represent the Endpoints). ? The type of the DataReader and DataWriter created from each kind of “Connector” is the same (even though they will act differently). This is because the DataReader and DataWriter are typed facades to write a specific data-type and it is not desirable to have to create (by means of implied IDL) different types for each kind of connector. ? The EndpointConnectors and GroupConnectors are informed of the connections/disconnections by means of Listeners with an “onConnect” and “onDisconnect” operations. ? For Point2Point communication the factory of DataReader and DataWriter entities would be the EndpointConnector • To match the two EndpointConnector objects that should be “hooked up” the application could use either a Topic, or a more general matching of “Attibute-value” pairs, or a combination of the above. • To aid in the establishment of many point2point connectors using the client-connect, server-listen/accept pattern the EndpointConnector could use an auxiliary “ServerConnector” and corresponding listeners that would inform it of the fact that clients are attempting a connection. ? For Group communications the factory of DataReader and DataWriter entities would be the GroupConnector • The same generic mechanism used by the EndpointConnector should be used to identify the group the GroupConnector entities are joining, that is either a Topic, or a more general matching of “Attibute-value” pairs, or a combination of the above. Comments[RTI] ? To avoid confusion it might be a good idea to propose a name other than “connector” for the base class and also avoid the use of the terms “client” and “server” which are often associated with the pattern of communications used by CORBA and RMI. ? Point2Point communications would never use KEEP_LAST QoS. They will use KEEP_ALL. They will also always have DURABILITY TRANSIENT. In a sense messages are sent to the other end “immediately” and held only as long as is necessary to ensure the QoS (e.g. RELIABLE or TRANSACTIONAL) afterwards they are removed from the middleware.

No Data Available