New Transport for omniORB

[Sai-Lai Lo]

Hi Luis,

It is good to know we share a common interest with another research group.

Let me first answer your query:

> We have knowledge of the key abstract classes that we need to work
> on: ropeFactoryTypes, ropeFactory, incomingRopeFactory,
> outgoingRopeFactory, Strand, Rope, and Endpoint. But, any further
> indications will be appreciated (modifications to the GIOP client and
> server, etc.)

You are on the right track. I left a note in ropeFactory.h which outlines
what has to be done. I guess you are aware of that.

- To get the ORB to use a new transport to create *outgoing* connections, an
  instance of its outgoingRopeFactory must be inserted into the
  globalOutgoingRopeFactories list. For tcp/ip this is done in
   corbaOrb.cc: (CORBA::ORB_init()).

- To get the ORB to use a new transport for *incoming* connections, an
  instance of its incomingRopeFactory must be inserted into the factory
  list of the BOAobjectManager. For tcp/ip this is done in
     corbaBoa.cc: ctor of BOAobjectManager.

- There is no need to modify giop client and server or NetBufferedStream.

- reliableStreamStrand is a generic class that implements most of the
  Strand interface over a reliable stream transport. The real network
  transport only needs to provide the actual functions to send and receive
  data. If your transport is also a reliable stream, you can reuse this
  class in the same way tcpSocketStrand does.

- If your transport is unreliable, e.g. ATM AAL5, you will have to provide
  the parallel of reliableStreamStrand to preserve the request-response
  semantics. We have done this but the code has not been integrated into
  the general release. (see below)

- When the ORB receives an IOR that contains multiple communication
  profiles, the current implementation simply iterates through them until
  it finds one that is supported by one of the outgoingRopeFactory in the
  globalOutgoingRopeFactories list. The code that does this is
    ropeFactory.cc: (ropeFactory::iopProfilesToRope()).
  We envisage there will be some negotiation with the other end to pick the
  best transport.

If you have more questions about the implementation, you are welcomed to
send us a message.

We have done some work to drive omniORB2 on top of ATM, SCI and shared
memory. In particular, we have omniORB2 communicates directly over ATM AAL5
and have a light weight implementation to preserve the exactly-once
request-response semantics on top of AAL5's unreliable packets.

Here is a sample of the latency we are getting:

                                micro seconds
     --------------------------------------------
      omniORB2/TCP over ATM      470
      omniORB2/AAL5              380
      omniORB2/Shared memory     270
      omniORB2/SCI event sync.   214
      omniORB2/SCI spinning      156

The figures measured the round trip time of echoing a null string. The tests
were done on pentium pro 200 machines running linux with ATM 155 and Dolphin
PCI SCI kit. We'll discuss our implementation and results in a paper that
is currently being prepared.

> We took the first step by adapting omnithread to our low-latency thread
> library (SCALE Threads) obtaining a 40 microsecond improvement in the two
> way latency. 

This is impressive! On which platform is this measured?

Regards,

Sai-Lai

-- 
Dr. Sai-Lai Lo                          |       Research Scientist
                                        |
E-mail:         S.Lo@orl.co.uk          |       Olivetti & Oracle Research Lab
                                        |       24a Trumpington Street
Tel:            +44 223 343000          |       Cambridge CB2 1QA
Fax:            +44 223 313542          |       ENGLAND