Help with Designing or Debugging CORBA Applications
So, with all these rules, how can we decode GIOP/IIOP messages? Let's add a GIOP API to Ethereal that understands these rules.
Tap tap tap (and some time later...) packet-giop.[ch] from the Ethereal distribution was upgraded to provide an API, with accessors like
gint16 get_CDR_short(tvbuff_t *tvb, int *offset, gboolean stream_is_big_endian, int boundary);
gint32 get_CDR_long(tvbuff_t *tvb, int *offset, gboolean stream_is_big_endian, int boundary);
where tvb is a ptr to a tvbuff_t type containing octets (in a buffer), offset is a ptr to an offset with the tvb, stream_is_big_endian is endianess to use for extracting data types (big endian or little endian) and boundary is alignment to use for extracting data from the tvb.
You can see that get_CDR_short() returns a gint16, and get_CDR_long() returns a gint32. These types are defined as part of the glib library (see Resources) and are used extensively throughout the Ethereal source. These data types are then added to the Ethereal GUI as an item attached to a tree or subtree.
There are, however, some OMG IDL types that are quite complex and handled slightly differently. One example of a complex type would be Object Reference:
/* * Decode an Object Reference and display it * on the tree. */ void get_CDR_object(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree, int *offset, gboolean stream_is_big_endian, int boundary);
An object reference in CORBA can be represented as an IOR (Interoperable Object Reference) when being passed over GIOP/IIOP. These types can be rather large, as shown in Figure 7. For this case, the get_CDR_object() accessor simply will add the decoded data inside an IOR, directly to the tree, rather than trying to pass some complex data structure back to the user.
Now Ethereal has functionality to pull OMG IDL defined data types from GIOP/IIOP messages. You could build a plugin manually using this new API, but wouldn't it be fun to generate one automagically from your own IDL files?
Tap tap tap (and several weeks later)...enter idl2eth, an OMG IDL to Ethereal plugin generator.
idl2eth is a compiler back end to omniidl that I wrote (in Python) to automate the process of generating an Ethereal plugin based on the user's OMG IDL file(s).
So now that we can generate a plugin from an OMG IDL file, let's do it (after all, that's what this article is about).
I develop and run all examples on a Red Hat 7.1 with the 2.4.3-12 kernel, but most recent Linux distributions should have the required tools already installed. The only extras may be the latest Ethereal src tree (download nightly CVS tarball), omniOrb, J2SE v1.3 and JacORB or similar to test the examples. I assume you are capable of compiling and running the JacORB examples. Please ensure you can compile and run the JacORB examples before proceeding any further.
The steps for creating your new plugin are pretty simple, so let's work though them. For the purpose of this example, because the OMG IDL file for our example is called server.idl, we will use "server" as the plugin name also, to be consistent.
First you should see that you can build Ethereal before adding your own plugin. Unpack a recent Ethereal nightly CVS snapshot tarball:
tar -zxvf ethereal-2001-09-17.tar.gz cd ethereal-2001-09-17
Next, run ./autogen.sh. Compile the source tree with make and install Ethereal. This will install Ethereal and other helper programs. It also will install man pages and plugins. Make sure you are root when you do make install.
You now should have Ethereal successfully installed on your system. So, let's build a GIOP plugin. First, generate plugin source code from a JacORB example and store the output in Ethereal's plugin/giop/ directory:
idl2eth ~/JacORB1_3_30/demo/grid/server.idl > plugin/giop/packet-server.c
Next, add packet-server.c to plugin/giop/Makefile.am. This is mainly a cut-and-paste exercise that should take about one minute to do. Just look at what the other GIOP plugin entries for cosnaming and coseventcomm look like:
Add server.la to plugin_LTLIBRARIES.
Add server_la_SOURCES entry.
Add server_la_LDFLAGS entry.
Add server to CLEANFILES.
Add packet-server-static.o entry.
Then add packet-server.c to plugin/giop/Makefile.nmake. This too is mainly a cut-and-paste exercise similar to the previous step:
Add packet-server.obj to OBJECTS.
Add entry for server.dll.
Add server entry to clean: target.
Run ./autogen.sh again to include our changes. Compile the source tree with make. You should see your new plugin being compiled as a shared library. This part will be quicker, as we are not rebuilding the entire Ethereal binary this time. Install the new Ethereal build containing your plugin. Make sure you are root when you do make install.
That's it. Now you can fire up Ethereal and check some CORBA logfiles containing the IDL operations logged when running the JacORB demo/grid example. You can decode existing capture files as a normal user. Or if you have root privileges, run Ethereal as root to capture live data from a network interface. In my case I selected "lo" (loopback) net device, as I was running JacORB examples entirely on my local machine:
You should be presented with a window that looks something like that shown in Figure 1.
Select Capture from the main menu and then Start to bring up the Capture Preferences window. The Interface option is a drop-down selection list. Go ahead and select lo if you run Ethereal, JacORB nameserver and its examples all on the same host. You also can disable "Capture packets in promiscuous mode".
To see if your new plugin is available, try one or both of the following:
Select Edit and then Protocols. You should see giop-server is present (Figure 2) and that it can be toggled on or off. By default, it is on.
Select Tools and then Plugins. This should list the available plugins that Ethereal is using. It should look like the list in Figure 3.
|Nativ Disc||Sep 23, 2016|
|Android Browser Security--What You Haven't Been Told||Sep 22, 2016|
|The Many Paths to a Solution||Sep 21, 2016|
|Synopsys' Coverity||Sep 20, 2016|
|Naztech's Roadstar 5 Car Charger||Sep 16, 2016|
|RPi-Powered pi-topCEED Makes the Case as a Low-Cost Modular Learning Desktop||Sep 15, 2016|
- Android Browser Security--What You Haven't Been Told
- Nativ Disc
- The Many Paths to a Solution
- Recovery of RAID and LVM2 Volumes
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- Naztech's Roadstar 5 Car Charger
- Securing the Programmer
- Synopsys' Coverity
- RPi-Powered pi-topCEED Makes the Case as a Low-Cost Modular Learning Desktop
- Identity: Our Last Stand
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide