Released rc3 today. There were still minor things I didn't get a chance to do before the release, but after fixing that major memory leak, I couldn't delay the release any longer. Better release more frequently with updates.
The rc3 adds major support for custom headers. Annotations, JRegistry and behind the scenes JHeaderScanner and JScanner are working very well so far.
I think once I get all the feedback on rc3 and if there are no more major bugs or API issues, I plan on finanalizing rc3 and releasing it as the official production 1.2 release. If there are any bugs or significant API updates we'll have 1.2.rc4, but I'm hoping to avoid it now that code is starting to stabilize and as far as I can tell the API is functioning very well both from performance and ease of use perspective.
I renamed the annotation @FieldRuntime to @Dynamic and also moved FieldRuntime.FieldFunction and renamed it to Field.Property. Property is an enum table and now dynamic properties are annotated in a way that is actually meaningful in itself. Here is what I mean:
@Dynamic(Field.Property.DESCRIPTION)
public String fieldADescription() {
return "My Description";
}
Before it would have said:
@FieldRuntime(FieldFunction.DESCRIPTION)
The new way is much more verbose and right to the point.
I tackled the Http and Html protocol headers as they are text based and stress different portions of the protocol development API. Glad I did as that highlighted some deficiencies in JBuffer. JBuffer didn't have any meaningful support for strings that may be contained in the buffer. Added a number of string related methods that now allows scanning for string patterns and string extractions from the buffer.
Now that we are dealing with application layer protocols such as Http, another deficiency comes to light. Need for stateful packet and tcp segment reassembly. It is impossible to reconstruct or decode certain headers without having something keep track of segments and some state. This is something I want to address in release 1.3, not 1.2.
Another issue that raises itself is the sheer volume of header java code. The single directory approach is going to very quickly be too crowded. I'm adding a new source directory "protocols/java" that will host packages for protocols. I'm creating base packages using general protocol suites. Here are the few I will be working on:
org.jnetpcap.protocol.lan - ethernet, ieee stuff org.jnetpcap.protocol.network - IP, icmp, arp, etc... org.jnetpcap.protocol.tcpip - tcp/udp, http, sip, etc...
I will also be adding a new package org.jnetpcap.packet.state which will have some baseclasses and interfaces that are general and related to protocol state. I will be creating a comprehensive packet fragment, tcp segment reassembly buffer (a little more advanced then the IpFramgmentReassemblyExample class) to do most of the work.
The stateful analyzers and reassemblers will be in seperate classes from the stateless protocol headers.
Like I said all these packages targetted for the for 1.3 release, although the packages may start to appear in the final 1.2 release.