jNetPcap project is broken up into 2 modules. The main module is called "jnetpcap" and the second is "protocols". When releases the protocols module is named as "jnetpcap-protocols" for package naming.
To access both packages in SVN you can checkout the latest code anonymously from the SVN server as follows:
svn co https://jnetpcap.svn.sourceforge.net/svnroot/jnetpcap jnetpcap/trunk
svn co https://jnetpcap.svn.sourceforge.net/svnroot/jnetpcap protocols/trunk
Major feature set in the development trunk currently:
- protocol analyzer - high level protocol based analysis
Here is a list of recent updates and changes to jNetPcap trunk:
- Feature #2706792 (done) - Added convenience JAnalyze interface and implemented it in Pcap class. This method allows easy packet capture, decode and analysis directly from the Pcap class - see blog for more details
Here is what I know I still have to do:
- Analyzer timestamp based buffering. Currently analyzer buffering is done using a global hold reference counter. Need a more fine granular holding mechanism that is timestamp based. So that as holds are released any packets that are older then the oldest hold are released upto the point that another hold exists at some other future time. This should improve performance and memory usage.
- Improve analyzer registration. Currently analyzers are listed within the
JRegistry initializer. Need to add annotation to headers that allows a list of analyzer's that belong to that protocol to be specified. Such as analyzer={HttpAnalyzer.class}.
- DONE Tcp and Http analyzer still needs more work. Currently not working under various conditions.
- Currently analyzer's have to be used manually - 1) retrieve from registry 2) pass it into the Pcap.loop methods 3) register your callbacks. Need a more simplified way of using analyzers such as a special Pcap.loop method that will automatically enable analysis.
- Protocol trailers. Add support for packet trailing bytes. That is any header within a packet always has dataat the front of the packet, but some protocols also have data at the end. For example Ethernet frame has frame CRC at the end of the packet (on some systems). Therefore how you calculate payload for any given protocol within the packet needs to take into account a possible trailer at the end. There may be more then one trailer at the end, for each header that has trailers within the packet.
- finish off javadocs in all the classes and public members.
