jNetPcap 1.2 introduces several new features and small changes to to the existing jNetPcap API.
PcapUtils.getHardwareAddress(String):byte[] is provided.
sendqueue(int size) size parameter was ignored. Fixed.
PcapPacket(JPacket) constructor.Release 1.2 adds significant new features and capabilities to jNetPcap library.
jNetPcap 1.2 features powerful memory management between native and java land. One of the most important features this class provides is the ability to reference any JMemory based object to a new native memory location, like changing a memory pointer in C. This provides ability to change object state without having to allocate new objects, initialize them or copy their data around. This functinality is provided through various protected JMemory.peer methods. Only subclasses of JMemory expose these peering methods as public API. This ensures that only compatible JMemory based native structures are referenced to each other. JPacket and JScanner classes use the peering features heavily to point a JPacket and its JBuffer and JPacket.State classes to new packet state and buffer. This happens very quickly by changing a single field within JMemory and instantly the new packet and its state is accessible.
Memory is more coherently managed behind the scenes through a JMemory class. This class provides combined memory manager and C like memory pointer functionality. The JMemory object, a base class for everything that references native memory, keeps track of allocated memory, who the owner is, the size of memory block and access to that memory to prevent buffer overruns, even throws a java.nio.BufferOverrunException. Similar JMemory objects can be peered to each other similar to a two pointers of the same type referencing the same memory location. JMemory also provides raw data transfer capabilities when you need to move some bytes around.
Provides similar methods like its counter part java.lang.Number but from native memory. This little class is passed around whenever an int * is needed for example.
Base class for anything that references a C structure.
Like its counter part java.nio.ByteBuffer it provides many accessor methods for retrieving data from a large native memory block. The JBuffer class does not keep track of current position but only provides accessor methods that index into the buffer and retrieve values. Both signed and unsigned accessor methods are provides (unsigned use bigger java native types to represent unsigned variables).
This class is also the base class for JHeader class which is base class for all the org.jnetpcap.protocol protocols.
New org.jnetpcap.packet package adds a significant new feature which allows packet decoding. The package adds 2 new significant class JPacket and JHeader. JPacket contains a reference to packet data buffer and a separate reference to the decoded packet state. The user can utilize the JHeader class and its more specific subclasses to references the header state and read data out of the packet data buffer as if using a native structure, with the logic builtin.
As packets arrive from libpcap, before they are dispatched to the user, a JScanner class is used to scan the packet buffer contents and record information about the state of the packet. That information is then simply referenced by JPacket object as a single pointer and returned to the user. JScanner uses internal builtin algorithm for scanning the contents of the packet buffer to decoded the protocol headers contained within. That information is stored in its native structure then a JPacket object is peered with the appropriate state of the packet and the packet data buffer. No new JPacket objects need to be created since any JPacket object can be very efficiently reused. If the user requires a more permanent storage for a packet and its state, that information can be copied using any of JPacket.transferTo methods. Both packet state and packet data buffer can be stored in a contiguous block of memory and efficiently copied around. As a matter of fact for
Starting with 1.2.rc5, we also have fully protocol analysis, not just header decoding. Protocols come as a bundle of headers, analyzers, events, utility classes and protocol handler interfaces. The user can register special per protocol listeners (called protocol handlers) with a specific protocol analyzer and it will receive decoded protocol messages.
Currently, with release 1.2, jNetPcap officially supports 3 platforms Linux, Win32 and Debian. The unix extensions should also work on AIX, HP-UP, Ubuntu. The Unix extension will not work on Solaris systems, at least not for the purpose of acquiring network interface hardware addresses. Certainly IOCTL and sockets are supported on Solaris, but access to network interface information is provided though the DLPI API and currently no support is provided for that.