Major cleanup in 1.2.rc5

I've been cleaning up the API and moving few things around in the non-wrapper part of the API. Specifically the org.jnetpcap.packet.header package has been removed and all the headers moved into a new package org.jnetpcap.protocol and into protocol suite specific sub-package of that.

Here are few examples of the move that took place:

org.jnetpcap.packet.header.Ip4 -> org.jnetpcap.protocol.network.Ip4
org.jnetpcap.packet.header.Ip6 -> org.jnetpcap.protocol.network.Ip6
org.jnetpcap.packet.header.Tcp-> org.jnetpcap.protocol.tcpip.Tcp
org.jnetpcap.packet.header.Ethernet-> org.jnetpcap.protocol.lan.Ethernet

and etc... The reason for the move, it turns out that packet.header package was not the best place for these headers as it was very constrictive, over crowded and becoming very messy quickly. On top of that a lot of the protocols also have several other classes to go along with the header to make up the entire protocol. Tcp for example has numerous classes besides the Tcp header, such as TcpAnalyzer, TcpSequencer, TcpAssember, different type of Tcp specific events and exceptions.

The current protocol setup, groups the protocol header, analyzers, support classes, events, exceptions all under a common "protocol suite" package. The idea being that if 3rd party protocols are provided, as an additional jar file for example, they would be bundled under a company or protocol suite directory.

Lets say, that Sly Technologies releases additional protocols such as "voice over ip". This belongs in the "voip" protocol suite. The protocol is actually a collection of several headers, analyzers, assemblers so we can reconstruct the VoIp stream and listen to it. It would be supplied in a package such as com.slytechs.protocol.voip with all the necessary classes in there. If another company, lets say, Ace Software provided a similar protocol, its package would be something like this com.acesoftware.protocol.voip provided in its own separate jar file. The user would have a choice which companies protocol to include in the project, or potentially both.

This is basic stuff, but I think the package layout will standardize and make it easier for the user to find the protocol needed, while providing greatest amount of flexibility.

Lastly, these moves don't leave deprecated classes in the old locations. The classes were physically moved and the user will have to update their projects. It would have been a lot of messy "deprecated" classes around, and since jNetStream 1.2 is not production and all the new features were released with the caveat that the API could change at any time, I did a hard move of them.

I don't like moving things around without a transition, but decided to move it like this hopefully this one time only, while jNetPcap 1.2 is still in "alpha" stage. None of the libpcap wrapper API has been moved and stays they same. None of the header constructors or the way to use them has changed either. You will simply have to change your "import" statements to reflect new locations.

Some other standardized conventions in protocols you will find and need to use if you are going to write protocols yourself:

1) Analyzer - all analyzers for a given protocol need to be in the same package as the protocol header. The analyzer class name must be preceded by the name of the header as well. So for Tcp header, you would use TcpAnalyzer. Analyzers are used to analyze headers and maintain external protocol state. For example, TcpAnalyzer analyzes each tcp packet, builds tcp stream objects which it maintains, checks for various conditions, fires off events, etc...

2) Assembler - assembles data contained in multiple packets into a new buffer/packet/header depending on the protocol. ie. TcpAssembler reassembles portions of the tcp stream as requested by higher level protocols.

3) Sequencer - groups multiple packets/headers into a contiguous sequence of packets/headers. Very similar to Assembler does, but does not actually copy data into a new buffer, simply arranges and groups related packet that are part of the sequence. i.e. TcpSequencer groups tcp segments together and fires off events, then TcpAssembler, while listening to those events, reassembles the tcp segments in a new buffer.

Here is a link to rc5 javadocs:
http://jnetpcap.com/docs/javadoc/jnetpcap-1.2.rc5-javadoc/index.html