Using an ORB with Multicast IP - Univ. Nantes

Using an ORB with Multicast IP Christophe Gransart, Jean-Marc Geib Université des Sciences et Technologies de Lille Laboratoire d’Informatique Fondamentale de Lille 59655 Villeneuve d’Ascq cedex, FRANCE Email: {gransart, geib}@lifl.fr

Abstract This paper describes our experiment to add a new transport protocol inside of an ORB. This work was done on ORBacus which offers a framework to simply add new protocols as plug-ins. So, we defined a plug-in to transport GIOP requests using a multicast IP layer. This leads to a new communication model in CORBA which can be used in parallel, distributed and groupware environments. Keywords: CORBA, distributed objects, multicast, MulticastIOP

on real-time and minimum CORBA for embeded applications.

1.2 GIOP/IIOP CORBA 1.0 focused on interoperability between software languages using the same ORB. Products conform with this specification were not interoperable together. The new specification release, CORBA 2.0 solved this problem. The OMG defined a protocol for interoperability between ORBs. This protocol is named GIOP: General Inter-ORB Protocol. This specification defines: •

A Common Data Representation (CDR) This is a mapping for IDL types to network representation

•

An Interoperable Object Reference (IOR) This is a common representation of object reference for compliant products with the CORBA 2.0 standard.

•

A Message Format This part specifies the kinds of requests that can be exchanged between clients and servers (Request, Reply, LocateRequest, MessageError, ...)

•

Some assumptions about the network transport layer The transport layer must be connection oriented, and reliable. Messages’ order must be provided, and message size must be unlimited.

1 Introduction 1.1 CORBA CORBA (Common Object Request Broker Architecture) is the result of the work initiated at the OMG (Object Management Group) since 1989. The OMG is a consortium involving more than 850 companies. Its main goal is to define a common platform in order to support software interoperability. Since 1996, lot of work have been done to allow communication between different operating systems, languages and platforms. Majors results[2] are: definition of the OMG IDL (Interface Definition Language) to define contracts between clients and servers independently from languages used for implementation. Mapping from OMG IDL to current languages such as C, C++, Java, ... Interoperability between CORBA products through IIOP (Internet Inter-ORB Protocol). Specifications to exchange models at design time : UML (Unified Modeling Language). Services: Naming and Trader services to find objects across the network, Life Cycle to follow an object during its life time, Transactions and Security to obtain reliable applications, Events and Messaging for asynchronous use of distributed applications and so on. Some current works are focused

This “abstract” layer is instanciated on TCP/IP, and is named IIOP (Internet Inter-Orb Protocol). In this version, an IOR contains: •

A version number: 1.0 or/and 1.1

•

An host address: IP number/ symbolic name

•

A port : socket number

•

A key: which is implementation dependent. This information allows server to find the object inside of its memory.

This layer offers interoperability between all versions of the CORBA specification.

1.3 Why Multicast? Currently, CORBA requests are “Unicast”. This involves that each request is sent to exactly one server. The standard protocol IIOP offers this kind of service: it is based on TCP/IP using the TCP layer. Moreover, if an application needs to send to same request to multiple servers, the application must send it once per server. Another problem which must be managed by the application is the object references management: the application (client) must keep references to all the servers to which it wants contact. Drawbacks of the current approach are: •

Waste of network bandwith For example, if an application needs to send the same request (1MB data) to 100 servers, this will imply a 100 MegaByte of network traffic.

•

Loss of client transparency Another problem is that client applications need to manage references to all servers that are interested in the request. Clients must be aware of new servers, of server disconnection, ... This requires, at least, explicit subscription/ management operations.

Our idea is to use the multicast power from the network layer in a CORBA environment. Using multicast, only one group reference is needed. This will simplify applications developement for several research topics: Multicast can be used in parallel computing to spread tasks and data among a network of workstations whithout overhead.

must be reliable, nor that an invocation will be achieved, nor will be aborted. According to our goals, we have chosen to manage only one-way operations to keep it simple. The major problem is that we do not want to make choices to define/ specify the semantic for the result of operation using multicast. One-way request are just like regular request but they cannot have any return values, inout, or out parameters. Moreover, no exception can be returned. The IDL language is designed to specify contract from point to point and not for point to multi-points receivers. Another problem is that requests to multiple objects imply multiple responses or no response at all, if the objet group is empty. Anyway, twoway operations can be handled using several solutions: •

Response handler Each time that a response arrives, the program can use code like the DII (Dynamic Invocation Interface) get_response operation for the multiple responses.

•

Rewriting operation signatures Instead of waiting for an answer, user can define a contract for which he/she is waiting for a sequence of results.

But the major problems with this approach are that the complexity added inside of programs and the loss of transparency (to manage object groups). From these requirements, operation signature cannot manage exceptions, out or inout parameters. A server that wants to send an answer to a multicast request should use a callback object. There is no direct support for fault tolerance, event service, ... The main idea is to design a basic building block for such services.

