Help with Designing or Debugging CORBA Applications

What follows now is an example of using our new plugin to monitor some CORBA GIOP/IIOP traffic generated by JacORB and its examples. I assume you can run these examples already (i.e., already compiled and set Java's CLASSPATH etc correctly).

In a new xterm, start the JacORB nameserver:

ns public_html/NS_Ref &
[2] 1850
JacORB V 1.3.30, www.jacorb.org
       (C) Gerald Brose, FU Berlin, 13 June 2001
[ POA RootPOA - ready ]
[ POA NameServer-POA - ready ]

Next, start server for demo.grid example:

jaco demo.grid.Server & [3] 1890
JacORB V 1.3.30, www.jacorb.org
       (C) Gerald Brose, FU Berlin, 13 June 2001
[ POA RootPOA - ready ]
[ New connection to 127.0.0.1:1295 ]
[ Accepted connection from 127.0.0.1:1298 ]
[ Bound name: grid.example ]

The Ethereal Capture Summary window will show what type of traffic is being captured (e.g., UDP, TCP).

Run demo.grid client, as shown here:

[frank@cray frank]$ jaco demo.grid.Client
       JacORB V 1.3.30, www.jacorb.org
       (C) Gerald Brose, FU Berlin, 13 June 2001
[ New connection to 127.0.0.1:1295 ]
[ Accepted connection from 127.0.0.1:1327 ]
[ New connection to 127.0.0.1:1307 ]
[ Accepted connection from 127.0.0.1:1328 ]
[ New connection to 127.0.0.1:1307 ]
[ Accepted connection from 127.0.0.1:1329 ]
Height = 31
Width = 14
Old value at (30,13): 0.21
Setting (30,13) to 470.11
New value at (30,13): 470.11
MyException, reason: This is only a test exception,
no harm done :-)
[ Closing connection to 127.0.0.1:1307 ]
[ Closing connection to 127.0.0.1:1295 ]
done.
[ Closing connection to 127.0.0.1:1327 ]
[frank@cray frank]$ [ Closing connection to 127.0.0.1:1329 ]

Now, stop data collection in Ethereal. Press the stop button on the Capture window. Notice that you should have seen some traffic by now.

Back in the main Ethereal GUI you should see three window panes, as shown in Figure 4. The top pane is a summary of traffic, showing Frame number, Time, Source and Destination, then Protocol and Info fields. The middle pane will contain a tree-like structure with all the layers of protocols. When you click on a packet in the top pane, its structure should be shown graphically in the middle pane. The lower pane provides a raw hex dump and highlights which octet(s) are related to whichever field you click on in the middle pane. This is a great feature. To the right of the hex dump you will see an ASCII dump for whichever characters are printable.

Figure 4. Summary of Traffic, Layers of Protocols and a Raw Hex Dump

You may have quite a bit of traffic, only some of which is GIOP. In order to select only GIOP traffic, we can apply a Display Filter.

In the bottom left-hand corner type giop in the Filter entry box (see Figure 4), and press Enter on the keyboard. You should be looking at GIOP/IIOP traffic only.

Now it's time to see in more detail what type of data is present in the GIOP/IIOP traffic and to see the relationship between IDL definitions and how it is marshaled via CDR Transfer Syntax rules onto TCP/IP.

Let's take a look at IDL file that represents the demo.grid example. It should look something like this:

  1     // grid.idl
  2     // IDL definition of a 2-D grid:
  3
  4     module demo
  5     {
  6     module grid
  7     {
  8         interface MyServer
  9         {
 10             typedef fixed <5,2> fixedT;
 11
 12             readonly attribute short height;
 13             readonly attribute short width;
 14
 15
 16             void set(in short n, in short m, \
                     in fixedT value);
 17
 18             // return element [n,m] of the grid:
 19             fixedT get(in short n, in short m);
 20
 21             exception MyException
 22             {
 23                 string why;
 24             };
 25
 26             short opWithException() \
                   raises( MyException );
 27
 28         };
 29     };
 30     };

Let's quickly step through and make sure we understand it. Interface demo/grid/Myserver contains two attributes, "height" and "width"; and it contains three operations, set(..), get(..) and opWithException(..). Exception MyException contains one member, "why", which is a string.

We also see a typedef at line 10 that uses a "fixed" type. This means that, for example, the "in" parameter called "value" in line 16 could be a value like 123.45 or -987.65, i.e., five digits with two digits after the decimal point.

Now, let's take a look at some of these and see how they look on the wire.

Example one: remember this operation definition from line 19:

fixedT get(in short n, in short m);

If you look at Figure 4 you can see both of the "in" parameters, i.e., parameters "n" and "m" are of type "short", so each is two octets in length. The "n" parameter has value of 30, and if you look at the hex dump in the bottom pane you can see "00 1e", which is the hex value for 30.

Example two: using the same operation definition from example one, let's look at the return value for this operation. It is of type fixedT, which is a typedef of a fixed type. You can see the return value in Figure 5. It occupies three octets, in this case 47 01 1c. These three octets map onto a value of +470.11, which is shown highlighted in the middle pane.

Figure 5. Return Value (See Example Two)

Example three: if you remember the operation definition for opWithException(), you see that it can raise an exception. According to the IDL, this exception MyException contains one member, a string.

In Figure 6, you can see a GIOP reply message that contains this exception: a string, of length 48, with the text This is only a test exception, no harm done :-).

Figure 6. GIOP Reply Message

Example four: although from a different capture, I have included an example of an operation decoded according to a plugin generated from CosNaming.IDL (see Figure 7). Here you can see an IOR and its structure. IORs can be much larger than this.

Figure 7. Example of an Operation Decoded According to a Plugin Generated from CosNaming.IDL