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.
|Speed Up Your Web Site with Varnish||Jun 19, 2013|
|Non-Linux FOSS: libnotify, OS X Style||Jun 18, 2013|
|Containers—Not Virtual Machines—Are the Future Cloud||Jun 17, 2013|
|Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer||Jun 12, 2013|
|Weechat, Irssi's Little Brother||Jun 11, 2013|
|One Tail Just Isn't Enough||Jun 07, 2013|
- Speed Up Your Web Site with Varnish
- Containers—Not Virtual Machines—Are the Future Cloud
- Linux Systems Administrator
- Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer
- Senior Perl Developer
- Technical Support Rep
- Non-Linux FOSS: libnotify, OS X Style
- UX Designer
- RSS Feeds
- It is quiet helping
51 min 9 sec ago
1 hour 8 min ago
- Reachli - Amplifying your
2 hours 24 min ago
3 hours 13 min ago
- good point!
3 hours 16 min ago
- Varnish works!
3 hours 25 min ago
- Reply to comment | Linux Journal
3 hours 54 min ago
- Reply to comment | Linux Journal
6 hours 21 min ago
- Reply to comment | Linux Journal
10 hours 20 min ago
- Yeah, user namespaces are
11 hours 37 min ago
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?