After careful review and a long design session about "Dissectors/containers" (analyzers are also part of this decision), I have made a decision that this feature can not be properly implemented using current memory model used in jNetPcap when managing natively allocated memory. This is something I will be working on, but only after 1.2.alpha is released. Therefore I am almost ready to freeze the feature set and get things ready for an official 1.2 release.

I say almost ready, because I'm working on an API change that needs to take place now rather then later. With the above mentioned memory enhancements to be implemented after 1.2 release, the bahavior for JPacketHandler and PcapPacketHandler will change as follows. Both handlers will provide a copy of the captured packet, not a direct reference to the original in the libpcap buffer. Currently the packet is delivered as a reference into the libpcap buffer and the user is required to make a copy of the packet in the handler. The new API for these handlers, will deliver an already copied packet into newly allocated memory block. For those users that are already dependent on the current "shared packet" behavior of these handlers, this change will require those users to remove the piece of code that copies the packet delivered to the handler. If the code is not removed, the only side effect will be that the packet contents will be copied twice with a bit of a performance hit, and nothing else.

The packet object delivered to the handler will also be newly instantiated and suitable for retaining a reference to. Currently the same packet object instance is used to deliver the shared libpcap packets. The packet object itself is also shared between each invocation of the handler callback method. With the API change, a new packet object instance will be allocated for every packet delivered.

For those users requiring the shared libpcap packet reference (i.e. when packets are processed immediately not requiring a copy out of the libpcap buffer), will still be able to utilize this powerful feature of jNetPcap using either JBufferHandler or ByteBufferHandler which are unchanged will deliver a reference to the shared buffer reference in a libpcap buffer.

The behavior and specification of JPacketHandler and PcapPacketHandler packet handlers, has been a source of great confusion among jNetPcap users. The new behavior is the behavior one would normally expect when dealing with packet objects. That is, you get a packet that you can do whatever you want with, which is not the case with current implementation (i.e. you can't put the shared packets on to a queue, or they might unxpectadly become corrupted with the next loop cycle, etc.)

This new API change is also being done with the anticipation of the memory management enhancements I mentioned at the top of this blog. The memory managment changes will focus on providing great flexibility in creating complex native data structures suitable for native code use. Currently only simple data structures are supported and those are mainly utilized by java code. The class JMemory which is responsible for memory management won't be affected by this. After careful review of JMemory class, I'm convicenced more then ever that it is one of the best approaches for managing direct memory allocation from java. Its very clean, simple in implementation and secure, having only 3 main properties (physical memory block address pointer, length of the memory block and a java reference to the owner of the memory block).

The new enhanced memory management will mainly expand on JMemoryPool class providing additional native methods for allocating memory for native code purposes and complex data structures.

In summary:

• Flexible header containers which are containers for dissected header information, will be implemented in the main development trunk and not released under 1.2.
• JPacketHandler and PcapPacketHandler handlers will have their API specification modified to provide already copied packets into unique packet object instances effective immediately and released under 1.2
• Memory enhancements will begin in main development trunk and not be part of 1.2 release.