[omniORB] Using CORBA for data transfer?

[Matej Kenda]

Thank you very much, Bruce.


I made a simple IDL to try this:

typedef sequence<octet> DataBuffer_t;

interface IVD {
    void write(in DataBuffer_t a_buf);
    DataBuffer_t read();
};


I ran some simple tests and the performance using simple client/servant data
transfer is quite OK. However, they consume 100% CPU when running on the
same computer (Linux 2.4.4, PIII 800).

I have browsed omniORB-list resources and found out that network interface
is used (lo) even when running on the same computer.

What about marshalling in this particular example?

I guess that it shouldn't be performed when using octets. Is it performed
anyway?

I agree with Stefan Seefeld (seefeld@sympatico.ca) that co-located
client/servant should be heavily optimised. (discussion: Server & client on
the same machine: no network used ?)


Matej


-----Original Message-----
From: Bruce Fountain [mailto:B_Fountain@motherwell.com.au]
Sent: Tuesday, June 12, 2001 11:03 AM
To: Matej Kenda; omniORB-list (E-mail)
Subject: RE: [omniORB] Using CORBA for data transfer?


Matej Kenda [mailto:matej.kenda@hermes.si] wrote:
> One of the crucial parts of our application is data transfer 
> between two of
> our objects. Data consists of files, enriched with some 
> additional meta-data
> and is generated by the object A and written to disk as-is by object B
> (ftp-like). Data is packaged in data blocks, which size is defined at
> run-time.

You would normally use a sequence, since you have variable-length blocks:

   // IDL
   typedef sequence<char> dataBlock;

You don't need a size parameter anymore because the sequence knows its
own length (this is pretty much equivalent to std::vector<char>).

If your data is actually binary you would probably use sequence<octet>
instead of sequence<char>. This should be sufficiently efficient for most
purposes, but applications like streaming video often push the limits of
the ORB implementation.

Bruce Fountain
b_fountain@motherwell.com.au