Groupware applications have to dispatch events among user groups[6]. Such applications can benefit of a true multicast layer to avoid network bandwidth waste.

1.3.2 Unlimited message size

We have decided to design a CORBA multicast layer based on oneway operations, and unlimited message size. Following subsections present our choices.

As we want to follow the GIOP requirements, we have to manage messages of unlimited size. For this, we have added a header to manage message contents transported in several network packets.

1.3.1 Oneway operations

2 The Open Communication Interface

The CORBA model offers two modes for operations in objects: two-ways and one-way.

This section presents the implementation done using the ORBacus ORB middleware[1]. This middleware offers a framework to add new network protocols in an easy way. This framework is named OCI: Open Communication Interface.

Two-ways operations are operations which provide a result. One-way operations are operations which do not provide a result. For this last kind of operations, the OMG specification neither specifies that an invocation

2.1 What is OCI?

2.2 Multicast Integration

OCI stands for Open Communication Interface. It is a framework based on the Connector/Acceptor design pattern defined by Douglas Schmidt[3]. This framework was designed in cooperation with Humboldt University and Deutsche Telekom.

According to the previous section, we have defined a new transport layer for CORBA messages using multicast IP as transport layer. For this, we have defined a new MulticastIOP IOR profile. This profile contains information related to the transport layer. In our case, the profile contains information as:

The main idea here is to support byte-stream oriented protocols like TCP/IP, SSL, SSCP, SAAL and ISDN. The protocol manages the quality of service with Policies to control protocol selection or the POA (Portable Object Adaptor), and Messaging quality of service frameworks. OCI is based on a common design pattern: the reactor , acceptor and connector patterns and the factory pattern. The main parts of the implementation are seven lightweigth interfaces: •

Buffer

•

Transport

•

Connector and Acceptor

•

Connector Factory

•

Connector Factory Registery and AcceptorRegistery

Protocolspecific Connector Factory

ORB

Connector

Transport

Acceptor

Protocolspecific Connector

Protocolspecific Transport

Protocolspecific Acceptor

Connector Factory Registry

Tag (defined by the OMG)

•

The protocol version

•

The multicast IP address

•

the IP port

•

The object key An object is an information dependent of an ORB implementation except if you give in your program the contain of such a key.

During our developements, we had to make some choices.The first step was to reuse the best part of GIOP standard like the Common Data Representation (CDR). Moreover, we have reused the message format defined in the GIOP protocol. But, according to our design choices, only request GIOP messages are managed.

The following schema presents the main architecture:

Connector Factory

•

OA

Acceptor Registry

In ORBacus, IIOP is defined by inheritance from the previous pattern. It is possible to choose which protocol to use on a perobject reference or for a complete process.

Finaly, we tried to follow the assumptions about the transport layer. The following chart presents some results about our current implementations

Unreliable version

Reliable version

Oriented connection

(1)

(1)

Reliable transport

No

Yes

Message order

No

Yes

Unlimited message size

Yes

Yes

(1) Not connection oriented but with connection loss detection.

3 Server vs. Client This section discusses about communication models for distributed applications. From CORBA point of view, there are two models: the classical client/server model, and the producer/consumer model from the Event service. We add a new model with our multicast layer.

The following sections present these models.

4 Technical points

3.1 The classical Client/Server model

The model of our work is the following:

This model is the basis of CORBA distributed applications. Clients can invoke remote operations on servers located somewhere else on the network.

1 Client

operation ()

DII/DSI Interface

CORBA Core Specification

DII/DSI DII/DSI with CDR Message Layer Interface

1 Server

OCI Message Layer Specification

Message GIOP Layer

result

Transport Layer Interface

OCI Transport Layer Specification

This model is the “one to one communication” one. Invocations are synchronous.

Network Interface

Network API Specification

3.2 The Producer/Consumer model The Event service base producer/consumer model allows communications from one to N. It offers asynchronous invocation through event channels. N point to point communications are used.

Transport MCASTIOP Layer

UDP/Multicast Network or reliable Mcast

In this figure, we can see our new transport layer: MCASTIOP. This layer is based on the UDP/multicast layer but can also be based on a reliable multicast library like LRMP [5].

produce (event) 1 Producer

N Consumers Event channel

4.1 IOR Creation Our multicast layer involves that object references have special properties at connection time: objects belonging to the same group of consumers must have the same IOR.

3.3 The Multicast model

4.1.1 Consumer side creation

The multicast model allows asynchronous communications from one to N. This model is based on a multicast communication layer, so that only one communication is used, without any kind of specific channel.

Objects have to be explicitly named. This allows to set the same name for all the objects located in several servers. Objects must have:

1 Producer

produce (event)

N Consumers

•

the same class D IP address

•

the same IP port

•

the same key

The symbolic name (i.e. the key) associated to objects is set using the CORBA.ORB.connect() operation. With the current implementation, this work has to be done by the programer, but we are now working on a group service to manage these names.

