I have added the implicit "transferTo" type copy of the packet in both PcapPacketHandler and JPacketHandler. Now both of these handlers deliver a stand-alone packet with fully copied contents. All 3 packet components header, state and data are copied into a single buffer and the java JMemory objects peered to point at their respective offsets into this memory block. Exactly the same as if done with PcapPacket.transferTo methods except its done natively.

This almost obsoletes the PcapPacket(PcapPacket) constructor. I say almost, because there may still be legitimate reasons to make an extract copy of all this information. It is however not neccessary to make a copy anymore in order to get the packet out of the temporary libpcap ring-buffer or JScanner ring-state-buffer.

I think this is the more intuitive behavior of both of these handlers and that should not only clear up many questions I receive and lots of frustrating programming errors for users learning jNetPcap library, but it also positions these 2 handlers for the enhanced memory model that will be implemented after 1.2 release. The new memory model will enhance JMemoryPool class and allow complex native structures to be peered.

Any existing implementations of these 2 handlers that perform a copy of the packets, should simply remove the code block that does the memory copies either using "transferTo" method or PcapPacket() constructors. In eclipse you can select the contructors and transferTo methods and perform "references" search which will list all the areas of the code that utilize these methods, pin pointing potential code that may need to be disabled.

If the code is not disabled, it will only result in packet data being copied twice. This is undersirable but not fatal in most cases resulting in some waist of memory and CPU, but fully functional.

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.

Greetings,

I'm new here, i just started trying to use jnetpcap on monday. I've run into a bunch of problems and so far i haven't been able to get past them. i've tried to do some searches on the forums, and i've read over just about all of the userguide, however, to be honest, i find this site very difficult to understand. It is hard to find information and simple code examples/snippets, and it is hard to understand what should work, and with what version. I'm unclear what examples are supposed to only work with 1.2, 1.3 or how jnetstream relates to all of this as well. I want to find the answer myself without having to bother anyone, but alas i need to post here.

I have a tcpdump file that i want to analyze and re-create the tcp stream a user application would receive from a tcp socket. I also then want to, for each byte of that stream, find the associated packet that byte was delivered in. I want to use this to do some performance analysis.

What i've tried so far:

* I first tried to apply the Mac OS X patch from Mardy but it had issues (not sure if it was for 1.2 or 1.3, and i tried 1.3, which might have been my problem). I then tried to re-create the changes by hand, but then i had a lot of compiler errors (i think related to lack of JAVA_HOME and proper pcap headers being available, but i could not find any help/docs on how to build and what the requirements are). I gave up on this, however i would really like to see a supported OS X distribution in the future

The most important function of the scanner is to perform a quick scan of the packet buffer and record information about what headers are found and at what location within the buffer. This information is then associated with a java packet or more specifically JPacket<code> and <code>JPacket.State classes. The first provides access to packet data buffer and the second to scanner state structures for packet. There is also a JHeader.State class which provides access to each individual's header's state. JHeader itself is peered (linked) with native memory location that is the packet buffer, but specifically at offset into the buffer that points to the start of the each header.