Re: Interoperability of Orbit2

[Michael Meeks <michael ximian com>]

Hi Munaut,

On Fri, 2003-03-07 at 08:50, Munaut Sylvain wrote:
> Michael Meeks wrote:
> 
> >	Can you re-build ORBit2 with --enable-debug; then export
> >ORBIT2_DEBUG=traces:giop, re-run the server, and post a link to the
> >output.
>
> Here is a link to the outpu :
> http://www.246tnt.com/s-orbit2_c-osx.log

	Thanks for that - most interesting.

> I'd like to use a Orbit2 server on a Linux machine with a MacOSX 
> client  using Objective C implementation of corba (ADORB). ADORB use
> IIOP 1.0 or  1.1.

	The data in your log is all GIOP 1.2 - [ bytes 5,6 of the header:
0x0000:   47 49 4f 50  01 02 00 00  00 00 00 40  XX XX XX XX |
                       ^^^^^ ]

> It works fine ( or almost, some times it just hangs ... ) with Orbit1.
> But not with Orbit2. Is'nt it backward compatible with IIOP 1.1 ?

	So the problem is with ORBit1 or ORBit2 ? I'm not that interested in
supporting ORBit1 really .

> The macosx apps connects to the server but the argument passing fails.
> For example, I have a 'long' argument and I always recive the same
> value 1074140992, It's always the same ( I can reboot client and
> server, it will always be ... ). And when I try to return a long, the
> client always  receive 0 ... Weird isn't it ?

	Very odd indeed. The on-the wire data is: 00 00 00 14:
[snip]
0x0040:   00 00 00 14  XX XX XX XX  XX XX XX XX  XX XX XX XX |  ...
p12562 : ([0x8050c30])->setValue (0x40064c20)[08050858] setValue called : 1074154528 
Outgoing IIOP data:
[snip]

	Of course - 1074154528 is 40064c20 hex; that may be some badly
endian-swapped something from the wire I suppose. The strange thing is
that setValue doesn't seem that different from 'replaceValue' - which
appears to demarshal 0a just fine. the Bigendianness [ bit 1 of byte 7
of the header ] is set correctly for a PPC machine I think.

> The server has some outputs : The IOR and each time a function is called, it prints stuff like :
> 
> [08050858] replaceValue called : 15 5
> 
> Where 08... is the object address, 15 is the old value, 5 the new one.
> 
> As I said, the OSX client receive always 0 and the value I receive for
> the setValue is not the one he sent ...

	It's very odd indeed. One would need to dig down further into the
de-marshalling code I think in order to work out quite why this is going
on. Can you try doing the same thing but using the 'octet' type instead
of long - and post another GIOP trace - it should be easier to unwind
any swapping problems from that.

	Thanks,

		Michael.

-- 
 mmeeks@gnu.org  <><, Pseudo Engineer, itinerant idiot