4.1.2 Producer side creation A producer has to be connected to consumers objects. For this, a producer can use the standard IOR format

(IOR:0123...456...789). But we also have defined an URL notation: mcast://host:port/name where: •

host is the class D IP address

•

port is the IP port

•

name is the symbolic name explicitely set at object connection time on the ORB.

Sender A Packet 2 Sender C Packet 1

A producer sees the group of consumers as a unique object.

Sender B Packet 1

5 Implementation and performances

Sender A Packet 1

The current implementation is based on ORBacus 3.1.1 for Java. We realized several implementations of our multicast plug-in: an unreliable one, and a reliable one. From the application point of view, there is no differences. Applications can switch from one to the other by simply changing the CLASSPATH variable. For the different implentations, a common part was defined: the MCASTIOP Packect Header. GIOP messages can have unlimited size and must be split into packets. The GIOP fragmentation cannot be used because GIOP fragments cannot be lost. UDP packets can be lost (some time, according to the needed quality of service). GIOP fragments must be ordered. UDP packets can arrive unordered. To response to these requirements, we defined a special MCASTIOP header completly defined using IDL and using the CDR. This header contains information about encoding (little/big endian), belonging of the packet, number and the size of the complete message. For the two following implementations, this header is used.

5.1 Our Architecture The following schema presents the scenario of packet reception for a MulticastIOP server. In this example, “To server” A receives a lot of information split in several packets (sender A, packet XX). B and C receive less information. The current implementation allows us to receive several unordered packets (as in the case of server A) and to reconstruct the original message thanks to infomation stored in our new header encapsulating GIOP messages. Our information allows us to avoid to duplicate fragments received several times. The same information allows us to reconstruct, without overhead, the original message. Another mechanism (not presented in this paper) allows us to determine a connection closing.

ServerPacketHandler

Sender A Packet 3

New Transport List Sender B

run()

Sender C

Transport for Sender A

Transport for Sender B

Transport for Sender C

Packet 1

Packet 1

Packet 1

Packet 2 Packet 3

5.2 The unreliable plug-in This implementation uses the standard JAVA API for UDP networking. It manages messages of unlimited size. This version allows very fast transferts but some packets can be lost.

5.3 The reliable plug-in The reliable plug-in is based on LRMP (Lightweight Reliable Multicast Protocol) developed by INRIA. Like the previous plug-in, it manages messages of unlimited size. It offers an ordered and reliable message delivery. This version is slower than the previous one.

5.4 Performances We tested the transfert speed for the plug-in. For our benchmarks, we have measured the througput between one producer and N consumers using IIOP, the unreliable plug-in, and the reliable one. This is the IDL contract used for our benchmarks. We have sent a file of 8 Mbytes to N consumers on a LAN ethernet network (10 Mbit/s) and analyzed the results from the producer’s side. // ****************************************** // // Testing transfert speed // // ****************************************** typedef sequence bench; interface TestPerf{ oneway void transfert(in bench data); };

Time (sec) Unreliable

9

50 %

7.1

Reliable

40

0%

1.6

IIOP

10 * N

0%

6.4 / N

IIOP offers good result for a one to one communication. Sending data to more than one receiver implies to send several times the same data. If we have to send the same data to more than 4 receivers, the best choice is the reliable multicast plug-in. Currently, we are developping the C++ version of the plug-in using ORBacus 3.1.3. Some applications have been developped: a Name service and Event service using the multicast, a multicaster-radio to diffuse sound from a CD player to several workstations. We are also working on distributed application management. Our project GoodeWatch offers a service to supervise distributed applications [4]. Events, such as object creation, operation invocation, are grabbed from the ORB and are multicasted to supervision servers. These servers offer functionalities to analyze application behaviors. We plan to use this tool to design a load balancing system for CORBA applications.

6 Conclusion and future work Until now, CORBA model was only based on one to one communications. We experiment solutions to offer multicast functionalities to CORBA applications. Future work is focused on the design of parallel and groupware environments.

7 References The

ORBacus Home Page, http:// www.ooc.com/ob/, Object-Oriented Concepts, Inc.

[2]

D. C. Schmidt, Reactor: An Object Behavioral Pattern for Concurrent Event Demultiplexing and Event Handler Dispatching, in Pattern Languages of Program Design, Addison-Wesley, 1995.

[4]

C. Gransart, P. Merle and JM. Geib, GoodeWatch: Supervision of CORBA Applications, ECOOP’99, workshop on Object-Orientation and Operating Systems, Lisbon, Portugal, June 1999.

[5]

LRMP, INRIA, France, 1998. http://monet.inria.fr/lrmp/

[6]

Silvano Maffeis, The Object Group Design Pattern, COOTS, Toronto, Canada, 1996.

Througput Packet loss (Mbits/s)

The unreliable version is very fast but lots of packets are lost. The problem is that sender’s buffers are overflowed, and packets are discarded.

[1]

[3]

The Common Object Request Broker: Architecture and Specification, Revision 2.0, OMG Document 97–02–25.