[jacorb-developer] TAO 1.7 Compatibility Issue

Fri Jun 22 11:35:54 CEST 2012

Hi Johnny,

Thank you for your advise.

I did enable TAO's debug anf set it to level 10.

The debug basically provided me with the same information I obtained using the packet sniffer.

The only difference between the GIOP requests sent by a working binary C++ TAO-based sample and my Java JacORB-based application is the packet content.

++TAO++
GIOP message - HEXDUMP 288 bytes
47 49 4f 50 01 02 01 00  14 01 00 00 02 00 00 00   GIOP............
03 00 00 00 00 00 18 00  1b 00 00 00 14 01 0f 00   ................
52 53 54 52 32 e4 4f b9  40 0f 00 02 00 00 00 01   RSTR2.O. at .......
00 00 00 03 00 00 00 72  10 00 00 00 53 74 61 72   .......r....Star
74 53 74 61 74 69 73 74  69 63 73 00 00 00 00 00   tStatistics.....
01 00 03 00 6e 00 6f 00  72 00 74 00 65 00 6c 00   ....n.o.r.t.e.l.
00 00 a7 00 78 f6 12 00  41 00 91 7c b8 12 a7 00   ....x...A..|....
5d 00 91 7c 50 aa a7 00  58 a7 a7 00 50 a8 a7 00   ]..|P...X...P...
fc f5 12 00 76 02 00 00  00 00 a7 00 22 02 91 7c   ....v......."..|
0c f6 12 00 00 00 a7 00  22 02 91 7c 04 00 00 00   ........"..|....
78 01 a7 00 00 00 a7 00  00 00 00 00 e4 f5 12 00   x...............
e8 f5 12 00 30 f6 12 00  00 00 6e 00 6f 00 72 00   ....0.....n.o.r.
74 00 65 00 6c 00 00 00  00 00 a7 00 81 00 00 00   t.e.l...........
08 02 00 00 13 00 00 00  4c f8 12 00 20 e9 90 7c   ........L... ..|
ff 02 00 00 5c f8 12 00  48 a8 a7 00 46 10 91 7c   ....\...H...F..|
00 00 00 00 00 00 00 00  00 00 a7 00 08 04 00 00   ................
50 a8 a7 00 80 f6 12 00  78 01 a7 00 08 04 00 00   P.......x.......
00 00 01 00 41 00 00 00  bc f5 12 00 00 00 00 00   ....A...........
++JacORB++
GIOP message - HEXDUMP 288 bytes
47 49 4f 50 01 02 00 00  00 00 01 14 00 00 00 02   GIOP............
03 00 00 00 00 00 00 00  00 00 00 1b 14 01 0f 00   ................
52 53 54 52 32 e4 4f b9  40 0f 00 01 00 00 00 01   RSTR2.O. at .......
00 00 00 02 00 00 00 00  00 00 00 10 53 74 61 72   ............Star
74 53 74 61 74 69 73 74  69 63 73 00 00 00 00 00   tStatistics.....
00 01 00 03 00 6e 00 6f  00 72 00 74 00 65 00 6c   .....n.o.r.t.e.l
00 20 00 20 00 20 00 20  00 20 00 20 00 20 00 20   . . . . . . . . 
00 20 00 20 00 20 00 20  00 20 00 20 00 20 00 20   . . . . . . . . 
00 20 00 20 00 20 00 20  00 20 00 20 00 20 00 20   . . . . . . . . 
00 20 00 20 00 20 00 20  00 20 00 20 00 20 00 20   . . . . . . . . 
00 20 00 20 00 20 00 20  00 20 00 20 00 20 00 20   . . . . . . . . 
00 20 00 20 00 20 00 20  00 20 00 6e 00 6f 00 72   . . . . . .n.o.r
00 74 00 65 00 6c 00 20  00 20 00 20 00 20 00 20   .t.e.l. . . . . 
00 20 00 20 00 20 00 20  00 20 00 20 00 20 00 20   . . . . . . . . 
00 20 00 20 00 20 00 20  00 20 00 20 00 20 00 20   . . . . . . . . 
00 20 00 20 00 20 00 20  00 20 00 20 00 20 00 20   . . . . . . . . 
00 20 00 20 00 20 00 20  00 20 00 20 00 20 00 20   . . . . . . . . 
00 20 00 20 00 20 00 20  00 20 00 20 00 20 00 20   . . . . . . . .

As you may see the binary sample contains some rubish notably in the parameter list section and does not have the leading byte in it if compared to my application. The method I am calling is
void StartStatistics(in NI_Version clVersion, in NI_UserId userId) raises(OperationFailed);
where
struct NI_Version
{
 NTUINT16 major;
 NTUINT16 minor;
};
struct NI_UserId
{
 NTCHAR username[51];
 NTCHAR password[51];
};

