🚀 go-pugleaf

Don't do it.  How large is large in MB.  What is the size of the
object and how many.  
Can you change your design to allow a drill down. and break the data
up into pieces.  
Speaking from personal experience, the larger the result set the
poorer the performance and your end users will not like it.  
I don't think that corba was designed to send large amounts (in
Megabytes) of data across the wire.  There are other tools/available
for this.
Don Stacy

On 5 Sep 2001 21:58:38 -0700, ashwani_kalra@yahoo.com (Ashwani Kalra)
wrote:

>Hi,
>
>Can any body point me to the sample code, documents etc for uploading
>or sending large files on the server from a client.I am using
>Visibroker for java 4.5.
>
>TIA
>
>Ashwani

dspublic-REMOVE THIS AND HYPENS- <dspublic-remove_this_and_hypens-@houston.rr.com> writes:

> Don't do it.  How large is large in MB.  What is the size of the
> object and how many.  
> Can you change your design to allow a drill down. and break the data
> up into pieces.  

The best way to send a large amount of data via CORBA is to design
your data transfer IDL using an "iterator" pattern so that the
data is not passed as one enormous message.

> Speaking from personal experience, the larger the result set the
> poorer the performance and your end users will not like it.

Sending large amounts of data that is not (all) going to be used
is bad design.
  
> I don't think that corba was designed to send large amounts (in
> Megabytes) of data across the wire.  

On the contrary, CORBA can do this pretty well if you:

  1)  choose a decent ORB,
  2)  design your IDL correctly, and
  3)  avoid excessive data copying on the client and server sides.

> There are other tools/available
> for this.

True.  But CORBA can come within a few percent of these tools.
At least that's what the ORB vendors claim.

-- Steve

Hi,

CORBA Audio/Video Streaming Service could be of interest
in such a case.

Sincerely,
Andrey Nechypurenko.

"dspublic-REMOVE THIS AND HYPENS-"
<dspublic-remove_this_and_hypens-@houston.rr.com> wrote in message
news:pmmgptotkei1lcj4dv043htm70nc1jlv82@4ax.com...
> Don't do it.  How large is large in MB.  What is the size of the
> object and how many.
> Can you change your design to allow a drill down. and break the data
> up into pieces.
> Speaking from personal experience, the larger the result set the
> poorer the performance and your end users will not like it.
> I don't think that corba was designed to send large amounts (in
> Megabytes) of data across the wire.  There are other tools/available
> for this.
> Don Stacy
>
> On 5 Sep 2001 21:58:38 -0700, ashwani_kalra@yahoo.com (Ashwani Kalra)
> wrote:
>
> >Hi,
> >
> >Can any body point me to the sample code, documents etc for uploading
> >or sending large files on the server from a client.I am using
> >Visibroker for java 4.5.
> >
> >TIA
> >
> >Ashwani
>

Andrey Nechypurenko wrote:

> Hi,
>
> CORBA Audio/Video Streaming Service could be of interest
> in such a case.
>
> Sincerely,
> Andrey Nechypurenko.
>

No need to get that complicated (although, its a creative thought, since
multimedia is generally "fat" over the wire).  Just use a sequence of
octet's to send the data (assuming it's binary data).

I've benchmarked this, as opposed to raw sockets, and the overhead was much
less that I expected (especially on a good ORB implementation... like TAO
or OmniORB... except we're talking about Java, aren't we?).  But, even in
Java, it's not that bad.  Once the connection is made (which is the biggest
overhead) individual invocations take a very small penalty in the grand
scheme of things.

BTW, one trick that works for "many" orb implementations is to put the most
frequently called methods at the top of your idl file.  It has been my
experience that rather than doing a decent hashtable design, most idl
compilers do a method-name string comparision in a long string of
if..then.. else if... clauses.  This means whatever is at the top of your
idl file gets compared first, and will invoke faster on the server side.
(just to reduce the overhead a little).

Derek

Derek Viljoen wrote:
> Andrey Nechypurenko wrote:
> > CORBA Audio/Video Streaming Service could be of interest
> > in such a case.
> 
> No need to get that complicated (although, its a creative thought, since
> multimedia is generally "fat" over the wire).  Just use a sequence of
> octet's to send the data (assuming it's binary data).
> 
> I've benchmarked this, as opposed to raw sockets, and the overhead was much
> less that I expected (especially on a good ORB implementation... like TAO
> or OmniORB... except we're talking about Java, aren't we?).  But, even in
> Java, it's not that bad.  Once the connection is made (which is the biggest
> overhead) individual invocations take a very small penalty in the grand
> scheme of things.
> Derek

