Here is a roadmap of future releases and features planned for jNetPcap.

+-> 2.X - volatile branch (Aug 2009) (Browse)
|   +-> new memory managment (in progress)
|
+-> 1.3  - stable code base
    +-> 1.3 alpha (Sept. 2009) (Download)(Browse)
|   +-> 1.3 beta (Dec. 2009)
|   +-> 1.3 final (Q1'10)
|
+-> 1.4 - add support for additional x32 and x64 platforms.
|
+-> 1.5 - add libpcap's API functions and change pre-req to libpcap 1.0.0.
|
+-> 2.0 - add support for native dissectors and analyzers (Q1 2010)

Wishlist

1. swing components
2. Fully functional graphical analyzer (comparable to wireshark)
3. Eclipse development module for jnetpcap
4. Support for nearly all public protocols

2.0 - native dissectors and analyzers

Analyzer feature is something that has been already introduces with jnetpcap starting with 1.2rc5, but it is still unsupported. The reason for this is that new memory management had to be developed first to properly allow analysis information to be generated and stored natively. Also all current analyzers are java based. The analyzer API is currently cumbersome and not flexible enough to handle interpretation and simulation of more complex protocols.

This is a feature that we expect will take a fair amount of time to properly design and develop. Due to the complexity that will be introduced with analyzer feature and the development effort involved (both time-wise, testing, design, evaluation and feedback) that it will be released as a new major release 2.0.

Will also start work on adding native "dissectors". Dissectors (a word borrowed from Wireshark project - many thanks to those folks), will add capabilities to natively dissect a header into its individual components. Further more, the dissected data will be attached to the
native header structures that already describe the contents of a packet. This new feature will utilize the new memory managment capabilities to allocate and attach additional data to existing structures. This in effect will allow dissected data to be shared among many java header objects without having to do any additional work. Dissectors will provide information for optional or irregular fields and sub-headers.

Currently, something called a "quick" scanner is used to scan the contents of an entire packet buffer and record information about each header that is discovered. Quick scanner does not process any data within the header boundaries, only at the packet level. The contents of the header are further decoded using a java object that is the java header definition. This decoding has to take place for each header every time it is bound/peered with a native header structure. Fortunately most headers don't have any or at least few irregular fields or sub-headers that have to discovered first.

Release 2.0 will add new capability that when requested, a protocol will be dissected either natively (if its a jnetpcap CORE protocol) or in java and that information will be stored along with the native header state. This will only need to be done once for each header within a packet. From that point on, any other header objects of the same type, when they are bound/peered with the native header that has already been dissected, the previously calculated detail about the contents of the header will be reused.

This should offer performance gains especially in places where multiple header objects have to be bound to same header over and over. This occurs, in the currently unsupported analyzer feature where multiple analyzers have to look at the same header over and over. The performance gain will not only be realized due to cached information, but also because it will be obtained by native dissectors, whereas currently dissection/decoding is done in java.

1.5 - libpcap 1.0.0 API support

Code based on 1.4 will integrate new libpcap 1.0.0 API functionality. The library will require minimum libpcap 1.0.0 support.

New functions to be added to jNetPcap-1.5 from libpcap 1.0.0 are as follows:

1.4 - addition platform support

Update 2009-12-07: Add "lazy scan" feature which will delay packet decoding until one of the packet's accessor methods is invoked, such as JPacket.getHeader which will trigger packet decode if it hasn't been done yet. This feature will allow packet decoding to be easily exported to another thread.

Also add new callback handler JPacketBufferHandler which will more efficiently dispatch a buffer full of packets to java instead of 1 packet at a time. Packets will be retrieved from the buffer in java. This will provide a very efficient mechanism for copying data out of libpcap buffers into user buffers and minimize entry into the java space and java object creation during capture. This new handler will provide another framework for multi threaded application building allowing efficient separation between capture/provider and consumer threads with virtually no java overhead in provider threads.

Add support for additional platforms and hardware architectures. The code base will be 1.3 based (no analyzer feature).

Will add x64 support for all existing and new platforms.

Excluding ia64 support, since this is still a major issue to address.

New platforms:

1. Open Solaris
2. Solaris
3. Darwin
4. FreeBSD

1.3 alpha frozen

This is the first stage of a production 1.3 release. At this stage all development on this release is frozen, no new features will be added. Only bug fixes and minor API adjustments will be allowed.

The alpha stage will be followed by beta stage, where no API adjustments will be allowed, only bug fixes.

The final stage will be when 1.3 becomes stable/production quality. There still may be additional bug fixes, if they are discovered. They will be released as 1.3 maintenance releases with numbering such as 1.3.1 and 1.3.2, etc..

2.X - Volatile branch (volatile memory managment)

This code will be integrated with 2.X releases starting in Q1'10.

This is an upgrade to previous memory managment for native parts of the library. jNetPcap uses custom memory managment that ties life-cycles of native memory objects (structures and C++ objects) with java objects. That allows native objects to allocated using normal C/C++ methods but release of those resources occurs automatically when their parent java objects (counter parts) are garbage collected by Java runtime.

The memory management allows other sophisticated features such as allowing java objects to access and read directly out native memory, peer native memory references between 2 separate java objects so that they share access to native memory without copies. It also allows the native objects to expand and contract in size allowing structures to grow in size when additional information needs to be added. This happens when protocol header description structures are created and later additional information needs to be attached to them such as when detailed header dissection occurs or when protocol analysis information is created.