Mark Bednarczyk's blog

1.3.b4 almost ready

The beta 4 release is nearly ready. The memory footprint of a running jNetPcap based application is much better.

Beta 4 does away with old way of finalizing objects using the common Object.finalize method, which gets called when object is no longer referenced and is about to be cleaned up. This was the place where certain native memory related jNetPcap objects, would perform their cleanup, releasing native resources. This approach has many issues which are discussed in this Sun/Oracle and several other articles.

1.3 Beta 4 performance

Latest beta 4 update being tested:

Test#Packets/sec (1000s)bits/s (Millions)PcapPacketGeneral ScanTcp-only ScanCopyPeerNotes
2100229noyesnoyesnoPcapPacket reused
4100229noyesnoyesnoExtra new Object(){};
81,290677nonoyesyesyescopy tcp payload only
91,0502,280nonoyesyesyescopy all packets

1.4 builds

I finally had time to take a look at 1.4 in the SVN trunk. It was broken and the fix turned out to be pretty simple. I'm synching it with the changes made in 1.3 to get that stable and will be releasing a dev build of it soon, that should be pretty stable.

1.4 also features something totally new. I have broken out the libpcap 1.0.0 functionality into a separate library and class called Pcap100. There is also a new java package: org.jnetpcap.compatibility that contains the Pcap100 and Pcap080 class. The 100 stands for libpcap version 1.0.0 and 080 stands for libpcap version 0.8.0. Those classes contain pcap API calls and nothing else, which makes them pretty portable because of lack of any other dependencies. As a matter of fact, we were able to take those 2 classes and apply then to get out of the box jnetpcap 1.3 installation and which gave it libpcap 1.0.0 functionality, without any modification.

Another words, those features are "backward" revision compatible. Pretty amazing and probably confusing.

Win64 for version 1.3

A little bit of status on Windows 64-bit build:

I am currently working to get 1.3 working on Windows 64 platform. A couple of things change immediately. The 'mingw' tool chain, which bring minimal-gnu-for-windows platform doesn't compile 64-bit code. I had to switch to 'mingw-w64' toolchain which is similar but maintained by a different team and is different. It compiles both 64 and 32-bit code.

There are also a few minor tweaks, that were needed to compile.

Lastly, the code compiles but core-dumps right away. So I still have some more work to do. I'm pretty sure I know where the problem lies (64-bit unsigned long to pointer conversion).

Hopefully its not anything more significant then this.

Results from long running "stresstest"

Just wanted to share some results from a long running stress test of jnetpcap version 1.3.b3 (beta 3).

Syndicate content