If I need to connect to such a server am I better off trying to mock this "dirty" patameter list section by guesing the appropriate NI_UserId.username and NI_UserId.password array content?

Regards,
Vasyl

Hi,

Try to run the TAO side with -ORBDebugLevel 10 to see what it outputs.

Johnny

On 06/21/2012 11:15 AM, Vasya Tretyakov wrote:
> Hi Nick,
>
> Thank you for the reply.
>
> Unfortunately the developer of the TAO-based CORBA server component doe not provide the source code for the application, hence I cannot undate the implementation to the up-to-date release of TAO.
>
> Do you have any idea whether the extra byte in the parameter list section of the GIOP Request packet could be the possible cause of the exception I am getting?
>
> Regards,
> Vasyl
>
> ________________________________
>  From: Nick Cross <jacorb at goots.org>
> To: Vasya Tretyakov <vasyamn at yahoo.com>; Discussions concerning CORBA development with JacORB <jacorb-developer at lists.spline.inf.fu-berlin.de>
> Sent: Wednesday, June 20, 2012 2:56 PM
> Subject: Re: [jacorb-developer] TAO 1.7 Compatibility Issue
>
>
> Hi,
>
> JacORB has been tested for interoperability with TAO.
>
> TAO 1.7 is I think 3 years old now - the current version is ACE 6.x and
> TAO 2.x (http://download.dre.vanderbilt.edu/).
>
> Could you retest with the current versions of TAO and JacORB ?
>
> Regards
>
> Nick
>
>
>
> On 20/06/12 11:12, Vasya Tretyakov wrote:
>> Dear Members,
>>
>> I have a need to write an application that communicates with another
>> process on a different server. The developers of the software I would
>> like to connect to provide an IDL file to facilitate programming
>> language and server independent communication between the interacting
>> applications. The ORB of the server side is implemented in C++ using
>> The ACE ORB (TAO) version 1.7 (as the folder name on the server
>> suggests). I also have several binary pre-compiled sample client
>> applications that successfully communicate with the server and the
>> corresponding C++ source code.
>>
>> After facing many problems with the ORB implementation provided by
>> Oracle in JDK, I came across your wonderful project.
>>
>> At this time I managed to connect to the server's Naming Service,
>> receive IOR to the desired object and sucessfully execute a void
>> method on it. However when I try calling the method that requires
>> parameters I get an OperationFailed exception.
>>
>> Investigation of the possible problem causes lead me to WireShark
>> sniffer, which I used to capture GIOP packets. Here is what I can
>> conlude by comparing the packets sent/received during the sample C++
>> TAO based client applicaton and my Java JacORB based application: 1)
>> GIOP requests from Java client application have big-endian byte
>> order, while C++ client application uses little-endian byte order. 2)
>> Replies to Java and C++ client applications have little-endian byte
>> order (actually, this was a problem when using JDK's ORB since it
>> could not parse the replies while JacORB does the job). 3) GIOP
>> requests Java and C++ applications have a lot in common (there are
>> some minor differences), expect for the parameter list of the called
>> method. C++ client application contains the name of the method, four
>> zero bytes, and parameter list while Java client contains the name of
>> the method, four zero bytes, and parameter list with a preceeding
>> zero byte.
>>
>> I conlude that I am facing the following problems: 1) Incorrect byte
>> order in reply messages (though JacORB manages to cope with it). 2)
>> An extra zero byte in the parameter list in the Java JacORB based
>> client implementation.
>>
>> Since I am quite unexperience with CORBA I would really appreciate
>> your advice on whether the extra zero byte in the parameter list is
>> indeed the cuase of the exception being raised by the server. If so,
>> what is the best place to start looking at in order to fix the
>> problem.
>>
>> Thank you in advance.
>>
>> Vasyl _______________________________________________
>> jacorb-developer maillist  -
>> jacorb-developer at lists.spline.inf.fu-berlin.de
>> https://lists.spline.inf.fu-berlin.de/mailman/listinfo/jacorb-developer
> _______________________________________________
> jacorb-developer maillist  -  jacorb-developer at lists.spline.inf.fu-berlin.de
> https://lists.spline.inf.fu-berlin.de/mailman/listinfo/jacorb-developer
>
>
>

________________________________

From: Johnny Willemsen <jwillemsen at remedy.nl>
To: Vasya Tretyakov <vasyamn at yahoo.com>; Discussions concerning CORBA development with JacORB <jacorb-developer at lists.spline.inf.fu-berlin.de> 
Cc: Nick Cross <jacorb at goots.org> 
Sent: Thursday, June 21, 2012 12:21 PM
Subject: Re: [jacorb-developer] TAO 1.7 Compatibility Issue