April 2010

I'm still working low level API and build scripts. The 'core' library that future jnetpcap will be dependent on is named 'jnetsoft'. I used other names too like jnetcore, jnetlib, but jnetsoft is what it will be called from now on. No other projects named as such that I could find.

Since I'm redoing the build scripts, I wrote an ANT task called 'javani' which stands for Java Network Interface, kind of like JNI but its the name of the ANT task. Its job is to help manage JNI field and method IDs. It also generates wrapper C functions around methods in any java class. So you can give 'javani' a class files in ANT build script and it will generate the necessary wrapper C and header files containing all of the code, including JNI IDs for access java resources.

It works pretty well, but still needs some work. I plan on contributing that code to ANT project if they will have it. It takes over where existing 'javah' task leaves off.

Here is a is the output from a run against the new JMemory class which is the basis of all native memory managment:


Buildfile: C:\jnetstream\jnetsoft\build.xml
prep-build:
javac:
javah:
[javah] [Loaded C:\jnetstream\jnetsoft\build\classes\org\jnetsoft\nio\JMemory.class]
javani:
[javani] javafile=org.jnetsoft.nio.JMemory
[javani] destfile=build/c/nio_jmemory.c
[javani] destfile=build/include/nio_jmemory.h
BUILD SUCCESSFUL
Total time: 797 milliseconds


You can see that the 'javani' task, takes a javafile as input and generates a C and a header file.

Here is what is inside the C file:

#include 
#include "nio_jmemory.h"

nio_jmemory_class_t nio_jmemory_class;

/*
 * Class:     org.jnetsoft.nio.JMemory
 * Method:    onClassLoad
 * Signature: ()V
 */
JNIEXPORT void JNICALL Java_org_jnetsoft_nio_JMemory_onClassLoad
  (JNIEnv *env, jclass clazz) {

	nio_jmemory_class_t *c = &nio_jmemory_class;

	memset(c, sizeof(nio_jmemory_class_t), 0);

I have been avoiding external prerequisites with jnetpcap up until now, but I am considering including glib. Its a non issue on non-windows systems, as glib is typically available and easily attainable for those systems. Win32 isn't hard either but glib installation doesn't have win32 auto-install packaging.

None the less there is so much functionality I have been duplicating in glib that I think it makes sense to make it a prereq. GLib for win32 can easily be downloaded from here: http://www.gtk.org/download-windows.html. So its not a big issue, no one has to compile anything. I may also bundle in the runtime glib with the win32 package, but I don't think its really necessary. Glib doesn't have any other dependencies of it own, so it would just be the 1 library that is needed by jnetpcap modules.

There are lots of goodies in glib that will make protocol development at native level much easier. Especially with complex analyzers. Multi-threading utilities are also included, to provide native level RW locks and so forth. Here is a complete list of things glib provides:

http://library.gnome.org/devel/glib/stable/index.html

Also I think it would be good to start this precedent for the sake of other 3rd party libraries. For example, we probably will need to include gzip and encryption libraries as well for some protocols. I know java provides a some of this capability as well, but java's iostream/byte[] based approach doesn't work all that well with jnetpcap. Native libraries can be much more efficient when they have this data in native memory already. I think glib as always present in the core module will make all the other modules easier to write.

If anyone has any feedback, now would be a good time to comment.

I have been redesigning the entire API from grounds up, starting with build system and modules. A new standalone module is nearing completion called "jnetcore". I created a new domain, jNetSoft under which I am bundling all common, non project specific code. Even have a website up for it under http://jnetsoft.com.

The main module is the 'core' module which will contain only a couple of features utilized jnetpcap and other projects. The core module mainly consists of native libraries that are glue code to be utilized by other projects.

• exception management - result codes returned by native function, exceptions, logging and some debugging functionality
• native memory manager (NMM) - 3 tier library of memory management functions

The module is compiled 2 sets of shared and archive type libraries. There are 2 versions of the memory management library. One with JNI (java native interface) bindings included and one without. The library without the bindings is a pure C native library with only C runtime as requirement, suitable for use in any type of project. The java bindings library also contains additional API calls for binding to java. The way that the libraries are written, bindings for other languages can also be provided allowing the core libraries to be reused under variety of programing environments.

The exception-management libraries also come in JNI and non-JNI flavors. The java flavored library provides easy for converting native errors, debugging and logging into java exceptions, loggers, etc...

	char *b = (char *)jns_malloc(1024);
        /* 

Maintenance Window Notification

Date: April 10, 2010
Time: 10:00 PM CST – 1:00 AM CST April 11, 2010
Purpose: Backup Power Systems Testing & Network Equipment Upgrades