October updates

Before we begin, I tried an iPhone blogger app and it deleted the contents of the last post (September updates) as well as all the titles from all of the previous posts. Sorry about that, I couldn't get the full text of the Sept. update version back.

Domain and package names

I was unable to acquire the org.jnet.* domain name. So the project was refactored back to org.jnetpcap.* domain, which Sly Technologies owns. It never have been under the org.jnet domain in the first place, but this was a unpublished what if scenerio. Everything is back to normal.

Maven pom.xml groupId is set to 'org.jnetpcap' and artivactId 'jnetpcap'. It will be published under these settings to maven2 repository.

Initial version is slated to be 'jnetpcap-2.0.0-preview.1'. It will continue to be released as previews, until the foreign function features become permanent in java. This should hopefully be in Java 20 or in Java 21 LTS at the latest.

API Progress

The API implementation is complete and going through testing. All of the libpcap native functions have a jNetPcap counter part through libpcap version 1.10.

Unix and Linux

Unix and Linux specific calls get their own Pcap subclass. You can use OS specific factories like so 'UnixPcap pcap = UnixPcap.openOffline()' or 'LinuxPcap pcap = LinuxPcap.openOffline()'.

On Windows

Two Microsoft Windows specific Pcap subclasses are provide, WinPcap and Npcap classes. Just like before, we use a factory method to create the platform specific instance such as 'WinPcap pcap = WinPcap.openOffline()' or 'Npcap pcap = Npcap.openOffline()' to have access to window's specific function calls such as WinPcap.sendQueueTransmit(), Npcap.sendQueueTransmit(), WinPcap.wsockinit() etc...

Fine grade versioning

For fine grade control of the version of Pcap class used, you can use the the versioned subclasses which provide all of the implementations up to that particular version. For example 'Pcap0_9 pcap = Pcap0_9.openOffline()' will instantiate Pcap0_9 class and not force initialization and loading of native function symbols for any higher version libpcap library.

The version management in jNetPcap is extensive and thoroughly designed. Each Pcap subclass provides a static method isSupported() to allow checks at runtime and adaptation to runtime libpcap version. For example Pcap1_5.isSupported(),  Npcap.isSupported(), Linux.isSupported(), etc...

Lastly Javadocs

I have spent a lot of time on javadocs, writing and carrying over descriptions form libpcap man pages where appropriate. The documentation part is pretty thorough for those not familiar with libpcap usage or its intricacies. For those well familiar with libpcap API, jNetPcap API will be a breeze as native API call names are preserved  and only modified to adapt to java naming conversions for the most part, with some minor exceptions.

Lastly, I'm working on upload to github and publishing to maven2 repository right now.

- Mark...

Comments

Post a Comment

Popular posts from this blog

jnetpcap-2.0.0-preview.1 imported to github

 The initial preview version of jNetPcap v2 has been pushed to github from our private repository. This is a preview release, until java make the Foreign Function preview feature permanent. Here is a link to the github repo: https://github.com/slytechs-repos Alpha.1 version: This initial version has been tested with the main libpcap API calls. There is an extensive unit test files in the src/test/java directory. However, due to expediency, Windows WinPcap and Npcap have not been well tested yet, but should work. Also please check out the Wikipages on github as well. They've been updated with getting started and concept pages to get you going. Version 2 is much easier to setup than version 1 was, since there is no JNI libraries you have to compile. Maven artifact: I am still working on Maven repository setup. Its a bit more complex and requires various approvals, etc. But it will get there. Initial release will be jnetpcap-2.0.0-alpha.1
Read more

August update

A rewrite of the BinaryLayout and BitField implementation to be able to handle very complex binary structures, even more so than just c-structures. The junit source test and others now pass successfully. Here is the output and source code for a mock-up Ip4 header. Note : that both BinaryLayout and BitField references should normally be declared in a static context and only defined once. For testing purposes here, each test case instantiates a new BitField which is discarded afterwards. (Beautified with: hilite.me ) 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118...
Read more