August 2009

Hi,

I'm currently using version 1.2 rc 5 in my project which doesn't provide the means to parse options in a TCP header, something I require. I'm unsure as to whether this has been addressed in more recent versions but would like to post my implementation anyway.

First there's a nice readable version...


import org.jnetpcap.protocol.tcpip.Tcp;

public class TcpOptionsVerbose implements TcpOptions
{
private static final int KIND_END = 0x00;
private static final int KIND_NOP = 0x01;
private static final int KIND_MSS = 0x02;
private static final int KIND_WINSCALE = 0x03;
private static final int KIND_SACK = 0x04;
private static final int KIND_TS = 0x08;

private static final int KIND_MSS_LENGTH = 4;
private static final int KIND_WINSCALE_LENGTH = 3;
private static final int KIND_SACK_LENGTH = 2;
private static final int KIND_TS_LENGTH = 10;

private static final int OPTION_HEADER_LENGTH = 2;
private static final int TCP_HEADER_LENGTH = 20;

private static final String BAD_FORMAT = "bad tcp option format";

private Tcp tcp = null;
//private ByteBuffer options = null;
private int offset = TCP_HEADER_LENGTH;

private boolean hasMss = false;
private boolean hasWinScale = false;
private boolean hasSack = false;
private boolean hasTs = false;

private int mss = 0;
private int winScale = 0;
private boolean sack = false;
private int tsVal = 0;
private int tsEcr = 0;

public TcpOptionsVerbose(Tcp tcp) throws Exception
{
int tcpSize = tcp.size();
this.tcp = tcp;

while(offset < tcpSize)
{
switch(tcp.getByte(offset))
{
case KIND_END:
return;

case KIND_NOP:
offset++;
break;

case KIND_MSS:
parseMss();
break;

case KIND_WINSCALE:
parseWinScale();
break;

case KIND_SACK:
parseSack();
break;

case KIND_TS:
parseTs();
break;

I've fixed the main memory leak, but I'm still seeing very slow-slow leak and I'm still investigating. I'm analyzing memory usage very carefully and I'm seeing a progressive slow leak. I think its actually due to memory thrashing, that is lots of small memory blocks allocated to hold copies of packet and quickly deallocated. This causes certain amount of overhead in allocation tables in the runtime library. At least that is what I think is I'm witnessing.

None the less I'm still working on it. I running long tests in different modes and carefully analyzing memory usage. The slow leak is about 200K per 1,000,000 packets processed. So its relatively very slow, none the less it could cause big problems for long running or never ending processes.

#10288 packets=741441 pps=17414.529312 bytes=4832Kb/s hdr=76649/s hdr=13us rm=26140Kb pm=36b vm=242812Kb
#10288 packets=734100 pps=17147.061572 bytes=4757Kb/s hdr=75472/s hdr=13us rm=26056Kb pm=36b vm=242812Kb
#10288 packets=734100 pps=17414.717465 bytes=4832Kb/s hdr=76650/s hdr=13us rm=26284Kb pm=36b vm=242812Kb
#10288 packets=734100 pps=17743.027022 bytes=4923Kb/s hdr=78095/s hdr=13us rm=26264Kb pm=36b vm=242812Kb
#10288 packets=734100 pps=17590.396089 bytes=4880Kb/s hdr=77423/s hdr=13us rm=26592Kb pm=37b vm=242812Kb
#10288 packets=734100 pps=17683.191213 bytes=4906Kb/s hdr=77832/s hdr=13us rm=26736Kb pm=37b vm=242812Kb
#10288 packets=734100 pps=17349.688032 bytes=4814Kb/s hdr=76364/s hdr=13us rm=26676Kb pm=37b vm=242812Kb
#10288 packets=734100 pps=17610.228854 bytes=4886Kb/s hdr=77510/s hdr=13us rm=26800Kb pm=37b vm=242812Kb

Memory counters: rm = Resident Memory, pm = per packet memory, vm = virtual memory. These are system process memory statistics, not java VM. I'm using a 3rd party library called SIGAR to access system process statistics.

Hi,

I'm currently using jNetPcap only for processing previously-captured PCAP files, using nextEx(). One of the things that we've been thinking about, in the future, is doing the same processing, but because of some of the things I'm doing in my code, I won't be able to move to using pcap.loop() or pcap.dispatch().

So, I was wondering, if anyone knows, what would the real-time capture performance be like with jNetPcap and using nextEx()?

Would it really be much less efficient/slower than using loop() or dispatch()?

Thanks,
Jim

I'm back from Europe.