AutoDiscovery Library Wiki
A tiny library to add auto discovery capability into your applications
Brought to you by:
alexgotev
Menu
▾
▴
Home
AutoDiscovery Library
If you want to learn how to use this library, I suggest you to read what I've written below and to follow the [Getting started] guide in which I show you how to use it in your own application. All the methods and fields are documented and you can find the full JavaDoc documentation here: http://www.gotev.net/docs/autodiscovery/1.0.1/.
Why another auto discovery library?
I know what you may think: "hey dude, there are many standard protocols that lets you do this, for example UPnP, Bonjour or SLP...why have you done this library?"
I've done this library first of all because I need it for a small Java application that I developed. I've read the docs of the aforementioned protocol implementations and for what I needed that was too much. I had to put in a lot of dependencies and handle many things to get my app up and running. I needed something small, written in pure Java and without any dependency. Since I haven't found anything that suited my needs, I decided to write it from scratch. After that I finished and completed the tests I thought that maybe somebody else in the world may need the same thing, and so I decided to share the source code as LGPLv3.
So, how does it work?
I assume that you have a little knowledge about networks and protocols.
First of all, the protocol works by sending and receiving UDP packets on a single port (that by default is 7447, but you can choose whatever you want).
When you start the autodiscovery, the library scans all your connected network interfaces finding the broadcast address of each interface. Then, an UDP packet containing what I called the "HELLO_BROADCAST" message, gets sent to each broadcast address. After that, the library creates a thread which is responsible of listening for incoming packets on the UDP port and managing them.
When a "HELLO_BROADCAST" is received, the sender of that message is registered in the list of the discovered peers and then a "HELLO_UNICAST" message is sent back to him to let him know who received his message, so he can also add us as a peer.
Periodically, when the autodiscovery is running, there's a task that sends "HELLO_BROADCAST" messages (you can configure how often to send them).
When you stop the autodiscovery, a "GOODBYE" message is sent to all the known peers to inform them that we're going offline.
The autodiscovery packets can also have additional data put in. In fact, I've implemented a Key-Value dictionary of strings that gets sent in each autodiscovery UDP packet. This way you can expose informations that you want other peers to know when they discover you on the network. For example, you may want to let the others know your username, your program version or your operating system name, vendor and version. You can easily build up a serverless chat or LAN file sharing application. The possibilities are endless and the only limit is your imagination.
Development tools used
The code of the library has been developed using NetBeans 7.1.2 (Downloadable from here: http://netbeans.org/downloads/7.1.2/index.html) with the following software quality plugins installed:
- PMD
- Checkstyle
- FindBugs
- Dependency Finder
To install those plugins, add the following repository URL in your NetBeans Plugin settings window (Tools > Plugins > Settings tab):
http://deadlock.netbeans.org/hudson/job/sqe/lastStableBuild/artifact/build/full-sqe-updatecenter/updates.xml
Then, click on the "Updates" tab and on "Reload catalog" and you'll be able to select and install them.
Personal notes on the software quality tools that I use
I try to follow as much as I can the coding style suggested by Checkstyle and PMD. In particular I strictly follow the 80 characters per line, because it forces you to not write too much complex code in a single statement, thus making the code more readable and maintainable. However if you scan the project, the two tools will show some issues. In my opinion, those that I haven't fixed are false positives, but I don't have the time to mess up with Checkstyle and PMD configurations to disable certain checks in certain situations. I prefer to leave all the checks activated and manually examine every warning that I get. E.g. Checkstyle complains about "DesignForExtensionCheck" and "JavadocMethodCheck" on the test suite class methods. In my opinion that doesn't make any sense, because no one is going to make a test suite by inheriting from another test suite in my project and the JavaDocs are useless on test methods because they are (or are supposed to be :D) self explaining.