Hello!

For more information you can read:

http://www.cs.wustl.edu/~schmidt/PDF/av_chapter.pdf

Chapter 4.3 contains the throughput result.

You should also consult the FTAM/FTP spec (CosFileTransfer):

http://www.omg.org/cgi-bin/doc?dtc/2000-11-05

BR
Nick

Niclas Eklund <Niclas.Eklund@NoSpam.uab.ericsson.se> wrote in message news:<3B9E2C1B.10AE48AB@NoSpam.uab.ericsson.se>...
> Derek Viljoen wrote:
> > Andrey Nechypurenko wrote:
> > > CORBA Audio/Video Streaming Service could be of interest
> > > in such a case.
> > 
> > No need to get that complicated (although, its a creative thought, since
> > multimedia is generally "fat" over the wire).  Just use a sequence of
> > octet's to send the data (assuming it's binary data).
> > 
> > I've benchmarked this, as opposed to raw sockets, and the overhead was much
> > less that I expected (especially on a good ORB implementation... like TAO
> > or OmniORB... except we're talking about Java, aren't we?).  But, even in
> > Java, it's not that bad.  Once the connection is made (which is the biggest
> > overhead) individual invocations take a very small penalty in the grand
> > scheme of things.
> > Derek
> 
> Hello!
> 
> For more information you can read:
> 
> http://www.cs.wustl.edu/~schmidt/PDF/av_chapter.pdf
> 
> Chapter 4.3 contains the throughput result.
> 
> You should also consult the FTAM/FTP spec (CosFileTransfer):
> 
> http://www.omg.org/cgi-bin/doc?dtc/2000-11-05
> 
> BR
> Nick

Hi,
Thank you all for this useful ideas and pointers. I will consider all
suggestion before implementing this solution. I think sending data in
chunks will be better idea using iterators no matter which technique I
use.

Ashwani

In article <3B9E2C1B.10AE48AB@NoSpam.uab.ericsson.se>, Niclas Eklund wrote:
> Derek Viljoen wrote:
>> Andrey Nechypurenko wrote:
>> > CORBA Audio/Video Streaming Service could be of interest
>> > in such a case.
>> 
>> No need to get that complicated (although, its a creative thought, since
>> multimedia is generally "fat" over the wire).  Just use a sequence of
>> octet's to send the data (assuming it's binary data).
>> 
>> I've benchmarked this, as opposed to raw sockets, and the overhead was much
>> less that I expected (especially on a good ORB implementation... like TAO
>> or OmniORB... except we're talking about Java, aren't we?).  But, even in
>> Java, it's not that bad.  Once the connection is made (which is the biggest
>> overhead) individual invocations take a very small penalty in the grand
>> scheme of things.
>> Derek
> 
> Hello!
> 
> For more information you can read:
> 
> http://www.cs.wustl.edu/~schmidt/PDF/av_chapter.pdf
> 
> Chapter 4.3 contains the throughput result.
> 
> You should also consult the FTAM/FTP spec (CosFileTransfer):
> 
> http://www.omg.org/cgi-bin/doc?dtc/2000-11-05
>
Hi,

Some additional info about the ftam spec. Since that document was
published a number of serious issues were raised against it. 

A revised version of the spec [dtc/2001-08-04] will be available by
Sept. 17th.  This revision is part of the work of the FTAM
finalization task force.

The revised spec allows for octet transfer using iterators.

Cheers,

Ted

-- 
Ted McFadden 
mcfadden@dstc.edu.au +61 7 3365-4310 <http://www.dstc.edu.au>
CRC for Enterprise Distributed Systems Technology DSTC Pty Ltd
Level 7 GP South - The University of Queensland, Brisbane 4072 Australia

On Tue, 11 Sep 2001, Derek Viljoen wrote:

> BTW, one trick that works for "many" orb implementations is to put the most
> frequently called methods at the top of your idl file.  It has been my
> experience that rather than doing a decent hashtable design, most idl
> compilers do a method-name string comparision in a long string of
> if..then.. else if... clauses.  This means whatever is at the top of your
> idl file gets compared first, and will invoke faster on the server side.
> (just to reduce the overhead a little).

This doesn't strike me as all that practical advice. Even with a linear
search, you would need hundreds of operations in an interface before the
effects would become noticable.

							Cheers,

								Michi.
--
Michi Henning                             +61 7 3324 9633
Chief CORBA Scientist                     +61 4 1118 2700 (mobile)
IONA Technologies                         +61 7 3324 9799 (fax)
Total Business Integration                http://www.ooc.com.au/staff/michi