[mico-devel] [NEWBIE] GIOP/IIOP Version Numbers
Alex Measday
c.a.measday at ieee.org
Fri May 10 21:30:58 PDT 2002
(I'm new to CORBA and MICO. I am modifying a legacy program
to talk to our new CORBA servers. Our CORBA development group
is using TAO on Solaris and Windows NT, but I wanted to try
something a bit lighter. So I am trying MICO under RedHat
Linux 7.2.)
How do I get my MICO-based client to use GIOP version 1.1 or 1.2?
MICO sends version 1.0 messages, even when I tell it to do
otherwise. This is a problem (I think!) because the server
returns wide strings in one message and MICO reports a
marshalling error. Which is the *CORRECT* response for
version 1.0 clients according to the CORBA spec, section
15.3.1.6: "If a server erroneously sends WCHAR data in a
GIOP 1.0 response, the client ORB shall raise a MARSHALL
exception ... with standard minor code 6." I assume they
meant to include WSTRING data.
(Some hand-crafted marshalling code I wrote correctly
decodes the message containing the wide strings, as do
the TAO-based clients of the CORBA development group.)
Thank you for any help - this stuff is complicated!
Alex Measday
c.a.measday at ieee.org
DETAILS
-------
I downloaded, built, and installed MICO 2.3.7. I run my client
as follows:
% configClient -ORBGIOPVersion 1.1 -ORBIIOPVersion 1.1
-ORBDebug All,Error=mico.dbg
corbaloc:iiop:v4dev2:9000/ConfigServer
The first 2 CORBA calls in the client are:
CORBA::ORB_var orb = CORBA::ORB_init (argc, argv, "mico-local-orb") ;
// a BOA_init() call here doesn't make any difference ...
CORBA::Object_var obj = orb->string_to_object (argv[1]) ;
Despite the presence of the command line options to change
the GIOP and/or the IIOP version number - I've tried all the
combinations - MICO sticks to version 1.0.
I added some debug printf()s to CORBA::ORB_init() in orb.cc
and to MICO::IIOPProxy::make_conn(addr,docreate,version) in
iop.cc. The printf()s show that MICO is picking up the
command line options, but make_conn() is not using them:
Output from ORB_init():
===== -ORBGIOPVersion = 1.1
===== -ORBIIOPVersion = 1.1
===== giop_ver = 0x0101
===== iiop_ver = 0x0101
followed by output from make_conn():
===== (make_conn) version = 0x0100 _giop_ver = 0x0101
which is output immediately before the following code in make_conn():
if (version == 0 || version > _giop_ver) {
version = _giop_ver;
}
Since "version" was passed in as 0x0100, MICO uses 0x0100
(i.e., version 1.0) instead of the command line-specified
version number. This make_conn() is called from the other
make_conn(obj), which does some magic with profiles to get
the version number of 1.0.
The MICO debug for the first request and response, calling
_is_a() on an Admin object, is below. The client and server
continue to use version 1.0 in subsequent messages. At one
point, my client requests an IOR from the server and then
calls a method of the indicated object. In response to
this call, the server returns the wide string data in a
version 1.0 message - and MICO chokes. (The iordump of
the IOR follows the MICO debug.)
----------------------------------------------------
(Server is big-endian SPARC)
----------------------------------------------------
IIOP: server listening on inet:0.0.0.0:1294 IIOP version 1.1
IIOP: making new GIOP 1.0 connection to inet:v4dev2:9000
GIOP: Codeset negotiation with inet:v4dev2.integ.com:9000 using GIOP version 1.0
GIOP: sending Request to inet:v4dev2.integ.com:9000 msgid is 1
Out Data 47 49 4f 50 01 00 01 00 52 00 00 00 00 00 00 00 GIOP....R.......
01 00 00 00 01 00 00 00 0c 00 00 00 43 6f 6e 66 ............Conf
69 67 53 65 72 76 65 72 06 00 00 00 5f 69 73 5f igServer...._is_
61 00 00 00 00 00 00 00 22 00 00 00 49 44 4c 3a a......."...IDL:
69 6e 74 65 67 2e 63 6f 6d 2f 45 70 6f 63 68 2f integ.com/Epoch/
41 64 6d 69 6e 2f 49 4f 52 3a 31 2e 30 00 Admin/IOR:1.0.
IIOP: incoming data from inet:v4dev2.integ.com:9000
In Data 47 49 4f 50 01 00 00 01 00 00 00 cc 00 00 00 00 GIOP.......Ì....
00 00 00 01 00 00 00 03 00 00 00 22 49 44 4c 3a ..........."IDL:
69 6e 74 65 67 2e 63 6f 6d 2f 45 70 6f 63 68 2f integ.com/Epoch/
41 64 6d 69 6e 2f 49 4f 52 3a 31 2e 30 00 00 00 Admin/IOR:1.0...
00 00 00 01 00 00 00 00 00 00 00 8c 00 01 02 0c ................
00 00 00 07 76 34 64 65 76 32 00 00 23 28 00 07 ....v4dev2..#(..
00 00 00 42 14 01 0f 00 4e 55 50 00 00 00 23 00 ...B....NUP...#.
00 00 00 00 00 00 01 00 45 70 6f 63 68 43 6f 6e ........EpochCon
66 69 67 50 65 72 73 69 73 74 65 6e 74 5f 50 4f figPersistent_PO
41 00 00 00 00 01 00 00 00 01 43 6f 6e 66 69 67 A.........Config
53 65 72 76 65 72 33 33 00 00 00 02 00 00 00 00 Server33........
00 00 00 08 00 00 00 00 54 41 4f 00 00 00 00 01 ........TAO.....
00 00 00 14 00 00 00 00 00 01 00 01 00 00 00 00 ................
00 01 01 09 00 00 00 00 ........
GIOP: incoming Reply from inet:v4dev2.integ.com:9000 for msgid 1 status is 3
...
... FINAL MESSAGE CONTAINING WSTRING DATA "t7sim1 at c" ...
...
IIOP: incoming data from inet:v4dev2.integ.com:9000
In Data 47 49 4f 50 01 00 00 01 00 00 1a af 00 00 00 00 GIOP.......¯....
00 00 00 04 00 00 00 00 00 00 00 08 00 00 00 10 ................
00 74 00 37 00 73 00 69 00 6d 00 31 00 40 00 63 .t.7.s.i.m.1. at .c
...
GIOP: incoming Reply from inet:v4dev2.integ.com:9000 for msgid 4 status is 0
GIOP: reply marshalling error for msgid 4
----------------------------------------------------
======================================================
IORDUMP of IOR for Server Object that returns WSTRINGs
======================================================
Repo Id: IDL:integ.com/Epoch/Config/StreamConfig:1.0
IIOP Profile
Version: 1.2
Address: inet:v4dev2:9000
Location: corbaloc::1.2 at v4dev2:9000/
%14%01%0f%00NUP%00%00%00%23%00%
00%00%00%00%00%00%01%00EpochCon
figPersistent%5fPOA%00%00%00%00
%00%00%00%00%01Shadoobie
Components: Unknown Component
Tag Id: 0
Tag: 00 00 00 00 54 41 4f 00 ....TAO.
Native Codesets:
normal: ISO 8859-1:1987; Latin Alphabet No. 1
wide: ISO/IEC 10646-1:1993; UTF-16, UCS Transformation Format 16-bit form
Key: 14 01 0f 00 4e 55 50 00 00 00 23 00 00 00 00 00 ....NUP...#.....
00 00 01 00 45 70 6f 63 68 43 6f 6e 66 69 67 50 ....EpochConfigP
65 72 73 69 73 74 65 6e 74 5f 50 4f 41 00 00 00 ersistent_POA...
00 00 00 00 00 01 53 68 61 64 6f 6f 62 69 65 ......Shadoobie
_______________________________________________
mico-devel mailing list
mico-devel at mico.org
http://www.mico.org/mailman/listinfo/mico-devel
More information about the Mico-devel
mailing list