jNetStream

Fixes a number of issues and provides SequencedInputStream for reassembling TCP streams and IP fragments.

Available on the Daily build page (accessible at the top of the front page.)

[Available Here]

I realize that I have not been releasing jNetStream with updates often enough. This is something I want to change. The issue is that given a full blown official release number and designation carries certain amount of prudence, which usually means delays. Therefore I'm going to create daily builds that will encompass a snapshot of the work, without all the hassles of a full blown release. Since SourceForge does not allow automation of file releases, I'm going to post them to the webserver and allow downloads.

I've built version 3a2 and I'm currently testing it. Should release it by tomorrow.

Fixes several bugs including the packet.getData() one. Also added a new class to CommonUtils for reconstructing streams from packets. Its called SequencedInputStream.

Here is a piece of code that uses it.

package org.jnetstream.userexamples;

import java.io.IOException;
import java.nio.ByteBuffer;

import junit.framework.TestCase;

import org.jnetstream.capture.Captures;
import org.jnetstream.packet.Packet;
import org.jnetstream.protocol.codec.CodecCreateException;
import org.jnetstream.protocol.lan.Ethernet2;

I've secured a dedicated server to host jnetstream website. The website will be moving to http://www.jnetstream.org (also .com and .net) within next 2 weeks. The old website address will redirect to the new website once everything is up and running. The main SF project page website address will be updated to point to new address.

The dedicated server will improve user experience tremendously. I will also enable account creation on the website and a user forum. I will close the sf.net forums as they are very cumbersome, hard to reply to and quote code.

The sister project http://jnetpcap.

Added a new feature #1909897 to the API. A super FasterIterator has been added. The iterator bypasses some of the higher level functionality of even the RawIterator and allows the user to iterate over raw buffers. The FastIterator does however take care of the complex details of how to aquire the buffers to return to the user, no matter what condition the file is in or how large it is.

Here is an example of a super fast packet counter that pretty much runs at the maximum speed allowed by the physical disk IO:

		int count = 0;

		try {
			FastIterator fast = Captures.openFile(superlarge).getFastIterator();

Working with packet objects in jNetStream is nice. jNetStream takes care of all of the details of acquiring and decoding a packet so you can use high level API to check if a particular header type exists and then work with a header object to access its content. These are all high level entities that make jNetStream powerful. But that is only scratching the surface of what can be done.

What if you need to build a real time or nearly real time analyzer of data coming in from live or offline captures. jNetStream can deliver raw packet buffers at a very fast speed (millions/second). The performance when working with packet objects drops down to somewhere around 70,000/sec on a typical machine. In V2 jNetStream decoded packets at around 700/sec, so this is a major improvement none the less. Wouldn't it be nice to bypass all of the high level api and work with something faster? I'm sure it would for advanced users and jNetStream has the answer.

Some people have been asking about the status of the NPL compiler which was not part of the recent alpha 1 release. The few protocols that were included with alpha 1, were hand written. The hand written java files are what the NPL compiler will generate automatically as part of compiling the NPL definitions, once the NPL compiler is finished.

The NPL compiler is in a separate module called 'NplLanguageModule' in SVN repository. The compiler currently parses the v3 NPL syntax which is enhanced and cleaned up. The compiler builds a AST tree and performs various transformations for it. So now I'm working on the last step to getting the right transformations working correctly and using ANTLR string-templates to emit java code that is then javac compiled to class files. I'm hoping to have NPL compiler released with alpha 2 or alpha 3 at the latest.