Re: omniORB transfer sizes.

On Fri, 2023-02-17 at 18:37 +0000, FAYOLLE Eric via omniORB-list wrote:



[...]
> It seems that when using a char sequence, because the sequence length
> mapping is of type CORBA:ULong the sequence size is limited by the
> 32bit type (uint C on my machine). Is the length of a sequence always
> limited by a 32bit count? I imagine it is indirectly constrained by
> the normalized CORBA mapping. 

Yes. In GIOP (the standard CORBA protocol) all the length fields are 32
bits. You cannot send a sequence with more than 2^32 members.

> Unless I'm mistaken (and it's quite possible), it seems that when
> using a double sequence, the limitation no longer comes from the size
> of the sequence but from the size of the underlying buffer, which
> also seems to be limited to 32 bits but signed. Indeed, I can
> transmit 256*1024*1024-1 double (8*256*1024*1024-1 == 0x7fffffff (MAX
> SIGN INT )) but not one more than that.

This is a limitation in omniORB. In some circumstances it internally
uses some methods that use an int (which is signed 32 bit) that
represents the number of bytes in the data to send. The CORBA protocol
allows a sequence<double> to have 2^32 members, but as you have seen,
omniORB's marshalling code limits it to 2^31-1 bytes, with 8 bytes per
double value.

That is something that could be changed in omniORB, but it is
exceptionally rare to send such large messages in a single call. To
send such large data, both sender and receiver must store the complete
contents in memory, and the call blocks while all that data is
transferred across the network. If you have such a large amount of data
to send with CORBA, the usual design is to split the data into smaller
chunks, and send them with separate calls.

What is your use case here?  Are you just experimenting, or do you have
a real need to send such large values in a single call?

Duncan.

-- 
 -- Duncan Grisby --
  -- [email protected] --
   -- http://www.grisby.org --